From 0069f838c72b32dcdf0bb85f5dd341408bbcd5bf Mon Sep 17 00:00:00 2001 From: Witold Date: Tue, 17 Jan 2023 16:18:15 +0100 Subject: [PATCH 0001/1171] 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 0002/1171] 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 0003/1171] 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 0004/1171] 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 0005/1171] 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 0006/1171] 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 0007/1171] 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 0008/1171] 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 0009/1171] 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 0010/1171] 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 0011/1171] 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 0012/1171] 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 0013/1171] 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 0014/1171] 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 0015/1171] 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 0016/1171] 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 0017/1171] 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 0018/1171] 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 0019/1171] 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 0020/1171] 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 0021/1171] 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 0022/1171] 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 0023/1171] 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 0024/1171] 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 0025/1171] 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 0026/1171] 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 0027/1171] 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 0028/1171] 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 0029/1171] 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 0030/1171] 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 0031/1171] 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 0032/1171] 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 0033/1171] 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 0034/1171] 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 0035/1171] 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 0036/1171] 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 0037/1171] 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 0038/1171] 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 0039/1171] 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 0040/1171] 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 0041/1171] 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 0042/1171] 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 0043/1171] 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 0044/1171] 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 0045/1171] 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 0046/1171] 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 0047/1171] 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 0048/1171] 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 0049/1171] 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 0050/1171] 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 0051/1171] 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 0052/1171] 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 0053/1171] 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 0054/1171] 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 0055/1171] 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 0056/1171] 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 0057/1171] 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 0058/1171] 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 0059/1171] 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 0060/1171] 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 0061/1171] 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 0062/1171] 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 0063/1171] 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 0064/1171] 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 0065/1171] 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 0066/1171] 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 0067/1171] 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 0068/1171] 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 0069/1171] 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 0070/1171] 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 0071/1171] 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 0072/1171] 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 0073/1171] 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 0074/1171] 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 0075/1171] 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 0076/1171] 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 0077/1171] 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 0078/1171] 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 0079/1171] 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 0080/1171] 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 0081/1171] 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 0082/1171] 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 0083/1171] 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 0084/1171] 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 0085/1171] 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 0086/1171] 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 0087/1171] 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 0088/1171] 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 0089/1171] 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 0090/1171] 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 0091/1171] 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 0092/1171] 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 0093/1171] 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 0094/1171] 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 0095/1171] 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 0096/1171] 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 0097/1171] 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 0098/1171] 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 0099/1171] 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 0100/1171] 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 0101/1171] 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 0102/1171] 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 0103/1171] 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 0104/1171] 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 0105/1171] 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 0106/1171] 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 0107/1171] 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 0108/1171] 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 0109/1171] 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 0110/1171] 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 0111/1171] 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 0112/1171] 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 0113/1171] 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 0114/1171] 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 0115/1171] 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 0116/1171] 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 0117/1171] 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 0118/1171] 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 0119/1171] 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 0120/1171] 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 0121/1171] 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 0122/1171] 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 0123/1171] 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 0124/1171] 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 0125/1171] 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 0126/1171] 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 0127/1171] 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 0128/1171] 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 0129/1171] 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 0130/1171] 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 0131/1171] 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 0132/1171] 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 0133/1171] 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 0134/1171] 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 0135/1171] 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 0136/1171] 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 0137/1171] 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 0138/1171] 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 0139/1171] 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 0140/1171] 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 0141/1171] 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 0142/1171] 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 0143/1171] 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 0144/1171] 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 0145/1171] 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 0146/1171] 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 0147/1171] 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 0148/1171] 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 0149/1171] 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 0150/1171] 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 0151/1171] 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 0152/1171] 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 0153/1171] 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 0154/1171] 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 0155/1171] 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 0156/1171] 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 0157/1171] 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 0158/1171] 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 0159/1171] 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 0160/1171] 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 0161/1171] 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 0162/1171] 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 0163/1171] 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 0164/1171] 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 0165/1171] 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 0166/1171] 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 0167/1171] 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 0168/1171] 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 0169/1171] 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 0170/1171] 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 0171/1171] 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 0172/1171] 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 0173/1171] 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 0174/1171] 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 0175/1171] 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 0176/1171] 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 0177/1171] 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 0178/1171] 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 0179/1171] 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 0180/1171] 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 0181/1171] 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 0182/1171] 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 0183/1171] 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 0184/1171] 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 0185/1171] 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 0186/1171] 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 0187/1171] 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 0188/1171] 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 0189/1171] 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 0190/1171] 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 0191/1171] 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 0192/1171] 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 0193/1171] 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 0194/1171] 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 0195/1171] 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 0196/1171] 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 0197/1171] 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 0198/1171] 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 0199/1171] 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 0200/1171] 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 0201/1171] 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 0202/1171] 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 0203/1171] 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 0204/1171] 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 0205/1171] 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 0206/1171] 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 0207/1171] 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 0208/1171] 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 0209/1171] 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 0210/1171] 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 0211/1171] 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 0212/1171] 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 0213/1171] 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 0214/1171] 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 0215/1171] 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 0216/1171] 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 0217/1171] 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 0218/1171] 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 0219/1171] 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 0220/1171] 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 0221/1171] 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 0222/1171] 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 0223/1171] 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 0224/1171] 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 0225/1171] 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 0226/1171] 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 0227/1171] 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 0228/1171] 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 0229/1171] 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 0230/1171] 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 0231/1171] 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 0232/1171] 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 0233/1171] 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 0234/1171] 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 0235/1171] 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 0236/1171] 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 0237/1171] 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 0238/1171] 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 0239/1171] 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 0240/1171] 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 0241/1171] 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 0242/1171] 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 0243/1171] 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 0244/1171] 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 0245/1171] 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 0246/1171] 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 0247/1171] 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 0248/1171] 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 0249/1171] 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 0250/1171] 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 0251/1171] 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 0252/1171] 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 0253/1171] 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 0254/1171] 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 0255/1171] 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 0256/1171] 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 0257/1171] 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 0258/1171] 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 0259/1171] 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 0260/1171] 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 0261/1171] 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 0262/1171] 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 0263/1171] 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 0264/1171] 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 0265/1171] 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 0266/1171] 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 0267/1171] 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 0268/1171] 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 0269/1171] 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 0270/1171] 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 0271/1171] 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 0272/1171] 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 0273/1171] 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 0274/1171] 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 0275/1171] 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 0276/1171] 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 0277/1171] 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 0278/1171] 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 0279/1171] 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 0280/1171] 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 0281/1171] 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 0282/1171] 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 0283/1171] 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 0284/1171] 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 0285/1171] 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 0286/1171] 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 0287/1171] 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 0288/1171] 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 0289/1171] 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 0290/1171] 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 0291/1171] 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 0292/1171] 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 0293/1171] 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 0294/1171] 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 0295/1171] 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 0296/1171] 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 0297/1171] 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 0298/1171] 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 0299/1171] 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 0300/1171] 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 0301/1171] 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 0302/1171] 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 0303/1171] 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 0304/1171] 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 0305/1171] 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 0306/1171] 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 0307/1171] 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 0308/1171] 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 0309/1171] 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 0310/1171] 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 0311/1171] 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 0312/1171] 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 0313/1171] 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 0314/1171] 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 0315/1171] 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 0316/1171] 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 0317/1171] 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 0318/1171] 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 0319/1171] 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 0320/1171] 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 0321/1171] 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 0322/1171] 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 0323/1171] 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 0324/1171] 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 0325/1171] 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 0326/1171] 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 0327/1171] 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 0328/1171] 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 0329/1171] 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 0330/1171] 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 0331/1171] 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 0332/1171] 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 0333/1171] 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 0334/1171] 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 0335/1171] 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 0336/1171] 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 0337/1171] 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 0338/1171] 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 0339/1171] 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 0340/1171] 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 0341/1171] 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 0342/1171] 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 0343/1171] 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 0344/1171] 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 0345/1171] 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 0346/1171] 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 0347/1171] 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 0348/1171] 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 0349/1171] 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 0350/1171] 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 0351/1171] 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 0352/1171] 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 0353/1171] 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 0354/1171] 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 0355/1171] 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 0356/1171] 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 0357/1171] 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 0358/1171] =?UTF-8?q?Markets=20in=20suspension=20can=20be?= =?UTF-8?q?=20resumed=20or=20terminated=20after=20a=20protocol=20u?= =?UTF-8?q?=E2=80=A6=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 0359/1171] 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 0360/1171] 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 0361/1171] 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 0362/1171] 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 0363/1171] 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 0364/1171] 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 0365/1171] 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 0366/1171] 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 0367/1171] 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 0368/1171] 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 0369/1171] 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 0370/1171] 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 0371/1171] 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 0372/1171] 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 0373/1171] 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 0374/1171] 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 0375/1171] 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 0376/1171] 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 0377/1171] 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 0378/1171] 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 0379/1171] 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 0380/1171] 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 0381/1171] 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 0382/1171] 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 0383/1171] 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 0384/1171] 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 0385/1171] 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 0386/1171] 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 0387/1171] 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 0388/1171] 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 0389/1171] 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 0390/1171] 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 0391/1171] 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 0392/1171] 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 0393/1171] 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 0394/1171] 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 0395/1171] 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 0396/1171] 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 0397/1171] 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 0398/1171] 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 0399/1171] 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 0400/1171] 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 0401/1171] 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 0402/1171] 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 0403/1171] 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 0404/1171] 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 0405/1171] 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 0406/1171] 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 0407/1171] 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 0408/1171] 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 0409/1171] 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 0410/1171] 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 0411/1171] 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 0412/1171] 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 0413/1171] 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 0414/1171] 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 0415/1171] 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 0416/1171] 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 0417/1171] 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 0418/1171] 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 0419/1171] 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 0420/1171] 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 0421/1171] 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 0422/1171] 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 0423/1171] 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 0424/1171] 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 0425/1171] 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 0426/1171] 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 0427/1171] 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 0428/1171] 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 0429/1171] 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 0430/1171] 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 0431/1171] 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 0432/1171] 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 0433/1171] 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 0434/1171] 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 0435/1171] 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 0436/1171] 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 0437/1171] 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 0438/1171] 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 0439/1171] 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 0440/1171] 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 0441/1171] 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 0442/1171] 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 0443/1171] 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 0444/1171] 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 0445/1171] 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 0446/1171] 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 0447/1171] 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 0448/1171] 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 0449/1171] 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 0450/1171] 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 0451/1171] 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 0452/1171] 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 0453/1171] 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 0454/1171] 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 0455/1171] 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 0456/1171] 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 0457/1171] 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 0458/1171] 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 0459/1171] 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 0460/1171] 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 0461/1171] 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 0462/1171] 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 0463/1171] 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 0464/1171] 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 0465/1171] 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 0466/1171] 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 0467/1171] 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 0468/1171] 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 0469/1171] 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 0470/1171] 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 0471/1171] 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 0472/1171] 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 0473/1171] 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 0474/1171] 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 0475/1171] 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 0476/1171] 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 0477/1171] 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 0478/1171] 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 0479/1171] 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 0480/1171] 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 0481/1171] 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 0482/1171] 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 0483/1171] 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 0484/1171] 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 0485/1171] 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 0486/1171] 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 0487/1171] 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 0488/1171] 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 0489/1171] 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 0490/1171] 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 0491/1171] 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 0492/1171] 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 0493/1171] 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 0494/1171] 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 0495/1171] 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 0496/1171] 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 0497/1171] 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 0498/1171] 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 0499/1171] 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 0500/1171] 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 0501/1171] 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 0502/1171] 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 0503/1171] 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 0504/1171] 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 0505/1171] 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 0506/1171] 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 0507/1171] 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 0508/1171] 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 0509/1171] 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 0510/1171] 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 0511/1171] 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 0512/1171] 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 0513/1171] 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 0514/1171] 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 0515/1171] 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 0516/1171] 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 0517/1171] 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 0518/1171] 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 0519/1171] 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 0520/1171] 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 0521/1171] 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 0522/1171] 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 0523/1171] 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 0524/1171] 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 0525/1171] 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 0526/1171] 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 0527/1171] 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 0528/1171] 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 0529/1171] 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 0530/1171] 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 0531/1171] 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 0532/1171] 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 0533/1171] 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 0534/1171] 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 0535/1171] 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 0536/1171] 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 0537/1171] 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 0538/1171] 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 0539/1171] 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 0540/1171] 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 0541/1171] 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 0542/1171] 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 0543/1171] 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 0544/1171] 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 0545/1171] 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 0546/1171] 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 0547/1171] 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 0548/1171] 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 0549/1171] 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 0550/1171] 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 0551/1171] 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 0552/1171] 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 0553/1171] 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 0554/1171] 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 0555/1171] 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 0556/1171] 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 0557/1171] 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 0558/1171] 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 0559/1171] 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 0560/1171] 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 0561/1171] 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 0562/1171] 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 0563/1171] 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 0564/1171] 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 0565/1171] 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 0566/1171] 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 0567/1171] 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 0568/1171] 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 0569/1171] 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 0570/1171] 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 0571/1171] 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 0572/1171] 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 0573/1171] 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 0574/1171] 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 0575/1171] 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 0576/1171] 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 0577/1171] 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 0578/1171] 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 0579/1171] 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 0580/1171] 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 0581/1171] 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 0582/1171] 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 0583/1171] 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 0584/1171] 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 0585/1171] 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 0586/1171] 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 0587/1171] 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 0588/1171] 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 0589/1171] 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 0590/1171] 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 0591/1171] 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 0592/1171] 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 0593/1171] 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 0594/1171] 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 0595/1171] 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 0596/1171] 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 0597/1171] 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 0598/1171] 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 0599/1171] 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 0600/1171] 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 0601/1171] 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 0602/1171] 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 0603/1171] 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 0604/1171] 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 0605/1171] 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 0606/1171] 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 0607/1171] 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 0608/1171] 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 0609/1171] 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 0610/1171] 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 0611/1171] 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 0612/1171] 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 0613/1171] 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 0614/1171] 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 0615/1171] 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 0616/1171] 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 0617/1171] 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 0618/1171] 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 0619/1171] 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 0620/1171] 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 0621/1171] 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 0622/1171] 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 0623/1171] 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 0624/1171] 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 0625/1171] 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 0626/1171] 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 0627/1171] 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 0628/1171] 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 0629/1171] 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 0630/1171] 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 0631/1171] 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 0632/1171] 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 0633/1171] 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 0634/1171] 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 0635/1171] 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 0636/1171] 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 15daa5f92265e77a1a20d5bfd3686eea13d31faa Mon Sep 17 00:00:00 2001 From: Witold Date: Tue, 17 Oct 2023 16:31:56 +0200 Subject: [PATCH 0637/1171] refactor: remove quadratic slippage --- ...0012-NP-LIPE-liquidation-price-estimate.md | 6 +-- protocol/0019-MCAL-margin_calculator.md | 37 +++++++++---------- 2 files changed, 21 insertions(+), 22 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 b1a0e973f..aedc68b83 100644 --- a/non-protocol-specs/0012-NP-LIPE-liquidation-price-estimate.md +++ b/non-protocol-specs/0012-NP-LIPE-liquidation-price-estimate.md @@ -8,7 +8,7 @@ Provide an estimate of the price range at which the liquidation of a specified p 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. +This amounts to carrying out the same computation twice, once with slippage factor set to `0` and once with the actual value 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. @@ -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}) + V \cdot \text{constant}, +\text{collateral available} + V(S^{\text{liquidation}}-S^\text{current}) = S^{\text{liquidation}} (V \cdot \text{linear 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{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} - V \cdot \text{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 \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). diff --git a/protocol/0019-MCAL-margin_calculator.md b/protocol/0019-MCAL-margin_calculator.md index d95fecdef..3050f308c 100644 --- a/protocol/0019-MCAL-margin_calculator.md +++ b/protocol/0019-MCAL-margin_calculator.md @@ -24,7 +24,7 @@ - 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 +- If a party is short `1` unit and the mark price is `15 900` and `market.linearSlippageFactor = 0.25` and `RF short = 0.1` and order book is ```book buy 1 @ 15 000 @@ -34,14 +34,14 @@ 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) + then the maintenance margin for the party is `15 900 x 0.25 x 1 + 0.1 x 1 x 15 900 = 5 565`. (0019-MCAL-024) -- 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) +- In the same situation as above, if `market.linearSlippageFactor = 100`, (i.e. 10 000%) instead, then the margin for the party is `1 590 000 + 0.1 x 1 x 15900 = 1 591 590`. (0019-MCAL-025) -- 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) +- If the `market.linearSlippageFactor` 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 + - If a party is long `1` unit and the mark price is `15 900` and `market.linearSlippageFactor = 0.25` and `RF long = 0.1` and order book is ```book buy 1 @ 15 000 @@ -51,7 +51,7 @@ 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 + then the dated future maintenance margin component for the party is `15 900 x 0.25 x 1 + 0.1 x 1 x 15 900 = 5 565`. 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) @@ -66,21 +66,21 @@ ``` - 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) + - Thus, if `margin funding factor = 0.5`, `total margin requirement = futures margin + funding margin = 5565 + 0.5 * 0.16 * 1 = 5565.08` (0019-MCAL-026) - 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) + - Thus, with `margin funding factor = 0.5`, `total margin requirement = futures margin + funding margin = 5565 + 0.5 * 70 * 1 = 5600` (0019-MCAL-027) + - However is position is instead `-1`, with the same margin requirement, if `margin funding factor = 0.5`, `total margin requirement = futures margin + funding margin = 5565 + 0.5 * max(0, 70 * -1) = 5565`(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) + - Thus, with `margin funding factor = 0.5`, `total margin requirement = futures margin + funding margin = 5565 + 0.5 * max(0, -90 * 1) = 5565` (0019-MCAL-028) + - However is position is instead `-1`, with the same margin requirement, if `margin funding factor = 0.5`, `total margin requirement = futures margin + funding margin = 5565 + 0.5 * max(0, -90 * -1) = 5610`(0019-MCAL-029) ## Summary @@ -107,7 +107,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`. +- `market.linearSlippageFactor` which is decimal optional market creation parameter with a default of `0.1` i.e. `10%` with the following validation: `0 <= market.linearSlippageFactor <= 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. @@ -149,7 +149,7 @@ 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) + = max(min(riskiest_long * slippage_per_unit, product.value(market_observable) * (riskiest_long * market.linearSlippageFactor)), 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) ]`, ``` @@ -177,7 +177,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.linearSlippageFactor)) = mark_price * (slippage_volume * market.linearSlippageFactor)` above. ### **Step 2** @@ -187,7 +187,7 @@ 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) + = max(min(abs(riskiest short) * slippage_per_unit, mark_price * (abs(riskiest short) * market.linearSlippageFactor), 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) ]` ``` @@ -250,8 +250,7 @@ bids: [ {volume: 7, price: $108} ] -market.maxSlippageFraction[1] = 0.25 -market.maxSlippageFraction[2] = 0.001 +market.linearSlippageFactor = 0.25 risk_factor_short = 0.11 risk_factor_long = 0.1 @@ -276,11 +275,11 @@ riskiest_short = min( open_volume + sell_orders, 0 ) = min( 10 - 8, 0 ) = 0 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) +maintenance_margin_long =max(min(riskiest_long * slippage_per_unit, product.value(market_observable) * (riskiest_long * market.linearSlippageFactor)), 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), 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 From 2d88e068371d3a0eb9fe0b8511cbd7a583855bc0 Mon Sep 17 00:00:00 2001 From: Gordsport <83510148+gordsport@users.noreply.github.com> Date: Thu, 19 Oct 2023 12:40:47 +0100 Subject: [PATCH 0638/1171] chore: update palazzo with change from PR 1992 (#2013) * chore: update palazzo with change from PR 1992 copies https://github.com/vegaprotocol/specs/pull/1992 into the palazzo branch * chore: update GH actions to run on palazzo branch * fix: removal of old AC codes --- .github/workflows/quality_check.yml | 2 +- protocol/0028-GOVE-governance.md | 2 +- protocol/features.json | 5 ----- 3 files changed, 2 insertions(+), 7 deletions(-) diff --git a/.github/workflows/quality_check.yml b/.github/workflows/quality_check.yml index 8d04b44ba..657a39b8a 100644 --- a/.github/workflows/quality_check.yml +++ b/.github/workflows/quality_check.yml @@ -8,7 +8,7 @@ name: "Quality checks" branches: - master - cosmicelevator - - palazzomistero + - palazzo env: GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} 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) diff --git a/protocol/features.json b/protocol/features.json index a6cdb59e5..eb29bec99 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -231,11 +231,6 @@ "0014-ORDT-121", "0014-ORDT-122", "0014-ORDT-123", - "0019-MCAL-019", - "0019-MCAL-020", - "0019-MCAL-021", - "0019-MCAL-022", - "0019-MCAL-023", "0053-PERP-024" ] }, From 764914be2d8d8a4b9abc4f58a83160235b022671 Mon Sep 17 00:00:00 2001 From: Gordsport <83510148+gordsport@users.noreply.github.com> Date: Thu, 19 Oct 2023 12:48:47 +0100 Subject: [PATCH 0639/1171] Make referrals spec line up with implementation - palazzo (#2012) * remove instances where 0 is valid * 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 * Update quality_check.yml --------- Co-authored-by: candida-d <62548908+candida-d@users.noreply.github.com> Co-authored-by: Charlie --- .../0083-RFPR-on_chain_referral_program.md | 62 ++++++++++--------- protocol/0084-VDPR-volume_discount_program.md | 14 +++-- protocol/features.json | 2 + 3 files changed, 42 insertions(+), 36 deletions(-) diff --git a/protocol/0083-RFPR-on_chain_referral_program.md b/protocol/0083-RFPR-on_chain_referral_program.md index 2b1ec2713..2ab645d82 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,26 +101,27 @@ 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`. +- all `referral_reward_factor` values must be greater than `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`. +- all `referral_discount_factor` values must be greater than `0` and be less than or equal to the network parameter `referralProgram.maxReferralDiscountFactor`. - `window_length` must be an integer strictly greater than zero. 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, 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,11 +402,12 @@ 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). + - all `referral_reward_factor` values must be greater than `0` and less than or equal to the network parameter `referralProgram.maxReferralRewardFactor` (0083-RFPR-004). + - all `referral_discount_factor` values must be greater than `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 `end_of_program_timestamp` is reached (0083-RFPR-008). 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 eb29bec99..8fa986fcf 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -423,6 +423,7 @@ "0083-RFPR-048", "0083-RFPR-049", "0083-RFPR-050", + "0083-RFPR-051", "0084-VDPR-001", "0084-VDPR-002", "0084-VDPR-003", @@ -439,6 +440,7 @@ "0084-VDPR-014", "0084-VDPR-015", "0084-VDPR-016", + "0084-VDPR-017", "0029-FEES-023", "0029-FEES-024", "0029-FEES-025", From 155aac217a38173b96d409c4a64028b24a5dfb55 Mon Sep 17 00:00:00 2001 From: Gordsport <83510148+gordsport@users.noreply.github.com> Date: Thu, 19 Oct 2023 12:58:41 +0100 Subject: [PATCH 0640/1171] chore: align validator ranking metric with implementation as per #2002 (#2004) * chore: align validator ranking metric with implementation as per #2002 this PR removes information relating to PoS rewards from the validator ranking metric as per the change made to cosmic branch in #2002 * chore: put AC 0044-LIME-029 into the correct feature --- protocol/0056-REWA-rewards_overview.md | 10 ---------- protocol/features.json | 2 +- 2 files changed, 1 insertion(+), 11 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. diff --git a/protocol/features.json b/protocol/features.json index 8fa986fcf..ceaad4db4 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -326,7 +326,6 @@ "0044-LIME-053", "0044-LIME-060", "0044-LIME-028", - "0044-LIME-029", "0044-LIME-032", "0044-LIME-033", "0044-LIME-034", @@ -587,6 +586,7 @@ "0080-SPOT-019", "0080-SPOT-020", "0081-SUCM-004", + "0044-LIME-029", "0044-LIME-043", "0044-LIME-044", "0044-LIME-045", From 1c57fd45a199c51804901710362f33de845971c1 Mon Sep 17 00:00:00 2001 From: Gordsport <83510148+gordsport@users.noreply.github.com> Date: Fri, 20 Oct 2023 21:58:39 +0100 Subject: [PATCH 0641/1171] chore: Update max amount parameter definition palazzo (#2015) Governance initiated transfer's network parameter for max amount has changed to be a quantum multiplier: vegaprotocol/vega#9856 asl as per cosmic elevator change https://github.com/vegaprotocol/specs/pull/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 8fabff17b55e2957de8e7b8e7695a5cd414598c5 Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Thu, 26 Oct 2023 11:04:22 +0800 Subject: [PATCH 0642/1171] feat: add 2 more liquidity fee setting methods --- .../0042-LIQF-setting_fees_and_rewarding_lps.md | 14 +++++++++++++- 1 file changed, 13 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 0d66ef6d8..d73db6bbf 100644 --- a/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md +++ b/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md @@ -12,6 +12,10 @@ The aim of this specification is to set out how fees on Vega are set based on co ## Calculating liquidity fee factor +There are three ways to set the liquidity fee factor, and the default method is the 'Ascending Clock Auction'. + +### Ascending Clock Auction method + The [liquidity fee factor](./0029-FEES-fees.md) is an input to the total taker fee that a price taker of a trade pays: `total_fee = infrastructure_fee + maker_fee + liquidity_fee` @@ -34,7 +38,7 @@ We now find the smallest integer `k` such that `[target stake] < sum from i=1 to Finally, we set the liquidity-fee-factor for this market to be the fee `LP-k-liquidity-fee-factor`. -### Example for fee setting mechanism +### Example for fee setting mechanism in Ascending Clock Auction method 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. @@ -176,6 +180,14 @@ An existing LP has `average entry valuation 1090.9` and `S=110`. Currently the s (average entry valuation) = 1090.9 ``` +### "Vickrey-Clarke-Groves (VCG) auction" ("VCG mechanism") for setting the liquidity fee factor + +The liquidity fee factor is set as the weighted average of the liquidity fee factors, with weights assigned based on the supplied stake from each liquidity provider, which can also account for the impact of one supplier's actions on others. + +### Vickrey auction for setting the liquidity fee factor + +The liquidity fee factor is set as the second lowest liquidity fee factor. + ### Calculating the instantaneous liquidity score At every vega time change calculate the liquidity score for each committed LP. From 9ecf6bd04ad72f60be6cba618292d6bd6c4547e6 Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Fri, 27 Oct 2023 09:11:08 +0800 Subject: [PATCH 0643/1171] feat: address comments from David --- .../0042-LIQF-setting_fees_and_rewarding_lps.md | 13 +++++++------ 1 file changed, 7 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 d73db6bbf..01a863849 100644 --- a/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md +++ b/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md @@ -10,11 +10,11 @@ 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 the Liquidity Fee Factor -There are three ways to set the liquidity fee factor, and the default method is the 'Ascending Clock Auction'. +There are three methods for setting the liquidity fee factor, with the default method being the 'Marginal Cost method.' The liquidity fee setting mechanism is configured per market as part of the market proposal. -### Ascending Clock Auction method +### Marginal Cost method The [liquidity fee factor](./0029-FEES-fees.md) is an input to the total taker fee that a price taker of a trade pays: @@ -180,13 +180,14 @@ An existing LP has `average entry valuation 1090.9` and `S=110`. Currently the s (average entry valuation) = 1090.9 ``` -### "Vickrey-Clarke-Groves (VCG) auction" ("VCG mechanism") for setting the liquidity fee factor +### Stake-weighted-average method for setting the liquidity fee factor The liquidity fee factor is set as the weighted average of the liquidity fee factors, with weights assigned based on the supplied stake from each liquidity provider, which can also account for the impact of one supplier's actions on others. -### Vickrey auction for setting the liquidity fee factor +### "Constant Liquidity Fee" Method + +The liquidity fee factor is set to a constant number -The liquidity fee factor is set as the second lowest liquidity fee factor. ### Calculating the instantaneous liquidity score From 89582dc57d120d95fcbc29034aa73a25f4fb9fa6 Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Mon, 30 Oct 2023 09:22:49 +0000 Subject: [PATCH 0644/1171] chore: remove empty spaces --- 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 01a863849..d95014f0f 100644 --- a/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md +++ b/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md @@ -14,7 +14,7 @@ The aim of this specification is to set out how fees on Vega are set based on co There are three methods for setting the liquidity fee factor, with the default method being the 'Marginal Cost method.' The liquidity fee setting mechanism is configured per market as part of the market proposal. -### Marginal Cost method +### Marginal Cost method The [liquidity fee factor](./0029-FEES-fees.md) is an input to the total taker fee that a price taker of a trade pays: From b7da834d64baa84bccce65ed65aa315f9cc2ad8e Mon Sep 17 00:00:00 2001 From: Jiajia-Cui <92106936+Jiajia-Cui@users.noreply.github.com> Date: Mon, 30 Oct 2023 09:41:25 +0000 Subject: [PATCH 0645/1171] feat: update method 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 d95014f0f..24e4d4841 100644 --- a/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md +++ b/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md @@ -38,7 +38,7 @@ We now find the smallest integer `k` such that `[target stake] < sum from i=1 to Finally, we set the liquidity-fee-factor for this market to be the fee `LP-k-liquidity-fee-factor`. -### Example for fee setting mechanism in Ascending Clock Auction method +### Example for fee setting mechanism using the marginal cost method 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. From edd75e5911d3e2d44f7f1be0be928e6e4a4af327 Mon Sep 17 00:00:00 2001 From: David Siska <62546419+davidsiska-vega@users.noreply.github.com> Date: Mon, 30 Oct 2023 09:43:05 +0000 Subject: [PATCH 0646/1171] Update protocol/0042-LIQF-setting_fees_and_rewarding_lps.md --- 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 24e4d4841..57baee9cd 100644 --- a/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md +++ b/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md @@ -186,7 +186,7 @@ The liquidity fee factor is set as the weighted average of the liquidity fee fac ### "Constant Liquidity Fee" Method -The liquidity fee factor is set to a constant number +The liquidity fee factor is set to a constant directly as part of the market proposal. ### Calculating the instantaneous liquidity score From d7ecf12e6cd1cd279676f250cef475af3984a6a1 Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Mon, 30 Oct 2023 09:45:10 +0000 Subject: [PATCH 0647/1171] chore: remove empty space --- 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 57baee9cd..16966a06e 100644 --- a/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md +++ b/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md @@ -186,7 +186,7 @@ The liquidity fee factor is set as the weighted average of the liquidity fee fac ### "Constant Liquidity Fee" Method -The liquidity fee factor is set to a constant directly as part of the market proposal. +The liquidity fee factor is set to a constant directly as part of the market proposal. ### Calculating the instantaneous liquidity score From e32146f864038818eb8cb8c4c6df77923017787f Mon Sep 17 00:00:00 2001 From: Gordsport <83510148+gordsport@users.noreply.github.com> Date: Mon, 30 Oct 2023 11:10:37 +0000 Subject: [PATCH 0648/1171] feat: align discount application with core implementation (#2021) to align with cosmic merge of: - https://github.com/vegaprotocol/specs/pull/2018 --- protocol/0029-FEES-fees.md | 58 ++++++++++++++++++++++---------------- protocol/features.json | 2 ++ 2 files changed, 36 insertions(+), 24 deletions(-) diff --git a/protocol/0029-FEES-fees.md b/protocol/0029-FEES-fees.md index 0d30f60d9..6573baea3 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 other 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.) @@ -159,27 +167,29 @@ 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` +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). diff --git a/protocol/features.json b/protocol/features.json index ceaad4db4..eef5b3bf7 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -449,6 +449,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 c8287fbc81f1cd10733e16ced1f311b7da9ec00f Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Mon, 30 Oct 2023 11:42:10 +0000 Subject: [PATCH 0649/1171] feat: add a cap for transfer fee --- protocol/0057-TRAN-transfers.md | 1 + 1 file changed, 1 insertion(+) diff --git a/protocol/0057-TRAN-transfers.md b/protocol/0057-TRAN-transfers.md index 2082e4b2c..a686aedbe 100644 --- a/protocol/0057-TRAN-transfers.md +++ b/protocol/0057-TRAN-transfers.md @@ -156,6 +156,7 @@ Note: if there is no market with contribution to the reward metric - no transfer 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-parameters) that defines the proportion of each transfer taken as a fee. +The fee is capped by the `transfer.fee.Maxfactor` network parameter to prevent people from paying a large transfer fee amount. 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-fees.md#collecting-and-distributing-fees). Fees are charged in the asset that is being transferred. From bd73405b767e14cf211c7e0cb7c385b00461f399 Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Mon, 30 Oct 2023 11:50:36 +0000 Subject: [PATCH 0650/1171] feat: add AC for transfer fee cap --- protocol/0057-TRAN-transfers.md | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/protocol/0057-TRAN-transfers.md b/protocol/0057-TRAN-transfers.md index a686aedbe..25df092e6 100644 --- a/protocol/0057-TRAN-transfers.md +++ b/protocol/0057-TRAN-transfers.md @@ -236,6 +236,11 @@ message CancelTransfer { - 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 do a transfer from any of the valid accounts (I control them and they're a valid source), and transfer fees (which are capped by `transfer.fee.Maxfactor`) are taken from the source account when the transfer is executed. (0057-TRAN-011) + - The fee cost is correctly calculated using the network parameter `transfer.fee.Maxfactor` + - 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) - 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. From 4052e09e5038e785de160731468ffa8e155c6af9 Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Mon, 30 Oct 2023 11:51:42 +0000 Subject: [PATCH 0651/1171] chore: update formatting --- 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 25df092e6..d30626194 100644 --- a/protocol/0057-TRAN-transfers.md +++ b/protocol/0057-TRAN-transfers.md @@ -236,7 +236,7 @@ message CancelTransfer { - 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 do a transfer from any of the valid accounts (I control them and they're a valid source), and transfer fees (which are capped by `transfer.fee.Maxfactor`) are taken from the source account when the transfer is executed. (0057-TRAN-011) +- As a user when I do a transfer from any of the valid accounts (I control them and they're a valid source), and transfer fees (which are capped by `transfer.fee.Maxfactor`) are taken from the source account when the transfer is executed. (0057-TRAN-011) - The fee cost is correctly calculated using the network parameter `transfer.fee.Maxfactor` - 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. From b192dfaf32afc07567d26ffd2e8948c13f90851f Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Mon, 30 Oct 2023 12:14:25 +0000 Subject: [PATCH 0652/1171] feat: chore --- 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 d30626194..f924b00ce 100644 --- a/protocol/0057-TRAN-transfers.md +++ b/protocol/0057-TRAN-transfers.md @@ -231,12 +231,12 @@ message CancelTransfer { - 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) +- As a user I can do a transfer from any of the valid accounts and `transfer.fee.factor <= transfer.fee.Maxfactor` (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 do a transfer from any of the valid accounts (I control them and they're a valid source), and transfer fees (which are capped by `transfer.fee.Maxfactor`) are taken from the source account when the transfer is executed. (0057-TRAN-011) +- As a user when I do a transfer from any of the valid accounts `transfer.fee.factor > transfer.fee.Maxfactor` (I control them and they're a valid source), and transfer fees (which are capped by `transfer.fee.Maxfactor`) are taken from the source account when the transfer is executed. (0057-TRAN-011) - The fee cost is correctly calculated using the network parameter `transfer.fee.Maxfactor` - 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. From e70efd1ca292560d9ef2c1f48616a2f894b27d2a Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Mon, 30 Oct 2023 12:17:52 +0000 Subject: [PATCH 0653/1171] feat: update grammar --- 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 f924b00ce..aa2c0d6c9 100644 --- a/protocol/0057-TRAN-transfers.md +++ b/protocol/0057-TRAN-transfers.md @@ -236,7 +236,7 @@ message CancelTransfer { - 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 do a transfer from any of the valid accounts `transfer.fee.factor > transfer.fee.Maxfactor` (I control them and they're a valid source), and transfer fees (which are capped by `transfer.fee.Maxfactor`) are taken from the source account when the transfer is executed. (0057-TRAN-011) +- As a user when I do a transfer from any of the valid accounts and `transfer.fee.factor > transfer.fee.Maxfactor` (I control them and they're a valid source), and transfer fees (which are capped by `transfer.fee.Maxfactor`) are taken from the source account when the transfer is executed. (0057-TRAN-011) - The fee cost is correctly calculated using the network parameter `transfer.fee.Maxfactor` - 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. From 8ce26c393178b9f54ca0e443ce32ba037fd41220 Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Mon, 30 Oct 2023 13:22:05 +0000 Subject: [PATCH 0654/1171] feat: address comments from Tom --- protocol/0057-TRAN-transfers.md | 13 ++++++++----- 1 file changed, 8 insertions(+), 5 deletions(-) diff --git a/protocol/0057-TRAN-transfers.md b/protocol/0057-TRAN-transfers.md index aa2c0d6c9..e977a5513 100644 --- a/protocol/0057-TRAN-transfers.md +++ b/protocol/0057-TRAN-transfers.md @@ -155,8 +155,7 @@ Note: if there is no market with contribution to the reward metric - no transfer 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-parameters) that defines the proportion of each transfer taken as a fee. -The fee is capped by the `transfer.fee.Maxfactor` network parameter to prevent people from paying a large transfer fee amount. +The fee is determined by the `transfer.fee.factor` and is subject to a cap defined by the multiplier `transfer.fee.maxQuantumAmount` as specified in the network parameters, which governs 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-fees.md#collecting-and-distributing-fees). Fees are charged in the asset that is being transferred. @@ -218,6 +217,7 @@ message CancelTransfer { | `spam.protection.maxUserTransfersPerEpoch` | String (integer) | strictly greater than `0` | `"20"` | The most transfers a use can initiate per epoch | | `transfer.minTransferQuantumMultiple` | String (decimal) | greater than or equal to `0`| `"0.1"` | This, when multiplied by `quantum` (which is specified per asset) determines the minimum transfer amount | | `transfer.fee.factor` | String (decimal) | in `[0.0,1.0]` | `"0.001"` | The proportion of the transfer charged as a fee | +| `transfer.fee.maxQuantumAmount` | String (decimal) | in `[0.0,1.0]` | `"0.001"` | The miltiplier of the transfer fee | ## Acceptance criteria @@ -231,12 +231,12 @@ message CancelTransfer { - 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 and `transfer.fee.factor <= transfer.fee.Maxfactor` (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 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 (when `transfer.fee.maxQuantumAmount` = 1). (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 do a transfer from any of the valid accounts and `transfer.fee.factor > transfer.fee.Maxfactor` (I control them and they're a valid source), and transfer fees (which are capped by `transfer.fee.Maxfactor`) are taken from the source account when the transfer is executed. (0057-TRAN-011) +- 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 (when `transfer.fee.maxQuantumAmount` = 0.02). (0057-TRAN-011) - The fee cost is correctly calculated using the network parameter `transfer.fee.Maxfactor` - 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. @@ -262,7 +262,7 @@ As a user I can create a recurring transfer _that decreases over time_ (0057-TRAN-062) +If the network parameter `transfer.fee.maxQuantumAmount` 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-064) + 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 From a65aa3e4cd8e5fe0bead7b0e9058e21afb1d61e1 Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Mon, 30 Oct 2023 13:32:05 +0000 Subject: [PATCH 0655/1171] chore: typo --- 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 e977a5513..624a6258c 100644 --- a/protocol/0057-TRAN-transfers.md +++ b/protocol/0057-TRAN-transfers.md @@ -217,7 +217,7 @@ message CancelTransfer { | `spam.protection.maxUserTransfersPerEpoch` | String (integer) | strictly greater than `0` | `"20"` | The most transfers a use can initiate per epoch | | `transfer.minTransferQuantumMultiple` | String (decimal) | greater than or equal to `0`| `"0.1"` | This, when multiplied by `quantum` (which is specified per asset) determines the minimum transfer amount | | `transfer.fee.factor` | String (decimal) | in `[0.0,1.0]` | `"0.001"` | The proportion of the transfer charged as a fee | -| `transfer.fee.maxQuantumAmount` | String (decimal) | in `[0.0,1.0]` | `"0.001"` | The miltiplier of the transfer fee | +| `transfer.fee.maxQuantumAmount` | String (decimal) | in `[0.0,1.0]` | `"0.001"` | The multiplier of the transfer fee | ## Acceptance criteria From 03d44ce06a7c0c5fbd1f36fc48697d6ff0bf655d Mon Sep 17 00:00:00 2001 From: Jiajia-Cui <92106936+Jiajia-Cui@users.noreply.github.com> Date: Mon, 30 Oct 2023 13:44:21 +0000 Subject: [PATCH 0656/1171] feat: add comment from Tom Co-authored-by: Tom --- protocol/0057-TRAN-transfers.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/protocol/0057-TRAN-transfers.md b/protocol/0057-TRAN-transfers.md index 624a6258c..cf9e813b7 100644 --- a/protocol/0057-TRAN-transfers.md +++ b/protocol/0057-TRAN-transfers.md @@ -156,6 +156,8 @@ Note: if there is no market with contribution to the reward metric - no transfer 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 determined by the `transfer.fee.factor` and is subject to a cap defined by the multiplier `transfer.fee.maxQuantumAmount` as specified in the network parameters, which governs the proportion of each transfer taken as a fee. + +As such, the transfer fee value used will be: `min(transfer amount * transfer.fee.factor, transfer.fee.maxQuantumAmount * asset quantum)` 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-fees.md#collecting-and-distributing-fees). Fees are charged in the asset that is being transferred. From 6fe58516a639c5c23ecf455550d5ff77c5996491 Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Mon, 30 Oct 2023 14:40:22 +0000 Subject: [PATCH 0657/1171] feat: update validation range for fee cap --- protocol/0057-TRAN-transfers.md | 23 ++++++++++++++++------- 1 file changed, 16 insertions(+), 7 deletions(-) diff --git a/protocol/0057-TRAN-transfers.md b/protocol/0057-TRAN-transfers.md index cf9e813b7..4e9ad92cc 100644 --- a/protocol/0057-TRAN-transfers.md +++ b/protocol/0057-TRAN-transfers.md @@ -157,7 +157,7 @@ A fee is taken from all transfers, and paid out to validators in a similar manne The fee is determined by the `transfer.fee.factor` and is subject to a cap defined by the multiplier `transfer.fee.maxQuantumAmount` as specified in the network parameters, which governs the proportion of each transfer taken as a fee. -As such, the transfer fee value used will be: `min(transfer amount * transfer.fee.factor, transfer.fee.maxQuantumAmount * asset quantum)` +As such, the transfer fee value used will be: `min(transfer amount * transfer.fee.factor, transfer.fee.maxQuantumAmount * quantum)`, `quantum` is for asset 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-fees.md#collecting-and-distributing-fees). Fees are charged in the asset that is being transferred. @@ -219,7 +219,7 @@ message CancelTransfer { | `spam.protection.maxUserTransfersPerEpoch` | String (integer) | strictly greater than `0` | `"20"` | The most transfers a use can initiate per epoch | | `transfer.minTransferQuantumMultiple` | String (decimal) | greater than or equal to `0`| `"0.1"` | This, when multiplied by `quantum` (which is specified per asset) determines the minimum transfer amount | | `transfer.fee.factor` | String (decimal) | in `[0.0,1.0]` | `"0.001"` | The proportion of the transfer charged as a fee | -| `transfer.fee.maxQuantumAmount` | String (decimal) | in `[0.0,1.0]` | `"0.001"` | The multiplier of the transfer fee | +| `transfer.fee.maxQuantumAmount` | String (decimal) | greater than or equal to `0` | `"100"` | The cap of the transfer fee | ## Acceptance criteria @@ -233,12 +233,12 @@ message CancelTransfer { - 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 (when `transfer.fee.maxQuantumAmount` = 1). (0057-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 (when `transfer amount * transfer.fee.factor <= transfer.fee.maxQuantumAmount * quantum`). (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 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 (when `transfer.fee.maxQuantumAmount` = 0.02). (0057-TRAN-011) +- 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 (when `transfer amount * transfer.fee.factor > transfer.fee.maxQuantumAmount * quantum`). (0057-TRAN-011) - The fee cost is correctly calculated using the network parameter `transfer.fee.Maxfactor` - 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. @@ -259,12 +259,21 @@ As a user I can create a recurring transfer _which expires after a specified epo - 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) when (when `transfer amount * transfer.fee.factor <= transfer.fee.maxQuantumAmount * quantum`) - I specify a start and end epoch, and a factor of `0.7` - Until the start epoch is reached not transfers are executed -- Once I reach the start epoch transfers happen and the first transfer is for the `start amount`. The fee amount taken from the source account is `start amount x transfer.fee.factor` and transferred to the infrastructure fee account for the asset. -- The transfer at end of `start epoch + 1` is `0.7 x start amount` and the fee amount is `0.7 x start amount x transfer.fee.factor x transfer.fee.maxQuantumAmount`. +- Once I reach the start epoch transfers happen and the first transfer is for the `start amount`. The fee amount taken from the source account is `min(start amount * transfer.fee.factor, transfer.fee.maxQuantumAmount * quantum)` and transferred to the infrastructure fee account for the asset. +- The transfer at end of `start epoch + 1` is `0.7 x start amount` and the fee amount is `0.7 x start amount * transfer.fee.factor`. +- The amount transferred every epoch decreases. +- After I reach the epoch `?`, no transfers are executed anymore + +As a user I can create a recurring transfer _that decreases over time_ (0057-TRAN-065) when (when `transfer amount * transfer.fee.factor > transfer.fee.maxQuantumAmount * quantum`) + +- I specify a start and end epoch, and a factor of `0.7` +- Until the start epoch is reached not transfers are executed +- Once I reach the start epoch transfers happen and the first transfer is for the `start amount`. The fee amount taken from the source account is `min(start amount * transfer.fee.factor, transfer.fee.maxQuantumAmount * quantum)` and transferred to the infrastructure fee account for the asset. +- The transfer at end of `start epoch + 1` is `0.7 x start amount` and the fee amount is `0.7 x transfer.fee.maxQuantumAmount * quantum`. - The amount transferred every epoch decreases. - After I reach the epoch `?`, no transfers are executed anymore From b3187ce5a504797036ec36473da40f27a155af10 Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Mon, 30 Oct 2023 14:44:02 +0000 Subject: [PATCH 0658/1171] chore: typo --- 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 4e9ad92cc..1ff56e19a 100644 --- a/protocol/0057-TRAN-transfers.md +++ b/protocol/0057-TRAN-transfers.md @@ -259,7 +259,7 @@ As a user I can create a recurring transfer _which expires after a specified epo - 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) when (when `transfer amount * transfer.fee.factor <= transfer.fee.maxQuantumAmount * quantum`) +As a user I can create a recurring transfer _that decreases over time_ (0057-TRAN-051) when `start amount * transfer.fee.factor <= transfer.fee.maxQuantumAmount * quantum` - I specify a start and end epoch, and a factor of `0.7` - Until the start epoch is reached not transfers are executed @@ -268,7 +268,7 @@ As a user I can create a recurring transfer _that decreases over time_ (0057-TRAN-065) when (when `transfer amount * transfer.fee.factor > transfer.fee.maxQuantumAmount * quantum`) +As a user I can create a recurring transfer _that decreases over time_ (0057-TRAN-065) when `start amount * transfer.fee.factor > transfer.fee.maxQuantumAmount * quantum` - I specify a start and end epoch, and a factor of `0.7` - Until the start epoch is reached not transfers are executed From dcf39b92fd7190fd7368bfb6ff38094bfe9f7e79 Mon Sep 17 00:00:00 2001 From: Tom Date: Wed, 1 Nov 2023 10:33:08 +0000 Subject: [PATCH 0659/1171] feat: isolated margin (#1850) * feat: Isolated margin --- protocol/0010-MARG-margin_orchestration.md | 3 +- protocol/0012-POSR-position_resolution.md | 2 +- protocol/0019-MCAL-margin_calculator.md | 179 +++++++++++++++++- .../0074-BTCH-batch-market-instructions.md | 5 +- wordlist.txt | 60 +++--- 5 files changed, 206 insertions(+), 43 deletions(-) diff --git a/protocol/0010-MARG-margin_orchestration.md b/protocol/0010-MARG-margin_orchestration.md index e2129a8eb..d3ed5badd 100644 --- a/protocol/0010-MARG-margin_orchestration.md +++ b/protocol/0010-MARG-margin_orchestration.md @@ -34,9 +34,10 @@ This specification outlines: ### **Background - how margin levels are calculated** -The [margin calculator](./0019-MCAL-margin_calculator.md) will calculate the margin levels when instructed to do so. It will return four margin levels for each trader: +The [margin calculator](./0019-MCAL-margin_calculator.md) will calculate the margin levels when instructed to do so. It will return five margin levels for each trader: 1. maintenance margin +1. order margin 1. collateral search level 1. initial margin 1. collateral release level diff --git a/protocol/0012-POSR-position_resolution.md b/protocol/0012-POSR-position_resolution.md index 6c69b452c..4dbaea5dc 100644 --- a/protocol/0012-POSR-position_resolution.md +++ b/protocol/0012-POSR-position_resolution.md @@ -24,7 +24,7 @@ Any trader that has insufficient collateral to cover their margin liability is r See [Whitepaper](https://vega.xyz/papers/vega-protocol-whitepaper.pdf), Section 5.3 , steps 1 - 3 -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. A "distressed trader" in cross-margining mode has all their open orders on that market cancelled. Note, the network must then recalculate their margin requirement on their remaining open position, perform one final margin search 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 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) diff --git a/protocol/0019-MCAL-margin_calculator.md b/protocol/0019-MCAL-margin_calculator.md index 3050f308c..069201c5a 100644 --- a/protocol/0019-MCAL-margin_calculator.md +++ b/protocol/0019-MCAL-margin_calculator.md @@ -84,21 +84,141 @@ ## Summary -The *margin calculator* returns the set of relevant margin levels for a given position and entry price: +The *margin calculator* returns the set of margin levels for a given *actual position*, along with the amount of additional margin (if any) required to support the party's *potential position* (i.e. active orders including any that are parked/untriggered/undeployed). -1. ***Maintenance margin*** -1. ***Collateral search level*** -1. ***Initial margin*** -1. ***Collateral release level*** + +### Margining modes + +The system can operate in one of two margining modes for each position. +The current mode will be stored alongside of party's position record. + +1. **Cross-margin mode (default)**: this is the mode used by all newly created positions. +When in cross-margin mode, margin is dynamically acquired and released as a position is marked to market, allowing profitable positions to offset losing positions for higher capital efficiency (especially with e.g. pairs trades). + +1. **Isolated margin mode**: this mode sacrifices capital efficiency for predictability and risk management by segregating positions. +In this mode, the entire margin for any newly opened position volume is transferred to the margin account when the trade is executed. +This includes completely new positions and increases to position size. Other than at time of future trades, the general account will then +*never* be searched for additional funds (a position will be allowed to be closed out instead), nor will profits be moved into the +general account from the margin account. + +### Actual position margin levels + +1. **Maintenance margin**: the minimum margin a party must have in their margin account to avoid the position being liquidated. + +1. **Collateral search level**: when in cross-margin mode, the margin account balance below which the system will seek to recollateralise the margin account back to the initial margin level. + +1. **Initial margin**: when in cross-margin mode, the margin account balance initially allocated for the position, and the balance to which the margin account will be returned after collateral search and release, if possible. + +1. **Collateral release level**: when in cross-margin mode, the margin account balance above which the system will return collateral from a profitable position to the party's general account for potential use elsewhere. The protocol is designed such that ***Maintenance margin < Collateral search level < Initial margin < Collateral release level***. +### Potential position margin level + +1. **Order margin**: the amount of additional margin on top of the amount in the margin account that is required for the party's current active orders. +Note that this may be zero if the active orders can only decrease the position size. + + Margin levels are used by the protocol to ascertain whether a trader has sufficient collateral to maintain a margined trade. When the trader enters an open position, this required amount is equal to the *initial margin*. Subsequently, throughout the life of this open position, the minimum required amount is the *maintenance margin*. As a trader's collateral level dips below the *collateral search level* the protocol will automatically search for more collateral to be assigned to support this open position from the trader's general collateral accounts. In the event that a trader has collateral that is above the *collateral release level* the protocol will automatically release collateral to a trader's general collateral account for the relevant asset. **Whitepaper reference:** 6.1, section "Margin Calculation" In future there can be multiple margin calculator implementations that would be configurable in the market framework. This spec describes one implementation. +## Isolated margin mode + +When in isolated margin mode, the position on the market has an associated margin factor. +The margin factor must be greater than 0 and less than or equal to 1, and also greater than `max(risk factor long, risk factor short)`. + +Isolated margin mode can be enabled by placing an *update margin mode* transaction. +The protocol will attempt to set the funds within the margin account equal to `average entry price * current position * new margin factor`. +This value must be above the `initial margin` for the current position or the transaction will be rejected. + +The default when placing an order with no change to margin mode specified must be to retain the current margin mode of the position. + +### Placing an order + +When submitting, amending, or deleting an order in isolated margin mode and continuous trading, a two step process will be followed: + + 1. First, the core will check whether the order will trade, either fully or in part, immediately upon entry. If so: + 1. If the trade would increase the party's position, the required additional funds as specified in the Increasing Position section will be calculated. The total expected margin balance (current plus new funds) will then be compared to the `maintenance margin` for the expected position, if the margin balance would be less than maintenance, instead reject the order in it's entirety. If the margin will be greater than the maintenance margin their general account will be checked for sufficient funds. + 1. If they have sufficient, that amount will be moved into their margin account and the immediately matching portion of the order will trade. + 1. If they do not have sufficient, the order will be rejected in it's entirety for not meeting margin requirements. + 1. If the trade would decrease the party's position, that portion will trade and margin will be released as in the Decreasing Position section + 1. If the order is not persistent this is the end, if it is persistent any portion of the order which has not traded in step 1 will move to being placed on the order book. + 1. At this point, the party's general account will be checked for margin to cover the additional amount required for the new orders. Each side can be checked individually and the maximum for either side taken into the order margin pool. This calculation must be rerun every time the party's orders or position change. For each side: + 1. Sort all orders by price, starting from first to execute (highest price for buying, lowest price for selling). + 1. If the party currently has a position `x`, assign `0` margin requirement the first-to-trade `x` of volume on the opposite side as this would reduce their position (for example, if a party had a long position `10` and sell orders of `15` at a price of `$100` and `10` at a price of `$150`, the first `10` of the sell order at `$100` would not require any order margin). + 1. For any remaining volume, sum `side margin = limit price * size * margin factor` for each price level, as this is the worst-case trade price of the remaining component. + 1. Take the maximum margin from the two `side margin`s as the margin required in the order margin account. Now the full margin requirement for all orders, including any new one, and open position should be run through the full margin calculator to obtain a `maintenance margin` value. If the new `side margin + margin account balance < maintenance margin`, or if the party's `general` account does not contain sufficient funds to cover any increases to the `order margin` account to be equal to `side margin` then: + 1. If a newly placed order is being evaluated, that order is `stopped` + 1. If the evaluation is the result of any other position/order update, all open orders are `stopped` and margin re-evaluated. + 1. The `order margin` account is now updated to the new `side margin` value and any new orders can be placed on the book. + +NB: This means that a party's order could partially match, with a trade executed and some funds moved to the margin account with correct leverage whilst the rest of the order is immediately stopped. + +When submitting, amending, or deleting an order in isolated margin mode and an auction is active there is no concept of an order trading immediately on entry, however the case of someone putting in a sell order for a very low price must be handled (as it is likely to execute at a much higher price). To handle this, when in an auction the amount taken into the order margin account should be the larger of either `limit price * size * margin factor` or `max(mark price, indicative uncrossing price) * size * margin factor`. All other steps are as above. + +### Increasing Position + +When an order trades which increases the position (increasing the absolute value of the trader's position), the target amount to be transferred is calculated as: + +```math +\text{margin to add} = \text{margin factor} \cdot \text{sum across executed trades}(|\text{trade size}| \cdot \text{trade price}) +``` + +This will be taken by performing three steps: + + 1. The margin to add as calculated here is compared to the margin which would have been placed into the order margin account for this order, `limit price * remaining size * margin factor`. + 2. If it is equal, this amount is taken from the order margin account and placed into the margin account + 3. If the order traded at a price which means less margin should be taken then the amount `margin to add` above is taken from the order margin account into the margin account and the excess is returned from the order margin account to the general account + +NB: In implementation, for any volume that trades immediately on entry, the additional margin may be transferred directly from the general account to the margin account. + +### Reducing Position + +When an order trades which reduces the trader's current position the amount to be withdrawn from the margin account is determined by the fraction of the position which is being closed. However, this fraction should also take into account that the entire position's margin may be due to change since the current trading price may have diverged from the last mark price update. As such the margin released should be calculated as: + +```math +\text{margin to remove} = \text{margin required for entire position at VWAP trade price} \cdot \frac{|\text{total size of new trades}|}{|\text{entire position prior to trade}|} +``` + +Note: This requires a calculation of the position's margin at trade time. + +### Changing Sides + +A single order could move a trader from a short to a long position (or vice versa) which either increases or decreases the required margin. When this occurs, the trade should be seen as two steps. One in which the position is reduced to zero (and so margin can be released) followed immediately by one which increases to the new position. (Note that these should *not* be two separate trades, merely modelled as such. The two account movements should occur at once with no other changes allowed between them). + + +### Position Resolution + +Isolated margin acts slightly differently to cross margining mode at times when the position becomes distressed. In the case of an open position dropping below maintenance margin levels active orders will remain active as these are margined separately and will not be cancelled. + +However in addition at each margin calculation update the returned `order margin` from the calculator should be compared to the balance in the `order margin account`. If the margin calculator `order margin > order margin account balance` all orders should be cancelled and the funds returned to the general account (any active positions will remain untouched and active). + +### Setting margin mode + +When isolated margin mode is enabled, amount to be transferred is a fraction of the position's notional size that must be specified by the user when enabling isolated margin mode. + +The transaction to update/change margin mode can be included in a batch transaction in order to allow updates when placing an order. + +When in isolated margin mode, it is possible to request to both increase or decrease the margin factor setting: + +- The protocol will attempt to set the funds within the margin account equal to `average entry price * current position * new margin factor`. This value must be above the `initial margin` for the current position or the transaction will be rejected. + - If this is less than the balance currently in the margin account, the difference will be moved from the margin account to the general account + - If this is larger than the balance currently in the margin account, the difference will be moved from the general account to the margin account. If there are not enough funds to complete this transfer, the transaction will be rejected and no change of margin factor will occur. + +When switching to isolated margin mode, the following steps will be taken: + + 1. For any active position, calculate `average entry price * abs(position) * margin factor`. Calculate the amount of funds which will be added to, or subtracted from, the general account in order to do this. If additional funds must be added which are not available, reject the transaction immediately. + 2. For any active orders, calculate the quantity `limit price * remaining size * margin factor` which needs to be placed in the order margin account. Add this amount to the difference calculated in step 1. If this amount is less than or equal to the amount in the general account, perform the transfers (first move funds into/out of margin account, then move funds into the order margin account). If there are insufficient funds, reject the transaction. + 3. Move account to isolated margin mode on this market + +When switching from isolated margin mode to cross margin mode, the following steps will be taken: + + 1. Any funds in the order margin account will be moved to the margin account. + 2. At this point trading can continue with the account switched to the cross margining account type. If there are excess funds in the margin account they will be freed at the next margin release cycle. + ## Reference Level Explanation The calculator takes as inputs: @@ -112,9 +232,10 @@ The calculator takes as inputs: 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. -and returns 4 margin requirement levels +and returns 5 margin requirement levels 1. Maintenance margin +1. Order margin 1. Collateral search level 1. Initial margin 1. Collateral release level @@ -125,7 +246,7 @@ and returns 4 margin requirement levels 1. Calculate the maintenance margin for the riskiest short position. 1. Select the maintenance margin that is highest out of steps 1 & 2. 1. Scale this maintenance margin by the margin level scaling factors. -1. Return 4 numbers: the maintenance margin, collateral search level, initial margin and collateral release level. +1. Return 5 numbers: the maintenance margin, order margin, collateral search level, initial margin and collateral release level. ## Calculation of riskiest long and short positions @@ -197,7 +318,35 @@ where meanings of terms in Step 1 apply except for: ### **Step 3** -`maintenance_margin = max ( maintenance_margin_long, maintenance_margin_short)` +If `open_volume > 0`: + +`maintenance_margin = max(min(open_volume * slippage_per_unit, product.value(market_observable) * (open_volume * market.maxSlippageFraction[1] + open_volume^2 * market.maxSlippageFraction[2])), 0) + + open_volume * [ quantitative_model.risk_factors_long ] . [ Product.value(market_observable) ]` +where + +`slippage_per_unit = max(0, Product.value(market_observable) - Product.value(exit_price))` + +If `open_volume < 0`: + +```formula +maintenance_margin + = max(min(abs(open_volume) * slippage_per_unit, mark_price * (abs(open_volume) * market.maxSlippageFraction[1] + abs(slippage_volume)^2 * market.maxSlippageFraction[2])), 0) + + abs(open_volume) * [ quantitative_model.risk_factors_short ] . [ Product.value(market_observable) ]` +``` + +where + +`slippage_per_unit = max(0, Product.value(market_observable) - Product.value(exit_price))` + +If `open_volume == 0`: + +`maintenance_margin = 0` + +### **Step 4** + +`maintenance_margin_with_orders = max(maintenance_margin_long, maintenance_margin_short)` + +`order_margin = maintenance_margin_with_orders - maintenance_margin` ## Margin calculation for auctions @@ -215,7 +364,7 @@ Note that because the order book is empty during auctions we will always end up ## Scaling other margin levels -### **Step 4** +### **Step 5** The other three margin levels are scaled relative to the maintenance margin level, using scaling levels defined in the risk parameters for a market. @@ -287,10 +436,19 @@ Since riskiest short == 0 then maintenance_margin_short = 0 # Step 3 -maintenance_margin = max ( 677.6, 0) = 677.6 +Since open_volume == 10 + +maintenance_margin = max(min(open_volume * slippage_per_unit, product.value(market_observable) * (open_volume * market.maxSlippageFraction[1] + open_volume^2 * market.maxSlippageFraction[2])), 0) + + open_volume * [ 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 = max(min(476, 532.224), 0) + 10 * 0.1 * 144 = 620 # Step 4 +maintenance_margin_with_orders = max ( 677.6, 0) = 677.6 +order_margin = 677.6 - 620 = 57.6 + +# Step 5 + 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 @@ -328,3 +486,4 @@ riskiest short: -1 ## SCENARIOS Scenarios found [here](https://docs.google.com/spreadsheets/d/1VXMdpgyyA9jp0hoWcIQTUFrhOdtu-fak/edit#gid=1586131462) + diff --git a/protocol/0074-BTCH-batch-market-instructions.md b/protocol/0074-BTCH-batch-market-instructions.md index 3bc322faf..193b20a25 100644 --- a/protocol/0074-BTCH-batch-market-instructions.md +++ b/protocol/0074-BTCH-batch-market-instructions.md @@ -25,12 +25,13 @@ Overall, building the ability to handle batches of market instructions in a sing - **Cancellations**: this is a list (repeated field) of Cancel Order instructions - **Amendments**: this is a list (repeated field) of Amend Order instructions - **Submissions**: this is a list (repeated field) of Submit Order instructions -- The total number of instructions across all three lists (i.e. sum of the lengths of the lists) must be less than or equal to the current value of the network parameter `network.spam_protection.max.batch.size`. +- Additionally the batch may contain a single transaction to change the current margin mode. +- The total number of instructions across all three lists (i.e. sum of the lengths of the lists) must be less than or equal to the current value of the network parameter `network.spam_protection.max.batch.size`. The margin mode update transaction is not included in this limit. ### Processing a batch - A batch is considered a single transaction, with a single transaction ID and a single timestamp applying to all instructions within it. Each instruction should be given a sub-identifier and index allowing it to be placed sequentially in the transaction (e.g. by consumers of the event stream). These identifiers must be sufficient for a user to determine which instruction within a batch any result (order updates, trades, errors, etc.) relates to. -- The batches must be processed in the order **all cancellations, then all amendments, then all submissions**. This is to prevent gaming the system, and to prevent any order being modified by more than one action in the batch. +- The batches must be processed in the order **all cancellations, then all amendments, any margin mode update, then all submissions**. This is to prevent gaming the system, and to prevent any order being modified by more than one action in the batch. Updating the margin mode after cancellations and amendments allows the party to have control of which orders are outstanding when the margin mode changes. - When processing each list, the instructions within the list must be processed in the order they appear in the list (i.e. in the order prescribed by the submitter). (Notwithstanding that each list is processed in its entirety before moving onto the next list, in the order specified above). - All instructions within each list must be validated as normal **at the time that the instruction is processed**. That is, instructions cannot be pre-validated as a batch. If a prior instruction, would create a state that would cause a later instruction to fail validation, the later instruction must fail validation (and vice verse). If validation fails, that instruction must be skipped and the subsequent instructions must still be processed. Any validation or other errors should be returned, as well as a reference to the instruction to which they relate, in the response. - Any errors encountered in processing an instruction after it passes validation must cause it to be skipped, and the errors, as well as the instruction to which they relate, must be available in the result of the transaction. diff --git a/wordlist.txt b/wordlist.txt index 7ca46810b..0211e4688 100644 --- a/wordlist.txt +++ b/wordlist.txt @@ -1,3 +1,4 @@ +$VEGA ABCI ABCI++ ABI @@ -12,6 +13,7 @@ asynchrony atomicity Auth authorisable +avatarUrl AVL bip blockchain @@ -30,8 +32,6 @@ cdot ceil ceiled CFD -CSF -CSV checkpointing CLEF closedout @@ -45,14 +45,18 @@ composable config cosmovisor counterparty +CQRS +CreateReferralSet crypto cryptocurrencies cryptographic -CQRS +CSF +CSV cumulated customisable customised DAI +dApp datanode datapoint datatypes @@ -70,6 +74,7 @@ discoverability disincentivise DLT DPOS +DS durations earlyExitPenalty ECDSA @@ -78,12 +83,13 @@ EIP ELS encodings ENE +enum enums EOS ERC +ERC-1155 ERC-20 ERC-721 -ERC-1155 ETH ETH's ETHB @@ -126,14 +132,15 @@ IBC incentivise incentivised incrementing +infty init initialisation initialise initialised initialising +int64 integrations intrablock -int64 IOC JSON keyholder @@ -141,7 +148,10 @@ keypair keypairs keystore KMS +ldots +leaderboards leftarrow +leq lifecycle linearisation linearised @@ -160,10 +170,10 @@ malus margined margining marketID -messager math mempool Merkle +messager MetaMask microstructure midprice @@ -201,10 +211,13 @@ protobuf Pseudocode pseudorandom pubkey +quant rata +recollateralise +ReferralSet reimplemented -repo renormalise +repo reponse repurpose resync @@ -215,19 +228,21 @@ Ropsten RPC runnable runtime -scalable scalability +scalable Scholes selectable sepolia serialisation SHA -sharded SHA3 +sharded siskas SLA Solana src +SSD +SSL stablecoin stablecoins stakers @@ -235,8 +250,6 @@ statebridge stateful statesync structs -SSD -SSL suboptimal subtype subtypes @@ -246,6 +259,7 @@ sybil sybils tau TBC +teamUrl Tendermint testnet testnets @@ -253,35 +267,35 @@ TIF TODO tokenholder tokenholders -tradable trackable +tradable Tron trustless TWAP tx TXs -quant UI uint -unmarshal unamended unassociated unbanned undelegate -undelegates undelegated +undelegates undelegating undelegation undelegations undeployed unencrypted unitless +unmarshal unnominated unnormalised unstake unstaked unstakes unstaking +untriggered unvested url USD @@ -289,8 +303,8 @@ USDC USDT UTC validator -validators validator's +validators vega vegaprotocol vegatools @@ -303,19 +317,7 @@ VW VWAP walkthrough walkthroughs -wei wBTC +wei whitepaper Yubikey -$VEGA -DS -teamUrl -avatarUrl -dApp -leaderboards -ReferralSet -CreateReferralSet -enum -ldots -infty -leq From 1d784883e67433fd01c70fbab9722100b8c078f6 Mon Sep 17 00:00:00 2001 From: Charlie Date: Mon, 30 Oct 2023 10:23:19 +0000 Subject: [PATCH 0660/1171] feat: fixed size amendments --- protocol/0004-AMND-amends.md | 20 ++++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/protocol/0004-AMND-amends.md b/protocol/0004-AMND-amends.md index 73848c678..e20294773 100644 --- a/protocol/0004-AMND-amends.md +++ b/protocol/0004-AMND-amends.md @@ -4,9 +4,9 @@ - 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) +- Size change amends specifying a size greater than the current size remove and reinsert the order at the back of the price level and increase the remaining amount accordingly (0004-AMND-055). +- Size change amends specifying a size lower than the current size leave the order in its current spot and reduce the remaining amount of the order accordingly (0004-AMND-056). +- Size change amends which would result in the remaining part of the order being reduced below zero should instead cancel the order (0004-AMND-057). - 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) @@ -42,7 +42,7 @@ The amend order can alter the quantity, price and expiry time/`TIF` type. For pe ## Guide-level explanation -The amend order message is a custom message containing the `orderID` of the original order and optional fields that can be altered. Prices can be changed with a new absolute value, quantity can be reduced or increased from their current remaining size. Expiry time can be set to a new value and the `TIF` type can be toggled between `GTC` and `GTT`. Changing the `TIF` field will impact the value in the `ExpiryTime` field as it will either be blanked or set to a new valid value. +The amend order message is a custom message containing the `orderID` of the original order and optional fields that can be altered. Prices and sizes can be changed with new absolute values. Expiry time can be set to a new value and the `TIF` type can be toggled between `GTC` and `GTT`. Changing the `TIF` field will impact the value in the `ExpiryTime` field as it will either be blanked or set to a new valid value. Some examples: A LIMIT order sitting on the bid side of the order book: @@ -54,7 +54,7 @@ If I send an amend with the following details: ```json amendOrder{ orderID: "V0000000001-0000000001" - sizeDelta: 200 + size: 300 } ``` @@ -85,8 +85,8 @@ The fields which can be altered are: - `Price` - Amending the price causes the order to be removed from the book and re-inserted at the new price level. This can result in the order being filled if the price is moved to a level that would cross. -- `SizeDelta` - - A size change is specified as a delta to the current amount. This will be applied to both the `Size` and `Remaining` part of the order. In the case that the remaining amount it reduced to zero or less, the order is cancelled. This must be a multiple of the smallest value allowed by the `Position Decimal Places` (PDP) specified in the [Market Framework](./0001-MKTF-market_framework.md), i.e. is PDP = 2 then `SizeDelta` must be a whole multiple of 0.01. (NB: `SizeDelta` may use an int64 where the int value 1 is the smallest multiple allowable given the configured dp). In case PDP is negative this again applies e.g. if PDP = -1 then `SizeDelta` must be a whole multiple of 10. +- `Size` + - Amending the size causes the the `Size` and `Remaining` part of the order to be amended by the difference between the original and amended size. In the case that the remaining amount it reduced to zero or less, the order is cancelled. This must be a multiple of the smallest value allowed by the `Position Decimal Places` (PDP) specified in the [Market Framework](./0001-MKTF-market_framework.md), i.e. is PDP = 2 then `Size` must be a whole multiple of 0.01. (NB: `Size` may use an int64 where the int value 1 is the smallest multiple allowable given the configured dp). In case PDP is negative this again applies e.g. if PDP = -1 then `Size` must be a whole multiple of 10. - `TimeInForce` - The `TIF` enumeration can only be toggled between `GTT` and `GTC`. Amending to `GTT` requires an `expiryTime` value to be set. Amending to `GTC` removes the `expiryTime` value. - `ExpiryTime` @@ -106,14 +106,14 @@ To keep all versions of an order available for historic lookup, when an order is message amendOrder { string orderID 1 [(validator.field) = {string_not_empty : true}]; uint64 price 2; - int64 sizeDelta 3; + int64 size 3; enum TIF 4; int64 expiryTime 5; PeggedOrder *peggedOrder 6; } ``` -An example of using a negative size is shown below: +An example of reducing the size is shown below: `Bids: 100@1000 GTC (OrderID V0000000001-0000000001)` @@ -121,7 +121,7 @@ If we send the following `amendOrder`: ```json amendOrder{ orderID:"V0000000001-0000000001", - sizeDelta: -50 } + size: 50 } ``` The resulting order book will be: From 782749f7d92bb92e1d24d324c30a027a30191390 Mon Sep 17 00:00:00 2001 From: Charlie Date: Mon, 30 Oct 2023 10:24:00 +0000 Subject: [PATCH 0661/1171] feat: update features --- protocol/features.json | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/protocol/features.json b/protocol/features.json index eef5b3bf7..3bfcf6b73 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -914,6 +914,14 @@ "0081-SUCM-034" ] }, + "Fixed Aize Amendments": { + "milestone": "deployment-3", + "acs": [ + "0004-AMND-055", + "0004-AMND-056", + "0004-AMND-057" + ] + }, "Unknown": { "milestone": "unknown", "acs": [] From f9776979dfc2976d6d7a7f31544f8e88fc2bb3dd Mon Sep 17 00:00:00 2001 From: Charlie Date: Mon, 30 Oct 2023 10:34:24 +0000 Subject: [PATCH 0662/1171] fix: remove deprecated acs --- protocol/features.json | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/protocol/features.json b/protocol/features.json index 3bfcf6b73..8af84a962 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -649,8 +649,6 @@ "0008-TRAD-008", "0004-AMND-030", "0004-AMND-031", - "0004-AMND-032", - "0004-AMND-033", "0004-AMND-034", "0004-AMND-035", "0004-AMND-036", @@ -914,7 +912,7 @@ "0081-SUCM-034" ] }, - "Fixed Aize Amendments": { + "Fixed Size Amendments": { "milestone": "deployment-3", "acs": [ "0004-AMND-055", From 665e2b201378534bded5f44489abe59b697089b1 Mon Sep 17 00:00:00 2001 From: Gordsport <83510148+gordsport@users.noreply.github.com> Date: Thu, 2 Nov 2023 15:54:05 +0000 Subject: [PATCH 0663/1171] chore: tidy up the features.json for palazzo milestone (#2030) * chore: tidy up the features.json for palazzo milestone This archives off the cosmic features.json file and tidies up current one ready for the addition of more palazzo ACs * fix: json liniting error * chore: remove not yet merged ACs from features.json * fix: more ACs * fix: typo --- protocol/cosmic-features.json | 927 +++++++++++++++++++++++++++++++++ protocol/features.json | 930 +++------------------------------- 2 files changed, 988 insertions(+), 869 deletions(-) create mode 100644 protocol/cosmic-features.json diff --git a/protocol/cosmic-features.json b/protocol/cosmic-features.json new file mode 100644 index 000000000..8af84a962 --- /dev/null +++ b/protocol/cosmic-features.json @@ -0,0 +1,927 @@ +{ + "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-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-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-008", + "0081-SUCM-027", + "0081-SUCM-009", + "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-035" + ] + }, + "Transfers by governance": { + "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", + "0028-GOVE-154", + "0028-GOVE-155", + "0028-GOVE-156", + "0028-GOVE-157", + "0028-GOVE-158", + "0055-TREA-011", + "0013-ACCT-032", + "0013-ACCT-026", + "0013-ACCT-027", + "0013-ACCT-028" + ] + }, + "Perpetuals": { + "milestone": "deployment-2", + "acs": [ + "0001-MKTF-005", + "0001-MKTF-011", + "0001-MKTF-012", + "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", + "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", + "0051-PROD-009", + "0070-MKTD-017", + "0070-MKTD-018", + "0070-MKTD-019", + "0073-LIMN-105", + "0073-LIMN-106", + "0073-LIMN-107", + "0073-LIMN-108", + "0073-LIMN-109", + "0073-LIMN-110", + "0073-LIMN-111", + "0081-SUCM-002", + "0081-SUCM-015", + "0014-ORDT-120", + "0014-ORDT-121", + "0014-ORDT-122", + "0014-ORDT-123", + "0053-PERP-024" + ] + }, + "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-047", + "0082-ETHD-048", + "0082-ETHD-049", + "0082-ETHD-050", + "0082-ETHD-051" + ] + }, + "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", + "0042-LIQF-053", + "0042-LIQF-054", + "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-060", + "0044-LIME-028", + "0044-LIME-032", + "0044-LIME-033", + "0044-LIME-034", + "0044-LIME-036", + "0044-LIME-062", + "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-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", + "0044-LIME-101", + "0044-LIME-102", + "0026-AUCT-016", + "0026-AUCT-017", + "0026-AUCT-018", + "0026-AUCT-019", + "0026-AUCT-020", + "0026-AUCT-021", + "0026-AUCT-022", + "0034-PROB-004", + "0042-LIQF-055" + ] + }, + "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-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", + "0083-RFPR-041", + "0083-RFPR-042", + "0083-RFPR-043", + "0083-RFPR-046", + "0083-RFPR-047", + "0083-RFPR-048", + "0083-RFPR-049", + "0083-RFPR-050", + "0083-RFPR-051", + "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", + "0084-VDPR-015", + "0084-VDPR-016", + "0084-VDPR-017", + "0029-FEES-023", + "0029-FEES-024", + "0029-FEES-025", + "0029-FEES-026", + "0029-FEES-027", + "0029-FEES-028", + "0029-FEES-029", + "0029-FEES-030", + "0029-FEES-031", + "0029-FEES-032", + "0029-FEES-033", + "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": { + "milestone": "deployment-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", + "0085-RVST-014", + "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", + "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" + ] + }, + "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": [ + "0028-GOVE-064", + "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", + "0028-GOVE-137", + "0028-GOVE-138", + "0028-GOVE-139", + "0028-GOVE-111", + "0028-GOVE-150", + "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", + "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-029", + "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-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" + ] + }, + "Fixed Size Amendments": { + "milestone": "deployment-3", + "acs": [ + "0004-AMND-055", + "0004-AMND-056", + "0004-AMND-057" + ] + }, + "Unknown": { + "milestone": "unknown", + "acs": [] + } +} diff --git a/protocol/features.json b/protocol/features.json index 8af84a962..fea4b333d 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -1,520 +1,53 @@ { "Iceberg Orders": { - "milestone": "deployment-1", + "milestone": "cosmic", "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-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" + "0014-ORDT-069" ] }, "Successor Markets": { - "milestone": "deployment-1", + "milestone": "cosmic", "acs": [ - "0001-MKTF-006", - "0001-MKTF-007", "0001-MKTF-008", - "0001-MKTF-009", - "0001-MKTF-010", - "0028-GOVE-071", - "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-008", - "0081-SUCM-027", - "0081-SUCM-009", - "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-035" ] }, - "Transfers by governance": { - "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", - "0028-GOVE-154", - "0028-GOVE-155", - "0028-GOVE-156", - "0028-GOVE-157", - "0028-GOVE-158", - "0055-TREA-011", - "0013-ACCT-032", - "0013-ACCT-026", - "0013-ACCT-027", - "0013-ACCT-028" - ] - }, - "Perpetuals": { - "milestone": "deployment-2", - "acs": [ - "0001-MKTF-005", - "0001-MKTF-011", - "0001-MKTF-012", - "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", - "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", - "0051-PROD-009", - "0070-MKTD-017", - "0070-MKTD-018", - "0070-MKTD-019", - "0073-LIMN-105", - "0073-LIMN-106", - "0073-LIMN-107", - "0073-LIMN-108", - "0073-LIMN-109", - "0073-LIMN-110", - "0073-LIMN-111", - "0081-SUCM-002", - "0081-SUCM-015", - "0014-ORDT-120", - "0014-ORDT-121", - "0014-ORDT-122", - "0014-ORDT-123", - "0053-PERP-024" - ] - }, - "Ethereum Oracles": { - "milestone": "deployment-2", + "Ethereum oracles": { + "milestone": "cosmic", "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-047", - "0082-ETHD-048", - "0082-ETHD-049", - "0082-ETHD-050", - "0082-ETHD-051" - ] - }, - "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", - "0042-LIQF-053", - "0042-LIQF-054", - "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-060", - "0044-LIME-028", - "0044-LIME-032", - "0044-LIME-033", - "0044-LIME-034", - "0044-LIME-036", - "0044-LIME-062", - "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-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", - "0044-LIME-101", - "0044-LIME-102", - "0026-AUCT-016", - "0026-AUCT-017", - "0026-AUCT-018", - "0026-AUCT-019", - "0026-AUCT-020", - "0026-AUCT-021", - "0026-AUCT-022", - "0034-PROB-004", - "0042-LIQF-055" + "0082-ETHD-041" ] }, "Referral program": { - "milestone": "deployment-2", + "milestone": "cosmic", "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-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", - "0083-RFPR-041", - "0083-RFPR-042", - "0083-RFPR-043", - "0083-RFPR-046", - "0083-RFPR-047", - "0083-RFPR-048", - "0083-RFPR-049", - "0083-RFPR-050", - "0083-RFPR-051", - "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", - "0084-VDPR-015", - "0084-VDPR-016", - "0084-VDPR-017", - "0029-FEES-023", - "0029-FEES-024", - "0029-FEES-025", - "0029-FEES-026", - "0029-FEES-027", - "0029-FEES-028", - "0029-FEES-029", - "0029-FEES-030", - "0029-FEES-031", - "0029-FEES-032", - "0029-FEES-033", - "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": { - "milestone": "deployment-2", + "Stop Orders": { + "milestone": "cosmic", "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", - "0085-RVST-014", - "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", - "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" + "0079-TGAP-004", + "0079-TGAP-005" + ] + }, + "Perpetuals": { + "milestone": "palazzo", + "acs": [ + "0073-LIMN-105", + "0073-LIMN-107", + "0073-LIMN-108", + "0073-LIMN-110", + "0073-LIMN-111", + "0081-SUCM-015", + "0053-PERP-024" ] }, "Team rewards": { - "milestone": "deployment-3", + "milestone": "palazzo", "acs": [ "0056-REWA-095", "0056-REWA-096", @@ -532,392 +65,51 @@ "0056-REWA-108" ] }, - "Market governance": { - "milestone": "deployment-2", + "Fixed size amendments": { + "milestone": "palazzo", "acs": [ - "0028-GOVE-064", - "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", - "0028-GOVE-137", - "0028-GOVE-138", - "0028-GOVE-139", - "0028-GOVE-111", - "0028-GOVE-150", - "0028-GOVE-151", - "0028-GOVE-152" + "0004-AMND-055", + "0004-AMND-056", + "0004-AMND-057" ] }, - "Batch change proposals": { - "milestone": "deployment-3", - "acs": [ - "0028-GOVE-145", - "0028-GOVE-146", - "0028-GOVE-147", - "0028-GOVE-148", - "0028-GOVE-149" - ] + "Ethereum heartbeat": { + "milestone": "palazzo", + "acs": [] + }, + "Margin isolation": { + "milestone": "palazzo", + "acs": [] }, - "Spot": { - "milestone": "deployment-3", + "Quadratic slippage removal": { + "milestone": "palazzo", "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-029", - "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-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" + "0019-MCAL-024", + "0019-MCAL-025", + "0019-MCAL-026", + "0019-MCAL-027", + "0019-MCAL-028", + "0019-MCAL-029" ] }, - "Fixed Size Amendments": { - "milestone": "deployment-3", + "Modify liquidation mechanics": { + "milestone": "palazzo", + "acs": [] + }, + "Passive liquidity": { + "milestone": "palazzo", + "acs": [] + }, + "Batch governance proposals": { + "milestone": "palazzo", + "acs": [] + }, + "Transfer fee cap": { + "milestone": "palazzo", "acs": [ - "0004-AMND-055", - "0004-AMND-056", - "0004-AMND-057" + "0057-TRAN-011", + "0057-TRAN-064", + "0057-TRAN-065" ] }, "Unknown": { From c295e900c3b7dda4e75932cd8ff71e9375be2c8c Mon Sep 17 00:00:00 2001 From: wwestgarth Date: Mon, 6 Nov 2023 09:45:22 +0000 Subject: [PATCH 0664/1171] chore: add AC's for liquidity fee setting methods --- ...042-LIQF-setting_fees_and_rewarding_lps.md | 48 +++++++++++++++---- protocol/features.json | 4 +- 2 files changed, 41 insertions(+), 11 deletions(-) diff --git a/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md b/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md index 16966a06e..127e7d7d0 100644 --- a/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md +++ b/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md @@ -38,7 +38,7 @@ We now find the smallest integer `k` such that `[target stake] < sum from i=1 to Finally, we set the liquidity-fee-factor for this market to be the fee `LP-k-liquidity-fee-factor`. -### Example for fee setting mechanism using the marginal cost method +#### Example for fee setting mechanism using the marginal cost method 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. @@ -53,6 +53,41 @@ In the example below there are 3 liquidity providers all bidding for their chose 1. If the `target stake = 240` then even putting all the liquidity supplied above does not meet the estimated market liquidity demand and thus we set `k=N` and so the market's liquidity-fee-factor is `LP N fee = LP 3 fee = 3.75%`. 1. Initially (before market opened) the `[target stake]` is by definition zero (it's not possible to have a position on a market that's not opened yet). Hence by default the market's initial liquidity-fee-factor is the lowest liquidity-fee-factor. + +### Stake-weighted-average method for setting the liquidity fee factor + +The liquidity fee factor is set as the weighted average of the liquidity fee factors, with weights assigned based on the supplied stake from each liquidity provider, which can also account for the impact of one supplier's actions on others. + +#### Example for fee setting mechanism using the Stake-weighted-average method + +In the example below there are 3 liquidity providers all bidding for their chosen fee level. The overall liquidity fee factor is the weight-average of their nominations: + +```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%] + +then + +liquidity-fee-factor = (120 * 0.05) + (20 * 0.075) + (60 8 0.0375) / (120 + 20 + 160) = 0.04875 +``` + +### "Constant Liquidity Fee" Method + +The liquidity fee factor is set to a constant directly as part of the market proposal. + +#### Example for fee setting mechanism using the constant method + +In the example below there are 3 liquidity providers all bidding for their chosen fee level and the overall liquidity fee factor is: + +```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%] +``` + +but the market was proposed with a constant fee of 0.08 so that is what the liquidity-fee-factor will be. + ### 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. @@ -61,7 +96,7 @@ Once the market opens (opening auction starts) a clock starts ticking. We calcul At time of call: -- The `liquidity-fee-factor` for the market. +- The `liquidity-fee-factor` for the market, and the method used to calculate it. - Current liquidity provider commitments and their individually nominated fee factors - [Target stake](./0041-TSTK-target_stake.md) @@ -180,14 +215,6 @@ An existing LP has `average entry valuation 1090.9` and `S=110`. Currently the s (average entry valuation) = 1090.9 ``` -### Stake-weighted-average method for setting the liquidity fee factor - -The liquidity fee factor is set as the weighted average of the liquidity fee factors, with weights assigned based on the supplied stake from each liquidity provider, which can also account for the impact of one supplier's actions on others. - -### "Constant Liquidity Fee" Method - -The liquidity fee factor is set to a constant directly as part of the market proposal. - ### Calculating the instantaneous liquidity score @@ -324,6 +351,7 @@ Each LP further gets a performance bonus: $b_i \times B$ with a transfer type th - Liquidity fee factors are recalculated every time the liquidity demand estimate changes. (0042-LIQF-005) - 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) +- A market can be proposed with a choice of liquidity fee settings. These settings can be updated by a subsequent market update proposal. (0042-LIQF-056) ### CHANGE OF NETWORK PARAMETERS TESTS diff --git a/protocol/features.json b/protocol/features.json index fea4b333d..06b9cc1cc 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -94,7 +94,9 @@ }, "Modify liquidation mechanics": { "milestone": "palazzo", - "acs": [] + "acs": [ + "0042-LIQF-056" + ] }, "Passive liquidity": { "milestone": "palazzo", From 5b22c3166063589beaf8cb5331ccb53fede42c21 Mon Sep 17 00:00:00 2001 From: wwestgarth Date: Mon, 6 Nov 2023 10:16:51 +0000 Subject: [PATCH 0665/1171] Update protocol/0042-LIQF-setting_fees_and_rewarding_lps.md Co-authored-by: Jiajia-Cui <92106936+Jiajia-Cui@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 127e7d7d0..f519e0c47 100644 --- a/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md +++ b/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md @@ -86,7 +86,7 @@ In the example below there are 3 liquidity providers all bidding for their chose [LP 3 stake = 60 ETH, LP 3 liquidity-fee-factor = 3.75%] ``` -but the market was proposed with a constant fee of 0.08 so that is what the liquidity-fee-factor will be. +but the market was proposed with a constant fee of 0.8% so that is what the liquidity-fee-factor will be. ### Timing market's liquidity-fee-factor changes From d5d48f82d96be81142389e56a43330d6ae03a015 Mon Sep 17 00:00:00 2001 From: wwestgarth Date: Mon, 6 Nov 2023 10:39:40 +0000 Subject: [PATCH 0666/1171] Update protocol/0042-LIQF-setting_fees_and_rewarding_lps.md Co-authored-by: Jiajia-Cui <92106936+Jiajia-Cui@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 f519e0c47..b301afb94 100644 --- a/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md +++ b/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md @@ -69,7 +69,7 @@ In the example below there are 3 liquidity providers all bidding for their chose then -liquidity-fee-factor = (120 * 0.05) + (20 * 0.075) + (60 8 0.0375) / (120 + 20 + 160) = 0.04875 +liquidity-fee-factor = ((120 * 0.5%) + (20 * 0.75%) + (60 * 3.75%)) / (120 + 20 + 60) = 1.5% ``` ### "Constant Liquidity Fee" Method From 2c06f9b8c6a0a566358a51c0c228e6ec693d02cd Mon Sep 17 00:00:00 2001 From: Charlie Date: Fri, 3 Nov 2023 11:41:28 +0000 Subject: [PATCH 0667/1171] feat: remove restrictions for transferring from a vested account --- protocol/0057-TRAN-transfers.md | 9 +++++++-- protocol/0085-RVST-rewards_vesting.md | 2 +- protocol/features.json | 8 ++++++++ 3 files changed, 16 insertions(+), 3 deletions(-) diff --git a/protocol/0057-TRAN-transfers.md b/protocol/0057-TRAN-transfers.md index 1ff56e19a..8e8f5e7bf 100644 --- a/protocol/0057-TRAN-transfers.md +++ b/protocol/0057-TRAN-transfers.md @@ -39,9 +39,11 @@ 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-ASSF-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`. +If a user is transferring funds from a vested account, if their balance (expressed in quantum) is less than the minimum amount, they should be able to transfer the full balance (note, transferring less then the full balance is not permitted). + ## Recurring transfers A party can also setup recurring transfers which will happen at the end of every epoch, before the next epoch begins. @@ -153,7 +155,7 @@ 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](0061-REWP-pos_rewards.md). For recurring transfers, the fee is charged each time the transfer occurs. +A fee is taken from all transfers (except transfers from a vested account), 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 determined by the `transfer.fee.factor` and is subject to a cap defined by the multiplier `transfer.fee.maxQuantumAmount` as specified in the network parameters, which governs the proportion of each transfer taken as a fee. @@ -243,6 +245,9 @@ message CancelTransfer { - 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 I can do a transfer from a vested account without incurring any fees (0057-TRAN-066). +- As a user, I **can not** transfer a quantum amount less than `transfer.fee.minTransferQuantumAmount` from any of the valid accounts excluding a vested account (0057-TRAN-067). +- As a user, I **can** transfer a quantum amount less than `transfer.fee.minTransferQuantumAmount` from a vested account if and only if I transfer the full balance (0057-TRAN-068). - 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. diff --git a/protocol/0085-RVST-rewards_vesting.md b/protocol/0085-RVST-rewards_vesting.md index c94c4ae84..51c0a5621 100644 --- a/protocol/0085-RVST-rewards_vesting.md +++ b/protocol/0085-RVST-rewards_vesting.md @@ -32,7 +32,7 @@ When transferring funds from the vesting account to the vested account, a new tr ## 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. +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. When transferring funds from a vested account a party will incur no transfer fees and if transferring the full balance they will not be subject to the minimum quantum transfer amount. 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. diff --git a/protocol/features.json b/protocol/features.json index 06b9cc1cc..9bd124602 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -114,6 +114,14 @@ "0057-TRAN-065" ] }, + "Transfers from vesting": { + "milestone": "palazzo", + "acs": [ + "0057-TRAN-066", + "0057-TRAN-067", + "0057-TRAN-068" + ] + }, "Unknown": { "milestone": "unknown", "acs": [] From f29933eff7992481cf90e0ad6fffbf442366a14b Mon Sep 17 00:00:00 2001 From: Charlie Date: Fri, 3 Nov 2023 16:36:50 +0000 Subject: [PATCH 0668/1171] feat: apply suggestions for restricting fee less transfers to general only Co-authored-by: David Siska <62546419+davidsiska-vega@users.noreply.github.com>[A --- protocol/0057-TRAN-transfers.md | 5 +++-- protocol/0085-RVST-rewards_vesting.md | 3 ++- protocol/features.json | 3 ++- 3 files changed, 7 insertions(+), 4 deletions(-) diff --git a/protocol/0057-TRAN-transfers.md b/protocol/0057-TRAN-transfers.md index 8e8f5e7bf..5de3b71a4 100644 --- a/protocol/0057-TRAN-transfers.md +++ b/protocol/0057-TRAN-transfers.md @@ -155,7 +155,7 @@ Note: if there is no market with contribution to the reward metric - no transfer ## Fees -A fee is taken from all transfers (except transfers from a vested account), 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. +A fee is taken from all transfers (except transfers from a vested account to a general account held by the same key), 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 determined by the `transfer.fee.factor` and is subject to a cap defined by the multiplier `transfer.fee.maxQuantumAmount` as specified in the network parameters, which governs the proportion of each transfer taken as a fee. @@ -245,7 +245,8 @@ message CancelTransfer { - 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 I can do a transfer from a vested account without incurring any fees (0057-TRAN-066). +- As a user I can do a transfer from a vested account to a general account held by the same key without incurring any fees (0057-TRAN-066). +- As a user I can do a transfer from a vested account to another account that isn't general account for my key but in this case transfer fees are incurred (0057-TRAN-069). - As a user, I **can not** transfer a quantum amount less than `transfer.fee.minTransferQuantumAmount` from any of the valid accounts excluding a vested account (0057-TRAN-067). - As a user, I **can** transfer a quantum amount less than `transfer.fee.minTransferQuantumAmount` from a vested account if and only if I transfer the full balance (0057-TRAN-068). - As a user, when I initiate a delayed transfer, the funds are taken from my account immediately (0057-TRAN-008) diff --git a/protocol/0085-RVST-rewards_vesting.md b/protocol/0085-RVST-rewards_vesting.md index 51c0a5621..6c4938b58 100644 --- a/protocol/0085-RVST-rewards_vesting.md +++ b/protocol/0085-RVST-rewards_vesting.md @@ -32,7 +32,8 @@ When transferring funds from the vesting account to the vested account, a new tr ## 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. When transferring funds from a vested account a party will incur no transfer fees and if transferring the full balance they will not be subject to the minimum quantum transfer amount. +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. +When transferring funds from a vested account to the general account held by their key a party will incur no transfer fees and if transferring the full balance they will not be subject to the minimum quantum transfer amount. 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. diff --git a/protocol/features.json b/protocol/features.json index 9bd124602..905c8b18a 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -119,7 +119,8 @@ "acs": [ "0057-TRAN-066", "0057-TRAN-067", - "0057-TRAN-068" + "0057-TRAN-068", + "0057-TRAN-069" ] }, "Unknown": { From 8e788de94864e79b674781792975afce94f38407 Mon Sep 17 00:00:00 2001 From: Charlie <99198652+cdummett@users.noreply.github.com> Date: Mon, 6 Nov 2023 10:30:16 +0000 Subject: [PATCH 0669/1171] chore: fix spelling Co-authored-by: Tom --- 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 5de3b71a4..6e6492a88 100644 --- a/protocol/0057-TRAN-transfers.md +++ b/protocol/0057-TRAN-transfers.md @@ -42,7 +42,7 @@ In order to prevent the abuse of user-initiated transfers as spam attack there w 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`. -If a user is transferring funds from a vested account, if their balance (expressed in quantum) is less than the minimum amount, they should be able to transfer the full balance (note, transferring less then the full balance is not permitted). +If a user is transferring funds from a vested account, if their balance (expressed in quantum) is less than the minimum amount, they should be able to transfer the full balance (note, transferring less than the full balance is not permitted). ## Recurring transfers From c5126105e2b910f1fd983f8cd3e765ac56942a13 Mon Sep 17 00:00:00 2001 From: Charlie Date: Thu, 2 Nov 2023 16:52:36 +0000 Subject: [PATCH 0670/1171] Revert "feat: fixed size amendments" This reverts commit 1d784883e67433fd01c70fbab9722100b8c078f6. --- protocol/0004-AMND-amends.md | 20 ++++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/protocol/0004-AMND-amends.md b/protocol/0004-AMND-amends.md index e20294773..73848c678 100644 --- a/protocol/0004-AMND-amends.md +++ b/protocol/0004-AMND-amends.md @@ -4,9 +4,9 @@ - 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) -- Size change amends specifying a size greater than the current size remove and reinsert the order at the back of the price level and increase the remaining amount accordingly (0004-AMND-055). -- Size change amends specifying a size lower than the current size leave the order in its current spot and reduce the remaining amount of the order accordingly (0004-AMND-056). -- Size change amends which would result in the remaining part of the order being reduced below zero should instead cancel the order (0004-AMND-057). +- 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) @@ -42,7 +42,7 @@ The amend order can alter the quantity, price and expiry time/`TIF` type. For pe ## Guide-level explanation -The amend order message is a custom message containing the `orderID` of the original order and optional fields that can be altered. Prices and sizes can be changed with new absolute values. Expiry time can be set to a new value and the `TIF` type can be toggled between `GTC` and `GTT`. Changing the `TIF` field will impact the value in the `ExpiryTime` field as it will either be blanked or set to a new valid value. +The amend order message is a custom message containing the `orderID` of the original order and optional fields that can be altered. Prices can be changed with a new absolute value, quantity can be reduced or increased from their current remaining size. Expiry time can be set to a new value and the `TIF` type can be toggled between `GTC` and `GTT`. Changing the `TIF` field will impact the value in the `ExpiryTime` field as it will either be blanked or set to a new valid value. Some examples: A LIMIT order sitting on the bid side of the order book: @@ -54,7 +54,7 @@ If I send an amend with the following details: ```json amendOrder{ orderID: "V0000000001-0000000001" - size: 300 + sizeDelta: 200 } ``` @@ -85,8 +85,8 @@ The fields which can be altered are: - `Price` - Amending the price causes the order to be removed from the book and re-inserted at the new price level. This can result in the order being filled if the price is moved to a level that would cross. -- `Size` - - Amending the size causes the the `Size` and `Remaining` part of the order to be amended by the difference between the original and amended size. In the case that the remaining amount it reduced to zero or less, the order is cancelled. This must be a multiple of the smallest value allowed by the `Position Decimal Places` (PDP) specified in the [Market Framework](./0001-MKTF-market_framework.md), i.e. is PDP = 2 then `Size` must be a whole multiple of 0.01. (NB: `Size` may use an int64 where the int value 1 is the smallest multiple allowable given the configured dp). In case PDP is negative this again applies e.g. if PDP = -1 then `Size` must be a whole multiple of 10. +- `SizeDelta` + - A size change is specified as a delta to the current amount. This will be applied to both the `Size` and `Remaining` part of the order. In the case that the remaining amount it reduced to zero or less, the order is cancelled. This must be a multiple of the smallest value allowed by the `Position Decimal Places` (PDP) specified in the [Market Framework](./0001-MKTF-market_framework.md), i.e. is PDP = 2 then `SizeDelta` must be a whole multiple of 0.01. (NB: `SizeDelta` may use an int64 where the int value 1 is the smallest multiple allowable given the configured dp). In case PDP is negative this again applies e.g. if PDP = -1 then `SizeDelta` must be a whole multiple of 10. - `TimeInForce` - The `TIF` enumeration can only be toggled between `GTT` and `GTC`. Amending to `GTT` requires an `expiryTime` value to be set. Amending to `GTC` removes the `expiryTime` value. - `ExpiryTime` @@ -106,14 +106,14 @@ To keep all versions of an order available for historic lookup, when an order is message amendOrder { string orderID 1 [(validator.field) = {string_not_empty : true}]; uint64 price 2; - int64 size 3; + int64 sizeDelta 3; enum TIF 4; int64 expiryTime 5; PeggedOrder *peggedOrder 6; } ``` -An example of reducing the size is shown below: +An example of using a negative size is shown below: `Bids: 100@1000 GTC (OrderID V0000000001-0000000001)` @@ -121,7 +121,7 @@ If we send the following `amendOrder`: ```json amendOrder{ orderID:"V0000000001-0000000001", - size: 50 } + sizeDelta: -50 } ``` The resulting order book will be: From 1d16ed589a97e67f9193ab810c10983e73a91383 Mon Sep 17 00:00:00 2001 From: Charlie Date: Thu, 2 Nov 2023 16:59:35 +0000 Subject: [PATCH 0671/1171] feat: support both methods of amending size --- protocol/0004-AMND-amends.md | 33 +++++++++++++++++++++++++++------ 1 file changed, 27 insertions(+), 6 deletions(-) diff --git a/protocol/0004-AMND-amends.md b/protocol/0004-AMND-amends.md index 73848c678..d9530bb38 100644 --- a/protocol/0004-AMND-amends.md +++ b/protocol/0004-AMND-amends.md @@ -4,9 +4,12 @@ - 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) +- Reducing the quantity by specifying a `sizeDelta` 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 using a `sizeDelta` 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 by specifying a `sizeDelta` 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) +- Size change amends specifying a `size` greater than the current size remove and reinsert the order at the back of the price level and increase the remaining amount accordingly (0004-AMND-055). +- Size change amends specifying a `size` lower than the current size leave the order in its current spot and reduce the remaining amount of the order accordingly (0004-AMND-056). +- Size change amends which would result in the remaining part of the order being reduced below zero should instead cancel the order (0004-AMND-057). - 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) @@ -42,7 +45,7 @@ The amend order can alter the quantity, price and expiry time/`TIF` type. For pe ## Guide-level explanation -The amend order message is a custom message containing the `orderID` of the original order and optional fields that can be altered. Prices can be changed with a new absolute value, quantity can be reduced or increased from their current remaining size. Expiry time can be set to a new value and the `TIF` type can be toggled between `GTC` and `GTT`. Changing the `TIF` field will impact the value in the `ExpiryTime` field as it will either be blanked or set to a new valid value. +The amend order message is a custom message containing the `orderID` of the original order and optional fields that can be altered. Prices can be changed with a new absolute value, sizes can be changed by either specifying a size delta or a new absolute value. Expiry time can be set to a new value and the `TIF` type can be toggled between `GTC` and `GTT`. Changing the `TIF` field will impact the value in the `ExpiryTime` field as it will either be blanked or set to a new valid value. Some examples: A LIMIT order sitting on the bid side of the order book: @@ -57,6 +60,14 @@ amendOrder{ sizeDelta: 200 } ``` +or + +```json +amendOrder{ + orderID: "V0000000001-0000000001" + size: 300 +} +``` This will be the resulting order book: @@ -86,7 +97,9 @@ The fields which can be altered are: - `Price` - Amending the price causes the order to be removed from the book and re-inserted at the new price level. This can result in the order being filled if the price is moved to a level that would cross. - `SizeDelta` - - A size change is specified as a delta to the current amount. This will be applied to both the `Size` and `Remaining` part of the order. In the case that the remaining amount it reduced to zero or less, the order is cancelled. This must be a multiple of the smallest value allowed by the `Position Decimal Places` (PDP) specified in the [Market Framework](./0001-MKTF-market_framework.md), i.e. is PDP = 2 then `SizeDelta` must be a whole multiple of 0.01. (NB: `SizeDelta` may use an int64 where the int value 1 is the smallest multiple allowable given the configured dp). In case PDP is negative this again applies e.g. if PDP = -1 then `SizeDelta` must be a whole multiple of 10. + - Amending the size by specifying a sizeDelta will be applied to both the `Size` and `Remaining` part of the order. In the case that the remaining amount it reduced to zero or less, the order is cancelled. This must be a multiple of the smallest value allowed by the `Position Decimal Places` (PDP) specified in the [Market Framework](./0001-MKTF-market_framework.md), i.e. is PDP = 2 then `SizeDelta` must be a whole multiple of 0.01. (NB: `SizeDelta` may use an int64 where the int value 1 is the smallest multiple allowable given the configured dp). In case PDP is negative this again applies e.g. if PDP = -1 then `SizeDelta` must be a whole multiple of 10. +- `Size` + - Amending the size by specifying a new `size` causes the the `Size` and `Remaining` part of the order to be amended by the difference between the original and amended size. In the case that the remaining amount it reduced to zero or less, the order is cancelled. This must be a multiple of the smallest value allowed by the `Position Decimal Places` (PDP) specified in the [Market Framework](./0001-MKTF-market_framework.md), i.e. is PDP = 2 then `Size` must be a whole multiple of 0.01. (NB: `Size` may use an int64 where the int value 1 is the smallest multiple allowable given the configured dp). In case PDP is negative this again applies e.g. if PDP = -1 then `Size` must be a whole multiple of 10. - `TimeInForce` - The `TIF` enumeration can only be toggled between `GTT` and `GTC`. Amending to `GTT` requires an `expiryTime` value to be set. Amending to `GTC` removes the `expiryTime` value. - `ExpiryTime` @@ -110,10 +123,11 @@ message amendOrder { enum TIF 4; int64 expiryTime 5; PeggedOrder *peggedOrder 6; + int64 size 7; } ``` -An example of using a negative size is shown below: +An example of reducing the size is shown below: `Bids: 100@1000 GTC (OrderID V0000000001-0000000001)` @@ -124,6 +138,13 @@ amendOrder{ orderID:"V0000000001-0000000001", sizeDelta: -50 } ``` +or + +```json +amendOrder{ orderID:"V0000000001-0000000001", + size: 50 } +``` + The resulting order book will be: `Bids: 50@1000 GTC (OrderID V0000000001-0000000001)` From 62737a6179e0854b0f1166928774ab27c3a90c10 Mon Sep 17 00:00:00 2001 From: Charlie Date: Thu, 2 Nov 2023 17:16:19 +0000 Subject: [PATCH 0672/1171] fix: updates for checks --- protocol/0004-AMND-amends.md | 9 +++++---- protocol/cosmic-features.json | 4 ++-- protocol/features.json | 4 ++-- 3 files changed, 9 insertions(+), 8 deletions(-) diff --git a/protocol/0004-AMND-amends.md b/protocol/0004-AMND-amends.md index d9530bb38..f6fb88ea2 100644 --- a/protocol/0004-AMND-amends.md +++ b/protocol/0004-AMND-amends.md @@ -7,9 +7,9 @@ - Reducing the quantity by specifying a `sizeDelta` 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 using a `sizeDelta` 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 by specifying a `sizeDelta` 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) -- Size change amends specifying a `size` greater than the current size remove and reinsert the order at the back of the price level and increase the remaining amount accordingly (0004-AMND-055). -- Size change amends specifying a `size` lower than the current size leave the order in its current spot and reduce the remaining amount of the order accordingly (0004-AMND-056). -- Size change amends which would result in the remaining part of the order being reduced below zero should instead cancel the order (0004-AMND-057). +- Size change amends specifying a `size` greater than the current size remove and reinsert the order at the back of the price level and increase the remaining amount accordingly (0004-AMND-056). +- Size change amends specifying a `size` lower than the current size leave the order in its current spot and reduce the remaining amount of the order accordingly (0004-AMND-057). +- Size change amends which would result in the remaining part of the order being reduced below zero should instead cancel the order (0004-AMND-058). - 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) @@ -60,6 +60,7 @@ amendOrder{ sizeDelta: 200 } ``` + or ```json @@ -97,7 +98,7 @@ The fields which can be altered are: - `Price` - Amending the price causes the order to be removed from the book and re-inserted at the new price level. This can result in the order being filled if the price is moved to a level that would cross. - `SizeDelta` - - Amending the size by specifying a sizeDelta will be applied to both the `Size` and `Remaining` part of the order. In the case that the remaining amount it reduced to zero or less, the order is cancelled. This must be a multiple of the smallest value allowed by the `Position Decimal Places` (PDP) specified in the [Market Framework](./0001-MKTF-market_framework.md), i.e. is PDP = 2 then `SizeDelta` must be a whole multiple of 0.01. (NB: `SizeDelta` may use an int64 where the int value 1 is the smallest multiple allowable given the configured dp). In case PDP is negative this again applies e.g. if PDP = -1 then `SizeDelta` must be a whole multiple of 10. + - Amending the size by specifying a `sizeDelta` will be applied to both the `Size` and `Remaining` part of the order. In the case that the remaining amount it reduced to zero or less, the order is cancelled. This must be a multiple of the smallest value allowed by the `Position Decimal Places` (PDP) specified in the [Market Framework](./0001-MKTF-market_framework.md), i.e. is PDP = 2 then `SizeDelta` must be a whole multiple of 0.01. (NB: `SizeDelta` may use an int64 where the int value 1 is the smallest multiple allowable given the configured dp). In case PDP is negative this again applies e.g. if PDP = -1 then `SizeDelta` must be a whole multiple of 10. - `Size` - Amending the size by specifying a new `size` causes the the `Size` and `Remaining` part of the order to be amended by the difference between the original and amended size. In the case that the remaining amount it reduced to zero or less, the order is cancelled. This must be a multiple of the smallest value allowed by the `Position Decimal Places` (PDP) specified in the [Market Framework](./0001-MKTF-market_framework.md), i.e. is PDP = 2 then `Size` must be a whole multiple of 0.01. (NB: `Size` may use an int64 where the int value 1 is the smallest multiple allowable given the configured dp). In case PDP is negative this again applies e.g. if PDP = -1 then `Size` must be a whole multiple of 10. - `TimeInForce` diff --git a/protocol/cosmic-features.json b/protocol/cosmic-features.json index 8af84a962..c4e898b64 100644 --- a/protocol/cosmic-features.json +++ b/protocol/cosmic-features.json @@ -915,9 +915,9 @@ "Fixed Size Amendments": { "milestone": "deployment-3", "acs": [ - "0004-AMND-055", "0004-AMND-056", - "0004-AMND-057" + "0004-AMND-057", + "0004-AMND-058" ] }, "Unknown": { diff --git a/protocol/features.json b/protocol/features.json index 905c8b18a..5227604fc 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -68,9 +68,9 @@ "Fixed size amendments": { "milestone": "palazzo", "acs": [ - "0004-AMND-055", "0004-AMND-056", - "0004-AMND-057" + "0004-AMND-057", + "0004-AMND-058" ] }, "Ethereum heartbeat": { From 5fd137f995b09f9b1667c9995460097482fe44e9 Mon Sep 17 00:00:00 2001 From: Charlie Date: Fri, 3 Nov 2023 10:08:03 +0000 Subject: [PATCH 0673/1171] feat: transaction rejection criteria --- protocol/0004-AMND-amends.md | 3 ++- protocol/features.json | 3 ++- 2 files changed, 4 insertions(+), 2 deletions(-) diff --git a/protocol/0004-AMND-amends.md b/protocol/0004-AMND-amends.md index f6fb88ea2..4d73351ff 100644 --- a/protocol/0004-AMND-amends.md +++ b/protocol/0004-AMND-amends.md @@ -10,6 +10,7 @@ - Size change amends specifying a `size` greater than the current size remove and reinsert the order at the back of the price level and increase the remaining amount accordingly (0004-AMND-056). - Size change amends specifying a `size` lower than the current size leave the order in its current spot and reduce the remaining amount of the order accordingly (0004-AMND-057). - Size change amends which would result in the remaining part of the order being reduced below zero should instead cancel the order (0004-AMND-058). +- A transaction specifying both a `sizeDelta` and `size` field should be rejected as invalid (0004-AMND-059). - 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) @@ -45,7 +46,7 @@ The amend order can alter the quantity, price and expiry time/`TIF` type. For pe ## Guide-level explanation -The amend order message is a custom message containing the `orderID` of the original order and optional fields that can be altered. Prices can be changed with a new absolute value, sizes can be changed by either specifying a size delta or a new absolute value. Expiry time can be set to a new value and the `TIF` type can be toggled between `GTC` and `GTT`. Changing the `TIF` field will impact the value in the `ExpiryTime` field as it will either be blanked or set to a new valid value. +The amend order message is a custom message containing the `orderID` of the original order and optional fields that can be altered. Prices can be changed with a new absolute value, sizes can be changed by either specifying a size delta or a new absolute value. If a user attempts to amend the size of an order by specifying both a size delta and anew absolute value the order should be rejected. Expiry time can be set to a new value and the `TIF` type can be toggled between `GTC` and `GTT`. Changing the `TIF` field will impact the value in the `ExpiryTime` field as it will either be blanked or set to a new valid value. Some examples: A LIMIT order sitting on the bid side of the order book: diff --git a/protocol/features.json b/protocol/features.json index 5227604fc..3c174a427 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -70,7 +70,8 @@ "acs": [ "0004-AMND-056", "0004-AMND-057", - "0004-AMND-058" + "0004-AMND-058", + "0004-AMND-059" ] }, "Ethereum heartbeat": { From 5b97720033ca640cb0dc4bf79cfbca3741d8b0b1 Mon Sep 17 00:00:00 2001 From: Witold Date: Mon, 16 Oct 2023 13:13:00 +0200 Subject: [PATCH 0674/1171] refactor: modify TWAP calculation (auctions) --- ...0053-PERP-product_builtin_perpetual_future.md | 16 ++++++++++------ 1 file changed, 10 insertions(+), 6 deletions(-) diff --git a/protocol/0053-PERP-product_builtin_perpetual_future.md b/protocol/0053-PERP-product_builtin_perpetual_future.md index 7323fd116..82bbc478a 100644 --- a/protocol/0053-PERP-product_builtin_perpetual_future.md +++ b/protocol/0053-PERP-product_builtin_perpetual_future.md @@ -83,9 +83,13 @@ Every time a [mark to market settlement](./0003-MTMK-mark_to_market_settlement.m 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`. +The following conditions must all be met for a funding payment within a given funding period to happen: -If such points are available then the calculations discussed in the following subsections get executed and funding payments get exchanged. +- there is at least on one oracle data point with timestamp greater than or requal to `funding_period_start` and less than `funding_period_end`, +- there is at least internal data point with timestamp greater than or requal to `funding_period_start` and less than `funding_period_end`. +Otherwise the payment is skipped and the next funding period is entered. + +Please refer to the following subsections for the details of calculation of the funding payment if both of the above conditions are met. #### TWAP spot price calculation @@ -110,10 +114,10 @@ for p := range oracle_data_points { } 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)) +s_twap = sum_product / (funding_period_end - max(funding_period_start, oracle_data_points[0].t) - time_in_auction) ``` -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. +Where `time_in_auction` is the cumulative time spent within auctions within the funding period being considered. Note that 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 @@ -135,10 +139,10 @@ for p := range internal_data_points { } 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)) +f_twap = sum_product / (funding_period_end - max(funding_period_start, internal_data_points[0].t) - time_in_auction) ``` -Only the internal data point with largest timestamp needs to be kept from that point on. +where `time_in_auction` is the cumulative time spent within auctions within the funding period being considered. Note that only the internal data point with largest timestamp needs to be kept from that point on. #### Funding payment calculation From 2755e588db21cb9697b30353a2202a3cd87381a1 Mon Sep 17 00:00:00 2001 From: Witold Date: Mon, 16 Oct 2023 15:10:46 +0200 Subject: [PATCH 0675/1171] refactor: remove auctions from calculation --- ...3-PERP-product_builtin_perpetual_future.md | 53 +------------------ 1 file changed, 2 insertions(+), 51 deletions(-) diff --git a/protocol/0053-PERP-product_builtin_perpetual_future.md b/protocol/0053-PERP-product_builtin_perpetual_future.md index 82bbc478a..c313a5cef 100644 --- a/protocol/0053-PERP-product_builtin_perpetual_future.md +++ b/protocol/0053-PERP-product_builtin_perpetual_future.md @@ -91,58 +91,9 @@ Otherwise the payment is skipped and the next funding period is entered. Please refer to the following subsections for the details of calculation of the funding payment if both of the above conditions are met. -#### TWAP spot price calculation +#### TWAP 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) - time_in_auction) -``` - -Where `time_in_auction` is the cumulative time spent within auctions within the funding period being considered. Note that 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 -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 -} - -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) - time_in_auction) -``` - -where `time_in_auction` is the cumulative time spent within auctions within the funding period being considered. Note that only the internal data point with largest timestamp needs to be kept from that point on. +Same methodology applies to spot (external) and perps (internal prices). The available prices (spot and perps considered separately of course) should be used to calculate the time weighted average price within the funding period. If no observations at or prior to the funding period start exist then the start of the period used for calculation should be moved forward to the time of the first observation. An observation is assumed to be applying until a subsequent observation is available. Periods spent in auction should be excluded from the calculation. #### Funding payment calculation From d4ecd160566b9811b64e8838f9a300fb13b81fb0 Mon Sep 17 00:00:00 2001 From: Witold Date: Thu, 26 Oct 2023 15:50:27 +0200 Subject: [PATCH 0676/1171] refactor: add ACs + spelling error fix --- ...3-PERP-product_builtin_perpetual_future.md | 63 +++++++++++++++++-- wordlist.txt | 1 + 2 files changed, 59 insertions(+), 5 deletions(-) diff --git a/protocol/0053-PERP-product_builtin_perpetual_future.md b/protocol/0053-PERP-product_builtin_perpetual_future.md index c313a5cef..a635fe8a8 100644 --- a/protocol/0053-PERP-product_builtin_perpetual_future.md +++ b/protocol/0053-PERP-product_builtin_perpetual_future.md @@ -83,13 +83,12 @@ Every time a [mark to market settlement](./0003-MTMK-mark_to_market_settlement.m When the `settlement_schedule` event is received we need to calculate the funding payment. Store the current vega time as `funding_period_end`. -The following conditions must all be met for a funding payment within a given funding period to happen: +Skip the funding payment calculation (set payment to `0`) if any of the following conditions is met: -- there is at least on one oracle data point with timestamp greater than or requal to `funding_period_start` and less than `funding_period_end`, -- there is at least internal data point with timestamp greater than or requal to `funding_period_start` and less than `funding_period_end`. -Otherwise the payment is skipped and the next funding period is entered. +- no spot (external) data has been ingested since market was created, +- market has been in auction throughout the entire funding period. -Please refer to the following subsections for the details of calculation of the funding payment if both of the above conditions are met. +Please refer to the following subsections for the details of calculation of the funding payment if none of the above conditions are met. #### TWAP calculation @@ -189,3 +188,57 @@ In both cases the estimates are for a hypothetical position of size 1. 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) + +1. Assume a market trades steadily generating a stream in mark price observations, but the first spot price observation only arrives during the 4th funding period of that market. Then funding payments for periods 1, 2 and 3 all equal 0. (0053-PERP-025) + +1. Assume the market has been in a long auction so that a funding period has started and ended while the market never went back into continuous trading. In that case the funding payment should be equal to 0 and no transfers should be exchanged. (0053-PERP-026) + +1. Assume a 10 minute funding period. Assume a few funding periods have already passed for this market. + +Assume the last known mark price before the start of the period to be `10` and that it gets updated every 2 minutes as follows: +| Time (min) since period start | mark price | +| ----------------------------- | ----------- | +| 1 | 11 | +| 3 | 10 | +| 5 | 9 | +| 7 | 8 | +| 9 | 7 | + +Assume the last known spot price before this funding period is `11`. Then assume the subsequent spot price observations get ingested according to the schedule specified below: +| Time (min) since period start | spot price | +| ----------------------------- | ----------- | +| 1 | 9 | +| 3 | 10 | +| 5 | 12 | +| 6 | 11 | +| 7 | 8 | +| 9 | 14 | + +Then, assuming no auctions during the period we get: +$\text{internal TWAP}= \frac{10\cdot(1-0)+11\cdot(3-1)+10\cdot(5-3)+9\cdot(7-5)+8\cdot(9-7)+7\cdot(10-9)}{10}=9.3$, +$\text{external TWAP}=\frac{11\cdot(1-0)+9\cdot(3-1)+10\cdot(5-3)+12\cdot(6-5)+11\cdot(7-6)+8\cdot(9-7)+14\cdot(10-9)}{10}=10.3$. (0053-PERP-027) + +1. Assume a 10 minute funding period. Assume a few funding periods have already passed for this market. Furthermore, assume that in this period that market is in an auction which starts 5 minutes into the period and ends 7 minutes into the period. + +Assume the last known mark price before the start of the period to be `10` and that it gets updated as follows: +| Time (min) since period start | mark price | +| ----------------------------- | ----------- | +| 1 | 11 | +| 3 | 10 | +| 7 | 9 | +| 8 | 8 | +| 10 | 30 | + +Assume the last known spot price before this funding period is `11`. Then assume the subsequent spot price observations get ingested according to the schedule specified below: +| Time (min) since period start | spot price | +| ----------------------------- | ----------- | +| 1 | 9 | +| 3 | 10 | +| 5 | 12 | +| 6 | 11 | +| 8 | 8 | +| 9 | 14 | + +Then, taking the auction into account we get: +$\text{internal TWAP}= \frac{10\cdot(1-0)+11\cdot(3-1)+10\cdot(5-3)+9\cdot(8-7)+8\cdot(10-8)+30\cdot(10-10)}{8}=9.625$, +$\text{external TWAP}=\frac{11\cdot(1-0)+9\cdot(3-1)+10\cdot(5-3)+11\cdot(8-7)+8\cdot(9-8)+14\cdot(10-9)}{10}=10.25$. (0053-PERP-028) diff --git a/wordlist.txt b/wordlist.txt index 0211e4688..c43055ace 100644 --- a/wordlist.txt +++ b/wordlist.txt @@ -200,6 +200,7 @@ PDP performant permissioned permissionless +perps PME PnL PoS From 02c962d95cd0f87cdf94d296c02435460bece6c9 Mon Sep 17 00:00:00 2001 From: Witold Date: Mon, 30 Oct 2023 14:59:07 +0100 Subject: [PATCH 0677/1171] refactor: clarify spot TWAP --- 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 a635fe8a8..85e36fd33 100644 --- a/protocol/0053-PERP-product_builtin_perpetual_future.md +++ b/protocol/0053-PERP-product_builtin_perpetual_future.md @@ -92,7 +92,7 @@ Please refer to the following subsections for the details of calculation of the #### TWAP calculation -Same methodology applies to spot (external) and perps (internal prices). The available prices (spot and perps considered separately of course) should be used to calculate the time weighted average price within the funding period. If no observations at or prior to the funding period start exist then the start of the period used for calculation should be moved forward to the time of the first observation. An observation is assumed to be applying until a subsequent observation is available. Periods spent in auction should be excluded from the calculation. +Same methodology applies to spot (external) and perps (internal prices). The available prices (spot and perps considered separately of course) should be used to calculate the time weighted average price within the funding period. If no observations at or prior to the funding period start exist then the start of the period used for calculation should be moved forward to the time of the first observation. An observation is assumed to be applying until a subsequent observation is available. Periods spent in auction should be excluded from the calculation. This implies that spot datapoints received during the auction except for the latest one should be disregarded. Please refer to 0053-PERP-027 and 0053-PERP-028 for a detailed example. #### Funding payment calculation From 962b7bc600a6ba589204130c2d08b29bd4fbca50 Mon Sep 17 00:00:00 2001 From: Witold Date: Wed, 1 Nov 2023 12:17:41 +0000 Subject: [PATCH 0678/1171] refactor: reinstate pseudo-code --- ...3-PERP-product_builtin_perpetual_future.md | 47 ++++++++++++++++++- 1 file changed, 46 insertions(+), 1 deletion(-) diff --git a/protocol/0053-PERP-product_builtin_perpetual_future.md b/protocol/0053-PERP-product_builtin_perpetual_future.md index 85e36fd33..71321ac07 100644 --- a/protocol/0053-PERP-product_builtin_perpetual_future.md +++ b/protocol/0053-PERP-product_builtin_perpetual_future.md @@ -92,7 +92,52 @@ Please refer to the following subsections for the details of calculation of the #### TWAP calculation -Same methodology applies to spot (external) and perps (internal prices). The available prices (spot and perps considered separately of course) should be used to calculate the time weighted average price within the funding period. If no observations at or prior to the funding period start exist then the start of the period used for calculation should be moved forward to the time of the first observation. An observation is assumed to be applying until a subsequent observation is available. Periods spent in auction should be excluded from the calculation. This implies that spot datapoints received during the auction except for the latest one should be disregarded. Please refer to 0053-PERP-027 and 0053-PERP-028 for a detailed example. +Same methodology applies to spot (external) and perps (internal). The available prices (spot and perps considered separately of course) should be used to calculate the time weighted average price within the funding period. If no observations at or prior to the funding period start exist then the start of the period used for calculation should be moved forward to the time of the first observation. An observation is assumed to be applying until a subsequent observation is available. Periods spent in auction should be excluded from the calculation. This implies that spot datapoints received during the auction except for the latest one should be disregarded. Please refer to 0053-PERP-027 and 0053-PERP-028 for a detailed example. + +Calculation of the TWAP is carried out by maintaining the following variables: `numerator`, `denominator`, `previous_price` and `previous_time`. It's also assumed that a function `current_time()` is available which returns the current Vega time, and a function `in_auction()` exists which returns `true` if the market being considered is currently in auction and `false` otherwise. +The variables are maintained as follows. + +When a new `price` observation arrives: + +```go +if previous_price != nil && in_auction() { + time_delta = current_time()-previous_time + numerator += previous_price*time_delta + denominator += time_delta +} +previous_price = price +previous_time = current_time() +``` + +When the market goes into auction: + +```go +time_delta = current_time()-previous_time +numerator += previous_price*time_delta +denominator += time_delta +``` + +When the market goes out of auction: + +```go +previous_time = current_time() +``` + +When the funding payment cue arrives TWAP gets calculated and returned as: + +```go +if !in_auction() { + time_delta = current_time()-previous_time + numerator += previous_price*time_delta + denominator += time_delta +} +previous_time = current_time +if denominator == 0 { + return 0 +} +return numerator / denominator + +``` #### Funding payment calculation From 409e91b8995a968a893d7791ee5cc6a85dcf4614 Mon Sep 17 00:00:00 2001 From: Witold Date: Wed, 1 Nov 2023 12:20:04 +0000 Subject: [PATCH 0679/1171] refactor: map new ACs --- protocol/features.json | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/protocol/features.json b/protocol/features.json index 3c174a427..96f61c6cd 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -43,7 +43,15 @@ "0073-LIMN-110", "0073-LIMN-111", "0081-SUCM-015", - "0053-PERP-024" + "0014-ORDT-120", + "0014-ORDT-121", + "0014-ORDT-122", + "0014-ORDT-123", + "0053-PERP-024", + "0053-PERP-025", + "0053-PERP-026", + "0053-PERP-027", + "0053-PERP-028" ] }, "Team rewards": { From fbf87a863134eda3ccf4c0913bdd5a649edb225c Mon Sep 17 00:00:00 2001 From: Witold Date: Wed, 1 Nov 2023 15:03:01 +0000 Subject: [PATCH 0680/1171] chore: fix spellcheck and apporbation --- protocol/0053-PERP-product_builtin_perpetual_future.md | 2 +- wordlist.txt | 2 ++ 2 files 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 71321ac07..32592a901 100644 --- a/protocol/0053-PERP-product_builtin_perpetual_future.md +++ b/protocol/0053-PERP-product_builtin_perpetual_future.md @@ -92,7 +92,7 @@ Please refer to the following subsections for the details of calculation of the #### TWAP calculation -Same methodology applies to spot (external) and perps (internal). The available prices (spot and perps considered separately of course) should be used to calculate the time weighted average price within the funding period. If no observations at or prior to the funding period start exist then the start of the period used for calculation should be moved forward to the time of the first observation. An observation is assumed to be applying until a subsequent observation is available. Periods spent in auction should be excluded from the calculation. This implies that spot datapoints received during the auction except for the latest one should be disregarded. Please refer to 0053-PERP-027 and 0053-PERP-028 for a detailed example. +Same methodology applies to spot (external) and perps (internal). The available prices (spot and perps considered separately of course) should be used to calculate the time weighted average price within the funding period. If no observations at or prior to the funding period start exist then the start of the period used for calculation should be moved forward to the time of the first observation. An observation is assumed to be applying until a subsequent observation is available. Periods spent in auction should be excluded from the calculation. This implies that spot datapoints received during the auction except for the latest one should be disregarded. Please refer to the acceptance criteria for a detailed example. Calculation of the TWAP is carried out by maintaining the following variables: `numerator`, `denominator`, `previous_price` and `previous_time`. It's also assumed that a function `current_time()` is available which returns the current Vega time, and a function `in_auction()` exists which returns `true` if the market being considered is currently in auction and `false` otherwise. The variables are maintained as follows. diff --git a/wordlist.txt b/wordlist.txt index c43055ace..bae7b667c 100644 --- a/wordlist.txt +++ b/wordlist.txt @@ -59,6 +59,7 @@ DAI dApp datanode datapoint +datapoints datatypes datetime decentralised @@ -200,6 +201,7 @@ PDP performant permissioned permissionless +PERP perps PME PnL From b4024d2845febbac4e2223f1a6e4d95f22e73b0b Mon Sep 17 00:00:00 2001 From: Witold Date: Mon, 6 Nov 2023 14:41:01 +0000 Subject: [PATCH 0681/1171] refactor: add a note on pseudocode --- protocol/0053-PERP-product_builtin_perpetual_future.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/protocol/0053-PERP-product_builtin_perpetual_future.md b/protocol/0053-PERP-product_builtin_perpetual_future.md index 32592a901..c6df79c66 100644 --- a/protocol/0053-PERP-product_builtin_perpetual_future.md +++ b/protocol/0053-PERP-product_builtin_perpetual_future.md @@ -139,6 +139,8 @@ return numerator / denominator ``` +Note that depending on what type of oracle is used for the spot price it may be that the oracle points only become known shortly before or at the funding payment cue time, so the above pseudocode is just an illustration of how these quantities should be calculated and the implementation will need to be able to apply such calculation retrospectively. + #### Funding payment calculation 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: From 59cd70dde1532a98776832bf8f8e5d09c79caed6 Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Sun, 5 Nov 2023 10:31:15 +0000 Subject: [PATCH 0682/1171] feat: add cumulated fees each epoch --- protocol/0057-TRAN-transfers.md | 3 +++ 1 file changed, 3 insertions(+) diff --git a/protocol/0057-TRAN-transfers.md b/protocol/0057-TRAN-transfers.md index 6e6492a88..6c2c4863c 100644 --- a/protocol/0057-TRAN-transfers.md +++ b/protocol/0057-TRAN-transfers.md @@ -157,6 +157,8 @@ Note: if there is no market with contribution to the reward metric - no transfer A fee is taken from all transfers (except transfers from a vested account to a general account held by the same key), 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. +For each party, we aggregate the fees paid during an epoch and maintain a running total. If there is a transfer activity, we deduct the corresponding fee from the accumulated total. Once this total reaches zero, the party incurs charges. We require API support to enable the frontend to transparently display the amount eligible for fee-free transfers. + The fee is determined by the `transfer.fee.factor` and is subject to a cap defined by the multiplier `transfer.fee.maxQuantumAmount` as specified in the network parameters, which governs the proportion of each transfer taken as a fee. As such, the transfer fee value used will be: `min(transfer amount * transfer.fee.factor, transfer.fee.maxQuantumAmount * quantum)`, `quantum` is for asset @@ -255,6 +257,7 @@ message CancelTransfer { - 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) +- As a user, I can accumulate the fees I collect over an epoch. When I initiate a transfer that incurs a transfer fee, I have the ability to view the amount that is exempt from transfer fees through the API. (0057-TRAN-012) ### Recurring transfer tests From b7275a096c2745b64450095a7dd02ca94813031c Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Mon, 6 Nov 2023 14:48:24 +0000 Subject: [PATCH 0683/1171] feat: addressing comments --- protocol/0057-TRAN-transfers.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/protocol/0057-TRAN-transfers.md b/protocol/0057-TRAN-transfers.md index 6c2c4863c..38bc90b7e 100644 --- a/protocol/0057-TRAN-transfers.md +++ b/protocol/0057-TRAN-transfers.md @@ -157,7 +157,7 @@ Note: if there is no market with contribution to the reward metric - no transfer A fee is taken from all transfers (except transfers from a vested account to a general account held by the same key), 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. -For each party, we aggregate the fees paid during an epoch and maintain a running total. If there is a transfer activity, we deduct the corresponding fee from the accumulated total. Once this total reaches zero, the party incurs charges. We require API support to enable the frontend to transparently display the amount eligible for fee-free transfers. +For each party, we aggregate taker fees paid over a specific number of epochs defined by `transfer.fee.offset.numberOfEpoch` and maintain a cumulative total. If a transfer activity occurs within the same time frame of `transfer.fee.offset.numberOfEpoch` epochs, we deduct the corresponding fee from the accumulated total. When this cumulative total reaches zero, the party becomes liable for charges of tranfer fees. To achieve this, we require API support, allowing the frontend to provide a transparent display of the amount eligible for fee-free transfers. It's important to note that this mechanism applies on a per-asset basis. `transfer.fee.offset.numberOfEpoch` serves as a network parameter that sets the time window during which taker fees can offset transfer fees. The fee is determined by the `transfer.fee.factor` and is subject to a cap defined by the multiplier `transfer.fee.maxQuantumAmount` as specified in the network parameters, which governs the proportion of each transfer taken as a fee. @@ -258,6 +258,7 @@ message CancelTransfer { - 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) - As a user, I can accumulate the fees I collect over an epoch. When I initiate a transfer that incurs a transfer fee, I have the ability to view the amount that is exempt from transfer fees through the API. (0057-TRAN-012) +- By setting `transfer.fee.offset.numberOfEpoch` to 3 epochs, you establish a time window spanning 3 consecutive epochs. During these 3 epochs, if you place market orders and subsequently initiate a transfer incurring a transfer fee, the 'free transfer amount' is calculated based on the cumulative fees collected over those same 3 epochs.(0057-TRAN-013) ### Recurring transfer tests From 4afddf4748c4d76770c0af0a49163687e1af0a38 Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Mon, 6 Nov 2023 18:06:29 +0000 Subject: [PATCH 0684/1171] feat: add an example --- protocol/0057-TRAN-transfers.md | 12 ++++++++++-- 1 file changed, 10 insertions(+), 2 deletions(-) diff --git a/protocol/0057-TRAN-transfers.md b/protocol/0057-TRAN-transfers.md index 38bc90b7e..69be7210c 100644 --- a/protocol/0057-TRAN-transfers.md +++ b/protocol/0057-TRAN-transfers.md @@ -157,7 +157,15 @@ Note: if there is no market with contribution to the reward metric - no transfer A fee is taken from all transfers (except transfers from a vested account to a general account held by the same key), 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. -For each party, we aggregate taker fees paid over a specific number of epochs defined by `transfer.fee.offset.numberOfEpoch` and maintain a cumulative total. If a transfer activity occurs within the same time frame of `transfer.fee.offset.numberOfEpoch` epochs, we deduct the corresponding fee from the accumulated total. When this cumulative total reaches zero, the party becomes liable for charges of tranfer fees. To achieve this, we require API support, allowing the frontend to provide a transparent display of the amount eligible for fee-free transfers. It's important to note that this mechanism applies on a per-asset basis. `transfer.fee.offset.numberOfEpoch` serves as a network parameter that sets the time window during which taker fees can offset transfer fees. +For each party, we accumulate the taker fees paid over a period defined by `transfer.feeDiscountNumOfEpoch` epochs. This cumulative value is stored, and if there is a subsequent transfer, we deduct the transfer fee from this stored value. When the stored value reaches zero, the party incurs charges for taker fees. To make this possible, we rely on API support, which enables the frontend to display the amount eligible for fee-free transfers transparently. `transfer.feeDiscountNumOfEpoch` is a network parameter that specifies the timeframe over which we acumulate the taker fees that can offset transfer fees. If the network parameter `transfer.feeDiscountNumOfEpoch` is increased through governance vote, the real parameter is then increased by one every epoch until it hits the target parameter that was voted for. + +example (if `transfer.feeDiscountNumOfEpoch` = 2): +| Epoch | 1 | 2 | 3 | 4 | +| ------------------------ |--------------------------|--------------------------|--------------------------|-----------------------| +|taker fee paid | 10 | 20 | 5 | 8 | +|cumulated fee paid | 0 | 10 | 30 then update to 20 | 25 then update to 22 | +|transfer fee theoretical | 5 | 15 | 3 | 4 | +|transfer fee paid | if(5>0),5-0, else 0 | if(15>10),15-10, else 0 | if(3>20),3-20, else 0 | if(4>22),4-22 else, 0 | The fee is determined by the `transfer.fee.factor` and is subject to a cap defined by the multiplier `transfer.fee.maxQuantumAmount` as specified in the network parameters, which governs the proportion of each transfer taken as a fee. @@ -258,7 +266,7 @@ message CancelTransfer { - 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) - As a user, I can accumulate the fees I collect over an epoch. When I initiate a transfer that incurs a transfer fee, I have the ability to view the amount that is exempt from transfer fees through the API. (0057-TRAN-012) -- By setting `transfer.fee.offset.numberOfEpoch` to 3 epochs, you establish a time window spanning 3 consecutive epochs. During these 3 epochs, if you place market orders and subsequently initiate a transfer incurring a transfer fee, the 'free transfer amount' is calculated based on the cumulative fees collected over those same 3 epochs.(0057-TRAN-013) +- By setting `transfer.feeDiscountNumOfEpoch` to 3 epochs, you establish a time window spanning 3 consecutive epochs. During these 3 epochs, if you place market orders and subsequently initiate a transfer incurring a transfer fee, the 'free transfer amount' is calculated based on the cumulative fees collected over those same 3 epochs.(0057-TRAN-013) ### Recurring transfer tests From d508b082772eeb0e416911163e2f660bee7dd649 Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Mon, 6 Nov 2023 19:28:25 +0000 Subject: [PATCH 0685/1171] feat: add details --- protocol/0057-TRAN-transfers.md | 19 ++++++++++++++----- 1 file changed, 14 insertions(+), 5 deletions(-) diff --git a/protocol/0057-TRAN-transfers.md b/protocol/0057-TRAN-transfers.md index 69be7210c..bdd4e9de1 100644 --- a/protocol/0057-TRAN-transfers.md +++ b/protocol/0057-TRAN-transfers.md @@ -157,15 +157,24 @@ Note: if there is no market with contribution to the reward metric - no transfer A fee is taken from all transfers (except transfers from a vested account to a general account held by the same key), 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. -For each party, we accumulate the taker fees paid over a period defined by `transfer.feeDiscountNumOfEpoch` epochs. This cumulative value is stored, and if there is a subsequent transfer, we deduct the transfer fee from this stored value. When the stored value reaches zero, the party incurs charges for taker fees. To make this possible, we rely on API support, which enables the frontend to display the amount eligible for fee-free transfers transparently. `transfer.feeDiscountNumOfEpoch` is a network parameter that specifies the timeframe over which we acumulate the taker fees that can offset transfer fees. If the network parameter `transfer.feeDiscountNumOfEpoch` is increased through governance vote, the real parameter is then increased by one every epoch until it hits the target parameter that was voted for. +Let `N` stand for `transfer.feeDiscountNumOfEpoch`. This is a network parameter that specifies the timeframe over which we acumulate the taker fees that can offset transfer fees. + +For each key for each asset assume you store a value denoted `c`. +During the epoch `k`: +- if the party makes a transfer and `f` would be the theoretical fee the party should pay then the fee on the transfer that is actually charged is `-min(c-f,0)`. The system subsequently updates `c <- max(0,c-f)`. +At the end of epoch `k`: +1. update `c <- c - old_taker_fees`, where `old_taker_fees` is set to the total taker fees paid during epoch `k-N` if this value exists and `0` otherwise. +1. update `c <- c - taker_fees`, where `taker_fees` is the total taker fees paid during the epoch that just ended i.e. epoch `k`. + +We need appropriate APIs to enable the frontend to display the amount eligible for fee-free transfers / correctly display the fee on any tranfer a party is proposing. example (if `transfer.feeDiscountNumOfEpoch` = 2): | Epoch | 1 | 2 | 3 | 4 | | ------------------------ |--------------------------|--------------------------|--------------------------|-----------------------| -|taker fee paid | 10 | 20 | 5 | 8 | -|cumulated fee paid | 0 | 10 | 30 then update to 20 | 25 then update to 22 | -|transfer fee theoretical | 5 | 15 | 3 | 4 | -|transfer fee paid | if(5>0),5-0, else 0 | if(15>10),15-10, else 0 | if(3>20),3-20, else 0 | if(4>22),4-22 else, 0 | +| taker fee paid | 10 | 20 | 5 | 8 | +| counter | 0 | 10 | 20 | 22 | +| transfer fee theoretical | 5 | 15 | 3 | 4 | +| transfer fee paid | if(5>0),5-0, else 0 | if(15>10),15-10, else 0 | if(3>20),3-20, else 0 | if(4>22),4-22 else, 0 | The fee is determined by the `transfer.fee.factor` and is subject to a cap defined by the multiplier `transfer.fee.maxQuantumAmount` as specified in the network parameters, which governs the proportion of each transfer taken as a fee. From f9ee589b49fd7330fa77996f0a267ce59438f33e Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Tue, 7 Nov 2023 09:28:08 +0000 Subject: [PATCH 0686/1171] chore: typo --- 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 bdd4e9de1..2968a441a 100644 --- a/protocol/0057-TRAN-transfers.md +++ b/protocol/0057-TRAN-transfers.md @@ -157,7 +157,7 @@ Note: if there is no market with contribution to the reward metric - no transfer A fee is taken from all transfers (except transfers from a vested account to a general account held by the same key), 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. -Let `N` stand for `transfer.feeDiscountNumOfEpoch`. This is a network parameter that specifies the timeframe over which we acumulate the taker fees that can offset transfer fees. +Let `N` stand for `transfer.feeDiscountNumOfEpoch`. This is a network parameter that specifies the timeframe over which we accumulate the taker fees that can offset transfer fees. For each key for each asset assume you store a value denoted `c`. During the epoch `k`: @@ -166,7 +166,7 @@ At the end of epoch `k`: 1. update `c <- c - old_taker_fees`, where `old_taker_fees` is set to the total taker fees paid during epoch `k-N` if this value exists and `0` otherwise. 1. update `c <- c - taker_fees`, where `taker_fees` is the total taker fees paid during the epoch that just ended i.e. epoch `k`. -We need appropriate APIs to enable the frontend to display the amount eligible for fee-free transfers / correctly display the fee on any tranfer a party is proposing. +We need appropriate APIs to enable the frontend to display the amount eligible for fee-free transfers / correctly display the fee on any transfer a party is proposing. example (if `transfer.feeDiscountNumOfEpoch` = 2): | Epoch | 1 | 2 | 3 | 4 | From 4de3762ae83f25acdf88b226664c40a447343038 Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Tue, 7 Nov 2023 09:53:19 +0000 Subject: [PATCH 0687/1171] chore: update format --- protocol/0057-TRAN-transfers.md | 14 +++++++++----- 1 file changed, 9 insertions(+), 5 deletions(-) diff --git a/protocol/0057-TRAN-transfers.md b/protocol/0057-TRAN-transfers.md index 2968a441a..c66221631 100644 --- a/protocol/0057-TRAN-transfers.md +++ b/protocol/0057-TRAN-transfers.md @@ -157,14 +157,18 @@ Note: if there is no market with contribution to the reward metric - no transfer A fee is taken from all transfers (except transfers from a vested account to a general account held by the same key), 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. -Let `N` stand for `transfer.feeDiscountNumOfEpoch`. This is a network parameter that specifies the timeframe over which we accumulate the taker fees that can offset transfer fees. +Let `N` stand for `transfer.feeDiscountNumOfEpoch`. This is a network parameter that specifies the time frame over which we accumulate the taker fees that can offset transfer fees. -For each key for each asset assume you store a value denoted `c`. +For each key for each asset assume you store a value denoted `c`. During the epoch `k`: + - if the party makes a transfer and `f` would be the theoretical fee the party should pay then the fee on the transfer that is actually charged is `-min(c-f,0)`. The system subsequently updates `c <- max(0,c-f)`. + At the end of epoch `k`: -1. update `c <- c - old_taker_fees`, where `old_taker_fees` is set to the total taker fees paid during epoch `k-N` if this value exists and `0` otherwise. -1. update `c <- c - taker_fees`, where `taker_fees` is the total taker fees paid during the epoch that just ended i.e. epoch `k`. + +1. update `c <- c - old_taker_fees`, where `old_taker_fees` is set to the total taker fees paid during epoch `k-N` if this value exists and `0` otherwise. + +1. update `c <- c - taker_fees`, where `taker_fees` is the total taker fees paid during the epoch that just ended i.e. epoch `k`. We need appropriate APIs to enable the frontend to display the amount eligible for fee-free transfers / correctly display the fee on any transfer a party is proposing. @@ -174,7 +178,7 @@ example (if `transfer.feeDiscountNumOfEpoch` = 2): | taker fee paid | 10 | 20 | 5 | 8 | | counter | 0 | 10 | 20 | 22 | | transfer fee theoretical | 5 | 15 | 3 | 4 | -| transfer fee paid | if(5>0),5-0, else 0 | if(15>10),15-10, else 0 | if(3>20),3-20, else 0 | if(4>22),4-22 else, 0 | +| transfer fee paid | if(5>0),5-0, else 0 | if(15>10),15-10, else 0 | if(3>20),3-20, else 0 | if(4>22),4-22 else, 0 | The fee is determined by the `transfer.fee.factor` and is subject to a cap defined by the multiplier `transfer.fee.maxQuantumAmount` as specified in the network parameters, which governs the proportion of each transfer taken as a fee. From ddd24f10f69f9106e8c193d5b93d9b747e4bb3eb Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Tue, 7 Nov 2023 09:59:02 +0000 Subject: [PATCH 0688/1171] chore: markdown --- 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 c66221631..10bc75db3 100644 --- a/protocol/0057-TRAN-transfers.md +++ b/protocol/0057-TRAN-transfers.md @@ -173,7 +173,7 @@ At the end of epoch `k`: We need appropriate APIs to enable the frontend to display the amount eligible for fee-free transfers / correctly display the fee on any transfer a party is proposing. example (if `transfer.feeDiscountNumOfEpoch` = 2): -| Epoch | 1 | 2 | 3 | 4 | +| Epoch | 1 | 2 | 3 | 4 | | ------------------------ |--------------------------|--------------------------|--------------------------|-----------------------| | taker fee paid | 10 | 20 | 5 | 8 | | counter | 0 | 10 | 20 | 22 | From 86f38e52807871d8347cd9fc82b966500488208f Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Tue, 7 Nov 2023 10:01:19 +0000 Subject: [PATCH 0689/1171] chore: markdown --- 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 10bc75db3..fb4cf4a40 100644 --- a/protocol/0057-TRAN-transfers.md +++ b/protocol/0057-TRAN-transfers.md @@ -173,7 +173,7 @@ At the end of epoch `k`: We need appropriate APIs to enable the frontend to display the amount eligible for fee-free transfers / correctly display the fee on any transfer a party is proposing. example (if `transfer.feeDiscountNumOfEpoch` = 2): -| Epoch | 1 | 2 | 3 | 4 | +| Epoch | 1 | 2 | 3 | 4 | | ------------------------ |--------------------------|--------------------------|--------------------------|-----------------------| | taker fee paid | 10 | 20 | 5 | 8 | | counter | 0 | 10 | 20 | 22 | From b6c545a70a175603e2a16774ab13c529d3baad92 Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Tue, 7 Nov 2023 10:16:16 +0000 Subject: [PATCH 0690/1171] feat: address comments --- protocol/0057-TRAN-transfers.md | 19 ++++++++++++------- 1 file changed, 12 insertions(+), 7 deletions(-) diff --git a/protocol/0057-TRAN-transfers.md b/protocol/0057-TRAN-transfers.md index fb4cf4a40..34b6525dd 100644 --- a/protocol/0057-TRAN-transfers.md +++ b/protocol/0057-TRAN-transfers.md @@ -159,6 +159,8 @@ A fee is taken from all transfers (except transfers from a vested account to a g Let `N` stand for `transfer.feeDiscountNumOfEpoch`. This is a network parameter that specifies the time frame over which we accumulate the taker fees that can offset transfer fees. +For each party and for each asset store the taker fees paid by the party in a given epoch for `N` epochs; this will be used to determine a transfer fee discount as described below. + For each key for each asset assume you store a value denoted `c`. During the epoch `k`: @@ -172,13 +174,16 @@ At the end of epoch `k`: We need appropriate APIs to enable the frontend to display the amount eligible for fee-free transfers / correctly display the fee on any transfer a party is proposing. -example (if `transfer.feeDiscountNumOfEpoch` = 2): -| Epoch | 1 | 2 | 3 | 4 | -| ------------------------ |--------------------------|--------------------------|--------------------------|-----------------------| -| taker fee paid | 10 | 20 | 5 | 8 | -| counter | 0 | 10 | 20 | 22 | -| transfer fee theoretical | 5 | 15 | 3 | 4 | -| transfer fee paid | if(5>0),5-0, else 0 | if(15>10),15-10, else 0 | if(3>20),3-20, else 0 | if(4>22),4-22 else, 0 | +###Example: + +Take `transfer.feeDiscountNumOfEpoch = 2`. + +| Epoch | 1 | 2 | 3 | 4 | +| ------------------------ |---------------------|---------------------|---------------------|------------------| +| taker fee paid | 10 | 20 | 5 | 8 | +| counter | 0 | 10 | 20 | 22 | +| transfer fee theoretical | 5 | 15 | 3 | 4 | +| transfer fee paid | 5 | 5 | 0 | 0 | The fee is determined by the `transfer.fee.factor` and is subject to a cap defined by the multiplier `transfer.fee.maxQuantumAmount` as specified in the network parameters, which governs the proportion of each transfer taken as a fee. From 0dbfe1555f97d0b9f4b29b3611929cc3851c616f Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Tue, 7 Nov 2023 10:17:29 +0000 Subject: [PATCH 0691/1171] chore: markdown --- 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 34b6525dd..6e04cb9a8 100644 --- a/protocol/0057-TRAN-transfers.md +++ b/protocol/0057-TRAN-transfers.md @@ -174,7 +174,7 @@ At the end of epoch `k`: We need appropriate APIs to enable the frontend to display the amount eligible for fee-free transfers / correctly display the fee on any transfer a party is proposing. -###Example: +### Example: Take `transfer.feeDiscountNumOfEpoch = 2`. From f39c11b1ac38ed53463185039b00b4f5e9208d91 Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Tue, 7 Nov 2023 10:19:18 +0000 Subject: [PATCH 0692/1171] chore: markdown --- 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 6e04cb9a8..856fb156a 100644 --- a/protocol/0057-TRAN-transfers.md +++ b/protocol/0057-TRAN-transfers.md @@ -174,7 +174,7 @@ At the end of epoch `k`: We need appropriate APIs to enable the frontend to display the amount eligible for fee-free transfers / correctly display the fee on any transfer a party is proposing. -### Example: +### Example Take `transfer.feeDiscountNumOfEpoch = 2`. From 72fdf62dd94fb01bdde91f5af4036dc44bcfcb4c Mon Sep 17 00:00:00 2001 From: wwestgarth Date: Tue, 7 Nov 2023 11:08:05 +0000 Subject: [PATCH 0693/1171] chore: split 0042-LIQF-001 so we can track new things better (#2042) --- protocol/0042-LIQF-setting_fees_and_rewarding_lps.md | 2 ++ protocol/features.json | 4 +++- 2 files changed, 5 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 b301afb94..22053904d 100644 --- a/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md +++ b/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md @@ -352,6 +352,8 @@ Each LP further gets a performance bonus: $b_i \times B$ with a transfer type th - 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) - A market can be proposed with a choice of liquidity fee settings. These settings can be updated by a subsequent market update proposal. (0042-LIQF-056) +- The above example for the liquidity fee when the method is weighted-average results in a fee-factor of 1.5% (0042-LIQF-057) +- The above example for the liquidity fee when the method is constant-fee results in a fee-factor of 0.8% (0042-LIQF-058) ### CHANGE OF NETWORK PARAMETERS TESTS diff --git a/protocol/features.json b/protocol/features.json index 96f61c6cd..7c7508886 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -104,7 +104,9 @@ "Modify liquidation mechanics": { "milestone": "palazzo", "acs": [ - "0042-LIQF-056" + "0042-LIQF-056", + "0042-LIQF-057", + "0042-LIQF-058" ] }, "Passive liquidity": { From 27b90a13451248ec28f7216b66c39cd448c329c6 Mon Sep 17 00:00:00 2001 From: Gordsport <83510148+gordsport@users.noreply.github.com> Date: Tue, 7 Nov 2023 10:58:37 +0000 Subject: [PATCH 0694/1171] chore: add ACs to features.json from transfer fee improvements This adds the ACs from: - https://github.com/vegaprotocol/specs/pull/2038 --- protocol/features.json | 2 ++ 1 file changed, 2 insertions(+) diff --git a/protocol/features.json b/protocol/features.json index 7c7508886..b464e783b 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -121,6 +121,8 @@ "milestone": "palazzo", "acs": [ "0057-TRAN-011", + "0057-TRAN-012", + "0057-TRAN-013", "0057-TRAN-064", "0057-TRAN-065" ] From fe2f61bdb89adec22cd083c95d57d8bcb8f2bdcb Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Tue, 7 Nov 2023 16:04:10 +0000 Subject: [PATCH 0695/1171] feat: add default value --- 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 856fb156a..ea145b87a 100644 --- a/protocol/0057-TRAN-transfers.md +++ b/protocol/0057-TRAN-transfers.md @@ -157,7 +157,7 @@ Note: if there is no market with contribution to the reward metric - no transfer A fee is taken from all transfers (except transfers from a vested account to a general account held by the same key), 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. -Let `N` stand for `transfer.feeDiscountNumOfEpoch`. This is a network parameter that specifies the time frame over which we accumulate the taker fees that can offset transfer fees. +Let `N` stand for `transfer.feeDiscountNumOfEpoch`. This is a network parameter that specifies the time frame over which we accumulate the taker fees that can offset transfer fees. The default value for `transfer.feeDiscountNumOfEpoch` is 30, with an upper boundary of 1000 and a lower boundary of 1. For each party and for each asset store the taker fees paid by the party in a given epoch for `N` epochs; this will be used to determine a transfer fee discount as described below. @@ -185,7 +185,7 @@ Take `transfer.feeDiscountNumOfEpoch = 2`. | transfer fee theoretical | 5 | 15 | 3 | 4 | | transfer fee paid | 5 | 5 | 0 | 0 | -The fee is determined by the `transfer.fee.factor` and is subject to a cap defined by the multiplier `transfer.fee.maxQuantumAmount` as specified in the network parameters, which governs the proportion of each transfer taken as a fee. +The fee is determined by the `transfer.fee.factor` and is subject to a cap defined by the multiplier `transfer.fee.maxQuantumAmount` as specified in the network parameters, which governs the proportion of each transfer taken as a fee. As such, the transfer fee value used will be: `min(transfer amount * transfer.fee.factor, transfer.fee.maxQuantumAmount * quantum)`, `quantum` is for asset The fee is taken from the transfer initiator's account immediately on execution, and is taken on top of the total amount transferred. From fbd9b96b5b2f6c71ec21b82dff5959749ceaf4d7 Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Tue, 7 Nov 2023 16:20:31 +0000 Subject: [PATCH 0696/1171] feat: update lower boundary --- 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 ea145b87a..4a1da8ca5 100644 --- a/protocol/0057-TRAN-transfers.md +++ b/protocol/0057-TRAN-transfers.md @@ -157,7 +157,7 @@ Note: if there is no market with contribution to the reward metric - no transfer A fee is taken from all transfers (except transfers from a vested account to a general account held by the same key), 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. -Let `N` stand for `transfer.feeDiscountNumOfEpoch`. This is a network parameter that specifies the time frame over which we accumulate the taker fees that can offset transfer fees. The default value for `transfer.feeDiscountNumOfEpoch` is 30, with an upper boundary of 1000 and a lower boundary of 1. +Let `N` stand for `transfer.feeDiscountNumOfEpoch`. This is a network parameter that specifies the time frame over which we accumulate the taker fees that can offset transfer fees. The default value for `transfer.feeDiscountNumOfEpoch` is 30, with an upper boundary of 1000 and a lower boundary of 0. For each party and for each asset store the taker fees paid by the party in a given epoch for `N` epochs; this will be used to determine a transfer fee discount as described below. From 0e271985f22df9597eb4c3856b6a37c1faca3f21 Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Tue, 7 Nov 2023 16:24:37 +0000 Subject: [PATCH 0697/1171] chore: markdown --- 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 4a1da8ca5..b0639f696 100644 --- a/protocol/0057-TRAN-transfers.md +++ b/protocol/0057-TRAN-transfers.md @@ -185,7 +185,7 @@ Take `transfer.feeDiscountNumOfEpoch = 2`. | transfer fee theoretical | 5 | 15 | 3 | 4 | | transfer fee paid | 5 | 5 | 0 | 0 | -The fee is determined by the `transfer.fee.factor` and is subject to a cap defined by the multiplier `transfer.fee.maxQuantumAmount` as specified in the network parameters, which governs the proportion of each transfer taken as a fee. +The fee is determined by the `transfer.fee.factor` and is subject to a cap defined by the multiplier `transfer.fee.maxQuantumAmount` as specified in the network parameters, which governs the proportion of each transfer taken as a fee. As such, the transfer fee value used will be: `min(transfer amount * transfer.fee.factor, transfer.fee.maxQuantumAmount * quantum)`, `quantum` is for asset The fee is taken from the transfer initiator's account immediately on execution, and is taken on top of the total amount transferred. From 38b5186c0e2d18bbdde42c4e87aba93d96015c19 Mon Sep 17 00:00:00 2001 From: Witold Date: Mon, 6 Nov 2023 14:00:18 +0000 Subject: [PATCH 0698/1171] refactor: modify liquidation mechanics --- protocol/0001-MKTF-market_framework.md | 1 + protocol/0012-POSR-position_resolution.md | 179 ++++++---------------- 2 files changed, 48 insertions(+), 132 deletions(-) diff --git a/protocol/0001-MKTF-market_framework.md b/protocol/0001-MKTF-market_framework.md index 1d0599a5f..1f4bc30d5 100644 --- a/protocol/0001-MKTF-market_framework.md +++ b/protocol/0001-MKTF-market_framework.md @@ -32,6 +32,7 @@ Data: - **Position Decimal Places**: number of decimal places for orders and positions, i.e. if this is 2 then the smallest increment that can be traded is 0.01, for example 0.01 BTC in a `BTSUSD` market. - If this is negative e.g. -3 this means that the smallest order and position is of size 1000. - Accepted values are `-6,...,-1,0,1,2,...,6`. +- **Liquidation strategy**: A field specifying the liquidation strategy for the market. Please refer to [0012-POSR-position_resolution](./0012-POSR-position_resolution.md#managing-networks-position) for supported strategies. Note: it is agreed that initially the integer representation of the full precision of both order and positions can be required to fit into an int64, so this means that the largest position/order size possible reduces by a factor of ten for every extra decimal place used. This also means that, for instance, it would not be possible to create a `BTCUSD` market that allows order/position sizes equivalent to 1 sat. diff --git a/protocol/0012-POSR-position_resolution.md b/protocol/0012-POSR-position_resolution.md index 4dbaea5dc..457d76573 100644 --- a/protocol/0012-POSR-position_resolution.md +++ b/protocol/0012-POSR-position_resolution.md @@ -2,167 +2,82 @@ ## Acceptance Criteria -- All orders of "distressed traders" are cancelled (0012-POSR-001) -- Open positions of distressed traders are closed (0012-POSR-002) -- One market order is submitted for the net liability (0012-POSR-003) +- All orders of "distressed traders" in cross-margin mode are cancelled (0012-POSR-001) +- Open positions of distressed traders are closed immediately (0012-POSR-002) - 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) +- Non-distressed traders who trade with the network because their open orders are hit during the networks' 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 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) +- When a party is distressed and gets closed out the network's position gets modified to reflect that it's now the network party that holds that volume. (0012-POSR-009) -## Summary - -Position resolution is the mechanism which deals with closing out distressed positions on a given market. It is instigated when one or more participant's collateral balance is insufficient to fulfil their settlement or margin liabilities. - -## Guide-level explanation +- When the network party holds a non-zero position and there are not enough funds in market's insurance pool to meet the mark-to-market payment the network's position is unaffected and loss socialisation is applied. (0012-POSR-010) -## Reference-level explanation +- When the network party holds a non-zero position and the market's insurance pool balance is below the network party's maintenance margin for that market the network's position in that market remains unaffected. (0012-POSR-011) -Any trader that has insufficient collateral to cover their margin liability is referred to as a "distressed trader". +- The liquidation strategy can be updated using the market update transaction (0012-POSR-012) -### Position resolution algorithm +- When the market is configured to use: + - `disposal time step` = `10s`, + - `disposal fraction` = `0.5`, + - `full disposal size` = `50`, + - `max fraction of book side within liquidity bounds consumed` = `0.01` -See [Whitepaper](https://vega.xyz/papers/vega-protocol-whitepaper.pdf), Section 5.3 , steps 1 - 3 + and the volume on the buy side of the book within the liquidity bounds is always `10,000` (as volume on the book gets filled new orders get placed) then liquidating a distressed party with an open volume of `280` results in 4 network trades in total spaced `10s` apart with volumes of: `100`, `90`, `45`, `45`. (0012-POSR-013) -1. A "distressed trader" in cross-margining mode has all their open orders on that market cancelled. Note, the network must then recalculate their margin requirement on their remaining open position, perform one final margin search 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 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 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. +- It is possible to check the network party's open volume and margin level in any market via the API. (0012-POSR-014) -### Note +- It is possible to check the time of the next liquidation trade attempt in any market via the API. (0012-POSR-015) -- Entire distressed position should always be liquidated - even if reducing position size, by say 50%, would result in the remaining portion being above the trader's maintenance margin. -- When there's insufficient volume on the order-book to close out a distressed position no action should be taken: the position remains open and any amounts in trader's margin account should stay there. Same principle should apply if upon next margin recalculation the position is still distressed. -- If the party is distressed at a point of leaving auction it should be closedout immediately (provided there's enough volume on the book once all the pegged and liquidity provision orders get redeployed). - -## Examples and Pseudo code +## Summary -### _Scenario - All steps_ - -`Trader1 open position: +5` -`Trader1 open orders: 0` -`Trader2 open position: -4` -`Trader2 open orders: 0` -`Trader3 open position: +2` -`Trader3 open orders: 0` - -#### STEP 1 +Position resolution is the mechanism which deals with closing out distressed positions on a given market. It is instigated when one or more participant's margin account balance falls below their latest maintenance margin level. -No traders are removed from the distressed trader list. +## Guide-level explanation -#### STEP 2 +## Reference-level explanation -`NetOutstandingLiability = 5 - 4 + 2 = 3` +Any trader that has insufficient collateral to cover their margin liability is referred to as a "distressed trader". -#### STEP 3 +### Position resolution algorithm -```json -LiquiditySourcingOrder: { - type: 'market', - direction: 'sell', - size: 3 -} +#### Liquidating distressed party's position in a market -LiquiditySourcingTrade1: { - buyer: Trader4, - seller: Network, - size: 2, - price: 120, - type: 'liquidity-sourcing' -} +- Position resolution evaluation gets carried out each time the mark price is updated, strictly after the margin levels margin level update and mark-to-market settlement. -LiquiditySourcingTrade2: { - buyer: Trader5, - seller: Network, - size: 1, - price: 100, - type: 'liquidity-sourcing' +- During position resolution evaluation party's margin account balance is compared to it's latest maintenance margin level. If the account balance is below the margin level then the party gets marked as distressed. -} +- If a party marked as "distressed" has the cross-margin mode selected for the market being considered: -``` + - all their open orders on that market get cancelled without releasing any collateral from the margin account, + - their margin level then gets recalculated to account only for the open volume they hold in a market + - if party's margin account balance is now above or equal to their latest maintenance margin level then such party is no longer marked as "distressed". -#### STEP 4 +- If party's is marked as "distressed" at this stage then: -Close out trades are generated with the distressed traders + - their open volume gets added to network's open volume for that market, + - party's open volume in that market gets set to 0, + - the full amount of party's margin account balance gets transferred to market's insurance pool. -```json -CloseOutTrade1 { - buyer: Network, - seller: Trader1, - size: 5, - price: 113.33, - type: 'safety-provision' -} +This concludes the position resolution from party's perspective. -CloseOutTrade2 { - buyer: Trade2, - seller: Network, - size: 4, - price: 113.33, - type: 'safety-provision' -} +#### Managing network's position -CloseOutTrade3 { - buyer: Network, - seller: Trader3, - size: 2, - price: 113.33, - type: 'safety-provision' -} -``` +Whilst network has a non-zero position in a given market it's treated as any other party with market's insurance in that market acting as its margin account and with and exception that margin search, margin release or liquidation are never attempted on a network party. -This results in the open position sizes for all distressed traders and the network entities to be zero. +Whenever the network party has a non-zero position it attempts to unload it using an [immediate or cancel](./0014-ORDT-order_types.md) limit order. If the the network has a `long` position it will submit a `sell` order. If it has a short position it will submit a buy order. The size of that order is chosen according to the liquidation strategy which forms a part of the market's configuration. The strategy can be updated at any point whilst market is active with a market change [governance vote](./0028-GOVE-governance.md#2-change-market-parameters). -`// OpenPosition of Network = -3 +5 -4 +2 = 0` -`// OpenPosition of Trader1 = +5 -5 = 0` -`// OpenPosition of Trader2 = -4 +4 = 0` -`// OpenPosition of Trader3 = +2 - 2 = 0` +Currently only one liquidation strategy is supported and its defined by the following parameters: -#### STEP 5 +- `disposal time step` (min: `1s`, max: `1h`, default: `n=10s`): network attempts to unload its position in a given market every time it goes out of auction and then every `n` seconds as long as market is not in auction mode and while the network's position is not equal to `0`, +- `disposal fraction` (min: `0.01`, max: `1`, default: `0.1`): fraction of network's current open volume that it will try to reduce in a single disposal attempt, +- `full disposal size` (min: `0`, max: `max int`, default: `20`): once net absolute value of network's open volume is at or below that value, the network will attempt to dispose the remaining amount in one go, +- `max fraction of book side within liquidity bounds consumed` (min: `0`, max: `1`, default: `m=0.05`): once the network chooses the size of its order (`s_candidate`) the effective size will be calculated as `s_effective=min(m*N, s_candidate)`, where `N` is the sum of volume (on the side of the book with which the network's order will be matching) that falls within the range implied by the `market.liquidity.priceRange` [parameter](./0044-LIME-lp_mechanics.md#market-parameters), -The collateral from distressed traders is moved to the market's insurance pool - -```json -// sent by Settlement Engine to the Collateral Engine -TransferRequest1 { - from: [Trader1_MarginAccount], - to: MarketInsuranceAccount, - amount: Trader1_MarginAccount.size, // this needs to be the full amount -} +Assume the price range implied by the `market.liquidity.priceRange` is `[a, b]`. Once the network has worked out a size of its immediate or cancel limit order it sets it's price to `a` if it's a sell order or `b` if it's a buy order, and it submits the order. -TransferRequest2 { - from: [Trader2_MarginAccount], - to: MarketInsuranceAccount, - amount: Trader2_MarginAccount.size, // this needs to be the full amount -} +Note that different liquidation strategies with different parameters might be proposed in the future, hence implementation should allow for easy substitution of strategies. -TransferRequest3 { - from: [Trader3_MarginAccount], - to: MarketInsuranceAccount, - amount: Trader3_MarginAccount.size, // this needs to be the full amount -} -``` - -#### STEP 6 +API requirements: -Traders from step 3 need to be settled. - -Prior to STEP 3 trades, assume Trader 4 and Trader 5 had the following open positions. - -`// OpenPosition of Trader4 = -3` -`// OpenPosition of Trader5 = 15` - -Trader 4 has therefore closed out 2 contracts through the `LiquiditySourcingTrade` 1. These need to be settled against the trade price. - -```json -TransferRequest4 { - from: [MarketInsuranceAccount], - to: Trader4_MarginAccount, - amount: (120 - PreviousMarkPrice) * -2, // this is the movement since the last settlement multiplied by the volume of the closed out amount -} - -``` +- create an endpoint to easily identify network's position in any given market, +- create an endpoint to easily identify network's margin levels in any given market, +- create an endpoint to easily check time of next liquidation trade attempt. From 7db53ec555146ef27016bc3b1b772967f293276b Mon Sep 17 00:00:00 2001 From: Witold Date: Mon, 6 Nov 2023 14:07:22 +0000 Subject: [PATCH 0699/1171] chore: map ACs to feature --- protocol/features.json | 18 ++++++++++++++---- 1 file changed, 14 insertions(+), 4 deletions(-) diff --git a/protocol/features.json b/protocol/features.json index b464e783b..39b51fed9 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -104,9 +104,15 @@ "Modify liquidation mechanics": { "milestone": "palazzo", "acs": [ - "0042-LIQF-056", - "0042-LIQF-057", - "0042-LIQF-058" + "0012-POSR-001", + "0012-POSR-005", + "0012-POSR-009", + "0012-POSR-010", + "0012-POSR-011", + "0012-POSR-012", + "0012-POSR-013", + "0012-POSR-014", + "0012-POSR-015" ] }, "Passive liquidity": { @@ -138,6 +144,10 @@ }, "Unknown": { "milestone": "unknown", - "acs": [] + "acs": [ + "0042-LIQF-056", + "0042-LIQF-057", + "0042-LIQF-058" + ] } } From 96701fcd3e7605c6d9890d161b5366c5f874c65a Mon Sep 17 00:00:00 2001 From: Witold Date: Tue, 7 Nov 2023 18:08:06 +0100 Subject: [PATCH 0700/1171] refactor: remove defaults --- protocol/0012-POSR-position_resolution.md | 19 ++++++++++++++----- 1 file changed, 14 insertions(+), 5 deletions(-) diff --git a/protocol/0012-POSR-position_resolution.md b/protocol/0012-POSR-position_resolution.md index 457d76573..acaa18609 100644 --- a/protocol/0012-POSR-position_resolution.md +++ b/protocol/0012-POSR-position_resolution.md @@ -67,14 +67,23 @@ Whenever the network party has a non-zero position it attempts to unload it usin Currently only one liquidation strategy is supported and its defined by the following parameters: -- `disposal time step` (min: `1s`, max: `1h`, default: `n=10s`): network attempts to unload its position in a given market every time it goes out of auction and then every `n` seconds as long as market is not in auction mode and while the network's position is not equal to `0`, -- `disposal fraction` (min: `0.01`, max: `1`, default: `0.1`): fraction of network's current open volume that it will try to reduce in a single disposal attempt, -- `full disposal size` (min: `0`, max: `max int`, default: `20`): once net absolute value of network's open volume is at or below that value, the network will attempt to dispose the remaining amount in one go, -- `max fraction of book side within liquidity bounds consumed` (min: `0`, max: `1`, default: `m=0.05`): once the network chooses the size of its order (`s_candidate`) the effective size will be calculated as `s_effective=min(m*N, s_candidate)`, where `N` is the sum of volume (on the side of the book with which the network's order will be matching) that falls within the range implied by the `market.liquidity.priceRange` [parameter](./0044-LIME-lp_mechanics.md#market-parameters), +- `disposal time step` (min: `1s`, max: `1h`): network attempts to unload its position in a given market every time it goes out of auction and then every `disposal time step` seconds as long as market is not in auction mode and while the network's position is not equal to `0`, +- `disposal fraction` (min: `0.01`, max: `1`): fraction of network's current open volume that it will try to reduce in a single disposal attempt, +- `full disposal size` (min: `0`, max: `max int`): once net absolute value of network's open volume is at or below that value, the network will attempt to dispose the remaining amount in one go, +- `max fraction of book side within liquidity bounds consumed` (min: `0`, max: `1`): once the network chooses the size of its order (`s_candidate`) the effective size will be calculated as `s_effective=min(m*N, s_candidate)`, where `N` is the sum of volume (on the side of the book with which the network's order will be matching) that falls within the range implied by the `market.liquidity.priceRange` [parameter](./0044-LIME-lp_mechanics.md#market-parameters) and `m` is the `max fraction of book side within liquidity bounds consumed`. Assume the price range implied by the `market.liquidity.priceRange` is `[a, b]`. Once the network has worked out a size of its immediate or cancel limit order it sets it's price to `a` if it's a sell order or `b` if it's a buy order, and it submits the order. -Note that different liquidation strategies with different parameters might be proposed in the future, hence implementation should allow for easy substitution of strategies. +Note that setting: + +- `disposal time step` = `0s`, +- `disposal fraction` = `1`, +- `full disposal size` = `max int`, +- `max fraction of book side within liquidity bounds consumed` = `1` + +is closest to reproducing the legacy setup where party would get liquidated immediately (with a difference that closeout now happens immediately even if there's not enough volume on the book to fully absorb it) hence the above values should be used when migrating existing markets to a new version. For all new markets these values should be specified explicitly. + +Different liquidation strategies with different parameters might be proposed in the future, hence implementation should allow for easy substitution of strategies. API requirements: From 7afdcd44a389075b1068c99c1f558f021313c479 Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Wed, 8 Nov 2023 15:14:28 +0000 Subject: [PATCH 0701/1171] feat: update AC 0019-MCAL-030 --- protocol/0019-MCAL-margin_calculator.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0019-MCAL-margin_calculator.md b/protocol/0019-MCAL-margin_calculator.md index 069201c5a..6daaf71b4 100644 --- a/protocol/0019-MCAL-margin_calculator.md +++ b/protocol/0019-MCAL-margin_calculator.md @@ -73,7 +73,7 @@ - `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 = 5565 + 0.5 * 70 * 1 = 5600` (0019-MCAL-027) - - However is position is instead `-1`, with the same margin requirement, if `margin funding factor = 0.5`, `total margin requirement = futures margin + funding margin = 5565 + 0.5 * max(0, 70 * -1) = 5565`(0019-MCAL-021) + - However is position is instead `-1`, with the same margin requirement, if `margin funding factor = 0.5`, `total margin requirement = futures margin + funding margin = 5565 + 0.5 * max(0, 70 * -1) = 5565`(0019-MCAL-030) - If instead - `clamp_upper_bound*s_twap > clamp_lower_bound*s_twap > (1 + delta_t * interest_rate)*s_twap-f_twap)` From fe9cf55473e337dfedf165393b0143b4cbfdf25c Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Wed, 8 Nov 2023 15:27:14 +0000 Subject: [PATCH 0702/1171] feat: add json file --- protocol/features.json | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/protocol/features.json b/protocol/features.json index 39b51fed9..4f17069be 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -98,7 +98,8 @@ "0019-MCAL-026", "0019-MCAL-027", "0019-MCAL-028", - "0019-MCAL-029" + "0019-MCAL-029", + "0019-MCAL-030" ] }, "Modify liquidation mechanics": { From d9f6180254dd189fc721da709fa5554d9780ee08 Mon Sep 17 00:00:00 2001 From: Sohill-Patel <85170301+Sohill-Patel@users.noreply.github.com> Date: Wed, 8 Nov 2023 17:23:10 +0000 Subject: [PATCH 0703/1171] chore: correct reference --- 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 b0639f696..e0aced232 100644 --- a/protocol/0057-TRAN-transfers.md +++ b/protocol/0057-TRAN-transfers.md @@ -275,8 +275,8 @@ message CancelTransfer { - The fees are being paid into the infrastructure pool - As a user I can do a transfer from a vested account to a general account held by the same key without incurring any fees (0057-TRAN-066). - As a user I can do a transfer from a vested account to another account that isn't general account for my key but in this case transfer fees are incurred (0057-TRAN-069). -- As a user, I **can not** transfer a quantum amount less than `transfer.fee.minTransferQuantumAmount` from any of the valid accounts excluding a vested account (0057-TRAN-067). -- As a user, I **can** transfer a quantum amount less than `transfer.fee.minTransferQuantumAmount` from a vested account if and only if I transfer the full balance (0057-TRAN-068). +- As a user, I **can not** transfer a quantum amount less than `transfer.minTransferQuantumAmount` from any of the valid accounts excluding a vested account (0057-TRAN-067). +- As a user, I **can** transfer a quantum amount less than `transfer.minTransferQuantumAmount` from a vested account if and only if I transfer the full balance (0057-TRAN-068). - 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. From 37a4a944e80a5a3e0bb29ccbcb295519c661033a Mon Sep 17 00:00:00 2001 From: Gordsport <83510148+gordsport@users.noreply.github.com> Date: Thu, 9 Nov 2023 10:26:17 +0000 Subject: [PATCH 0704/1171] chore: Update features.json for LP fee setting improvements --- protocol/features.json | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/protocol/features.json b/protocol/features.json index 4f17069be..17f4f8bd0 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -143,12 +143,16 @@ "0057-TRAN-069" ] }, - "Unknown": { - "milestone": "unknown", + "Liquidity fee setting": { + "milestone": "palazzo", "acs": [ "0042-LIQF-056", "0042-LIQF-057", "0042-LIQF-058" ] } + "Unknown": { + "milestone": "unknown", + "acs": [ ] + } } From bf71f8ee9e3a0b46e68957d6c63a6cfc4a2ac487 Mon Sep 17 00:00:00 2001 From: Gordsport <83510148+gordsport@users.noreply.github.com> Date: Thu, 9 Nov 2023 10:28:37 +0000 Subject: [PATCH 0705/1171] fix: syntax --- protocol/features.json | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/features.json b/protocol/features.json index 17f4f8bd0..fb1664a6e 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -150,7 +150,7 @@ "0042-LIQF-057", "0042-LIQF-058" ] - } + }, "Unknown": { "milestone": "unknown", "acs": [ ] From 8616207fdbe2a2fdf3505bbb939c1c04a7de1c53 Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Thu, 9 Nov 2023 11:17:29 +0000 Subject: [PATCH 0706/1171] feat: update margin example in 0019 --- protocol/0019-MCAL-margin_calculator.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/protocol/0019-MCAL-margin_calculator.md b/protocol/0019-MCAL-margin_calculator.md index 6daaf71b4..e1d315796 100644 --- a/protocol/0019-MCAL-margin_calculator.md +++ b/protocol/0019-MCAL-margin_calculator.md @@ -34,9 +34,9 @@ sell 10 @ 100 100 ``` - then the maintenance margin for the party is `15 900 x 0.25 x 1 + 0.1 x 1 x 15 900 = 5 565`. (0019-MCAL-024) + then the maintenance margin for the party is `min(1*(100000-15900), 15900 x 0.25 x 1) + 0.1 x 1 x 15900 = 5565`. (0019-MCAL-024) -- In the same situation as above, if `market.linearSlippageFactor = 100`, (i.e. 10 000%) instead, then the margin for the party is `1 590 000 + 0.1 x 1 x 15900 = 1 591 590`. (0019-MCAL-025) +- In the same situation as above, if `market.linearSlippageFactor = 100`, (i.e. 10 000%) instead, then the margin for the party is `min(1*(100000-15900), 15900 x 100 x 1) + 0.1 x 1 x 15900 = 85690`. (0019-MCAL-025) - If the `market.linearSlippageFactor` 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) @@ -51,7 +51,7 @@ sell 10 @ 100 100 ``` - then the dated future maintenance margin component for the party is `15 900 x 0.25 x 1 + 0.1 x 1 x 15 900 = 5 565`. The current accrued funding payment for the perpetual component is calculated using + then the dated future maintenance margin component for the party is `min(1*(100000-15900), 15900 x 0.25 x 1) + 0.1 x 1 x 15900 = 5565`. 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) From 02339cc32e3fb7687ffaf4f2225b74f74306689c Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Thu, 9 Nov 2023 11:25:10 +0000 Subject: [PATCH 0707/1171] chore: format --- protocol/0019-MCAL-margin_calculator.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/protocol/0019-MCAL-margin_calculator.md b/protocol/0019-MCAL-margin_calculator.md index e1d315796..872127220 100644 --- a/protocol/0019-MCAL-margin_calculator.md +++ b/protocol/0019-MCAL-margin_calculator.md @@ -34,9 +34,9 @@ sell 10 @ 100 100 ``` - then the maintenance margin for the party is `min(1*(100000-15900), 15900 x 0.25 x 1) + 0.1 x 1 x 15900 = 5565`. (0019-MCAL-024) + then the maintenance margin for the party is `min(1 x (100000-15900), 15900 x 0.25 x 1) + 0.1 x 1 x 15900 = 5565`. (0019-MCAL-024) -- In the same situation as above, if `market.linearSlippageFactor = 100`, (i.e. 10 000%) instead, then the margin for the party is `min(1*(100000-15900), 15900 x 100 x 1) + 0.1 x 1 x 15900 = 85690`. (0019-MCAL-025) +- In the same situation as above, if `market.linearSlippageFactor = 100`, (i.e. 10 000%) instead, then the margin for the party is `min(1 x (100000-15900), 15900 x 100 x 1) + 0.1 x 1 x 15900 = 85690`. (0019-MCAL-025) - If the `market.linearSlippageFactor` 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) @@ -51,7 +51,7 @@ sell 10 @ 100 100 ``` - then the dated future maintenance margin component for the party is `min(1*(100000-15900), 15900 x 0.25 x 1) + 0.1 x 1 x 15900 = 5565`. The current accrued funding payment for the perpetual component is calculated using + then the dated future maintenance margin component for the party is `min(1 x (100000-15900), 15900 x 0.25 x 1) + 0.1 x 1 x 15900 = 5565`. 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) From 9a5f622c9686d71a1ebda6e94e27ca5ff32ff806 Mon Sep 17 00:00:00 2001 From: Charlie Date: Thu, 9 Nov 2023 15:32:05 +0000 Subject: [PATCH 0708/1171] refactor: clarify AC 0057-TRAN-069 --- 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 e0aced232..c5d9c122a 100644 --- a/protocol/0057-TRAN-transfers.md +++ b/protocol/0057-TRAN-transfers.md @@ -274,7 +274,7 @@ message CancelTransfer { - 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 I can do a transfer from a vested account to a general account held by the same key without incurring any fees (0057-TRAN-066). -- As a user I can do a transfer from a vested account to another account that isn't general account for my key but in this case transfer fees are incurred (0057-TRAN-069). +- If a user transfers funds from their vested account to any valid account other than their general account for that asset, they will incur fees. This includes accounts not owned by the user. (0057-TRAN-069). - As a user, I **can not** transfer a quantum amount less than `transfer.minTransferQuantumAmount` from any of the valid accounts excluding a vested account (0057-TRAN-067). - As a user, I **can** transfer a quantum amount less than `transfer.minTransferQuantumAmount` from a vested account if and only if I transfer the full balance (0057-TRAN-068). - As a user, when I initiate a delayed transfer, the funds are taken from my account immediately (0057-TRAN-008) From ac40b1e35a20b9dac6a0b2b9baf51e3957a3cdaf Mon Sep 17 00:00:00 2001 From: Vegaklaus <62546834+Vegaklaus@users.noreply.github.com> Date: Thu, 9 Nov 2023 11:42:07 -0800 Subject: [PATCH 0709/1171] Update 0057-TRAN-transfers.md Fixed some details. --- protocol/0057-TRAN-transfers.md | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/protocol/0057-TRAN-transfers.md b/protocol/0057-TRAN-transfers.md index c5d9c122a..3a4e70b97 100644 --- a/protocol/0057-TRAN-transfers.md +++ b/protocol/0057-TRAN-transfers.md @@ -164,14 +164,15 @@ For each party and for each asset store the taker fees paid by the party in a gi For each key for each asset assume you store a value denoted `c`. During the epoch `k`: -- if the party makes a transfer and `f` would be the theoretical fee the party should pay then the fee on the transfer that is actually charged is `-min(c-f,0)`. The system subsequently updates `c <- max(0,c-f)`. +- if the party makes a transfer and `f` would be the theoretical fee the party should pay then the fee on the transfer that is actually charged is `-min(f-c,0)`. The system subsequently updates `c <- max(0,c-f)`. At the end of epoch `k`: -1. update `c <- c - old_taker_fees`, where `old_taker_fees` is set to the total taker fees paid during epoch `k-N` if this value exists and `0` otherwise. +1. update `c <- max(0,c - old_fees)`, where `old_fees` is set to the total fees paid during epoch `k-N` if this value exists and `0` otherwise. -1. update `c <- c - taker_fees`, where `taker_fees` is the total taker fees paid during the epoch that just ended i.e. epoch `k`. +1. update `c <- c _ fees`, where `fees` is the total fees paid during the epoch that just ended i.e. epoch `k`. +Fees include taker_fees as well as taker_fees payed by the opposing side of a trade (i.e., all fees generated by trades in which this party was involved) We need appropriate APIs to enable the frontend to display the amount eligible for fee-free transfers / correctly display the fee on any transfer a party is proposing. ### Example From d93c2dd3ff158fd65b064d788f08413f849197bb Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Fri, 10 Nov 2023 09:35:13 +0000 Subject: [PATCH 0710/1171] feat: change taker fee to total fee --- protocol/0057-TRAN-transfers.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/protocol/0057-TRAN-transfers.md b/protocol/0057-TRAN-transfers.md index 3a4e70b97..61b1a755d 100644 --- a/protocol/0057-TRAN-transfers.md +++ b/protocol/0057-TRAN-transfers.md @@ -157,9 +157,9 @@ Note: if there is no market with contribution to the reward metric - no transfer A fee is taken from all transfers (except transfers from a vested account to a general account held by the same key), 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. -Let `N` stand for `transfer.feeDiscountNumOfEpoch`. This is a network parameter that specifies the time frame over which we accumulate the taker fees that can offset transfer fees. The default value for `transfer.feeDiscountNumOfEpoch` is 30, with an upper boundary of 1000 and a lower boundary of 0. +Let `N` stand for `transfer.feeDiscountNumOfEpoch`. This is a network parameter that specifies the time frame over which we accumulate the total fees that can offset transfer fees. The default value for `transfer.feeDiscountNumOfEpoch` is 30, with an upper boundary of 1000 and a lower boundary of 0. -For each party and for each asset store the taker fees paid by the party in a given epoch for `N` epochs; this will be used to determine a transfer fee discount as described below. +For each party and for each asset store the total fees paid by the party in a given epoch for `N` epochs; this will be used to determine a transfer fee discount as described below. For each key for each asset assume you store a value denoted `c`. During the epoch `k`: @@ -181,7 +181,7 @@ Take `transfer.feeDiscountNumOfEpoch = 2`. | Epoch | 1 | 2 | 3 | 4 | | ------------------------ |---------------------|---------------------|---------------------|------------------| -| taker fee paid | 10 | 20 | 5 | 8 | +| total fee paid | 10 | 20 | 5 | 8 | | counter | 0 | 10 | 20 | 22 | | transfer fee theoretical | 5 | 15 | 3 | 4 | | transfer fee paid | 5 | 5 | 0 | 0 | From b0db7f1efcd3f95fb74f40bffcfd6b2e6c46223b Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Fri, 10 Nov 2023 10:17:51 +0000 Subject: [PATCH 0711/1171] feat: update upper boundary for feeDiscountNumOfEpoch --- 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 61b1a755d..2f1ddac07 100644 --- a/protocol/0057-TRAN-transfers.md +++ b/protocol/0057-TRAN-transfers.md @@ -157,7 +157,7 @@ Note: if there is no market with contribution to the reward metric - no transfer A fee is taken from all transfers (except transfers from a vested account to a general account held by the same key), 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. -Let `N` stand for `transfer.feeDiscountNumOfEpoch`. This is a network parameter that specifies the time frame over which we accumulate the total fees that can offset transfer fees. The default value for `transfer.feeDiscountNumOfEpoch` is 30, with an upper boundary of 1000 and a lower boundary of 0. +Let `N` stand for `transfer.feeDiscountNumOfEpoch`. This is a network parameter that specifies the time frame over which we accumulate the total fees (which is the value generated for network by both price takers and price makers) that can offset transfer fees. The default value for `transfer.feeDiscountNumOfEpoch` is 30, with an upper boundary of 60 and a lower boundary of 0. For each party and for each asset store the total fees paid by the party in a given epoch for `N` epochs; this will be used to determine a transfer fee discount as described below. From 644b3f56be32e5d8aec0792e29ad27c74f26ac58 Mon Sep 17 00:00:00 2001 From: David Siska <62546419+davidsiska-vega@users.noreply.github.com> Date: Fri, 10 Nov 2023 14:01:56 +0000 Subject: [PATCH 0712/1171] feat: fee free transfers --- protocol/0057-TRAN-transfers.md | 16 +++++++++++----- 1 file changed, 11 insertions(+), 5 deletions(-) diff --git a/protocol/0057-TRAN-transfers.md b/protocol/0057-TRAN-transfers.md index 2f1ddac07..23b7369b6 100644 --- a/protocol/0057-TRAN-transfers.md +++ b/protocol/0057-TRAN-transfers.md @@ -157,9 +157,14 @@ Note: if there is no market with contribution to the reward metric - no transfer A fee is taken from all transfers (except transfers from a vested account to a general account held by the same key), 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. -Let `N` stand for `transfer.feeDiscountNumOfEpoch`. This is a network parameter that specifies the time frame over which we accumulate the total fees (which is the value generated for network by both price takers and price makers) that can offset transfer fees. The default value for `transfer.feeDiscountNumOfEpoch` is 30, with an upper boundary of 60 and a lower boundary of 0. +Fee are primarily a spam-protection mechanism, so for accounts generating "useful activity" discounts apply. -For each party and for each asset store the total fees paid by the party in a given epoch for `N` epochs; this will be used to determine a transfer fee discount as described below. +### Transfer fee discounts + +Let `D` stand for `transfer.feeDiscountDecay`. This is a network parameter that specifies the how cumulated trading fees decay for the purpose of being used to do transfer-fee-free transfers. Minimum value is `0`, maximum value is any decimal strictly less than `1` and default it `0.5`. +Let `M` stand for network parameter `transfer.feeDiscountMinimumTrackedAmount`. Minimum value is `0`, there is no maximum beyond that dictated by the data type used and the default is `0.001`. + +For each party and for each asset store the an amount which tracks all trading fees paid and received by the party with tranfer fees subtracted and the amount decayed as specified below. For each key for each asset assume you store a value denoted `c`. During the epoch `k`: @@ -168,11 +173,12 @@ During the epoch `k`: At the end of epoch `k`: -1. update `c <- max(0,c - old_fees)`, where `old_fees` is set to the total fees paid during epoch `k-N` if this value exists and `0` otherwise. +1. update `c <- c + all_trading_fees_paid_and_received`, where `all_trading_fees_paid_and_received` are the trading fees paid by the party (taker fees) plus the maker and liquidity fees received by the party during the epoch in that asset across all markets. + +1. update `c <- c x D`, i.e. apply the decay factor `D` -1. update `c <- c _ fees`, where `fees` is the total fees paid during the epoch that just ended i.e. epoch `k`. +1. if `c` is less than `M x quantum` (where quantum is the asset quantum) then set `c <- 0`. -Fees include taker_fees as well as taker_fees payed by the opposing side of a trade (i.e., all fees generated by trades in which this party was involved) We need appropriate APIs to enable the frontend to display the amount eligible for fee-free transfers / correctly display the fee on any transfer a party is proposing. ### Example From e6c5731e6db4ea0f4215776b7147384ac3490088 Mon Sep 17 00:00:00 2001 From: David Siska <62546419+davidsiska-vega@users.noreply.github.com> Date: Fri, 10 Nov 2023 14:06:52 +0000 Subject: [PATCH 0713/1171] feat: fee free transfers --- 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 23b7369b6..bf05542f5 100644 --- a/protocol/0057-TRAN-transfers.md +++ b/protocol/0057-TRAN-transfers.md @@ -173,7 +173,7 @@ During the epoch `k`: At the end of epoch `k`: -1. update `c <- c + all_trading_fees_paid_and_received`, where `all_trading_fees_paid_and_received` are the trading fees paid by the party (taker fees) plus the maker and liquidity fees received by the party during the epoch in that asset across all markets. +1. update `c <- c + all_trading_fees_for_trades_involved_in`, where `all_trading_fees_for_trades_involved_in` are the cumulated trading fees paid by the aggressive party (taker fees) but also cumulated (with a +sign) the trading fees result from any trade in which the party was invovled as the passive party (i.e. their limit order got lifted). 1. update `c <- c x D`, i.e. apply the decay factor `D` From 2c0ba21c3ec001441999c6ba6a8d3b2ca620bba7 Mon Sep 17 00:00:00 2001 From: David Siska <62546419+davidsiska-vega@users.noreply.github.com> Date: Fri, 10 Nov 2023 14:10:43 +0000 Subject: [PATCH 0714/1171] feat: fee free transfers --- protocol/0057-TRAN-transfers.md | 23 +++++++---------------- 1 file changed, 7 insertions(+), 16 deletions(-) diff --git a/protocol/0057-TRAN-transfers.md b/protocol/0057-TRAN-transfers.md index bf05542f5..f7d6c3e8f 100644 --- a/protocol/0057-TRAN-transfers.md +++ b/protocol/0057-TRAN-transfers.md @@ -157,6 +157,13 @@ Note: if there is no market with contribution to the reward metric - no transfer A fee is taken from all transfers (except transfers from a vested account to a general account held by the same key), 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 determined by the `transfer.fee.factor` and is subject to a cap defined by the multiplier `transfer.fee.maxQuantumAmount` as specified in the network parameters, which governs the proportion of each transfer taken as a fee. + +As such, the transfer fee value used will be: `min(transfer amount * transfer.fee.factor, transfer.fee.maxQuantumAmount * quantum)`, `quantum` is for asset +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-fees.md#collecting-and-distributing-fees). +Fees are charged in the asset that is being transferred. + Fee are primarily a spam-protection mechanism, so for accounts generating "useful activity" discounts apply. ### Transfer fee discounts @@ -181,23 +188,7 @@ At the end of epoch `k`: We need appropriate APIs to enable the frontend to display the amount eligible for fee-free transfers / correctly display the fee on any transfer a party is proposing. -### Example - -Take `transfer.feeDiscountNumOfEpoch = 2`. -| Epoch | 1 | 2 | 3 | 4 | -| ------------------------ |---------------------|---------------------|---------------------|------------------| -| total fee paid | 10 | 20 | 5 | 8 | -| counter | 0 | 10 | 20 | 22 | -| transfer fee theoretical | 5 | 15 | 3 | 4 | -| transfer fee paid | 5 | 5 | 0 | 0 | - -The fee is determined by the `transfer.fee.factor` and is subject to a cap defined by the multiplier `transfer.fee.maxQuantumAmount` as specified in the network parameters, which governs the proportion of each transfer taken as a fee. - -As such, the transfer fee value used will be: `min(transfer amount * transfer.fee.factor, transfer.fee.maxQuantumAmount * quantum)`, `quantum` is for asset -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-fees.md#collecting-and-distributing-fees). -Fees are charged in the asset that is being transferred. ## Proposed command From bbccbd05ea98c6bc687e19a90ff3d0f1372c9e2d Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Fri, 10 Nov 2023 14:30:38 +0000 Subject: [PATCH 0715/1171] chore: typo and markdown --- protocol/0057-TRAN-transfers.md | 10 ++++------ 1 file changed, 4 insertions(+), 6 deletions(-) diff --git a/protocol/0057-TRAN-transfers.md b/protocol/0057-TRAN-transfers.md index f7d6c3e8f..59ea7b62f 100644 --- a/protocol/0057-TRAN-transfers.md +++ b/protocol/0057-TRAN-transfers.md @@ -164,14 +164,14 @@ The fee is taken from the transfer initiator's account immediately on execution, 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. -Fee are primarily a spam-protection mechanism, so for accounts generating "useful activity" discounts apply. +Fee are primarily a spam-protection mechanism, so for accounts generating "useful activity" discounts apply. ### Transfer fee discounts Let `D` stand for `transfer.feeDiscountDecay`. This is a network parameter that specifies the how cumulated trading fees decay for the purpose of being used to do transfer-fee-free transfers. Minimum value is `0`, maximum value is any decimal strictly less than `1` and default it `0.5`. -Let `M` stand for network parameter `transfer.feeDiscountMinimumTrackedAmount`. Minimum value is `0`, there is no maximum beyond that dictated by the data type used and the default is `0.001`. +Let `M` stand for network parameter `transfer.feeDiscountMinimumTrackedAmount`. Minimum value is `0`, there is no maximum beyond that dictated by the data type used and the default is `0.001`. -For each party and for each asset store the an amount which tracks all trading fees paid and received by the party with tranfer fees subtracted and the amount decayed as specified below. +For each party and for each asset store the an amount which tracks all trading fees paid and received by the party with transfer fees subtracted and the amount decayed as specified below. For each key for each asset assume you store a value denoted `c`. During the epoch `k`: @@ -180,7 +180,7 @@ During the epoch `k`: At the end of epoch `k`: -1. update `c <- c + all_trading_fees_for_trades_involved_in`, where `all_trading_fees_for_trades_involved_in` are the cumulated trading fees paid by the aggressive party (taker fees) but also cumulated (with a +sign) the trading fees result from any trade in which the party was invovled as the passive party (i.e. their limit order got lifted). +1. update `c <- c + all_trading_fees_for_trades_involved_in`, where `all_trading_fees_for_trades_involved_in` are the cumulated trading fees paid by the aggressive party (taker fees) but also cumulated (with a +sign) the trading fees result from any trade in which the party was involved as the passive party (i.e. their limit order got lifted). 1. update `c <- c x D`, i.e. apply the decay factor `D` @@ -188,8 +188,6 @@ At the end of epoch `k`: We need appropriate APIs to enable the frontend to display the amount eligible for fee-free transfers / correctly display the fee on any transfer a party is proposing. - - ## Proposed command This new functionality requires the introduction of a new command in the transaction API. The payload is as follows: From 1f950675629c31bb285bfb49086c49ac04553659 Mon Sep 17 00:00:00 2001 From: David Siska <62546419+davidsiska-vega@users.noreply.github.com> Date: Fri, 10 Nov 2023 14:57:55 +0000 Subject: [PATCH 0716/1171] feat: fee free transfers --- 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 59ea7b62f..059be4870 100644 --- a/protocol/0057-TRAN-transfers.md +++ b/protocol/0057-TRAN-transfers.md @@ -180,10 +180,10 @@ During the epoch `k`: At the end of epoch `k`: -1. update `c <- c + all_trading_fees_for_trades_involved_in`, where `all_trading_fees_for_trades_involved_in` are the cumulated trading fees paid by the aggressive party (taker fees) but also cumulated (with a +sign) the trading fees result from any trade in which the party was involved as the passive party (i.e. their limit order got lifted). - 1. update `c <- c x D`, i.e. apply the decay factor `D` +1. update `c <- c + all_trading_fees_for_trades_involved_in`, where `all_trading_fees_for_trades_involved_in` are the cumulated trading fees paid by the aggressive party (taker fees) but also cumulated (with a +sign) the trading fees result from any trade in which the party was invovled as the passive party (i.e. their limit order got lifted). + 1. if `c` is less than `M x quantum` (where quantum is the asset quantum) then set `c <- 0`. We need appropriate APIs to enable the frontend to display the amount eligible for fee-free transfers / correctly display the fee on any transfer a party is proposing. From e21b2a3f367e98a5eb2c4407a1efb46a696fce6d Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Fri, 10 Nov 2023 15:02:31 +0000 Subject: [PATCH 0717/1171] chore: typo --- 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 059be4870..af17fc61b 100644 --- a/protocol/0057-TRAN-transfers.md +++ b/protocol/0057-TRAN-transfers.md @@ -182,7 +182,7 @@ At the end of epoch `k`: 1. update `c <- c x D`, i.e. apply the decay factor `D` -1. update `c <- c + all_trading_fees_for_trades_involved_in`, where `all_trading_fees_for_trades_involved_in` are the cumulated trading fees paid by the aggressive party (taker fees) but also cumulated (with a +sign) the trading fees result from any trade in which the party was invovled as the passive party (i.e. their limit order got lifted). +1. update `c <- c + all_trading_fees_for_trades_involved_in`, where `all_trading_fees_for_trades_involved_in` are the cumulated trading fees paid by the aggressive party (taker fees) but also cumulated (with a +sign) the trading fees result from any trade in which the party was involved as the passive party (i.e. their limit order got lifted). 1. if `c` is less than `M x quantum` (where quantum is the asset quantum) then set `c <- 0`. From aeb7501b5686212c9e9c4419d1851d8b42db8fec Mon Sep 17 00:00:00 2001 From: David Siska <62546419+davidsiska-vega@users.noreply.github.com> Date: Mon, 13 Nov 2023 10:33:27 +0000 Subject: [PATCH 0718/1171] Feat: remove liquidity monitoring auctions (#1991) * Feat: remove liquidity monitoring auctions * fix: markdown linting --------- Co-authored-by: gordsport --- protocol/0026-AUCT-auctions.md | 11 +-- protocol/0028-GOVE-governance.md | 1 - protocol/0032-PRIM-price_monitoring.md | 2 +- protocol/0035-LIQM-liquidity_monitoring.md | 76 ------------------- protocol/0041-TSTK-target_stake.md | 6 +- protocol/0043-MKTL-market_lifecycle.md | 23 ++---- protocol/0044-LIME-lp_mechanics.md | 5 -- ...3-PERP-product_builtin_perpetual_future.md | 1 - .../0065-FTCO-floating_point_consensus.md | 1 - protocol/0080-SPOT-product_builtin_spot.md | 2 - protocol/README.md | 1 - 11 files changed, 13 insertions(+), 116 deletions(-) delete mode 100644 protocol/0035-LIQM-liquidity_monitoring.md diff --git a/protocol/0026-AUCT-auctions.md b/protocol/0026-AUCT-auctions.md index a358bc1bf..97ce75efb 100644 --- a/protocol/0026-AUCT-auctions.md +++ b/protocol/0026-AUCT-auctions.md @@ -6,7 +6,8 @@ Auctions are a trading mode that 'collect' orders during an *auction call period In comparison to continuous trading, the auction mode for a market, is a state of the orderbook where each order placed is just sitting on the book, for a given period of time or until some requirements are met (called `call period`), then the matching orders are uncrossed. -They are mostly useful in less liquid markets, or in specific scenarios where a price must be determined, i.e. at opening of a market, when a potentially excessively large price move might occur (price monitoring) or when liquidity needs to be sourced and aggregated (liquidity monitoring). In traditional markets (where markets open and close every day) we can run an open and closing auction for the price to stabilise at both ends. +They are mostly useful in less liquid markets, or in specific scenarios where a price must be determined, i.e. at opening of a market, when a potentially excessively large price move might occur (price monitoring). +In traditional markets (where markets open and close every day) we can run an open and closing auction for the price to stabilise at both ends. ## Reference-level explanation @@ -22,7 +23,7 @@ All auctions have a `min_auction_length` (which is a single network parameter fo - Any auction that would be less than `min_auction_length` seconds (network parameter) should not be started (e.g. if the market is nearing the end of its open period / active trading). This is to prevent auction calls that are too short given the network latency/granularity, so should be some multiple of the worst case expected block time at some confidence level, which is best maintained by governance voting (hence being a network parameter). - a proposal should be rejected if it would require an auction shorter `min_auction_length` -- for price/liquidity monitoring, etc. the auction must last for at least the `min_auction_length` and therefore we can avoid checking other conditions until that length is reached +- for price monitoring, etc. the auction must last for at least the `min_auction_length` and therefore we can avoid checking other conditions until that length is reached - if the parameter is changed it needs to be re-applied to any current auctions, this means that shortening it could trigger an auction ending ### Opening auctions (at creation of the market) @@ -39,7 +40,7 @@ The frequent batch auction mode is a trading mode in perpetual auction, meaning e.g: auctions could be set to last 10 minutes, then every 10 minutes the book would uncross, potentially generating trades. -Note that FBAs will still have an opening auction (which must have a duration equal to or greater than the minimum batch auction duration, as well as meeting the minimum opening auction duration. Price and liquidity monitoring will be able to override the trading mode and push the market into longer auctions to resolve the triggering event. +Note that FBAs will still have an opening auction (which must have a duration equal to or greater than the minimum batch auction duration, as well as meeting the minimum opening auction duration. Price monitoring will be able to override the trading mode and push the market into longer auctions to resolve the triggering event. #### Duration of frequent batch auctions @@ -97,7 +98,7 @@ Auction periods may be ended with an uncrossing and the creation of any resultin - the auction call period end time being reached (if such a time is set); or - other functionality (related to the type of auction period) that triggers the end of auction. -Auction periods do not end if the resulting state would immediately cause another auction to occur. Instead the current auction gets extended. For example, if a liquidity monitoring auction would be triggered at the end of an opening auction, then the opening auction continues and the *auction extension trigger* field in the [market data API](./0021-MDAT-market_data_spec.md) is updated to account for the fact that the opening auction has been extended due to insufficient liquidity. +Auction periods do not end if the resulting state would immediately cause another auction to occur. Instead the current auction gets extended. ### Ending when a market is going to enter Trading Terminated status @@ -109,7 +110,7 @@ Functionality that either triggers the end of an auction or delays the auction e - opening auction (market creation): [governance](./0028-GOVE-governance.md) - [price monitoring](./0032-PRIM-price_monitoring.md) -- [liquidity monitoring](./0035-LIQM-liquidity_monitoring.md) + ## First/Naive implementation diff --git a/protocol/0028-GOVE-governance.md b/protocol/0028-GOVE-governance.md index 9686b198a..6f3f96e5c 100644 --- a/protocol/0028-GOVE-governance.md +++ b/protocol/0028-GOVE-governance.md @@ -514,7 +514,6 @@ 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](./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) diff --git a/protocol/0032-PRIM-price_monitoring.md b/protocol/0032-PRIM-price_monitoring.md index 3de366ae7..306daee1b 100644 --- a/protocol/0032-PRIM-price_monitoring.md +++ b/protocol/0032-PRIM-price_monitoring.md @@ -13,7 +13,7 @@ Please see the [auction spec](./0026-AUCT-auctions.md) for auction details. ### Note -Price monitoring likely won't be the only possible trigger of auction period ([liquidity monitoring](./0035-LIQM-liquidity_monitoring.md) or governance action could be the other ones). Thus the framework put in place as part of this spec should be flexible enough to easily accommodate other types of triggers. +Price monitoring likely won't be the only possible trigger of auction period e.g. governance action could be the other ones. Thus the framework put in place as part of this spec should be flexible enough to easily accommodate other types of triggers. Likewise, pre-processing transactions will be needed as part of the [fees spec](./0029-FEES-fees.md), hence it should be implemented in such a way that it's easy to repurpose it. diff --git a/protocol/0035-LIQM-liquidity_monitoring.md b/protocol/0035-LIQM-liquidity_monitoring.md deleted file mode 100644 index a2392fc87..000000000 --- a/protocol/0035-LIQM-liquidity_monitoring.md +++ /dev/null @@ -1,76 +0,0 @@ -# Liquidity monitoring - -## Summary - -Liquidity in the market is not only a desirable feature from a trader's point of view, but also an important consideration from the risk-management standpoint. Position of a distressed trader can only be liquidated if there's enough volume on the order book to offload it, otherwise a potentially insolvent party remains part of the market. - -Similarly to [price monitoring](./0032-PRIM-price_monitoring.md), we need to be able to detect when the market liquidity drops below the safe level, launch a "liquidity seeking" auction (in which, due to the [liquidity mechanics](./0044-LIME-lp_mechanics.md), there is an incentive through the ability to set fees, to provide the missing liquidity) and terminate it when the market liquidity level is back at a sufficiently high level. - -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_volume = market.liquidity.stakeToCcyVolume ⨉ 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. - - -## 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 `triggering_ratio` in `LiquidityMonitoringParameters` in market creation or update proposal. - -## Total stake - -`total_stake` is the sum the stake amounts committed by all the LPs in the market (see [LP mechanics](./0044-LIME-lp_mechanics.md)) for how LPs commit stake and what it obliges them to do. - -## Trigger for entering an auction - -The auction is triggered when - -`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. - -### Increasing target stake - -If an incoming order would match orders on the book resulting in trades increasing `target_stake` so that liquidity auction gets triggered then: - -- if the incoming order would stay on the book in auction mode the auction should get triggered preemptively (the order doesn't get matched in market's current trading mode, market switches to auction mode and the incoming order gets added to the book once market is in auction mode). - -### 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 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 - -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 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? - -The auction proceeds as usual. Please see the [auction spec](./0026-AUCT-auctions.md) for details. - -## Frequency of checking for liquidity auction entry conditions - - Through a sequence of actions which occur with the same timestamp the market may be moved into a state in which a liquidity auction is expected and then back out of said state. Ideally, liquidity auctions should only be entered when the market truly requires one as once entered a minimum auction length (controlled by `market.auction.minimumDuration`) must be observed. Even with a very short a minimum auction length, a market flickering between two states is suboptimal. - - 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 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. 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. 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 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 0aae865b7..bc7af1ea1 100644 --- a/protocol/0041-TSTK-target_stake.md +++ b/protocol/0041-TSTK-target_stake.md @@ -5,15 +5,11 @@ 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: -- 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 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 - **Open interest**: the volume of all open positions in a given market. - `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`. +- `market.stake.target.scalingFactor` is a network parameter providing the default scaling between liquidity demand estimate based on open interest and target stake. - `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. diff --git a/protocol/0043-MKTL-market_lifecycle.md b/protocol/0043-MKTL-market_lifecycle.md index 6d9678d33..7f34a1f62 100644 --- a/protocol/0043-MKTL-market_lifecycle.md +++ b/protocol/0043-MKTL-market_lifecycle.md @@ -14,7 +14,6 @@ Markets proposed via [governance proposals](./0028-GOVE-governance.md#1-create-m 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). ## Market lifecycle statuses @@ -27,7 +26,7 @@ A market can progress through a number of statuses through its life. The overall | 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 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) +| Suspended | Yes | Exceptional auction | Price 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 | Settled | No | No trading | Settlement triggered and completed as defined by product | N/A @@ -128,12 +127,12 @@ All data sources that are only referenced by this market should be unregistered. ### Active -Once the enactment date is reached and the other conditions specified to exit the Pending state are met, the market becomes Active on conclusion of uncrossing of the opening auction. This status indicates it is trading via its normally configured trading mode according to the market framework (continuous trading, frequent batch auction, RFQ, block only, etc.). The specification for the trading mode should describe which orders are accepted and how trading proceeds. The market will terminate trading according to a product trigger (for futures, if the trading termination date is reached) and can be temporarily suspended automatically by various monitoring systems ([price monitoring](./0032-PRIM-price_monitoring.md), [liquidity monitoring](./0035-LIQM-liquidity_monitoring.md)). The market can also be closed via a governance vote (market parameter update) to change the status to closed [see the governance spec](./0028-GOVE-governance.md). +Once the enactment date is reached and the other conditions specified to exit the Pending state are met, the market becomes Active on conclusion of uncrossing of the opening auction. This status indicates it is trading via its normally configured trading mode according to the market framework (continuous trading, frequent batch auction, RFQ, block only, etc.). The specification for the trading mode should describe which orders are accepted and how trading proceeds. The market will terminate trading according to a product trigger (for futures, if the trading termination date is reached) and can be temporarily suspended automatically by ([price monitoring](./0032-PRIM-price_monitoring.md). The market can also be closed via a governance vote (market parameter update) to change the status to closed [see the governance spec](./0028-GOVE-governance.md). **Entry:** - From Pending: enactment date reached and conditions to transition from Pending state to Active as detailed above are met -- From Suspended: conditions specified in [price monitoring](./0032-PRIM-price_monitoring.md) and [liquidity monitoring](./0035-LIQM-liquidity_monitoring.md) are met for the market to exit the suspended status back to Active. +- From Suspended: conditions specified in [price monitoring](./0032-PRIM-price_monitoring.md) are met for the market to exit the suspended status back to Active. **Exit:** @@ -160,7 +159,7 @@ Suspension currently always operates as an auction call period. Depending on the **Exit:** -- Conditions specified in [price monitoring](./0032-PRIM-price_monitoring.md) and [liquidity monitoring](./0035-LIQM-liquidity_monitoring.md) and the usual [ending of auction checks](./0026-AUCT-auctions.md) pass → Active +- Conditions specified in [price monitoring](./0032-PRIM-price_monitoring.md) and the usual [ending of auction checks](./0026-AUCT-auctions.md) pass → Active - Governance vote to close a market passes → Closed - Market was suspended by governance vote of product lifecycle trigger and a governance vote passes to set the status to ACTIVE → Active @@ -209,7 +208,7 @@ 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 -- No risk management or price/liquidity monitoring occurs +- No risk management or price occurs ### Settled @@ -267,12 +266,6 @@ Market state is `active`. 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. The mark price is `p`. 1. The time specified at market proposal by the internal time oracle is reached. @@ -315,12 +308,6 @@ Market state is `active`. 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. diff --git a/protocol/0044-LIME-lp_mechanics.md b/protocol/0044-LIME-lp_mechanics.md index 291174d44..82ccea0dd 100644 --- a/protocol/0044-LIME-lp_mechanics.md +++ b/protocol/0044-LIME-lp_mechanics.md @@ -161,7 +161,6 @@ Note that in the case of spot market or any market that isn't running an insuran 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 @@ -354,10 +353,6 @@ In the case of spot markets it will be transferred into the network treasury for - 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) diff --git a/protocol/0053-PERP-product_builtin_perpetual_future.md b/protocol/0053-PERP-product_builtin_perpetual_future.md index c6df79c66..c8f094a42 100644 --- a/protocol/0053-PERP-product_builtin_perpetual_future.md +++ b/protocol/0053-PERP-product_builtin_perpetual_future.md @@ -223,7 +223,6 @@ In both cases the estimates are for a hypothetical position of size 1. 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 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. 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) diff --git a/protocol/0065-FTCO-floating_point_consensus.md b/protocol/0065-FTCO-floating_point_consensus.md index f6309d68c..c197998d7 100644 --- a/protocol/0065-FTCO-floating_point_consensus.md +++ b/protocol/0065-FTCO-floating_point_consensus.md @@ -98,7 +98,6 @@ This section outlines floating-point quantities `vega` currently relies on: - When the opening auction ends (choose uncrossing price that's different from first indicative uncrossing price) price monitoring bounds and probability of trading get recalculated. - When the market goes into price 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. - 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) - For all the state variables nodes submit candidate values that differ by up to half the tolerance. diff --git a/protocol/0080-SPOT-product_builtin_spot.md b/protocol/0080-SPOT-product_builtin_spot.md index 9a1b82d45..f7e30a4c9 100644 --- a/protocol/0080-SPOT-product_builtin_spot.md +++ b/protocol/0080-SPOT-product_builtin_spot.md @@ -114,8 +114,6 @@ When exiting an auction, for any orders which are still open, the funds held in ## 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 diff --git a/protocol/README.md b/protocol/README.md index 14f8dc393..1961d9d08 100644 --- a/protocol/README.md +++ b/protocol/README.md @@ -29,7 +29,6 @@ ## Market protections - [Price monitoring](./0032-PRIM-price_monitoring.md) -- [Liquidity monitoring](./0035-LIQM-liquidity_monitoring.md) ## Liquidity From fb09a9f8c963ed097b8240ac590e3f3b3d6a7678 Mon Sep 17 00:00:00 2001 From: Gordsport <83510148+gordsport@users.noreply.github.com> Date: Mon, 13 Nov 2023 11:31:06 +0000 Subject: [PATCH 0719/1171] fix: add ac - quantum updates on enactment (#2056) * fix: add ac - quantum updates on enactment Fix/quantum updates on enactment ac: - https://github.com/vegaprotocol/specs/pull/2016 same as the following PR but with `palazzo` as the base branch * fix: markdown linting --- protocol/0027-ASSP-asset_proposal.md | 1 + 1 file changed, 1 insertion(+) diff --git a/protocol/0027-ASSP-asset_proposal.md b/protocol/0027-ASSP-asset_proposal.md index 159c5d745..26455df6e 100644 --- a/protocol/0027-ASSP-asset_proposal.md +++ b/protocol/0027-ASSP-asset_proposal.md @@ -167,6 +167,7 @@ This must be an integer strictly greater than `0`. - 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) +- If an update asset proposal passed and it changes `quantum` _only_ then this new value becomes used immediately on enactment. (0027-ASSP-025) ### Node actions From d4cd6817ff0529f4ea6802003fa9c04c72fe4b9a Mon Sep 17 00:00:00 2001 From: David Siska <62546419+davidsiska-vega@users.noreply.github.com> Date: Tue, 7 Nov 2023 16:18:57 +0000 Subject: [PATCH 0720/1171] feat: batch governance --- protocol/0028-GOVE-governance.md | 36 +++++++++++++++++++++++++------- 1 file changed, 28 insertions(+), 8 deletions(-) diff --git a/protocol/0028-GOVE-governance.md b/protocol/0028-GOVE-governance.md index 6f3f96e5c..95c4c47bd 100644 --- a/protocol/0028-GOVE-governance.md +++ b/protocol/0028-GOVE-governance.md @@ -455,11 +455,20 @@ Notes: ## 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. +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 individual proposals 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. +The individual submissions keep their own rationale entries. -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. +Validation should be applied by the protocol when accepting such a transaction to verify that all proposals within the batch meet their own minimum voting periods (if not transaction is rejected). +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, as long as the minimum enactment time of each individual proposal within the batch is respected. -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. +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 *must* not be possible to vote for components in the batch separately. +Once the closing timestamp is reached each individual proposal within the batch is evaluated against the votes received. +If all proposals pass (on their own rules on participation, majority, LP-ELS voting etc.) then the entire batch passes. +If even one proposal within the batch would fail then the entire batch fails. + +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 @@ -679,15 +688,26 @@ It is NOT possible to submit a governance proposal where the source account is t ##### 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 containing one or more component submissions mixing different proposal types can be submitted and is accepted as a valid proposal. (0028-GOVE-146) -- 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 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) +- A batch proposal submitted with component submissions with 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) +- A batch proposal containing +1. freeform proposal, +1. an asset proposal, +1. a network parameter change, +1. a market proposal, +1. a change proposal for another market, +1. volume discount program, +1. referal programe, +1. governance transfer, +can be submitted, voted through and each proposal enacted. (0028-GOVE-160) + + + ##### 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 6d5d0083a1c62c9ba82f3c9982561e9299cec7a1 Mon Sep 17 00:00:00 2001 From: David Siska <62546419+davidsiska-vega@users.noreply.github.com> Date: Tue, 7 Nov 2023 16:22:52 +0000 Subject: [PATCH 0721/1171] feat: batch governance --- protocol/0028-GOVE-governance.md | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/protocol/0028-GOVE-governance.md b/protocol/0028-GOVE-governance.md index 95c4c47bd..cbd7c45de 100644 --- a/protocol/0028-GOVE-governance.md +++ b/protocol/0028-GOVE-governance.md @@ -465,7 +465,7 @@ The enactment timestamp, however, should be customisable and can be different fo 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 *must* not be possible to vote for components in the batch separately. Once the closing timestamp is reached each individual proposal within the batch is evaluated against the votes received. -If all proposals pass (on their own rules on participation, majority, LP-ELS voting etc.) then the entire batch passes. +If all individual proposals would pass (given the votes received, based on their individual rules on participation, majority, LP-ELS voting etc.) then the entire batch passes. If even one proposal within the batch would fail then the entire batch fails. 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. @@ -706,6 +706,9 @@ It is NOT possible to submit a governance proposal where the source account is t 1. governance transfer, can be submitted, voted through and each proposal enacted. (0028-GOVE-160) +- A batch proposal can be submitted changing the same network parameter twice to two different values with two different enactment timestamps. +The voting to approve the batch happens, the batch passes, both changes are observed at the desired time. (0028-GOVE-161) + ##### Network History From b9d0b52855ed5de6885391306b1100d6e3cfd8a1 Mon Sep 17 00:00:00 2001 From: gordsport Date: Mon, 13 Nov 2023 11:49:08 +0000 Subject: [PATCH 0722/1171] fix: MD and spelling lint checks --- protocol/0028-GOVE-governance.md | 28 ++++++++++++++-------------- 1 file changed, 14 insertions(+), 14 deletions(-) diff --git a/protocol/0028-GOVE-governance.md b/protocol/0028-GOVE-governance.md index cbd7c45de..091d97691 100644 --- a/protocol/0028-GOVE-governance.md +++ b/protocol/0028-GOVE-governance.md @@ -456,17 +456,17 @@ Notes: ## 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 individual proposals 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. -The individual submissions keep their own rationale entries. +The batch proposal is a wrapper containing the same `reference` and `rationale` fields as a standard `ProposalSubmission` alongside a repeated list of `ProposalSubmission`s. +The individual submissions keep their own rationale entries. Validation should be applied by the protocol when accepting such a transaction to verify that all proposals within the batch meet their own minimum voting periods (if not transaction is rejected). -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. +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, as long as the minimum enactment time of each individual proposal within the batch is respected. 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 *must* not be possible to vote for components in the batch separately. -Once the closing timestamp is reached each individual proposal within the batch is evaluated against the votes received. -If all individual proposals would pass (given the votes received, based on their individual rules on participation, majority, LP-ELS voting etc.) then the entire batch passes. -If even one proposal within the batch would fail then the entire batch fails. +Once the closing timestamp is reached each individual proposal within the batch is evaluated against the votes received. +If all individual proposals would pass (given the votes received, based on their individual rules on participation, majority, LP-ELS voting etc.) then the entire batch passes. +If even one proposal within the batch would fail then the entire batch fails. 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. @@ -695,18 +695,18 @@ It is NOT possible to submit a governance proposal where the source account is t - A batch proposal submitted with component submissions with 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) -- A batch proposal containing +- A batch proposal containing 1. freeform proposal, -1. an asset proposal, -1. a network parameter change, -1. a market proposal, -1. a change proposal for another market, +1. an asset proposal, +1. a network parameter change, +1. a market proposal, +1. a change proposal for another market, 1. volume discount program, -1. referal programe, -1. governance transfer, +1. referral program, +1. governance transfer, can be submitted, voted through and each proposal enacted. (0028-GOVE-160) -- A batch proposal can be submitted changing the same network parameter twice to two different values with two different enactment timestamps. +- A batch proposal can be submitted changing the same network parameter twice to two different values with two different enactment timestamps. The voting to approve the batch happens, the batch passes, both changes are observed at the desired time. (0028-GOVE-161) From 50fed58a4f0c9ed54fb4214e4b2d143800fc3de7 Mon Sep 17 00:00:00 2001 From: David Siska <62546419+davidsiska-vega@users.noreply.github.com> Date: Mon, 13 Nov 2023 16:44:31 +0000 Subject: [PATCH 0723/1171] feat: batch proposals --- protocol/0028-GOVE-governance.md | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/protocol/0028-GOVE-governance.md b/protocol/0028-GOVE-governance.md index 091d97691..2606d03b0 100644 --- a/protocol/0028-GOVE-governance.md +++ b/protocol/0028-GOVE-governance.md @@ -458,6 +458,8 @@ Notes: 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 individual proposals 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. The individual submissions keep their own rationale entries. +Any governance proposal can be included in a batch *except* proposals to add new assets. +For avoidance of doubt: asset *change* proposals can be included. Validation should be applied by the protocol when accepting such a transaction to verify that all proposals within the batch meet their own minimum voting periods (if not transaction is rejected). 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. @@ -469,6 +471,7 @@ If all individual proposals would pass (given the votes received, based on their If even one proposal within the batch would fail then the entire batch fails. 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. +In particular asset update proposals may emit signed bundles to be submitted to the bridge on ethereum side (for withdrawal delay / threshold updates). ## APIs @@ -697,14 +700,15 @@ It is NOT possible to submit a governance proposal where the source account is t - A batch proposal containing 1. freeform proposal, -1. an asset proposal, +1. an update asset proposal changing the asset quantum, withdrawal delay and withdrawal delay threshold 1. a network parameter change, 1. a market proposal, 1. a change proposal for another market, 1. volume discount program, 1. referral program, 1. governance transfer, -can be submitted, voted through and each proposal enacted. (0028-GOVE-160) +can be submitted, voted through and each proposal enacted. +On top of that signed bundles for changing withdrawal delay and threshold on the bridge are emmitted (0028-GOVE-160) - A batch proposal can be submitted changing the same network parameter twice to two different values with two different enactment timestamps. The voting to approve the batch happens, the batch passes, both changes are observed at the desired time. (0028-GOVE-161) From 2ac124ea9af7f87b35aeea5eb14ee1c231cea514 Mon Sep 17 00:00:00 2001 From: David Siska <62546419+davidsiska-vega@users.noreply.github.com> Date: Mon, 13 Nov 2023 16:45:50 +0000 Subject: [PATCH 0724/1171] feat: batch proposals --- 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 2606d03b0..45521c06b 100644 --- a/protocol/0028-GOVE-governance.md +++ b/protocol/0028-GOVE-governance.md @@ -470,7 +470,7 @@ Once the closing timestamp is reached each individual proposal within the batch If all individual proposals would pass (given the votes received, based on their individual rules on participation, majority, LP-ELS voting etc.) then the entire batch passes. If even one proposal within the batch would fail then the entire batch fails. -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. +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: they enact in the order they appear in the batch. In particular asset update proposals may emit signed bundles to be submitted to the bridge on ethereum side (for withdrawal delay / threshold updates). ## APIs From edfe971786839c358939c14f32552db35d767af7 Mon Sep 17 00:00:00 2001 From: gordsport Date: Tue, 14 Nov 2023 12:14:46 +0000 Subject: [PATCH 0725/1171] fix: linting errors --- protocol/0028-GOVE-governance.md | 24 ++++++++++++------------ 1 file changed, 12 insertions(+), 12 deletions(-) diff --git a/protocol/0028-GOVE-governance.md b/protocol/0028-GOVE-governance.md index 45521c06b..28bb15006 100644 --- a/protocol/0028-GOVE-governance.md +++ b/protocol/0028-GOVE-governance.md @@ -459,13 +459,13 @@ A `BatchProposalSubmission` is a top-level proposal type (living at the same lev The batch proposal is a wrapper containing the same `reference` and `rationale` fields as a standard `ProposalSubmission` alongside a repeated list of `ProposalSubmission`s. The individual submissions keep their own rationale entries. Any governance proposal can be included in a batch *except* proposals to add new assets. -For avoidance of doubt: asset *change* proposals can be included. +For avoidance of doubt: asset _change_ proposals can be included. Validation should be applied by the protocol when accepting such a transaction to verify that all proposals within the batch meet their own minimum voting periods (if not transaction is rejected). 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, as long as the minimum enactment time of each individual proposal within the batch is respected. -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 *must* not be possible to vote for components in the batch separately. +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 _must_ not be possible to vote for components in the batch separately. Once the closing timestamp is reached each individual proposal within the batch is evaluated against the votes received. If all individual proposals would pass (given the votes received, based on their individual rules on participation, majority, LP-ELS voting etc.) then the entire batch passes. If even one proposal within the batch would fail then the entire batch fails. @@ -699,22 +699,22 @@ It is NOT possible to submit a governance proposal where the source account is t 1. If this proposal is accepted, each of the components will be enacted at the time of their differing enactment timestamps. (0028-GOVE-145) - A batch proposal containing -1. freeform proposal, -1. an update asset proposal changing the asset quantum, withdrawal delay and withdrawal delay threshold -1. a network parameter change, -1. a market proposal, -1. a change proposal for another market, -1. volume discount program, -1. referral program, -1. governance transfer, + 1. freeform proposal, + 1. an update asset proposal changing the asset quantum, withdrawal delay and withdrawal delay threshold + 1. a network parameter change, + 1. a market proposal, + 1. a change proposal for another market, + 1. volume discount program, + 1. referral program, + 1. governance transfer, + can be submitted, voted through and each proposal enacted. -On top of that signed bundles for changing withdrawal delay and threshold on the bridge are emmitted (0028-GOVE-160) +On top of that signed bundles for changing withdrawal delay and threshold on the bridge are emitted (0028-GOVE-160) - A batch proposal can be submitted changing the same network parameter twice to two different values with two different enactment timestamps. The voting to approve the batch happens, the batch passes, both changes are observed at the desired time. (0028-GOVE-161) - ##### 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 578e61629c11db77d99b892fd8b48e8a9dae4397 Mon Sep 17 00:00:00 2001 From: gordsport Date: Tue, 14 Nov 2023 12:16:06 +0000 Subject: [PATCH 0726/1171] fix: MD 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 28bb15006..fbd1c7f70 100644 --- a/protocol/0028-GOVE-governance.md +++ b/protocol/0028-GOVE-governance.md @@ -458,7 +458,7 @@ Notes: 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 individual proposals 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. The individual submissions keep their own rationale entries. -Any governance proposal can be included in a batch *except* proposals to add new assets. +Any governance proposal can be included in a batch _except_ proposals to add new assets. For avoidance of doubt: asset _change_ proposals can be included. Validation should be applied by the protocol when accepting such a transaction to verify that all proposals within the batch meet their own minimum voting periods (if not transaction is rejected). From 4977882ac9cb5f675a29ebec3f5f562a21d9ca62 Mon Sep 17 00:00:00 2001 From: gordsport Date: Tue, 14 Nov 2023 12:26:13 +0000 Subject: [PATCH 0727/1171] chore: add ACs to feature file --- protocol/features.json | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/protocol/features.json b/protocol/features.json index fb1664a6e..97138c418 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -122,7 +122,16 @@ }, "Batch governance proposals": { "milestone": "palazzo", - "acs": [] + "acs": [ + "0028-GOVE-067", + "0028-GOVE-068", + "0028-GOVE-145", + "0028-GOVE-146", + "0028-GOVE-148", + "0028-GOVE-149", + "0028-GOVE-160", + "0028-GOVE-161" + ] }, "Transfer fee cap": { "milestone": "palazzo", From 9d63ae228df1faf5d0e1867160caf6c16dd2a5e6 Mon Sep 17 00:00:00 2001 From: Witold Date: Tue, 14 Nov 2023 17:11:28 +0100 Subject: [PATCH 0728/1171] refactor: additional perps parameters --- ...3-PERP-product_builtin_perpetual_future.md | 50 ++++++++++++++++++- protocol/features.json | 6 ++- 2 files changed, 53 insertions(+), 3 deletions(-) diff --git a/protocol/0053-PERP-product_builtin_perpetual_future.md b/protocol/0053-PERP-product_builtin_perpetual_future.md index c8f094a42..5cc91ea5f 100644 --- a/protocol/0053-PERP-product_builtin_perpetual_future.md +++ b/protocol/0053-PERP-product_builtin_perpetual_future.md @@ -17,6 +17,9 @@ Unlike traditional futures contracts, the perpetual futures never expire. Withou 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 upper bound for the clamp function used as part of the funding rate calculation. +1. `scaling_factor`: optional scaling factor applied to funding payment. +1. `rate_lower_bound`: optional lower bound applied to funding payment such that the resulting funding rate will never be lower than the specified value. +1. `rate_upper_bound`: optional upper bound applied to funding payment such that the resulting funding rate will never be greater than than the specified value. Validation: @@ -24,7 +27,17 @@ Validation: - `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`. +- `scaling_factor` any positive real number, +- `rate_lower_bound` any real number, +- `rate_upper_bound` any real number, +- `clamp_upper_bound` >= `clamp_lower_bound`, +- `rate_upper_bound` >= `rate_lower_bound`. + +When migrating legacy markets the following value should be used: + +- `scaling_factor` = `1.0`, +- `rate_lower_bound` = -`max supported value`, +- `rate_upper_bound` = `max supported value`. ### Example specification @@ -152,6 +165,26 @@ funding_payment = f_twap - s_twap + min(clamp_upper_bound*s_twap,max(clamp_lower where `(1 + delta_t * interest_rate)` is the linearisation of `exp(delta_t*interest_rate)` and `delta_t` is expressed as a year fraction. +If `scaling_factor` is specified set: + +```go +funding_payment = scaling_factor * funding_payment +``` + +If `rate_lower_bound` is specified set: + +```go +funding_payment = max(rate_lower_bound*s_twap, funding_payment) +``` + +If `rate_upper_bound` is specified set: + +```go +funding_payment = min(rate_upper_bound*s_twap, funding_payment) +``` + +Please note that scaling should happen strictly before any of the bounds are applied, i.e. if all 3 paramters are specified then the resulting funding rate is guaranteed to fall within the specified bounds irrespective of how big the scaling factor may be. + #### 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. @@ -159,7 +192,7 @@ While not needed for calculation of cashflows to be exchanged by market particip Funding rate should be calculated as: ```go -funding_rate = (f_twap - s_twap) / s_twap +funding_rate = funding_payment / s_twap ``` and emitted as an event. @@ -288,3 +321,16 @@ Assume the last known spot price before this funding period is `11`. Then assume Then, taking the auction into account we get: $\text{internal TWAP}= \frac{10\cdot(1-0)+11\cdot(3-1)+10\cdot(5-3)+9\cdot(8-7)+8\cdot(10-8)+30\cdot(10-10)}{8}=9.625$, $\text{external TWAP}=\frac{11\cdot(1-0)+9\cdot(3-1)+10\cdot(5-3)+11\cdot(8-7)+8\cdot(9-8)+14\cdot(10-9)}{10}=10.25$. (0053-PERP-028) + +When $\text{clamp_lower_bound}=\text{clamp_upper_bound}=0$, $\text{scaling factor}=2.5$ and the funding period ends with $\text{internal TWAP}=99$, $\text{external TWAP} = 100$ then the resulting funding rate equals $-0.025$. (0053-PERP-029) + +When $\text{clamp_lower_bound}=\text{clamp_upper_bound}=0$, $\text{scaling factor}=1$, $\text{rate_lower_bound}=-0.015$, $\text{rate_upper_bound}=0.005$ and the funding period ends with $\text{internal TWAP}=99$, $\text{external TWAP} = 100$ then the resulting funding rate equals $-0.015$. (0053-PERP-030) + +When $\text{clamp_lower_bound}=\text{clamp_upper_bound}=0$, $\text{scaling factor}=1$, $\text{rate_lower_bound}=-0.015$, $\text{rate_upper_bound}=0.005$ and the funding period ends with $\text{internal TWAP}=101$, $\text{external TWAP} = 100$ then the resulting funding rate equals $0.005$. (0053-PERP-031) + +When migrating the market existing prior to introduction of the additional parameters their values get set to: + +- $\text{scaling factor}=1$, +- $\text{rate_lower_bound}= -\text{max supported value}$, +- $\text{rate_upper_bound}= \text{max supported value}$ +(0053-PERP-032). diff --git a/protocol/features.json b/protocol/features.json index fb1664a6e..39cf00d6a 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -51,7 +51,11 @@ "0053-PERP-025", "0053-PERP-026", "0053-PERP-027", - "0053-PERP-028" + "0053-PERP-028", + "0053-PERP-029", + "0053-PERP-030", + "0053-PERP-031", + "0053-PERP-032" ] }, "Team rewards": { From d5257be9a084fc2d55c0d1747dc8dbfd7b73116c Mon Sep 17 00:00:00 2001 From: Witold Date: Tue, 14 Nov 2023 17:18:13 +0100 Subject: [PATCH 0729/1171] refactor: fix some legacy spelling errors --- .../0007-NP-SNTP-sweetwater_signed_netparams.md | 6 +++--- protocol/0053-PERP-product_builtin_perpetual_future.md | 2 +- protocol/0059-STKG-simple_staking_and_delegating.md | 2 +- 3 files changed, 5 insertions(+), 5 deletions(-) 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 5ccba9522..77da509b5 100644 --- a/non-protocol-specs/0007-NP-SNTP-sweetwater_signed_netparams.md +++ b/non-protocol-specs/0007-NP-SNTP-sweetwater_signed_netparams.md @@ -3,7 +3,7 @@ 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) +- 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 parameters](../protocol/0054-NETP-network_parameters.md) 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. @@ -22,8 +22,8 @@ The values to be specified as a PR against ??? repo. | Name | Comment | Suggested value (optional) | |-------------------------------------------------------------|:------------------------------------------------------------------:| :-------------------------:| -| `min number of validators` (not in sweetwater) | Not in [network paramters](../protocol/0054-NETP-network_parameters.md) | | -| `validator min balance` | Not in [network paramters](../protocol/0054-NETP-network_parameters.md) | 3000 VEGA | +| `min number of validators` (not in sweetwater) | Not in [network parameters](../protocol/0054-NETP-network_parameters.md) | | +| `validator min balance` | Not in [network parameters](../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 length, best fix it. | 1 day | diff --git a/protocol/0053-PERP-product_builtin_perpetual_future.md b/protocol/0053-PERP-product_builtin_perpetual_future.md index 5cc91ea5f..06ff19756 100644 --- a/protocol/0053-PERP-product_builtin_perpetual_future.md +++ b/protocol/0053-PERP-product_builtin_perpetual_future.md @@ -183,7 +183,7 @@ If `rate_upper_bound` is specified set: funding_payment = min(rate_upper_bound*s_twap, funding_payment) ``` -Please note that scaling should happen strictly before any of the bounds are applied, i.e. if all 3 paramters are specified then the resulting funding rate is guaranteed to fall within the specified bounds irrespective of how big the scaling factor may be. +Please note that scaling should happen strictly before any of the bounds are applied, i.e. if all 3 parameters are specified then the resulting funding rate is guaranteed to fall within the specified bounds irrespective of how big the scaling factor may be. #### Funding rate calculation diff --git a/protocol/0059-STKG-simple_staking_and_delegating.md b/protocol/0059-STKG-simple_staking_and_delegating.md index 3cb481662..f99f68a59 100644 --- a/protocol/0059-STKG-simple_staking_and_delegating.md +++ b/protocol/0059-STKG-simple_staking_and_delegating.md @@ -164,7 +164,7 @@ Another edge case is the following: during the epoch the party had x tokens asso Actual validator score calculation is in [simple scheme for Sweetwater](0061-simple-POS-rewards\ -\ SweetWater.md) and it introduces its own network parameters. -See the [network paramters spec](./0054-NETP-network_parameters.md#current-network-parameters) for a full list of parameters. +See the [network parameters spec](./0054-NETP-network_parameters.md#current-network-parameters) for a full list of parameters. ## Acceptance Criteria From 07426e97e2ce627cb5d38dd61509ae37104b72bb Mon Sep 17 00:00:00 2001 From: David Siska <62546419+davidsiska-vega@users.noreply.github.com> Date: Tue, 14 Nov 2023 17:45:58 +0000 Subject: [PATCH 0730/1171] feat: batch proposals --- protocol/0028-GOVE-governance.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/protocol/0028-GOVE-governance.md b/protocol/0028-GOVE-governance.md index fbd1c7f70..e940922cd 100644 --- a/protocol/0028-GOVE-governance.md +++ b/protocol/0028-GOVE-governance.md @@ -456,16 +456,16 @@ Notes: ## 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 individual proposals 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. -The individual submissions keep their own rationale entries. +The batch proposal is a wrapper containing one `rationale` (i.e. `title` and `description`) field as a standard `ProposalSubmission`, one `closingTimestamp` field and a list of `ProposalSubmission`s which omit certain fields. +The individual `ProposalSubmission` have no `rationale` entry (i.e. no `title` and `description`). +The individual `ProposalSubmission` have no `closingTimestamp` entry. Any governance proposal can be included in a batch _except_ proposals to add new assets. For avoidance of doubt: asset _change_ proposals can be included. Validation should be applied by the protocol when accepting such a transaction to verify that all proposals within the batch meet their own minimum voting periods (if not transaction is rejected). -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, as long as the minimum enactment time of each individual proposal within the batch is respected. +The enactment timestamp, is customisable and can be different for each proposal within the batch, as long as the minimum enactment time of each individual proposal within the batch is respected and as long as every `enactmentTimestamp` is greater than or equal to `closingTimestamp` of the entire 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 _must_ not be possible to vote for components in the batch separately. +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 _must_ _not_ be possible to vote for components in the batch separately. Once the closing timestamp is reached each individual proposal within the batch is evaluated against the votes received. If all individual proposals would pass (given the votes received, based on their individual rules on participation, majority, LP-ELS voting etc.) then the entire batch passes. If even one proposal within the batch would fail then the entire batch fails. From f3621aac5564077efd130297e8a96420e7045ed4 Mon Sep 17 00:00:00 2001 From: David Siska <62546419+davidsiska-vega@users.noreply.github.com> Date: Tue, 14 Nov 2023 18:01:15 +0000 Subject: [PATCH 0731/1171] feat: batch proposals --- 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 e940922cd..bf722c908 100644 --- a/protocol/0028-GOVE-governance.md +++ b/protocol/0028-GOVE-governance.md @@ -693,7 +693,7 @@ It is NOT possible to submit a governance proposal where the source account is t - A batch proposal containing one or more component submissions mixing different proposal types can be submitted and is accepted as a valid proposal. (0028-GOVE-146) -- A batch proposal submitted with component submissions having different closing timestamps will be rejected with an informative error message. (0028-GOVE-148) +- A batch proposal submitted with component submissions having different one or more enactment timestamps lower than the closing timestamps will be rejected with an informative error message. (0028-GOVE-148) - A batch proposal submitted with component submissions with 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) From 98187985d6be97024c6ac44929586b444c751d1f Mon Sep 17 00:00:00 2001 From: David Siska <62546419+davidsiska-vega@users.noreply.github.com> Date: Tue, 14 Nov 2023 18:03:27 +0000 Subject: [PATCH 0732/1171] feat: batch proposals Co-authored-by: Barnaby M --- 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 bf722c908..a2016f1ae 100644 --- a/protocol/0028-GOVE-governance.md +++ b/protocol/0028-GOVE-governance.md @@ -695,7 +695,7 @@ It is NOT possible to submit a governance proposal where the source account is t - A batch proposal submitted with component submissions having different one or more enactment timestamps lower than the closing timestamps will be rejected with an informative error message. (0028-GOVE-148) -- A batch proposal submitted with component submissions with different enactment timestamps will be accepted and move to voting. (0028-GOVE-149) +- A batch proposal submitted with component submissions with different enactment timestamps, all of which are valid for the type of change being proposed for that enactment time, 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) - A batch proposal containing From e7ee892fa8d7a98e41defafdb342385d2362ecf3 Mon Sep 17 00:00:00 2001 From: David Siska <62546419+davidsiska-vega@users.noreply.github.com> Date: Tue, 14 Nov 2023 18:04:51 +0000 Subject: [PATCH 0733/1171] feat: batch proposals Co-authored-by: Edd --- protocol/0028-GOVE-governance.md | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/protocol/0028-GOVE-governance.md b/protocol/0028-GOVE-governance.md index a2016f1ae..968dfd1c3 100644 --- a/protocol/0028-GOVE-governance.md +++ b/protocol/0028-GOVE-governance.md @@ -714,6 +714,11 @@ On top of that signed bundles for changing withdrawal delay and threshold on the - A batch proposal can be submitted changing the same network parameter twice to two different values with two different enactment timestamps. The voting to approve the batch happens, the batch passes, both changes are observed at the desired time. (0028-GOVE-161) +A batch proposal submission must not contain a batch proposal submission (0028-GOVE-162) + +A vote cannot be submitted for an invidual component in a batch (0028-GOVE-163) + +When a batch contains two proposals with identical enactment timestamps, they are executed in the order the appear in the batch. For example two network parameter update proposals in the same batch with the same enactment timestamp will both be executed, in the order specified. (0028-GOVE-164) ##### Network History From 64e932d027cb511d30cd7809e6512383931e754d Mon Sep 17 00:00:00 2001 From: David Siska <62546419+davidsiska-vega@users.noreply.github.com> Date: Tue, 14 Nov 2023 18:07:15 +0000 Subject: [PATCH 0734/1171] feat: batch proposals --- protocol/0028-GOVE-governance.md | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/protocol/0028-GOVE-governance.md b/protocol/0028-GOVE-governance.md index 968dfd1c3..5ba22e140 100644 --- a/protocol/0028-GOVE-governance.md +++ b/protocol/0028-GOVE-governance.md @@ -720,6 +720,10 @@ A vote cannot be submitted for an invidual component in a batch (0028-GOVE-164) +- A batch proposal can be submitted changing the same network parameter twice to two different values with the same enactment timestamps. +The voting to approve the batch happens, the batch passes, the value of the proposal appearing later in the batch is observed at the desired time. (0028-GOVE-165) + + ##### 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 0e9a1361f68885af5cbf0282a7e87659580f5c55 Mon Sep 17 00:00:00 2001 From: David Siska <62546419+davidsiska-vega@users.noreply.github.com> Date: Tue, 14 Nov 2023 18:08:11 +0000 Subject: [PATCH 0735/1171] feat: batch proposals --- protocol/features.json | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/protocol/features.json b/protocol/features.json index 97138c418..554b29dc9 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -130,7 +130,11 @@ "0028-GOVE-148", "0028-GOVE-149", "0028-GOVE-160", - "0028-GOVE-161" + "0028-GOVE-161", + "0028-GOVE-162", + "0028-GOVE-163", + "0028-GOVE-164", + "0028-GOVE-165" ] }, "Transfer fee cap": { From 8d1610bd5e9b13fb63ff9f72eda8cf47973559b8 Mon Sep 17 00:00:00 2001 From: David Siska <62546419+davidsiska-vega@users.noreply.github.com> Date: Wed, 15 Nov 2023 08:57:19 +0000 Subject: [PATCH 0736/1171] feat: batch proposals --- 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 5ba22e140..55f83e9c0 100644 --- a/protocol/0028-GOVE-governance.md +++ b/protocol/0028-GOVE-governance.md @@ -716,7 +716,7 @@ The voting to approve the batch happens, the batch passes, both changes are obse A batch proposal submission must not contain a batch proposal submission (0028-GOVE-162) -A vote cannot be submitted for an invidual component in a batch (0028-GOVE-163) +A vote cannot be submitted for an individual component in a batch (0028-GOVE-163) When a batch contains two proposals with identical enactment timestamps, they are executed in the order the appear in the batch. For example two network parameter update proposals in the same batch with the same enactment timestamp will both be executed, in the order specified. (0028-GOVE-164) From 6a5ca70301c8b21343a98698a4f824e855048806 Mon Sep 17 00:00:00 2001 From: Tom Date: Wed, 15 Nov 2023 11:05:23 +0000 Subject: [PATCH 0737/1171] feat: isolated margin tweaks (#2055) * feat: Clarifying and improving isolated margin specs --- protocol/0019-MCAL-margin_calculator.md | 24 ++++++++++++++++-------- wordlist.txt | 1 + 2 files changed, 17 insertions(+), 8 deletions(-) diff --git a/protocol/0019-MCAL-margin_calculator.md b/protocol/0019-MCAL-margin_calculator.md index 872127220..430ff143c 100644 --- a/protocol/0019-MCAL-margin_calculator.md +++ b/protocol/0019-MCAL-margin_calculator.md @@ -157,19 +157,19 @@ When submitting, amending, or deleting an order in isolated margin mode and cont NB: This means that a party's order could partially match, with a trade executed and some funds moved to the margin account with correct leverage whilst the rest of the order is immediately stopped. -When submitting, amending, or deleting an order in isolated margin mode and an auction is active there is no concept of an order trading immediately on entry, however the case of someone putting in a sell order for a very low price must be handled (as it is likely to execute at a much higher price). To handle this, when in an auction the amount taken into the order margin account should be the larger of either `limit price * size * margin factor` or `max(mark price, indicative uncrossing price) * size * margin factor`. All other steps are as above. +When submitting, amending, or deleting an order in isolated margin mode and an auction is active there is no concept of an order trading immediately on entry, however the case of someone putting in a sell order for a very low price must be handled (as it is likely to execute at a much higher price). To handle this, when in an auction the amount taken into the order margin account should be the larger of either `limit price * size * margin factor` or `max(mark price, indicative uncrossing price) * size * margin factor`. After uncrossing, all remaining open order volume should be rebased back to simply `limit price * size * margin factor` in the order margin account. All other steps are as above. ### Increasing Position When an order trades which increases the position (increasing the absolute value of the trader's position), the target amount to be transferred is calculated as: -```math +$$ \text{margin to add} = \text{margin factor} \cdot \text{sum across executed trades}(|\text{trade size}| \cdot \text{trade price}) -``` +$$ This will be taken by performing three steps: - 1. The margin to add as calculated here is compared to the margin which would have been placed into the order margin account for this order, `limit price * remaining size * margin factor`. + 1. The margin to add as calculated here is compared to the margin which would have been placed into the order margin account for this order, `limit price * total traded size * margin factor`. 2. If it is equal, this amount is taken from the order margin account and placed into the margin account 3. If the order traded at a price which means less margin should be taken then the amount `margin to add` above is taken from the order margin account into the margin account and the excess is returned from the order margin account to the general account @@ -177,11 +177,19 @@ NB: In implementation, for any volume that trades immediately on entry, the addi ### Reducing Position -When an order trades which reduces the trader's current position the amount to be withdrawn from the margin account is determined by the fraction of the position which is being closed. However, this fraction should also take into account that the entire position's margin may be due to change since the current trading price may have diverged from the last mark price update. As such the margin released should be calculated as: +When an order trades which reduces the trader's current position the amount to be withdrawn from the margin account is determined by the fraction of the position which is being closed. If the entire position is being closed (either as a result of changing sides as below or just moving to `0`) then the entirety of the margin balance will be moved back to the general account. -```math -\text{margin to remove} = \text{margin required for entire position at VWAP trade price} \cdot \frac{|\text{total size of new trades}|}{|\text{entire position prior to trade}|} -``` +However, if only a fraction is being closed then this fraction should also take into account that the entire position's margin may be due to change, since the current trading price may have diverged from the last mark price update. As such the margin released should be calculated by first calculating what the `theoretical account balance` of the margin account would be if the entire pre-existing position (i.e. the position prior to any reduction) were margined at the VWAP of the executed trade, then taking the proportion of that corresponding to the proportion of the position closed. + +$$ +\text{margin to remove} = \text{theoretical account balance} \cdot \frac{|\text{total size of new trades}|}{|\text{entire position prior to trade}|} +$$ + +Concretely, this should resolve to: + +$$ +\text{margin to remove} = (\text{balance before} + \text{position before} \cdot (\text{new trade VWAP} - \text{mark price})) \cdot \frac{|\text{total size of new trades}|}{|\text{entire position prior to trade}|} +$$ Note: This requires a calculation of the position's margin at trade time. diff --git a/wordlist.txt b/wordlist.txt index bae7b667c..4e8ae5725 100644 --- a/wordlist.txt +++ b/wordlist.txt @@ -216,6 +216,7 @@ pseudorandom pubkey quant rata +rebased recollateralise ReferralSet reimplemented From 80449cb84cad7f62a5c04c013b7ed0aa7a2964e1 Mon Sep 17 00:00:00 2001 From: Vegaklaus <62546834+Vegaklaus@users.noreply.github.com> Date: Wed, 15 Nov 2023 12:27:58 +0100 Subject: [PATCH 0738/1171] Update 0062-SPAM-spam_protection.md (#2037) * Update 0062-SPAM-spam_protection.md Removed banning from anti-spam * fix: MD linting and approbation checks * Update 0072-SPPW-spam-protection-PoW.md Removed banning of accounts --------- Co-authored-by: gordsport Co-authored-by: Gordsport <83510148+gordsport@users.noreply.github.com> --- protocol/0062-SPAM-spam_protection.md | 65 +++++------------------ protocol/0072-SPPW-spam-protection-PoW.md | 18 +------ protocol/features.json | 16 ++---- 3 files changed, 18 insertions(+), 81 deletions(-) diff --git a/protocol/0062-SPAM-spam_protection.md b/protocol/0062-SPAM-spam_protection.md index 57a715b82..938b1f93d 100644 --- a/protocol/0062-SPAM-spam_protection.md +++ b/protocol/0062-SPAM-spam_protection.md @@ -1,15 +1,5 @@ # Spam protection -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 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) 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. - ## Governance spam 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. @@ -20,18 +10,16 @@ The following three policies are also specific to governance actions: - 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. -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. - 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 governance messages that do not follow the anti-spam rules. This can happen in two different ways: -- 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. +- **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. This is currently not used and only kept in here for reference. -The policies enforced are relatively simple: +The policies enforced are the following thresholds: ```text num_votes = 3 // maximum number of times per epoch a tokenholder van change their vote on an issue @@ -48,11 +36,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. +- 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. +- 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. Thus, proposals get **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 @@ -60,16 +45,6 @@ As (due to Tendermint constraints) it is currently possible to exceed all thresh - 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 `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 - -**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 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 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). @@ -92,9 +67,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 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. - -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. +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`). ### Related topics @@ -116,35 +89,21 @@ More than 360 delegation changes in one epoch (or, respectively, the value of `s - 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-PALAZZO-001) -- 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 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). -- 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 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 **pre-block** rejected (0062-SPAM-032). - 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 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 **pre-block** rejected (0062-SPAM-034). - 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). +- 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 **pre-block** rejected (0062-SPAM-036). > **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/0072-SPPW-spam-protection-PoW.md b/protocol/0072-SPPW-spam-protection-PoW.md index 0d0c26beb..c251bfac5 100644 --- a/protocol/0072-SPPW-spam-protection-PoW.md +++ b/protocol/0072-SPPW-spam-protection-PoW.md @@ -47,26 +47,13 @@ Furthermore, the validators check that: - The same identifier has not been used for another transaction from a previously committed block. If the same identifier is used for several transactions in the same block, these transactions need to be removed during post-processing, and the initiator blocked as a spammer. - The same block has not been used for more than `spam.pow.numberOfTxPerBlock` transactions by the same party per spam difficulty level (i.e., if `spam.pow.increaseDifficulty` is `= 1`, the same block can be used for more transactions if the PoW accordingly increases in difficulty). -Violations of the latter rules cannot lead to a transaction being removed, as different validators have a different view on this; however, they can be verified post-agreement, and the offending vega-key can be banished for the duration of 1/48 of an Epoch with a minimum duration of 30 seconds. 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; this is measured starting at the blocktime in which the violation occurs, and transactions are allowed again in the first block after. Validators should return a meaningful error message to the wallet to let it know that/why a transaction got rejected. -Linking a transaction to a too old block will not lead to a banishment, but only to a rejection of the offending transaction. - Notes: - We do not require feeding the hash of the actual transaction into the hash function; this allows users to pre-compute the PoW and thus allows them to perform low latency transactions. - As for replay protection, there is a danger that a trader communicates with a slow validator, and thus gets a wrong block number. The safest is to check validators worth > 1/3 of the weight and take the highest block hash. -- Due to Tendermint constraints, a decision if a transaction is to be rejected or not can only be done based on information that is either synchronised through the chain or contained in the transaction itself, but not based on any other transactions in the mempool. Thus, if a client ties too many transactions to the same block or does not execute the increased difficulty properly, we can not stop this pre-agreement, only detect it post-agreement. This is the reason why some violations are punished with banishment rather than prevented. -- In the [0062 spam protection spec](./0062-SPAM-spam_protection.md), we want to do anti-spam before verifying signatures; this order, however, cannot be done if the consequence of spam is banishment. - -Thus, here the order is: -1. check if the account is banished and (if so) ignore the transaction -2. check if the basic PoW with lowest difficulty is done properly -3. verify the signatures -4. put the transaction on the blockchain -5. if the signed transactions violate the conditions, issue the banishment -6. if the signed transactions in a block violate the conditions, remove the offending ones from the block before calling vega [May need discussion] Depending on how things pan out, we may have an issue with the timing; to make sure traders have sufficient time to get the block height needs us to have a large parameter of `spam.pow.numberOfPastBlocks`, which may allow too many transactions. There are ways to fix this (e.g., the block height needs to end with the same bit as the validator ID), but for now we assume this doesn't cause an issue. @@ -89,10 +76,9 @@ 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) +- Linking too many transactions to the same block is detected and leads to rejecting the transactions that are too many (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 rejecting the transactions that are too many (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-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) diff --git a/protocol/features.json b/protocol/features.json index 39cf00d6a..6a3f7d0ba 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -1,34 +1,26 @@ { "Iceberg Orders": { - "milestone": "cosmic", + "milestone": "cosmic-carryover", "acs": [ "0014-ORDT-069" ] }, "Successor Markets": { - "milestone": "cosmic", + "milestone": "cosmic-carryover", "acs": [ "0001-MKTF-008", "0081-SUCM-035" ] }, "Ethereum oracles": { - "milestone": "cosmic", + "milestone": "cosmic-carryover", "acs": [ "0082-ETHD-035", "0082-ETHD-041" ] }, - "Referral program": { - "milestone": "cosmic", - "acs": [ - "0062-SPAM-033", - "0062-SPAM-035", - "0062-SPAM-037" - ] - }, "Stop Orders": { - "milestone": "cosmic", + "milestone": "cosmic-carryover", "acs": [ "0079-TGAP-004", "0079-TGAP-005" From 3d6718a9f0be8fd90d6395687e96bd1249780526 Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Fri, 10 Nov 2023 11:31:46 +0000 Subject: [PATCH 0739/1171] feat: add ACs for isolated margin --- protocol/0019-MCAL-margin_calculator.md | 99 ++++++++++++++++++++++++- protocol/features.json | 28 ++++++- 2 files changed, 125 insertions(+), 2 deletions(-) diff --git a/protocol/0019-MCAL-margin_calculator.md b/protocol/0019-MCAL-margin_calculator.md index 430ff143c..a9c1a60ac 100644 --- a/protocol/0019-MCAL-margin_calculator.md +++ b/protocol/0019-MCAL-margin_calculator.md @@ -1,6 +1,6 @@ # Margin Calculator -## Acceptance Criteria +## Acceptance Criteria (under Cross-margin modes) - Get four margin levels for one or more parties (0019-MCAL-001) @@ -82,6 +82,102 @@ - Thus, with `margin funding factor = 0.5`, `total margin requirement = futures margin + funding margin = 5565 + 0.5 * max(0, -90 * 1) = 5565` (0019-MCAL-028) - However is position is instead `-1`, with the same margin requirement, if `margin funding factor = 0.5`, `total margin requirement = futures margin + funding margin = 5565 + 0.5 * max(0, -90 * -1) = 5610`(0019-MCAL-029) +## Acceptance Criteria (under Isolated-margin modes) + +- Margin levels are correctly calculated against newly created positions. (0019-MCAL-032) + +- Margin levels are correctly calculated against newly created orders. (0019-MCAL-033) + +- Additional margin levels are correctly calculated if new orders is placed and would increase the trader's existing position size. (0019-MCAL-034) + +- Additional margin levels are correctly calculated if new orders is placed and would decrease the trader's existing position size. (0019-MCAL-035) + +- Margin levels are correctly calculated when an order trades which increases the position (increasing the absolute value of the trader's position). (0019-MCAL-036) + +- Margin levels are correctly calculated when an order trades which decreases the position (decreasing the absolute value of the trader's position). (0019-MCAL-037) + +- Margin levels are correctly calculated with a single order that moves a trader from a short to a long position which increases the required margin. (0019-MCAL-038) + +- Margin levels are correctly calculated with a single order that moves a trader from a long to a short position which decreases the required margin. (0019-MCAL-039) + +- Margin levels are correctly calculated in the case of an open position dropping below maintenance margin levels active orders will remain active as these are margined separately and will not be cancelled.(0019-MCAL-040) + +- Zero position and zero orders results in all zero margin levels. (0019-MCAL-041) + +- If a trader has a long position 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-042) + +- If a trader's `long position > 0 && 0 < *sum of volume of order book bids* < long position`, the `exit price` is equal to infinity. (0019-MCAL-043) + +- If a trader's `short position < 0 && 0 < *sum of absolute volume of order book offers* < short position`, the `exit price` is equal to infinity. (0019-MCAL-044) + +- If a trader's `long position > 0 && long position < *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-045) + +- If a trader's `short position < 0 && 0 < abs(short position) < *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-046) + +- A feature test that checks margin in case market PDP > 0 is created and passes. (0019-MCAL-047) + +- A feature test that checks margin in case market PDP < 0 is created and passes. (0019-MCAL-048) + +- For each market and each party which has either orders or positions on the market, the API provides the maintenance margin levels. (0019-MCAL-049) + +- If a party is short `1` unit and the mark price is `15 900` and `market.linearSlippageFactor = 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 `min(1 x (100000-15900), 15900 x 0.25 x 1) + 0.1 x 1 x 15900 = 5565`. (0019-MCAL-050) + +- In the same situation as above, if `market.linearSlippageFactor = 100`, (i.e. 10 000%) instead, then the margin for the party is `min(1 x (100000-15900), 15900 x 100 x 1) + 0.1 x 1 x 15900 = 85690`. (0019-MCAL-051) + +- If the `market.linearSlippageFactor` 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-052) + +- 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.linearSlippageFactor = 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 `min(1 x (100000-15900), 15900 x 0.25 x 1) + 0.1 x 1 x 15900 = 5565`. 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 = 5565 + 0.5 * 0.16 * 1 = 5565.08` (0019-MCAL-053) + + - 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 = 5565 + 0.5 * 70 * 1 = 5600` (0019-MCAL-027) + - However is position is instead `-1`, with the same margin requirement, if `margin funding factor = 0.5`, `total margin requirement = futures margin + funding margin = 5565 + 0.5 * max(0, 70 * -1) = 5565`(0019-MCAL-054) + + - 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 = 5565 + 0.5 * max(0, -90 * 1) = 5565` (0019-MCAL-055) + - However is position is instead `-1`, with the same margin requirement, if `margin funding factor = 0.5`, `total margin requirement = futures margin + funding margin = 5565 + 0.5 * max(0, -90 * -1) = 5610`(0019-MCAL-056) + ## Summary The *margin calculator* returns the set of margin levels for a given *actual position*, along with the amount of additional margin (if any) required to support the party's *potential position* (i.e. active orders including any that are parked/untriggered/undeployed). @@ -495,3 +591,4 @@ riskiest short: -1 Scenarios found [here](https://docs.google.com/spreadsheets/d/1VXMdpgyyA9jp0hoWcIQTUFrhOdtu-fak/edit#gid=1586131462) + diff --git a/protocol/features.json b/protocol/features.json index 6a3f7d0ba..4cf6fdee3 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -84,7 +84,33 @@ }, "Margin isolation": { "milestone": "palazzo", - "acs": [] + "acs": [ + "0019-MCAL-032", + "0019-MCAL-033", + "0019-MCAL-034", + "0019-MCAL-035", + "0019-MCAL-036", + "0019-MCAL-037", + "0019-MCAL-038", + "0019-MCAL-039", + "0019-MCAL-040", + "0019-MCAL-041", + "0019-MCAL-042", + "0019-MCAL-043", + "0019-MCAL-044", + "0019-MCAL-045", + "0019-MCAL-046", + "0019-MCAL-047", + "0019-MCAL-048", + "0019-MCAL-049", + "0019-MCAL-050", + "0019-MCAL-051", + "0019-MCAL-052", + "0019-MCAL-053", + "0019-MCAL-054", + "0019-MCAL-055", + "0019-MCAL-056" + ] }, "Quadratic slippage removal": { "milestone": "palazzo", From 5f21758d42118f228ea14ec4cc6a82f98f032959 Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Tue, 14 Nov 2023 17:16:15 +0000 Subject: [PATCH 0740/1171] feat: add example in isolated margin --- protocol/0019-MCAL-margin_calculator.md | 101 +----------------------- protocol/features.json | 1 + 2 files changed, 3 insertions(+), 99 deletions(-) diff --git a/protocol/0019-MCAL-margin_calculator.md b/protocol/0019-MCAL-margin_calculator.md index a9c1a60ac..7034c617b 100644 --- a/protocol/0019-MCAL-margin_calculator.md +++ b/protocol/0019-MCAL-margin_calculator.md @@ -1,6 +1,6 @@ # Margin Calculator -## Acceptance Criteria (under Cross-margin modes) +## Acceptance Criteria - Get four margin levels for one or more parties (0019-MCAL-001) @@ -82,102 +82,6 @@ - Thus, with `margin funding factor = 0.5`, `total margin requirement = futures margin + funding margin = 5565 + 0.5 * max(0, -90 * 1) = 5565` (0019-MCAL-028) - However is position is instead `-1`, with the same margin requirement, if `margin funding factor = 0.5`, `total margin requirement = futures margin + funding margin = 5565 + 0.5 * max(0, -90 * -1) = 5610`(0019-MCAL-029) -## Acceptance Criteria (under Isolated-margin modes) - -- Margin levels are correctly calculated against newly created positions. (0019-MCAL-032) - -- Margin levels are correctly calculated against newly created orders. (0019-MCAL-033) - -- Additional margin levels are correctly calculated if new orders is placed and would increase the trader's existing position size. (0019-MCAL-034) - -- Additional margin levels are correctly calculated if new orders is placed and would decrease the trader's existing position size. (0019-MCAL-035) - -- Margin levels are correctly calculated when an order trades which increases the position (increasing the absolute value of the trader's position). (0019-MCAL-036) - -- Margin levels are correctly calculated when an order trades which decreases the position (decreasing the absolute value of the trader's position). (0019-MCAL-037) - -- Margin levels are correctly calculated with a single order that moves a trader from a short to a long position which increases the required margin. (0019-MCAL-038) - -- Margin levels are correctly calculated with a single order that moves a trader from a long to a short position which decreases the required margin. (0019-MCAL-039) - -- Margin levels are correctly calculated in the case of an open position dropping below maintenance margin levels active orders will remain active as these are margined separately and will not be cancelled.(0019-MCAL-040) - -- Zero position and zero orders results in all zero margin levels. (0019-MCAL-041) - -- If a trader has a long position 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-042) - -- If a trader's `long position > 0 && 0 < *sum of volume of order book bids* < long position`, the `exit price` is equal to infinity. (0019-MCAL-043) - -- If a trader's `short position < 0 && 0 < *sum of absolute volume of order book offers* < short position`, the `exit price` is equal to infinity. (0019-MCAL-044) - -- If a trader's `long position > 0 && long position < *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-045) - -- If a trader's `short position < 0 && 0 < abs(short position) < *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-046) - -- A feature test that checks margin in case market PDP > 0 is created and passes. (0019-MCAL-047) - -- A feature test that checks margin in case market PDP < 0 is created and passes. (0019-MCAL-048) - -- For each market and each party which has either orders or positions on the market, the API provides the maintenance margin levels. (0019-MCAL-049) - -- If a party is short `1` unit and the mark price is `15 900` and `market.linearSlippageFactor = 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 `min(1 x (100000-15900), 15900 x 0.25 x 1) + 0.1 x 1 x 15900 = 5565`. (0019-MCAL-050) - -- In the same situation as above, if `market.linearSlippageFactor = 100`, (i.e. 10 000%) instead, then the margin for the party is `min(1 x (100000-15900), 15900 x 100 x 1) + 0.1 x 1 x 15900 = 85690`. (0019-MCAL-051) - -- If the `market.linearSlippageFactor` 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-052) - -- 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.linearSlippageFactor = 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 `min(1 x (100000-15900), 15900 x 0.25 x 1) + 0.1 x 1 x 15900 = 5565`. 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 = 5565 + 0.5 * 0.16 * 1 = 5565.08` (0019-MCAL-053) - - - 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 = 5565 + 0.5 * 70 * 1 = 5600` (0019-MCAL-027) - - However is position is instead `-1`, with the same margin requirement, if `margin funding factor = 0.5`, `total margin requirement = futures margin + funding margin = 5565 + 0.5 * max(0, 70 * -1) = 5565`(0019-MCAL-054) - - - 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 = 5565 + 0.5 * max(0, -90 * 1) = 5565` (0019-MCAL-055) - - However is position is instead `-1`, with the same margin requirement, if `margin funding factor = 0.5`, `total margin requirement = futures margin + funding margin = 5565 + 0.5 * max(0, -90 * -1) = 5610`(0019-MCAL-056) - ## Summary The *margin calculator* returns the set of margin levels for a given *actual position*, along with the amount of additional margin (if any) required to support the party's *potential position* (i.e. active orders including any that are parked/untriggered/undeployed). @@ -222,7 +126,7 @@ Margin levels are used by the protocol to ascertain whether a trader has suffici In future there can be multiple margin calculator implementations that would be configurable in the market framework. This spec describes one implementation. ## Isolated margin mode - + When in isolated margin mode, the position on the market has an associated margin factor. The margin factor must be greater than 0 and less than or equal to 1, and also greater than `max(risk factor long, risk factor short)`. @@ -591,4 +495,3 @@ riskiest short: -1 Scenarios found [here](https://docs.google.com/spreadsheets/d/1VXMdpgyyA9jp0hoWcIQTUFrhOdtu-fak/edit#gid=1586131462) - diff --git a/protocol/features.json b/protocol/features.json index 4cf6fdee3..ec4390466 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -85,6 +85,7 @@ "Margin isolation": { "milestone": "palazzo", "acs": [ + "0019-MCAL-031", "0019-MCAL-032", "0019-MCAL-033", "0019-MCAL-034", From 2a1d5a23b301b76e82649dcff27b250fff82b2d7 Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Tue, 14 Nov 2023 17:32:39 +0000 Subject: [PATCH 0741/1171] feat: update commit --- protocol/0019-MCAL-margin_calculator.md | 107 +++++++++++++++++++++++- 1 file changed, 105 insertions(+), 2 deletions(-) diff --git a/protocol/0019-MCAL-margin_calculator.md b/protocol/0019-MCAL-margin_calculator.md index 7034c617b..346c1d5a2 100644 --- a/protocol/0019-MCAL-margin_calculator.md +++ b/protocol/0019-MCAL-margin_calculator.md @@ -1,6 +1,6 @@ # Margin Calculator -## Acceptance Criteria +## Acceptance Criteria (under Cross-margin modes) - Get four margin levels for one or more parties (0019-MCAL-001) @@ -82,6 +82,106 @@ - Thus, with `margin funding factor = 0.5`, `total margin requirement = futures margin + funding margin = 5565 + 0.5 * max(0, -90 * 1) = 5565` (0019-MCAL-028) - However is position is instead `-1`, with the same margin requirement, if `margin funding factor = 0.5`, `total margin requirement = futures margin + funding margin = 5565 + 0.5 * max(0, -90 * -1) = 5610`(0019-MCAL-029) +## Acceptance Criteria (under Isolated-margin modes) + +- If a party has a newly created short position of `1` and the mark price is `15 900` and `market.linearSlippageFactor = 0.25`, `RF short = 0.1` and `Initial margin factor = 1.5` 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 (under cross-margin mode) for the party is `min(1 x (100000-15900), 15900 x 0.25 x 1) + 0.1 x 1 x 15900 = 5565`, and margin account should have initial margin level which is `5565 x 1.5 = 8348`. + when switching to isolated-margin mode and the `margin factor short = 0.3`, the maintenance margin should be updated to `average entry price x current position x new margin factor = 57500 x 1 x 0.3 = 17250`, and margin account should be updated to `17250`. (0019-MCAL-031) + + when switching to isolated-margin mode and the `margin factor short = 0.11`, the maintenance margin should be updated to `average entry price x current position x new margin factor = 57500 x 1 x 0.11 = 6325`, the switching will be rejected. (0019-MCAL-032) + + when switching to isolated-margin mode and the `margin factor short = 0.3`, the maintenance margin should be updated to `average entry price x current position x new margin factor = 57500 x 1 x 0.3 = 17250`, and margin account should be updated to `17250`. (0019-MCAL-033) + +- When the party place a new short order of `1` with price `15000`, and the market is in continouse trading. + + The margin account should have additional amount `average entry price x current position x new margin factor = 59524 x 1 x 0.3 = 17857` added if the party has enough asset in the general account(0019-MCAL-034) + + The order will be rejected if the party does not have enough asset in the general account (0019-MCAL-035) + +- When the party place a new short order of `1` with price `45000`, and the market is in continouse trading. + + The margin account should have additional amount `limit price * size * margin factor = 45000 x 1 x 0.3 = 13500` added if the party has enough asset in the general account(0019-MCAL-036) + + The order will be rejected if the party does not have enough asset in the general account(0019-MCAL-037) + +- When the party place a new long order of `1` with price `145000` and the party has existing short position of `3`, and the market is in continouse trading. The margin account should not change(0019-MCAL-038) + +- When the party place a new long order of `10` with price `145000` and the party has existing short position of `3`, and the market is in continouse trading. The margin account should have additional amount `limit price * size * margin factor = 145000 x (10-3) x 0.3 = 304500` added if the party has enough asset in the general account(0019-MCAL-039) + +- Margin levels are correctly calculated in the case of an open position dropping below maintenance margin levels active orders will remain active as these are margined separately and will not be cancelled.(0019-MCAL-040) + +- Zero position and zero orders results in all zero margin levels. (0019-MCAL-041) + +- If a trader has a long position 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-042) + +- If a trader's `long position > 0 && 0 < *sum of volume of order book bids* < long position`, the `exit price` is equal to infinity. (0019-MCAL-043) + +- If a trader's `short position < 0 && 0 < *sum of absolute volume of order book offers* < short position`, the `exit price` is equal to infinity. (0019-MCAL-044) + +- If a trader's `long position > 0 && long position < *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-045) + +- If a trader's `short position < 0 && 0 < abs(short position) < *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-046) + +- A feature test that checks margin in case market PDP > 0 is created and passes. (0019-MCAL-047) + +- A feature test that checks margin in case market PDP < 0 is created and passes. (0019-MCAL-048) + +- For each market and each party which has either orders or positions on the market, the API provides the maintenance margin levels. (0019-MCAL-049) + +- In the same situation as above, if `market.linearSlippageFactor = 100`, (i.e. 10 000%) instead, then the margin for the party is `min(1 x (100000-15900), 15900 x 100 x 1) + 0.1 x 1 x 15900 = 85690`. (0019-MCAL-051) + +- If the `market.linearSlippageFactor` 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-052) + +- 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.linearSlippageFactor = 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 `min(1 x (100000-15900), 15900 x 0.25 x 1) + 0.1 x 1 x 15900 = 5565`. 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 = 5565 + 0.5 * 0.16 * 1 = 5565.08` (0019-MCAL-053) + + - 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 = 5565 + 0.5 * 70 * 1 = 5600` (0019-MCAL-027) + - However is position is instead `-1`, with the same margin requirement, if `margin funding factor = 0.5`, `total margin requirement = futures margin + funding margin = 5565 + 0.5 * max(0, 70 * -1) = 5565`(0019-MCAL-054) + + - 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 = 5565 + 0.5 * max(0, -90 * 1) = 5565` (0019-MCAL-055) + - However is position is instead `-1`, with the same margin requirement, if `margin funding factor = 0.5`, `total margin requirement = futures margin + funding margin = 5565 + 0.5 * max(0, -90 * -1) = 5610`(0019-MCAL-056) + ## Summary The *margin calculator* returns the set of margin levels for a given *actual position*, along with the amount of additional margin (if any) required to support the party's *potential position* (i.e. active orders including any that are parked/untriggered/undeployed). @@ -126,7 +226,7 @@ Margin levels are used by the protocol to ascertain whether a trader has suffici In future there can be multiple margin calculator implementations that would be configurable in the market framework. This spec describes one implementation. ## Isolated margin mode - + When in isolated margin mode, the position on the market has an associated margin factor. The margin factor must be greater than 0 and less than or equal to 1, and also greater than `max(risk factor long, risk factor short)`. @@ -495,3 +595,6 @@ riskiest short: -1 Scenarios found [here](https://docs.google.com/spreadsheets/d/1VXMdpgyyA9jp0hoWcIQTUFrhOdtu-fak/edit#gid=1586131462) + + + From 288bbe83cd0c41054037842fa0adf8f16f764dad Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Tue, 14 Nov 2023 17:35:45 +0000 Subject: [PATCH 0742/1171] chore: markdown --- protocol/0019-MCAL-margin_calculator.md | 7 ++----- 1 file changed, 2 insertions(+), 5 deletions(-) diff --git a/protocol/0019-MCAL-margin_calculator.md b/protocol/0019-MCAL-margin_calculator.md index 346c1d5a2..bba0d47c0 100644 --- a/protocol/0019-MCAL-margin_calculator.md +++ b/protocol/0019-MCAL-margin_calculator.md @@ -93,6 +93,7 @@ sell 1 @ 100 000 sell 10 @ 100 100 ``` + then the maintenance margin (under cross-margin mode) for the party is `min(1 x (100000-15900), 15900 x 0.25 x 1) + 0.1 x 1 x 15900 = 5565`, and margin account should have initial margin level which is `5565 x 1.5 = 8348`. when switching to isolated-margin mode and the `margin factor short = 0.3`, the maintenance margin should be updated to `average entry price x current position x new margin factor = 57500 x 1 x 0.3 = 17250`, and margin account should be updated to `17250`. (0019-MCAL-031) @@ -593,8 +594,4 @@ riskiest short: -1 ## SCENARIOS -Scenarios found [here](https://docs.google.com/spreadsheets/d/1VXMdpgyyA9jp0hoWcIQTUFrhOdtu-fak/edit#gid=1586131462) - - - - +Scenarios found [here](https://docs.google.com/spreadsheets/d/1VXMdpgyyA9jp0hoWcIQTUFrhOdtu-fak/edit#gid=1586131462) \ No newline at end of file From b935780ef0923bb1f9e5e77b4ba78236d36a9ca4 Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Tue, 14 Nov 2023 17:45:41 +0000 Subject: [PATCH 0743/1171] feat: markdown --- protocol/0019-MCAL-margin_calculator.md | 12 ++++++------ protocol/features.json | 4 +++- 2 files changed, 9 insertions(+), 7 deletions(-) diff --git a/protocol/0019-MCAL-margin_calculator.md b/protocol/0019-MCAL-margin_calculator.md index bba0d47c0..0f04c97d5 100644 --- a/protocol/0019-MCAL-margin_calculator.md +++ b/protocol/0019-MCAL-margin_calculator.md @@ -94,20 +94,20 @@ sell 10 @ 100 100 ``` - then the maintenance margin (under cross-margin mode) for the party is `min(1 x (100000-15900), 15900 x 0.25 x 1) + 0.1 x 1 x 15900 = 5565`, and margin account should have initial margin level which is `5565 x 1.5 = 8348`. + then the maintenance margin (under cross-margin mode) for the party is `min(1 x (100000-15900), 15900 x 0.25 x 1) + 0.1 x 1 x 15900 = 5565`, and margin account should have initial margin level which is `5565 x 1.5 = 8348`. when switching to isolated-margin mode and the `margin factor short = 0.3`, the maintenance margin should be updated to `average entry price x current position x new margin factor = 57500 x 1 x 0.3 = 17250`, and margin account should be updated to `17250`. (0019-MCAL-031) when switching to isolated-margin mode and the `margin factor short = 0.11`, the maintenance margin should be updated to `average entry price x current position x new margin factor = 57500 x 1 x 0.11 = 6325`, the switching will be rejected. (0019-MCAL-032) when switching to isolated-margin mode and the `margin factor short = 0.3`, the maintenance margin should be updated to `average entry price x current position x new margin factor = 57500 x 1 x 0.3 = 17250`, and margin account should be updated to `17250`. (0019-MCAL-033) -- When the party place a new short order of `1` with price `15000`, and the market is in continouse trading. +- When the party place a new short order of `1` with price `15000`, and the market is in continous trading. The margin account should have additional amount `average entry price x current position x new margin factor = 59524 x 1 x 0.3 = 17857` added if the party has enough asset in the general account(0019-MCAL-034) The order will be rejected if the party does not have enough asset in the general account (0019-MCAL-035) -- When the party place a new short order of `1` with price `45000`, and the market is in continouse trading. +- When the party place a new short order of `1` with price `45000`, and the market is in continous trading. The margin account should have additional amount `limit price * size * margin factor = 45000 x 1 x 0.3 = 13500` added if the party has enough asset in the general account(0019-MCAL-036) @@ -133,7 +133,7 @@ - A feature test that checks margin in case market PDP > 0 is created and passes. (0019-MCAL-047) -- A feature test that checks margin in case market PDP < 0 is created and passes. (0019-MCAL-048) +- A feature test that checks margin in case market PDP < 0 is created and passes. (0019-MCAL-057) - For each market and each party which has either orders or positions on the market, the API provides the maintenance margin levels. (0019-MCAL-049) @@ -173,7 +173,7 @@ - `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 = 5565 + 0.5 * 70 * 1 = 5600` (0019-MCAL-027) + - Thus, with `margin funding factor = 0.5`, `total margin requirement = futures margin + funding margin = 5565 + 0.5 * 70 * 1 = 5600` (0019-MCAL-058) - However is position is instead `-1`, with the same margin requirement, if `margin funding factor = 0.5`, `total margin requirement = futures margin + funding margin = 5565 + 0.5 * max(0, 70 * -1) = 5565`(0019-MCAL-054) - If instead @@ -594,4 +594,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) diff --git a/protocol/features.json b/protocol/features.json index ec4390466..f25aa834d 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -110,7 +110,9 @@ "0019-MCAL-053", "0019-MCAL-054", "0019-MCAL-055", - "0019-MCAL-056" + "0019-MCAL-056", + "0019-MCAL-057", + "0019-MCAL-058" ] }, "Quadratic slippage removal": { From c313ed7b19e5514adeb65eed855858cb1047c142 Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Tue, 14 Nov 2023 17:47:19 +0000 Subject: [PATCH 0744/1171] chore: markdown --- protocol/features.json | 2 -- 1 file changed, 2 deletions(-) diff --git a/protocol/features.json b/protocol/features.json index f25aa834d..85b161c2f 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -102,9 +102,7 @@ "0019-MCAL-045", "0019-MCAL-046", "0019-MCAL-047", - "0019-MCAL-048", "0019-MCAL-049", - "0019-MCAL-050", "0019-MCAL-051", "0019-MCAL-052", "0019-MCAL-053", From 9388a74531430151bd077a5ecad8f11c61de1528 Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Tue, 14 Nov 2023 17:49:15 +0000 Subject: [PATCH 0745/1171] chore: typo --- protocol/0019-MCAL-margin_calculator.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/protocol/0019-MCAL-margin_calculator.md b/protocol/0019-MCAL-margin_calculator.md index 0f04c97d5..b0cf6d298 100644 --- a/protocol/0019-MCAL-margin_calculator.md +++ b/protocol/0019-MCAL-margin_calculator.md @@ -113,9 +113,9 @@ The order will be rejected if the party does not have enough asset in the general account(0019-MCAL-037) -- When the party place a new long order of `1` with price `145000` and the party has existing short position of `3`, and the market is in continouse trading. The margin account should not change(0019-MCAL-038) +- When the party place a new long order of `1` with price `145000` and the party has existing short position of `3`, and the market is in continous trading. The margin account should not change(0019-MCAL-038) -- When the party place a new long order of `10` with price `145000` and the party has existing short position of `3`, and the market is in continouse trading. The margin account should have additional amount `limit price * size * margin factor = 145000 x (10-3) x 0.3 = 304500` added if the party has enough asset in the general account(0019-MCAL-039) +- When the party place a new long order of `10` with price `145000` and the party has existing short position of `3`, and the market is in continous trading. The margin account should have additional amount `limit price * size * margin factor = 145000 x (10-3) x 0.3 = 304500` added if the party has enough asset in the general account(0019-MCAL-039) - Margin levels are correctly calculated in the case of an open position dropping below maintenance margin levels active orders will remain active as these are margined separately and will not be cancelled.(0019-MCAL-040) From ea191b2da0ab963148451a073740592ab4811216 Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Wed, 15 Nov 2023 08:57:25 +0000 Subject: [PATCH 0746/1171] chore: typo --- protocol/0019-MCAL-margin_calculator.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/protocol/0019-MCAL-margin_calculator.md b/protocol/0019-MCAL-margin_calculator.md index b0cf6d298..0ef76df25 100644 --- a/protocol/0019-MCAL-margin_calculator.md +++ b/protocol/0019-MCAL-margin_calculator.md @@ -101,13 +101,13 @@ when switching to isolated-margin mode and the `margin factor short = 0.3`, the maintenance margin should be updated to `average entry price x current position x new margin factor = 57500 x 1 x 0.3 = 17250`, and margin account should be updated to `17250`. (0019-MCAL-033) -- When the party place a new short order of `1` with price `15000`, and the market is in continous trading. +- When the party place a new short order of `1` with price `15000`, and the market is in continuous trading. The margin account should have additional amount `average entry price x current position x new margin factor = 59524 x 1 x 0.3 = 17857` added if the party has enough asset in the general account(0019-MCAL-034) The order will be rejected if the party does not have enough asset in the general account (0019-MCAL-035) -- When the party place a new short order of `1` with price `45000`, and the market is in continous trading. +- When the party place a new short order of `1` with price `45000`, and the market is in continuous trading. The margin account should have additional amount `limit price * size * margin factor = 45000 x 1 x 0.3 = 13500` added if the party has enough asset in the general account(0019-MCAL-036) From 0b3c9c81a2facea5c1ed443bc50db7bddbdfa9ed Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Wed, 15 Nov 2023 15:14:18 +0000 Subject: [PATCH 0747/1171] chore: typo --- protocol/0019-MCAL-margin_calculator.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/protocol/0019-MCAL-margin_calculator.md b/protocol/0019-MCAL-margin_calculator.md index 0ef76df25..61ab47442 100644 --- a/protocol/0019-MCAL-margin_calculator.md +++ b/protocol/0019-MCAL-margin_calculator.md @@ -113,9 +113,9 @@ The order will be rejected if the party does not have enough asset in the general account(0019-MCAL-037) -- When the party place a new long order of `1` with price `145000` and the party has existing short position of `3`, and the market is in continous trading. The margin account should not change(0019-MCAL-038) +- When the party place a new long order of `1` with price `145000` and the party has existing short position of `3`, and the market is in continuous trading. The margin account should not change(0019-MCAL-038) -- When the party place a new long order of `10` with price `145000` and the party has existing short position of `3`, and the market is in continous trading. The margin account should have additional amount `limit price * size * margin factor = 145000 x (10-3) x 0.3 = 304500` added if the party has enough asset in the general account(0019-MCAL-039) +- When the party place a new long order of `10` with price `145000` and the party has existing short position of `3`, and the market is in continuous trading. The margin account should have additional amount `limit price * size * margin factor = 145000 x (10-3) x 0.3 = 304500` added if the party has enough asset in the general account(0019-MCAL-039) - Margin levels are correctly calculated in the case of an open position dropping below maintenance margin levels active orders will remain active as these are margined separately and will not be cancelled.(0019-MCAL-040) From 5798ed0d523a2949536ef8b008e94a9fe3cc6a89 Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Mon, 13 Nov 2023 11:18:44 +0000 Subject: [PATCH 0748/1171] feat: update transfer fee spec and ac --- protocol/0057-TRAN-transfers.md | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/protocol/0057-TRAN-transfers.md b/protocol/0057-TRAN-transfers.md index af17fc61b..0e4355848 100644 --- a/protocol/0057-TRAN-transfers.md +++ b/protocol/0057-TRAN-transfers.md @@ -246,6 +246,9 @@ message CancelTransfer { | `transfer.minTransferQuantumMultiple` | String (decimal) | greater than or equal to `0`| `"0.1"` | This, when multiplied by `quantum` (which is specified per asset) determines the minimum transfer amount | | `transfer.fee.factor` | String (decimal) | in `[0.0,1.0]` | `"0.001"` | The proportion of the transfer charged as a fee | | `transfer.fee.maxQuantumAmount` | String (decimal) | greater than or equal to `0` | `"100"` | The cap of the transfer fee | +| `transfer.feeDiscountMinimumTrackedAmount` | String (decimal) | greater than or equal to `0` | `"0.001"` | The lower bound of transfer fee tracked | +| `transfer.feeDiscountDecay` | String (decimal) | greater than or equal to `0` and strictly less than `1` | `"0.5"` | The speed of cumulated trading fees decay for the purpose of being used to do transfer-fee-free transfers | + ## Acceptance criteria @@ -264,11 +267,14 @@ message CancelTransfer { - 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 + - The transfer fee discount is correctly applied with network parameter`transfer.feeDiscountDecay`(0057-TRAN-014) - 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 (when `transfer amount * transfer.fee.factor > transfer.fee.maxQuantumAmount * quantum`). (0057-TRAN-011) - - The fee cost is correctly calculated using the network parameter `transfer.fee.Maxfactor` + - 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 + - The transfer fee discount is correctly applied with network parameter`transfer.feeDiscountDecay`(0057-TRAN-015) + - When transfer fee discount amount is less than `M x quantum` (M is network parameter `transfer.feeDiscountMinimumTrackedAmount`), then no tranfer fee discount will be applied (0057-TRAN-016) - As a user I can do a transfer from a vested account to a general account held by the same key without incurring any fees (0057-TRAN-066). - If a user transfers funds from their vested account to any valid account other than their general account for that asset, they will incur fees. This includes accounts not owned by the user. (0057-TRAN-069). - As a user, I **can not** transfer a quantum amount less than `transfer.minTransferQuantumAmount` from any of the valid accounts excluding a vested account (0057-TRAN-067). @@ -280,7 +286,6 @@ message CancelTransfer { - 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) - As a user, I can accumulate the fees I collect over an epoch. When I initiate a transfer that incurs a transfer fee, I have the ability to view the amount that is exempt from transfer fees through the API. (0057-TRAN-012) -- By setting `transfer.feeDiscountNumOfEpoch` to 3 epochs, you establish a time window spanning 3 consecutive epochs. During these 3 epochs, if you place market orders and subsequently initiate a transfer incurring a transfer fee, the 'free transfer amount' is calculated based on the cumulative fees collected over those same 3 epochs.(0057-TRAN-013) ### Recurring transfer tests From 0d831e8721574e048e76bf14ba20b15416603620 Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Mon, 13 Nov 2023 11:18:46 +0000 Subject: [PATCH 0749/1171] update spec 0057 and add ACS --- protocol/features.json | 3 +++ 1 file changed, 3 insertions(+) diff --git a/protocol/features.json b/protocol/features.json index 85b161c2f..3a218f4ba 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -153,6 +153,9 @@ "0057-TRAN-011", "0057-TRAN-012", "0057-TRAN-013", + "0057-TRAN-014", + "0057-TRAN-015", + "0057-TRAN-016", "0057-TRAN-064", "0057-TRAN-065" ] From d561732a4c0719bee1f7122043cb156eade11cfe Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Mon, 13 Nov 2023 11:35:32 +0000 Subject: [PATCH 0750/1171] feat: add AC for API --- protocol/0057-TRAN-transfers.md | 2 ++ protocol/features.json | 2 ++ 2 files changed, 4 insertions(+) diff --git a/protocol/0057-TRAN-transfers.md b/protocol/0057-TRAN-transfers.md index 0e4355848..f544324ba 100644 --- a/protocol/0057-TRAN-transfers.md +++ b/protocol/0057-TRAN-transfers.md @@ -268,12 +268,14 @@ message CancelTransfer { - 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 - The transfer fee discount is correctly applied with network parameter`transfer.feeDiscountDecay`(0057-TRAN-014) + - The fee-free transfer amount is accessible while API (0057-TRAN-017) - 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 (when `transfer amount * transfer.fee.factor > transfer.fee.maxQuantumAmount * quantum`). (0057-TRAN-011) - 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 - The transfer fee discount is correctly applied with network parameter`transfer.feeDiscountDecay`(0057-TRAN-015) + - The fee-free transfer amount is accessible while API (0057-TRAN-018) - When transfer fee discount amount is less than `M x quantum` (M is network parameter `transfer.feeDiscountMinimumTrackedAmount`), then no tranfer fee discount will be applied (0057-TRAN-016) - As a user I can do a transfer from a vested account to a general account held by the same key without incurring any fees (0057-TRAN-066). - If a user transfers funds from their vested account to any valid account other than their general account for that asset, they will incur fees. This includes accounts not owned by the user. (0057-TRAN-069). diff --git a/protocol/features.json b/protocol/features.json index 3a218f4ba..7b200517b 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -156,6 +156,8 @@ "0057-TRAN-014", "0057-TRAN-015", "0057-TRAN-016", + "0057-TRAN-017", + "0057-TRAN-018", "0057-TRAN-064", "0057-TRAN-065" ] From 674b021ea13bc79484a5944ad5878e2fe8d9ab9e Mon Sep 17 00:00:00 2001 From: gordsport Date: Mon, 13 Nov 2023 14:07:32 +0000 Subject: [PATCH 0751/1171] fix: MD and spelling linting --- protocol/0057-TRAN-transfers.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/protocol/0057-TRAN-transfers.md b/protocol/0057-TRAN-transfers.md index f544324ba..576a8d25b 100644 --- a/protocol/0057-TRAN-transfers.md +++ b/protocol/0057-TRAN-transfers.md @@ -184,7 +184,7 @@ At the end of epoch `k`: 1. update `c <- c + all_trading_fees_for_trades_involved_in`, where `all_trading_fees_for_trades_involved_in` are the cumulated trading fees paid by the aggressive party (taker fees) but also cumulated (with a +sign) the trading fees result from any trade in which the party was involved as the passive party (i.e. their limit order got lifted). -1. if `c` is less than `M x quantum` (where quantum is the asset quantum) then set `c <- 0`. +1. if `c` is less than `M x quantum` (where quantum is the asset quantum) then set `c <- 0`. We need appropriate APIs to enable the frontend to display the amount eligible for fee-free transfers / correctly display the fee on any transfer a party is proposing. @@ -270,13 +270,13 @@ message CancelTransfer { - The transfer fee discount is correctly applied with network parameter`transfer.feeDiscountDecay`(0057-TRAN-014) - The fee-free transfer amount is accessible while API (0057-TRAN-017) - 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 (when `transfer amount * transfer.fee.factor > transfer.fee.maxQuantumAmount * quantum`). (0057-TRAN-011) - - The fee cost is correctly calculated using the network parameter + - 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 - The transfer fee discount is correctly applied with network parameter`transfer.feeDiscountDecay`(0057-TRAN-015) - The fee-free transfer amount is accessible while API (0057-TRAN-018) - - When transfer fee discount amount is less than `M x quantum` (M is network parameter `transfer.feeDiscountMinimumTrackedAmount`), then no tranfer fee discount will be applied (0057-TRAN-016) + - When transfer fee discount amount is less than `M x quantum` (M is network parameter `transfer.feeDiscountMinimumTrackedAmount`), then no transfer fee discount will be applied (0057-TRAN-016) - As a user I can do a transfer from a vested account to a general account held by the same key without incurring any fees (0057-TRAN-066). - If a user transfers funds from their vested account to any valid account other than their general account for that asset, they will incur fees. This includes accounts not owned by the user. (0057-TRAN-069). - As a user, I **can not** transfer a quantum amount less than `transfer.minTransferQuantumAmount` from any of the valid accounts excluding a vested account (0057-TRAN-067). From 4e5a4b6c66d1218d872e9a8f80591e23e6ee3f27 Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Mon, 13 Nov 2023 15:34:10 +0000 Subject: [PATCH 0752/1171] chore: remove redundant AC --- protocol/features.json | 1 - 1 file changed, 1 deletion(-) diff --git a/protocol/features.json b/protocol/features.json index 7b200517b..ae110109a 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -152,7 +152,6 @@ "acs": [ "0057-TRAN-011", "0057-TRAN-012", - "0057-TRAN-013", "0057-TRAN-014", "0057-TRAN-015", "0057-TRAN-016", From a99af6801a0a561726c76147fc6ffd7b290126cb Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Wed, 15 Nov 2023 15:08:30 +0000 Subject: [PATCH 0753/1171] feat: address comments --- protocol/0057-TRAN-transfers.md | 51 +++++++++++++++++++++------------ protocol/features.json | 10 +++++++ 2 files changed, 43 insertions(+), 18 deletions(-) diff --git a/protocol/0057-TRAN-transfers.md b/protocol/0057-TRAN-transfers.md index 576a8d25b..fbf922578 100644 --- a/protocol/0057-TRAN-transfers.md +++ b/protocol/0057-TRAN-transfers.md @@ -159,7 +159,7 @@ A fee is taken from all transfers (except transfers from a vested account to a g The fee is determined by the `transfer.fee.factor` and is subject to a cap defined by the multiplier `transfer.fee.maxQuantumAmount` as specified in the network parameters, which governs the proportion of each transfer taken as a fee. -As such, the transfer fee value used will be: `min(transfer amount * transfer.fee.factor, transfer.fee.maxQuantumAmount * quantum)`, `quantum` is for asset +As such, the transfer fee value used will be: `min(transfer amount x transfer.fee.factor, transfer.fee.maxQuantumAmount x quantum)`, `quantum` is for asset 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-fees.md#collecting-and-distributing-fees). Fees are charged in the asset that is being transferred. @@ -249,34 +249,47 @@ message CancelTransfer { | `transfer.feeDiscountMinimumTrackedAmount` | String (decimal) | greater than or equal to `0` | `"0.001"` | The lower bound of transfer fee tracked | | `transfer.feeDiscountDecay` | String (decimal) | greater than or equal to `0` and strictly less than `1` | `"0.5"` | The speed of cumulated trading fees decay for the purpose of being used to do transfer-fee-free transfers | - ## Acceptance criteria ### 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-PALAZZO-003). +- As a user I can transfer funds from a general account I control to a 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) - 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 (when `transfer amount * transfer.fee.factor <= transfer.fee.maxQuantumAmount * quantum`). (0057-TRAN-007) - - The fee cost is correctly calculated using the network parameter +- 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 (when `transfer amount x transfer.fee.factor <= transfer.fee.maxQuantumAmount x quantum`). (0057-TRAN-007) + - The fee cost is correctly calculated using the network parameters listed above. - 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 + - The fees are being paid into the infrastructure pool. - The transfer fee discount is correctly applied with network parameter`transfer.feeDiscountDecay`(0057-TRAN-014) - The fee-free transfer amount is accessible while API (0057-TRAN-017) -- 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 (when `transfer amount * transfer.fee.factor > transfer.fee.maxQuantumAmount * quantum`). (0057-TRAN-011) - - The fee cost is correctly calculated using the network parameter +- 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 (when `transfer amount x transfer.fee.factor > transfer.fee.maxQuantumAmount x quantum`). (0057-TRAN-011) + - The fee cost is correctly calculated using the network parameters listed above. - 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 - - The transfer fee discount is correctly applied with network parameter`transfer.feeDiscountDecay`(0057-TRAN-015) + - The fees are being paid into the infrastructure pool. + - The transfer fee discount is correctly applied with network parameter `transfer.feeDiscountDecay` (0057-TRAN-015) - The fee-free transfer amount is accessible while API (0057-TRAN-018) - - When transfer fee discount amount is less than `M x quantum` (M is network parameter `transfer.feeDiscountMinimumTrackedAmount`), then no transfer fee discount will be applied (0057-TRAN-016) +- when a party makes a transfer and fee-free discount is `c = 0`, then the full transfer fee amount is paid (0057-TRAN-016) + - The fee cost is correctly calculated using the network parameter `transfer.fee.factor`. + - 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. +- when a party paid ticker fee `g` in previous epoch, and `transfer.feeDiscountDecay = 0.9`, then in the next epoch when a party (did not generate any fees) makes a transfer and the theoretical fee the party should pay is `f`, fee-free amount is then `c = 0.9 x g`. If `c > f`, then no transfer fee is paid (0057-TRAN-019) +- when a party made maker fee `g` in previous epoch, and `transfer.feeDiscountDecay = 0.9`, then in the next epoch when a party (did not generate any fees) makes a transfer and the theoretical fee the party should pay is `f`, fee-free amount is then `c = 0.9 x g`. If `c > f`, then no transfer fee is paid (0057-TRAN-020) +- when a party paid ticker fee `g` in previous epoch, and `transfer.feeDiscountDecay = 0.9`, then in the next epoch when a party (did not generate any fees) makes a transfer and the theoretical fee the party should pay is `f`, fee-free amount is then `c = 0.9 x g`. If `c > f`, then no transfer fee is paid. And a party makes another transfer, and the theoretical fee the party should pay is `f`, then the party is not getting any fee-free discount(0057-TRAN-021) +- when a party made maker fee `g` in previous epoch, and `transfer.feeDiscountDecay = 0.9`, then in the next epoch when a party (did not generate any fees) makes a transfer and the theoretical fee the party should pay is `f`, fee-free amount is then `c = 0.9 x g`. If `c > f`, then no transfer fee is paid. And a party makes another transfer, and the theoretical fee the party should pay is `f`, then the party is not getting any fee-free discount(0057-TRAN-022) +- when a party paid ticker fee `f` in previous epoch, and `transfer.feeDiscountDecay = 0.9`, then in 3 epochs the fee-free discount amount would be `c = 0.9^3 x f`, when a party makes a transfer and the theoretical fee the party should pay is `f1`, and `f1 <= 0.729 x f`, then no amount is paid for transfer (0057-TRAN-023) +- when a party received maker fee `f` in previous epoch, and `transfer.feeDiscountDecay = 0.9`, then in 3 epochs the fee-free discount amount would be `c = 0.9^3 x f`, when a party makes a transfer and the theoretical fee the party should pay is `f1`, and `f1 <= 0.729 x f`, then no amount is paid for transfer (0057-TRAN-024) +- when a party paid ticker fee `f` in previous epoch, and `transfer.feeDiscountDecay = 0.01`, then in 4 epochs the fee-free discount amount would be `c = 0.01^4 x f`, when a party makes a transfer and the theoretical fee the party should pay is `f1`, and `c < transfer.feeDiscountMinimumTrackedAmount`, then no fee-free discount and transfer fee `f1` is paid (0057-TRAN-025) +- when a party received maker fee `f` in previous epoch, and `transfer.feeDiscountDecay = 0.01`, then in 4 epochs the fee-free discount amount would be `c = 0.01^4 x f`, when a party makes a transfer and the theoretical fee the party should pay is `f1`, and `c < transfer.feeDiscountMinimumTrackedAmount`, then no fee-free discount and transfer fee `f1` is paid (0057-TRAN-026) +- when a party makes a transfer and `f` would be the theoretical fee the party should pay then the fee on the transfer that is actually charged is `-min(f-c,0)`. The system subsequently updates `c <- max(0,c-f)`. At the end of epoch, update `c <- c x D` and `c <- c + all_trading_fees_for_trades_involved_in`, if `c < M x quantum`(M is `transfer.feeDiscountMinimumTrackedAmount`), then set `c <- 0` (0057-TRAN-027) +- when a party makes a transfer and `f` would be the theoretical fee the party should pay then the fee on the transfer that is actually charged is `-min(f-c,0)`. The system subsequently updates `c <- max(0,c-f)`. At the end of epoch, update `c <- c x D` and `c <- c + all_trading_fees_for_trades_involved_in`, if `c < M x quantum`(M is `transfer.feeDiscountMinimumTrackedAmount`), then set `c <- 0` (0057-TRAN-028) - As a user I can do a transfer from a vested account to a general account held by the same key without incurring any fees (0057-TRAN-066). - If a user transfers funds from their vested account to any valid account other than their general account for that asset, they will incur fees. This includes accounts not owned by the user. (0057-TRAN-069). - As a user, I **can not** transfer a quantum amount less than `transfer.minTransferQuantumAmount` from any of the valid accounts excluding a vested account (0057-TRAN-067). @@ -288,6 +301,7 @@ message CancelTransfer { - 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) - As a user, I can accumulate the fees I collect over an epoch. When I initiate a transfer that incurs a transfer fee, I have the ability to view the amount that is exempt from transfer fees through the API. (0057-TRAN-012) +- By setting `transfer.feeDiscountNumOfEpoch` to 3 epochs, you establish a time window spanning 3 consecutive epochs. During these 3 epochs, if you place market orders and subsequently initiate a transfer incurring a transfer fee, the 'free transfer amount' is calculated based on the cumulative fees collected over those same 3 epochs.(0057-TRAN-013) ### Recurring transfer tests @@ -298,21 +312,21 @@ As a user I can create a recurring transfer _which expires after a specified epo - 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) when `start amount * transfer.fee.factor <= transfer.fee.maxQuantumAmount * quantum` +As a user I can create a recurring transfer _that decreases over time_ (0057-TRAN-051) when `start amount x transfer.fee.factor <= transfer.fee.maxQuantumAmount x quantum` - I specify a start and end epoch, and a factor of `0.7` - Until the start epoch is reached not transfers are executed -- Once I reach the start epoch transfers happen and the first transfer is for the `start amount`. The fee amount taken from the source account is `min(start amount * transfer.fee.factor, transfer.fee.maxQuantumAmount * quantum)` and transferred to the infrastructure fee account for the asset. -- The transfer at end of `start epoch + 1` is `0.7 x start amount` and the fee amount is `0.7 x start amount * transfer.fee.factor`. +- Once I reach the start epoch transfers happen and the first transfer is for the `start amount`. The fee amount taken from the source account is `min(start amount x transfer.fee.factor, transfer.fee.maxQuantumAmount x quantum)` and transferred to the infrastructure fee account for the asset. +- The transfer at end of `start epoch + 1` is `0.7 x start amount` and the fee amount is `0.7 x start amount x transfer.fee.factor`. - The amount transferred every epoch decreases. - After I reach the epoch `?`, no transfers are executed anymore -As a user I can create a recurring transfer _that decreases over time_ (0057-TRAN-065) when `start amount * transfer.fee.factor > transfer.fee.maxQuantumAmount * quantum` +As a user I can create a recurring transfer _that decreases over time_ (0057-TRAN-065) when `start amount x transfer.fee.factor > transfer.fee.maxQuantumAmount x quantum` - I specify a start and end epoch, and a factor of `0.7` - Until the start epoch is reached not transfers are executed -- Once I reach the start epoch transfers happen and the first transfer is for the `start amount`. The fee amount taken from the source account is `min(start amount * transfer.fee.factor, transfer.fee.maxQuantumAmount * quantum)` and transferred to the infrastructure fee account for the asset. -- The transfer at end of `start epoch + 1` is `0.7 x start amount` and the fee amount is `0.7 x transfer.fee.maxQuantumAmount * quantum`. +- Once I reach the start epoch transfers happen and the first transfer is for the `start amount`. The fee amount taken from the source account is `min(start amount x transfer.fee.factor, transfer.fee.maxQuantumAmount x quantum)` and transferred to the infrastructure fee account for the asset. +- The transfer at end of `start epoch + 1` is `0.7 x start amount` and the fee amount is `0.7 x transfer.fee.maxQuantumAmount x quantum`. - The amount transferred every epoch decreases. - After I reach the epoch `?`, no transfers are executed anymore @@ -363,7 +377,7 @@ A user's recurring transfer to a reward account does not occur if there are no p - The value of `marketCreationQuantumMultiple` is `10^6` and `quantum` for `USDT` is `1`. - I specify a start and no end epoch, and a factor of 1 to a reward account `ETHUSDT | market creation | $VEGA` - In the first epoch no trading occurs and nothing is transferred to the reward account at the end of the epoch -- In the second epoch, 2 * 10^6 trading occurs, and at the end of the epoch the transfer to the reward account occurs +- In the second epoch, 2 x 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.fee.factor` is modified, this modification is applied @@ -376,3 +390,4 @@ If the network parameter `spam.protection.maxUserTransfersPerEpoch` is modified, 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/features.json b/protocol/features.json index ae110109a..cad28187f 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -157,6 +157,16 @@ "0057-TRAN-016", "0057-TRAN-017", "0057-TRAN-018", + "0057-TRAN-019", + "0057-TRAN-020", + "0057-TRAN-021", + "0057-TRAN-022", + "0057-TRAN-023", + "0057-TRAN-024", + "0057-TRAN-025", + "0057-TRAN-026", + "0057-TRAN-027", + "0057-TRAN-028", "0057-TRAN-064", "0057-TRAN-065" ] From 3ea54527e59acd36cb3c4e0e25ed2ae221418b7e Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Wed, 15 Nov 2023 15:26:59 +0000 Subject: [PATCH 0754/1171] feat: remove redundant AC 013 --- protocol/0057-TRAN-transfers.md | 1 - 1 file changed, 1 deletion(-) diff --git a/protocol/0057-TRAN-transfers.md b/protocol/0057-TRAN-transfers.md index fbf922578..fcc01bc95 100644 --- a/protocol/0057-TRAN-transfers.md +++ b/protocol/0057-TRAN-transfers.md @@ -301,7 +301,6 @@ message CancelTransfer { - 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) - As a user, I can accumulate the fees I collect over an epoch. When I initiate a transfer that incurs a transfer fee, I have the ability to view the amount that is exempt from transfer fees through the API. (0057-TRAN-012) -- By setting `transfer.feeDiscountNumOfEpoch` to 3 epochs, you establish a time window spanning 3 consecutive epochs. During these 3 epochs, if you place market orders and subsequently initiate a transfer incurring a transfer fee, the 'free transfer amount' is calculated based on the cumulative fees collected over those same 3 epochs.(0057-TRAN-013) ### Recurring transfer tests From 44315322b2d9a73c222a32038d1e2732776ff889 Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Wed, 15 Nov 2023 15:37:45 +0000 Subject: [PATCH 0755/1171] feat: address comments --- 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 fcc01bc95..bfd26345b 100644 --- a/protocol/0057-TRAN-transfers.md +++ b/protocol/0057-TRAN-transfers.md @@ -267,14 +267,14 @@ message CancelTransfer { - 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. - The transfer fee discount is correctly applied with network parameter`transfer.feeDiscountDecay`(0057-TRAN-014) - - The fee-free transfer amount is accessible while API (0057-TRAN-017) + - The fee-free transfer amount is accessible through the API (0057-TRAN-017) - 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 (when `transfer amount x transfer.fee.factor > transfer.fee.maxQuantumAmount x quantum`). (0057-TRAN-011) - The fee cost is correctly calculated using the network parameters listed above. - 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. - The transfer fee discount is correctly applied with network parameter `transfer.feeDiscountDecay` (0057-TRAN-015) - - The fee-free transfer amount is accessible while API (0057-TRAN-018) + - The fee-free transfer amount is accessible through the API (0057-TRAN-018) - when a party makes a transfer and fee-free discount is `c = 0`, then the full transfer fee amount is paid (0057-TRAN-016) - The fee cost is correctly calculated using the network parameter `transfer.fee.factor`. - If I have enough funds to pay transfer and fees, the transfer happens. From 3d79843a09d36f6d93a7fd98a7b1c92a91c21434 Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Wed, 15 Nov 2023 15:53:06 +0000 Subject: [PATCH 0756/1171] feat: remove duplicated ACs --- protocol/0057-TRAN-transfers.md | 8 +++----- 1 file changed, 3 insertions(+), 5 deletions(-) diff --git a/protocol/0057-TRAN-transfers.md b/protocol/0057-TRAN-transfers.md index bfd26345b..22b5509f5 100644 --- a/protocol/0057-TRAN-transfers.md +++ b/protocol/0057-TRAN-transfers.md @@ -280,14 +280,12 @@ message CancelTransfer { - 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. -- when a party paid ticker fee `g` in previous epoch, and `transfer.feeDiscountDecay = 0.9`, then in the next epoch when a party (did not generate any fees) makes a transfer and the theoretical fee the party should pay is `f`, fee-free amount is then `c = 0.9 x g`. If `c > f`, then no transfer fee is paid (0057-TRAN-019) +- when a party paid taker fee `g` in previous epoch, and `transfer.feeDiscountDecay = 0.9`, then in the next epoch when a party (did not generate any fees) makes a transfer and the theoretical fee the party should pay is `f`, fee-free amount is then `c = 0.9 x g`. If `c > f`, then no transfer fee is paid (0057-TRAN-019) - when a party made maker fee `g` in previous epoch, and `transfer.feeDiscountDecay = 0.9`, then in the next epoch when a party (did not generate any fees) makes a transfer and the theoretical fee the party should pay is `f`, fee-free amount is then `c = 0.9 x g`. If `c > f`, then no transfer fee is paid (0057-TRAN-020) -- when a party paid ticker fee `g` in previous epoch, and `transfer.feeDiscountDecay = 0.9`, then in the next epoch when a party (did not generate any fees) makes a transfer and the theoretical fee the party should pay is `f`, fee-free amount is then `c = 0.9 x g`. If `c > f`, then no transfer fee is paid. And a party makes another transfer, and the theoretical fee the party should pay is `f`, then the party is not getting any fee-free discount(0057-TRAN-021) +- when a party paid taker fee `g` in previous epoch, and `transfer.feeDiscountDecay = 0.9`, then in the next epoch when a party (did not generate any fees) makes a transfer and the theoretical fee the party should pay is `f`, fee-free amount is then `c = 0.9 x g`. If `c > f`, then no transfer fee is paid. And a party makes another transfer, and the theoretical fee the party should pay is `f`, then the party is not getting any fee-free discount(0057-TRAN-021) - when a party made maker fee `g` in previous epoch, and `transfer.feeDiscountDecay = 0.9`, then in the next epoch when a party (did not generate any fees) makes a transfer and the theoretical fee the party should pay is `f`, fee-free amount is then `c = 0.9 x g`. If `c > f`, then no transfer fee is paid. And a party makes another transfer, and the theoretical fee the party should pay is `f`, then the party is not getting any fee-free discount(0057-TRAN-022) -- when a party paid ticker fee `f` in previous epoch, and `transfer.feeDiscountDecay = 0.9`, then in 3 epochs the fee-free discount amount would be `c = 0.9^3 x f`, when a party makes a transfer and the theoretical fee the party should pay is `f1`, and `f1 <= 0.729 x f`, then no amount is paid for transfer (0057-TRAN-023) +- when a party paid taker fee `f` in previous epoch, and `transfer.feeDiscountDecay = 0.9`, then in 3 epochs the fee-free discount amount would be `c = 0.9^3 x f`, when a party makes a transfer and the theoretical fee the party should pay is `f1`, and `f1 <= 0.729 x f`, then no amount is paid for transfer (0057-TRAN-023) - when a party received maker fee `f` in previous epoch, and `transfer.feeDiscountDecay = 0.9`, then in 3 epochs the fee-free discount amount would be `c = 0.9^3 x f`, when a party makes a transfer and the theoretical fee the party should pay is `f1`, and `f1 <= 0.729 x f`, then no amount is paid for transfer (0057-TRAN-024) -- when a party paid ticker fee `f` in previous epoch, and `transfer.feeDiscountDecay = 0.01`, then in 4 epochs the fee-free discount amount would be `c = 0.01^4 x f`, when a party makes a transfer and the theoretical fee the party should pay is `f1`, and `c < transfer.feeDiscountMinimumTrackedAmount`, then no fee-free discount and transfer fee `f1` is paid (0057-TRAN-025) -- when a party received maker fee `f` in previous epoch, and `transfer.feeDiscountDecay = 0.01`, then in 4 epochs the fee-free discount amount would be `c = 0.01^4 x f`, when a party makes a transfer and the theoretical fee the party should pay is `f1`, and `c < transfer.feeDiscountMinimumTrackedAmount`, then no fee-free discount and transfer fee `f1` is paid (0057-TRAN-026) - when a party makes a transfer and `f` would be the theoretical fee the party should pay then the fee on the transfer that is actually charged is `-min(f-c,0)`. The system subsequently updates `c <- max(0,c-f)`. At the end of epoch, update `c <- c x D` and `c <- c + all_trading_fees_for_trades_involved_in`, if `c < M x quantum`(M is `transfer.feeDiscountMinimumTrackedAmount`), then set `c <- 0` (0057-TRAN-027) - when a party makes a transfer and `f` would be the theoretical fee the party should pay then the fee on the transfer that is actually charged is `-min(f-c,0)`. The system subsequently updates `c <- max(0,c-f)`. At the end of epoch, update `c <- c x D` and `c <- c + all_trading_fees_for_trades_involved_in`, if `c < M x quantum`(M is `transfer.feeDiscountMinimumTrackedAmount`), then set `c <- 0` (0057-TRAN-028) - As a user I can do a transfer from a vested account to a general account held by the same key without incurring any fees (0057-TRAN-066). From c69b4003bb57b20b4804b556e0050fb2a91e2ee8 Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Wed, 15 Nov 2023 15:53:24 +0000 Subject: [PATCH 0757/1171] feat: remove duplicated ACs --- protocol/features.json | 2 -- 1 file changed, 2 deletions(-) diff --git a/protocol/features.json b/protocol/features.json index cad28187f..c98b0399e 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -163,8 +163,6 @@ "0057-TRAN-022", "0057-TRAN-023", "0057-TRAN-024", - "0057-TRAN-025", - "0057-TRAN-026", "0057-TRAN-027", "0057-TRAN-028", "0057-TRAN-064", From 18ebda9fbf9e3bce82586a8463198da601d5add1 Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Thu, 16 Nov 2023 09:55:42 +0000 Subject: [PATCH 0758/1171] feat: rename network parameter FeeDiscountDecay --- protocol/0057-TRAN-transfers.md | 20 ++++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/protocol/0057-TRAN-transfers.md b/protocol/0057-TRAN-transfers.md index 22b5509f5..4336f0595 100644 --- a/protocol/0057-TRAN-transfers.md +++ b/protocol/0057-TRAN-transfers.md @@ -168,7 +168,7 @@ Fee are primarily a spam-protection mechanism, so for accounts generating "usefu ### Transfer fee discounts -Let `D` stand for `transfer.feeDiscountDecay`. This is a network parameter that specifies the how cumulated trading fees decay for the purpose of being used to do transfer-fee-free transfers. Minimum value is `0`, maximum value is any decimal strictly less than `1` and default it `0.5`. +Let `D` stand for `transfer.feeDiscountDecayFraction`. This is a network parameter that specifies the how cumulated trading fees decay for the purpose of being used to do transfer-fee-free transfers. Minimum value is `0`, maximum value is any decimal strictly less than `1` and default it `0.5`. Let `M` stand for network parameter `transfer.feeDiscountMinimumTrackedAmount`. Minimum value is `0`, there is no maximum beyond that dictated by the data type used and the default is `0.001`. For each party and for each asset store the an amount which tracks all trading fees paid and received by the party with transfer fees subtracted and the amount decayed as specified below. @@ -247,7 +247,7 @@ message CancelTransfer { | `transfer.fee.factor` | String (decimal) | in `[0.0,1.0]` | `"0.001"` | The proportion of the transfer charged as a fee | | `transfer.fee.maxQuantumAmount` | String (decimal) | greater than or equal to `0` | `"100"` | The cap of the transfer fee | | `transfer.feeDiscountMinimumTrackedAmount` | String (decimal) | greater than or equal to `0` | `"0.001"` | The lower bound of transfer fee tracked | -| `transfer.feeDiscountDecay` | String (decimal) | greater than or equal to `0` and strictly less than `1` | `"0.5"` | The speed of cumulated trading fees decay for the purpose of being used to do transfer-fee-free transfers | +| `transfer.feeDiscountDecayFraction` | String (decimal) | greater than or equal to `0` and strictly less than `1` | `"0.5"` | The speed of cumulated trading fees decay for the purpose of being used to do transfer-fee-free transfers | ## Acceptance criteria @@ -266,26 +266,26 @@ message CancelTransfer { - 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. - - The transfer fee discount is correctly applied with network parameter`transfer.feeDiscountDecay`(0057-TRAN-014) + - The transfer fee discount is correctly applied with network parameter`transfer.feeDiscountDecayFraction`(0057-TRAN-014) - The fee-free transfer amount is accessible through the API (0057-TRAN-017) - 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 (when `transfer amount x transfer.fee.factor > transfer.fee.maxQuantumAmount x quantum`). (0057-TRAN-011) - The fee cost is correctly calculated using the network parameters listed above. - 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. - - The transfer fee discount is correctly applied with network parameter `transfer.feeDiscountDecay` (0057-TRAN-015) + - The transfer fee discount is correctly applied with network parameter `transfer.feeDiscountDecayFraction` (0057-TRAN-015) - The fee-free transfer amount is accessible through the API (0057-TRAN-018) - when a party makes a transfer and fee-free discount is `c = 0`, then the full transfer fee amount is paid (0057-TRAN-016) - The fee cost is correctly calculated using the network parameter `transfer.fee.factor`. - 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. -- when a party paid taker fee `g` in previous epoch, and `transfer.feeDiscountDecay = 0.9`, then in the next epoch when a party (did not generate any fees) makes a transfer and the theoretical fee the party should pay is `f`, fee-free amount is then `c = 0.9 x g`. If `c > f`, then no transfer fee is paid (0057-TRAN-019) -- when a party made maker fee `g` in previous epoch, and `transfer.feeDiscountDecay = 0.9`, then in the next epoch when a party (did not generate any fees) makes a transfer and the theoretical fee the party should pay is `f`, fee-free amount is then `c = 0.9 x g`. If `c > f`, then no transfer fee is paid (0057-TRAN-020) -- when a party paid taker fee `g` in previous epoch, and `transfer.feeDiscountDecay = 0.9`, then in the next epoch when a party (did not generate any fees) makes a transfer and the theoretical fee the party should pay is `f`, fee-free amount is then `c = 0.9 x g`. If `c > f`, then no transfer fee is paid. And a party makes another transfer, and the theoretical fee the party should pay is `f`, then the party is not getting any fee-free discount(0057-TRAN-021) -- when a party made maker fee `g` in previous epoch, and `transfer.feeDiscountDecay = 0.9`, then in the next epoch when a party (did not generate any fees) makes a transfer and the theoretical fee the party should pay is `f`, fee-free amount is then `c = 0.9 x g`. If `c > f`, then no transfer fee is paid. And a party makes another transfer, and the theoretical fee the party should pay is `f`, then the party is not getting any fee-free discount(0057-TRAN-022) -- when a party paid taker fee `f` in previous epoch, and `transfer.feeDiscountDecay = 0.9`, then in 3 epochs the fee-free discount amount would be `c = 0.9^3 x f`, when a party makes a transfer and the theoretical fee the party should pay is `f1`, and `f1 <= 0.729 x f`, then no amount is paid for transfer (0057-TRAN-023) -- when a party received maker fee `f` in previous epoch, and `transfer.feeDiscountDecay = 0.9`, then in 3 epochs the fee-free discount amount would be `c = 0.9^3 x f`, when a party makes a transfer and the theoretical fee the party should pay is `f1`, and `f1 <= 0.729 x f`, then no amount is paid for transfer (0057-TRAN-024) +- when a party paid taker fee `g` in previous epoch, and `transfer.feeDiscountDecayFraction = 0.9`, then in the next epoch when a party (did not generate any fees) makes a transfer and the theoretical fee the party should pay is `f`, fee-free amount is then `c = 0.9 x g`. If `c > f`, then no transfer fee is paid (0057-TRAN-019) +- when a party made maker fee `g` in previous epoch, and `transfer.feeDiscountDecayFraction = 0.9`, then in the next epoch when a party (did not generate any fees) makes a transfer and the theoretical fee the party should pay is `f`, fee-free amount is then `c = 0.9 x g`. If `c > f`, then no transfer fee is paid (0057-TRAN-020) +- when a party paid taker fee `g` in previous epoch, and `transfer.feeDiscountDecayFraction = 0.9`, then in the next epoch when a party (did not generate any fees) makes a transfer and the theoretical fee the party should pay is `f`, fee-free amount is then `c = 0.9 x g`. If `c > f`, then no transfer fee is paid. And a party makes another transfer, and the theoretical fee the party should pay is `f`, then the party is not getting any fee-free discount(0057-TRAN-021) +- when a party made maker fee `g` in previous epoch, and `transfer.feeDiscountDecayFraction = 0.9`, then in the next epoch when a party (did not generate any fees) makes a transfer and the theoretical fee the party should pay is `f`, fee-free amount is then `c = 0.9 x g`. If `c > f`, then no transfer fee is paid. And a party makes another transfer, and the theoretical fee the party should pay is `f`, then the party is not getting any fee-free discount(0057-TRAN-022) +- when a party paid taker fee `f` in previous epoch, and `transfer.feeDiscountDecayFraction = 0.9`, then in 3 epochs the fee-free discount amount would be `c = 0.9^3 x f`, when a party makes a transfer and the theoretical fee the party should pay is `f1`, and `f1 <= 0.729 x f`, then no amount is paid for transfer (0057-TRAN-023) +- when a party received maker fee `f` in previous epoch, and `transfer.feeDiscountDecayFraction = 0.9`, then in 3 epochs the fee-free discount amount would be `c = 0.9^3 x f`, when a party makes a transfer and the theoretical fee the party should pay is `f1`, and `f1 <= 0.729 x f`, then no amount is paid for transfer (0057-TRAN-024) - when a party makes a transfer and `f` would be the theoretical fee the party should pay then the fee on the transfer that is actually charged is `-min(f-c,0)`. The system subsequently updates `c <- max(0,c-f)`. At the end of epoch, update `c <- c x D` and `c <- c + all_trading_fees_for_trades_involved_in`, if `c < M x quantum`(M is `transfer.feeDiscountMinimumTrackedAmount`), then set `c <- 0` (0057-TRAN-027) - when a party makes a transfer and `f` would be the theoretical fee the party should pay then the fee on the transfer that is actually charged is `-min(f-c,0)`. The system subsequently updates `c <- max(0,c-f)`. At the end of epoch, update `c <- c x D` and `c <- c + all_trading_fees_for_trades_involved_in`, if `c < M x quantum`(M is `transfer.feeDiscountMinimumTrackedAmount`), then set `c <- 0` (0057-TRAN-028) - As a user I can do a transfer from a vested account to a general account held by the same key without incurring any fees (0057-TRAN-066). From 3cbcd8e7232895552ad3b6639cb1ef8b6c63ad31 Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Mon, 20 Nov 2023 12:07:19 +0000 Subject: [PATCH 0759/1171] feat: add governance proposal change market name --- 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 55f83e9c0..db9d7d9bc 100644 --- a/protocol/0028-GOVE-governance.md +++ b/protocol/0028-GOVE-governance.md @@ -248,9 +248,8 @@ The following are immutable and cannot be changed: - market decimal places - position decimal places - `settlementAsset` -- name -## 3. Change network parameters +## 3 Change network parameters [Network parameters](./0054-NETP-network_parameters.md) that may be changed are described in the _Network Parameters_ spec, this document for details on these parameters, including the category of the parameters. New network parameters require a code change, so there is no support for adding new network parameters. @@ -547,6 +546,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 market change proposal that's to modify the market name on a market in any state 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-159) - 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 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) From 02b0419736b3e5e25cabe5b49365cb0364914147 Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Mon, 20 Nov 2023 12:09:04 +0000 Subject: [PATCH 0760/1171] chore: typo --- 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 db9d7d9bc..3a767fdeb 100644 --- a/protocol/0028-GOVE-governance.md +++ b/protocol/0028-GOVE-governance.md @@ -249,7 +249,7 @@ The following are immutable and cannot be changed: - position decimal places - `settlementAsset` -## 3 Change network parameters +## 3. Change network parameters [Network parameters](./0054-NETP-network_parameters.md) that may be changed are described in the _Network Parameters_ spec, this document for details on these parameters, including the category of the parameters. New network parameters require a code change, so there is no support for adding new network parameters. From 4926e9024dfd4b2e1ee8315a3f26c38ec9bc8dbd Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Mon, 20 Nov 2023 13:41:45 +0000 Subject: [PATCH 0761/1171] feat: address comments --- protocol/0028-GOVE-governance.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/protocol/0028-GOVE-governance.md b/protocol/0028-GOVE-governance.md index 3a767fdeb..3c6dd68d3 100644 --- a/protocol/0028-GOVE-governance.md +++ b/protocol/0028-GOVE-governance.md @@ -257,7 +257,7 @@ All _change network parameter proposals_ have their validation configured by the ## 4.1 Add a new asset -New [assets](./0040-ASSF-asset_framework.md) can be proposed through the governance system. The procedure is covered in detail in the [asset proposal spec](./0027-ASSP-asset_proposal.md)). +New [assets](./0040-ASSF-asset_framework.md) can be proposed through the governance system. The procedure is covered in detail in the [asset proposal spec](./0027-ASSP-asset_proposal.md). All new asset proposals have their validation configured by the network parameters `governance.proposal.asset.`. ## 4.2 Modify an existing asset @@ -546,7 +546,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 market change proposal that's to modify the market name on a market in any state 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-159) +- A market change proposal that's to modify the market name on a market in any state will modity the market name at vote enactment time (0028-GOVE-159) +- A market change proposal that's to modify the market code on a market in any state will modity the market code at vote enactment time (0028-GOVE-166) - 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 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) From 7a3e3801c1ed2cf94e3878fd3c9abd40e7aaca6e Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Mon, 20 Nov 2023 13:50:12 +0000 Subject: [PATCH 0762/1171] feat: typo --- 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 3c6dd68d3..0649406e4 100644 --- a/protocol/0028-GOVE-governance.md +++ b/protocol/0028-GOVE-governance.md @@ -546,8 +546,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 market change proposal that's to modify the market name on a market in any state will modity the market name at vote enactment time (0028-GOVE-159) -- A market change proposal that's to modify the market code on a market in any state will modity the market code at vote enactment time (0028-GOVE-166) +- A market change proposal that aims to modify the market name in any state will modify the market name at the time of vote enactment. (0028-GOVE-159) +- A market change proposal that aims to modify the market code in any state will modify the market code at the time of vote enactment. (0028-GOVE-166) - 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 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) From 0240eaeb4ee31a2f2a7ac7f8f666e8826bea1eba Mon Sep 17 00:00:00 2001 From: Gordsport <83510148+gordsport@users.noreply.github.com> Date: Mon, 20 Nov 2023 15:53:08 +0000 Subject: [PATCH 0763/1171] chore: add ACs to features file for overnance proposal market name --- protocol/features.json | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/protocol/features.json b/protocol/features.json index b159375a6..d26718cc8 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -199,6 +199,13 @@ "0042-LIQF-058" ] }, + "Governance market name change": { + "milestone": "palazzo", + "acs": [ + "0028-GOVE-159", + "0028-GOVE-166" + ] + }, "Unknown": { "milestone": "unknown", "acs": [ ] From e14bc7f973c0583defa8ef3d42fd330ed6b69878 Mon Sep 17 00:00:00 2001 From: Jiajia-Cui <92106936+Jiajia-Cui@users.noreply.github.com> Date: Wed, 22 Nov 2023 11:23:30 +0000 Subject: [PATCH 0764/1171] Insurance pools of closed / settled markets to go to on - chain treasury (#2065) * feat: insurance pool redistribution * feat: add more updates * chore: markdown * chore: remove old AC * feat: address comments Co-authored-by: David Siska <62546419+davidsiska-vega@users.noreply.github.com> * feat: address comments Co-authored-by: David Siska <62546419+davidsiska-vega@users.noreply.github.com> * feat: address comments * feat: update spec 0015 * chore: markdown * chore: typo --------- Co-authored-by: David Siska <62546419+davidsiska-vega@users.noreply.github.com> --- protocol/0002-STTL-settlement.md | 13 +++++++------ protocol/0013-ACCT-accounts.md | 6 +++--- ...15-INSR-market_insurance_pool_collateral.md | 4 ++-- protocol/0043-MKTL-market_lifecycle.md | 12 ++++++------ protocol/0073-LIMN-limited_network_life.md | 6 +++--- protocol/0081-SUCM-successor_markets.md | 10 +++++----- protocol/features.json | 18 ++++++++++++++++-- 7 files changed, 42 insertions(+), 27 deletions(-) diff --git a/protocol/0002-STTL-settlement.md b/protocol/0002-STTL-settlement.md index fc6458f63..07f8a2e88 100644 --- a/protocol/0002-STTL-settlement.md +++ b/protocol/0002-STTL-settlement.md @@ -68,7 +68,7 @@ The [market lifecycle spec](./0043-MKTL-market_lifecycle.md) provides detail on - 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 (0002-STTL-011) 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) @@ -79,12 +79,12 @@ 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) equally between the global insurance pool and the insurance pools of the remaining active markets using the same settlement asset. +1. The market's [insurance pool balance is transferred](./0015-INSR-market_insurance_pool_collateral.md) into the global insurance pool 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) -### 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 (0002-STTL-012) 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) @@ -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) equally between the global insurance pool and the insurance pools of the remaining active markets using the same settlement asset. +1. The [market's insurance pool](./0015-INSR-market_insurance_pool_collateral.md) balance is transferred into the global insurance pool 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) @@ -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-013) 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. @@ -124,6 +124,7 @@ 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) equally between the global insurance pool and the insurance pools of the remaining active markets using the same settlement asset. +1. The [market's insurance pool](./0015-INSR-market_insurance_pool_collateral.md) balance is transferred into the global insurance pool 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/0013-ACCT-accounts.md b/protocol/0013-ACCT-accounts.md index dcb70b47f..8e98dc4ec 100644 --- a/protocol/0013-ACCT-accounts.md +++ b/protocol/0013-ACCT-accounts.md @@ -4,7 +4,7 @@ A party only has control over balances in the "general" account for each asset. [Parties](./0017-PART-party.md) are identified by Vega public keys. Each party that makes a deposit on one of the asset bridges, currently only [Ethereum ERC20 bridge](./0031-ETHB-ethereum_bridge_spec.md) will have a general account for the relevant [asset](./0040-ASSF-asset_framework.md) created. -In order to submit [orders](./0014-ORDT-order_types.md a non-zero general account balance is needed; Vega will transfer appropriate amount to the [margin account](./0011-MARA-check_order_allocate_margin.md) for the party and the market. +In order to submit [orders](./0014-ORDT-order_types.md) a non-zero general account balance is needed; Vega will transfer appropriate amount to the [margin account](./0011-MARA-check_order_allocate_margin.md) for the party and the market. Any party can submit a withdrawal transaction to withdraw assets from the general account to a specified address on another chain, currently only [Ethereum ERC20 bridge](./0031-ETHB-ethereum_bridge_spec.md). @@ -85,7 +85,7 @@ 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 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. +When a market is finalised / closed remaining funds are transferred into the global insurance pool using the same settlement asset. This occurs using ledger entries to preserve double entry accounting records within the collateral engine. ## General insurance pool @@ -159,7 +159,7 @@ Additional accounts associated with [distribution](./0056-REWA-rewards_overview. - 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 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) +- When a market terminates and settles (the final settlement cashflow happens), the insurance pool account has its outstanding balance transferred to the global insurance pool account for the appropriate asset (if it doesn't exist create it), other insurance pools using the same asset will not get the outstanding funds. (0013-ACCT-033) ### 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 be3dee548..34677e201 100644 --- a/protocol/0015-INSR-market_insurance_pool_collateral.md +++ b/protocol/0015-INSR-market_insurance_pool_collateral.md @@ -14,7 +14,7 @@ When a market is finalised / closed remaining funds are distributed equally amon ## 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). +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 all the funds from market's insurance pool upon its closure. 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. @@ -23,6 +23,6 @@ Funds can only be withdrawn from the global insurance pool via a [governance ini ## 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) +- 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 transferred to the on-chain treasury for the settlement asset of the market. For markets that have a named successor market the appropriate fraction of the insurance pool balance is transferred to the insurance pool of the successor market. (0015-INSR-005) - 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/0043-MKTL-market_lifecycle.md b/protocol/0043-MKTL-market_lifecycle.md index 7f34a1f62..04ee9d0f1 100644 --- a/protocol/0043-MKTL-market_lifecycle.md +++ b/protocol/0043-MKTL-market_lifecycle.md @@ -106,7 +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 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 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. +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](./0015-INSR-market_insurance_pool_collateral.md) balance should get transferred into the global insurance pool 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. @@ -218,7 +218,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 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. +- [Insurance pool funds](./0015-INSR-market_insurance_pool_collateral.md) are transferred (after window for successor creation elapsed) into the global insurance pool using the same settlement asset. For markets that have a named successor market the appropriate fraction of 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:** @@ -278,7 +278,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) equally between the global insurance pool and the insurance pools of the remaining active markets using the same settlement asset. +After `market.liquidity.successorLaunchWindowLength` has passed since market settlement, any [insurance pool](./0015-INSR-market_insurance_pool_collateral.md) balance is transferred into the global insurance pool using the same settlement asset. ### Lifecycle happy path in Spot market (0043-MKTL-006) @@ -316,15 +316,15 @@ 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) equally between the global insurance pool and the insurance pools of the remaining active markets using the same settlement asset. +After `market.liquidity.successorLaunchWindowLength` has passed since market settlement, any [insurance pool](./0015-INSR-market_insurance_pool_collateral.md) balance is transferred into the global insurance pool using the same settlement asset. -### Market never leaves opening auction, trading terminated triggered, market cancelled (0043-MKTL-003) +### Market never leaves opening auction, trading terminated triggered, market cancelled (0043-MKTL-010) 1. A market is proposed, approved by governance process and enters the opening auction (Pending state). 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) equally between the global insurance pool and the insurance pools of the remaining active markets using the same settlement asset. +1. After `market.liquidity.successorLaunchWindowLength` has elapsed since market cancellation, any insurance pool balance should be transferred into the global insurance pool 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/0073-LIMN-limited_network_life.md b/protocol/0073-LIMN-limited_network_life.md index 9756a7031..c65072ccd 100644 --- a/protocol/0073-LIMN-limited_network_life.md +++ b/protocol/0073-LIMN-limited_network_life.md @@ -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 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 insurance pool balance has been transferred into the global insurance pool using the same settlement asset. (0073-LIMN-115) 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 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 insurance pool balance has been transferred into the global insurance pool using the same settlement asset. (0073-LIMN-116) 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 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 insurance pool balance has been transferred into the global insurance pool using the same settlement asset. (0073-LIMN-117) 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 eb9bc26b5..bd6ca2718 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, global insurance pool). +Moreover, part of the insurance pool of a parent market can be earmarked for transfer to the successor market instead of being transferred into the global insurance pool. ## Relevant network / market parameters @@ -76,9 +76,9 @@ 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 the global insurance pool and all markets with the same settlement asset, including those markets which are still in opening auction (0081-SUCM-035) +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 transferred into the global insurance pool (0081-SUCM-036) -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 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: 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) @@ -107,7 +107,7 @@ When fetching a market that is part of a "parent / successor chain", we should s ### 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 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) @@ -117,7 +117,7 @@ A market which has been settled, and already has a child which has succeeded it, 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) +After snapshot restart the successor (child) / parent market state is preserved where applicable including 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) diff --git a/protocol/features.json b/protocol/features.json index d26718cc8..06dec2808 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -8,8 +8,7 @@ "Successor Markets": { "milestone": "cosmic-carryover", "acs": [ - "0001-MKTF-008", - "0081-SUCM-035" + "0001-MKTF-008" ] }, "Ethereum oracles": { @@ -206,6 +205,21 @@ "0028-GOVE-166" ] }, + "Insurance pools redistribution": { + "milestone": "palazzo", + "acs": [ + "0002-STTL-011", + "0002-STTL-012", + "0002-STTL-013", + "0013-ACCT-033", + "0015-INSR-005", + "0043-MKTL-010", + "0073-LIMN-115", + "0073-LIMN-116", + "0073-LIMN-117", + "0081-SUCM-036" + ] + }, "Unknown": { "milestone": "unknown", "acs": [ ] From f4c7af5a6f8a71501dfbd6920ffad2edfc9bdf1e Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Thu, 23 Nov 2023 14:41:58 +0000 Subject: [PATCH 0765/1171] feat: add more ACs to isolated margin --- protocol/0019-MCAL-margin_calculator.md | 8 ++++---- protocol/features.json | 3 ++- 2 files changed, 6 insertions(+), 5 deletions(-) diff --git a/protocol/0019-MCAL-margin_calculator.md b/protocol/0019-MCAL-margin_calculator.md index 61ab47442..389fc54b4 100644 --- a/protocol/0019-MCAL-margin_calculator.md +++ b/protocol/0019-MCAL-margin_calculator.md @@ -93,13 +93,13 @@ sell 1 @ 100 000 sell 10 @ 100 100 ``` + when switching to isolated-margin mode and the `margin factor short = 0.11`, the maintenance margin should be updated to `average entry price x current position x new margin factor = 57500 x 1 x 0.11 = 6325`, the switching will be rejected. (0019-MCAL-032) - then the maintenance margin (under cross-margin mode) for the party is `min(1 x (100000-15900), 15900 x 0.25 x 1) + 0.1 x 1 x 15900 = 5565`, and margin account should have initial margin level which is `5565 x 1.5 = 8348`. - when switching to isolated-margin mode and the `margin factor short = 0.3`, the maintenance margin should be updated to `average entry price x current position x new margin factor = 57500 x 1 x 0.3 = 17250`, and margin account should be updated to `17250`. (0019-MCAL-031) + when switching to isolated-margin mode and the `margin factor short = 0.9`, the maintenance margin should be updated to `average entry price x current position x new margin factor = 15900 x 1 x 0.9 = 14310`, and margin account should be updated to `14310`. (0019-MCAL-033) - when switching to isolated-margin mode and the `margin factor short = 0.11`, the maintenance margin should be updated to `average entry price x current position x new margin factor = 57500 x 1 x 0.11 = 6325`, the switching will be rejected. (0019-MCAL-032) + when decreasing the `margin factor short` from `0.9` to `0.7`, the maintenance margin should be updated to `average entry price x current position x new margin factor = 15900 x 1 x 0.7 = 11130`, and margin account should be updated to `11130`. (0019-MCAL-031) - when switching to isolated-margin mode and the `margin factor short = 0.3`, the maintenance margin should be updated to `average entry price x current position x new margin factor = 57500 x 1 x 0.3 = 17250`, and margin account should be updated to `17250`. (0019-MCAL-033) + when increasing the `margin factor short` from `0.7` to `0.9`, the maintenance margin should be updated to `average entry price x current position x new margin factor = 15900 x 1 x 0.9 = 14310`, and margin account should be updated to `14310`. (0019-MCAL-059) - When the party place a new short order of `1` with price `15000`, and the market is in continuous trading. diff --git a/protocol/features.json b/protocol/features.json index 06dec2808..1c83ac15e 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -109,7 +109,8 @@ "0019-MCAL-055", "0019-MCAL-056", "0019-MCAL-057", - "0019-MCAL-058" + "0019-MCAL-058", + "0019-MCAL-059" ] }, "Quadratic slippage removal": { From ee0f896f41ab3aa7b0ae5e2a8e716637a6883474 Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Thu, 23 Nov 2023 15:06:04 +0000 Subject: [PATCH 0766/1171] chore: markdown --- protocol/0019-MCAL-margin_calculator.md | 1 + 1 file changed, 1 insertion(+) diff --git a/protocol/0019-MCAL-margin_calculator.md b/protocol/0019-MCAL-margin_calculator.md index 389fc54b4..46c11a787 100644 --- a/protocol/0019-MCAL-margin_calculator.md +++ b/protocol/0019-MCAL-margin_calculator.md @@ -93,6 +93,7 @@ sell 1 @ 100 000 sell 10 @ 100 100 ``` + when switching to isolated-margin mode and the `margin factor short = 0.11`, the maintenance margin should be updated to `average entry price x current position x new margin factor = 57500 x 1 x 0.11 = 6325`, the switching will be rejected. (0019-MCAL-032) when switching to isolated-margin mode and the `margin factor short = 0.9`, the maintenance margin should be updated to `average entry price x current position x new margin factor = 15900 x 1 x 0.9 = 14310`, and margin account should be updated to `14310`. (0019-MCAL-033) From 44a0e3c9aa24fa9d16a31b559793e8c7c3e43d50 Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Thu, 23 Nov 2023 15:15:17 +0000 Subject: [PATCH 0767/1171] chore: markdown --- protocol/0019-MCAL-margin_calculator.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0019-MCAL-margin_calculator.md b/protocol/0019-MCAL-margin_calculator.md index 46c11a787..0f5a01847 100644 --- a/protocol/0019-MCAL-margin_calculator.md +++ b/protocol/0019-MCAL-margin_calculator.md @@ -93,7 +93,7 @@ sell 1 @ 100 000 sell 10 @ 100 100 ``` - + when switching to isolated-margin mode and the `margin factor short = 0.11`, the maintenance margin should be updated to `average entry price x current position x new margin factor = 57500 x 1 x 0.11 = 6325`, the switching will be rejected. (0019-MCAL-032) when switching to isolated-margin mode and the `margin factor short = 0.9`, the maintenance margin should be updated to `average entry price x current position x new margin factor = 15900 x 1 x 0.9 = 14310`, and margin account should be updated to `14310`. (0019-MCAL-033) From f6e7a7d6e0ead1ff0399aff071bf6685b29390b9 Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Tue, 28 Nov 2023 09:11:55 +0000 Subject: [PATCH 0768/1171] feat: add more ACs --- protocol/0019-MCAL-margin_calculator.md | 39 +++++++++++++++++-------- protocol/features.json | 10 ++++++- 2 files changed, 36 insertions(+), 13 deletions(-) diff --git a/protocol/0019-MCAL-margin_calculator.md b/protocol/0019-MCAL-margin_calculator.md index 0f5a01847..fcf839697 100644 --- a/protocol/0019-MCAL-margin_calculator.md +++ b/protocol/0019-MCAL-margin_calculator.md @@ -94,29 +94,44 @@ sell 10 @ 100 100 ``` - when switching to isolated-margin mode and the `margin factor short = 0.11`, the maintenance margin should be updated to `average entry price x current position x new margin factor = 57500 x 1 x 0.11 = 6325`, the switching will be rejected. (0019-MCAL-032) + - when switching to isolated-margin mode and the `margin factor short = 0.11`, the maintenance margin should be updated to `average entry price x current position x new margin factor = 57500 x 1 x 0.11 = 6325`, the switching will be rejected. (0019-MCAL-032) - when switching to isolated-margin mode and the `margin factor short = 0.9`, the maintenance margin should be updated to `average entry price x current position x new margin factor = 15900 x 1 x 0.9 = 14310`, and margin account should be updated to `14310`. (0019-MCAL-033) + - when switching to isolated-margin mode and the `margin factor short = 0.9`, the maintenance margin should be updated to `average entry price x current position x new margin factor = 15900 x 1 x 0.9 = 14310`, and margin account should be updated to `14310`. (0019-MCAL-033) - when decreasing the `margin factor short` from `0.9` to `0.7`, the maintenance margin should be updated to `average entry price x current position x new margin factor = 15900 x 1 x 0.7 = 11130`, and margin account should be updated to `11130`. (0019-MCAL-031) + - when decreasing the `margin factor short` from `0.9` to `0.7`, the maintenance margin should be updated to `average entry price x current position x new margin factor = 15900 x 1 x 0.7 = 11130`, and margin account should be updated to `11130`. (0019-MCAL-031) - when increasing the `margin factor short` from `0.7` to `0.9`, the maintenance margin should be updated to `average entry price x current position x new margin factor = 15900 x 1 x 0.9 = 14310`, and margin account should be updated to `14310`. (0019-MCAL-059) + - when increasing the `margin factor short` from `0.7` to `0.9`, the maintenance margin should be updated to `average entry price x current position x new margin factor = 15900 x 1 x 0.9 = 14310`, and margin account should be updated to `14310`. (0019-MCAL-059) -- When the party place a new short order of `1` with price `15000`, and the market is in continuous trading. + - Switch to isolated margin mode will be rejected if the party does not have enough asset in the general account(0019-MCAL-066) - The margin account should have additional amount `average entry price x current position x new margin factor = 59524 x 1 x 0.3 = 17857` added if the party has enough asset in the general account(0019-MCAL-034) +- When the party place a new short order of `10` with price `15910` which does not offset the existing position, and the market is in continuous trading. - The order will be rejected if the party does not have enough asset in the general account (0019-MCAL-035) + - The margin account should have additional amount `limit price x size x margin factor = 15910 x 10 x 0.9 = 143190` transfered into "order margin" account if the party has enough asset in the general account(0019-MCAL-034) -- When the party place a new short order of `1` with price `45000`, and the market is in continuous trading. + - The order will be rejected if the party does not have enough asset in the general account (0019-MCAL-035) - The margin account should have additional amount `limit price * size * margin factor = 45000 x 1 x 0.3 = 13500` added if the party has enough asset in the general account(0019-MCAL-036) + - The party amend the order size to `5`, and the amount `limit price x size x margin factor = 15912 x 5 x 0.9 = 71604` will be transfered from "order margin" account into general account (0019-MCAL-060) - The order will be rejected if the party does not have enough asset in the general account(0019-MCAL-037) + - Another trader placed a buy order of `3` with price `15912`, party's position becomes `4`, party's margin account should be updated to `15912 x 4 x 0.9 =57283` and order margin should be `15912x 2 x 0.9 = 28642` (0019-MCAL-061) -- When the party place a new long order of `1` with price `145000` and the party has existing short position of `3`, and the market is in continuous trading. The margin account should not change(0019-MCAL-038) + - Switch margin mode from isolated margin to cross margin when party holds position only, the margin account should be updated to `average entry price x current position x new margin factor = 15900 x 1 x 0.9 = 14310` (0019-MCAL-065) -- When the party place a new long order of `10` with price `145000` and the party has existing short position of `3`, and the market is in continuous trading. The margin account should have additional amount `limit price * size * margin factor = 145000 x (10-3) x 0.3 = 304500` added if the party has enough asset in the general account(0019-MCAL-039) + - Switch from isolated margin to cross margin mode, the margin account is only updated in the next MTM (0019-MCAL-063) + + - Switch from cross margin to isolated margin mode, check both margin account and order margin are updated (0019-MCAL-064) + + - When the party has no orders, their order margin account should be `0` (0019-MCAL-062) + - Create some MTM, the margin account should be updated while order margin account should not (0019-MCAL-067) + +- When the party place a new long order of `2` with price `15912` which does offset the existing position, and the market is in continuous trading. + + - The margin account should not change as no additional margin is required (0019-MCAL-038) + + - When the party switch to cross margin mode, the margin accounts will not updated till nect MTM(0019-MCAL-036) + + - The order will be rejected if the party does not have enough asset in the general account(0019-MCAL-037) + + - When the party place a new long order of `10` with price `145000` and the party has existing short position of `3`, and the market is in continuous trading. The margin account should have additional amount `limit price * size * margin factor = 145000 x (10-3) x 0.3 = 304500` added if the party has enough asset in the general account(0019-MCAL-039) - Margin levels are correctly calculated in the case of an open position dropping below maintenance margin levels active orders will remain active as these are margined separately and will not be cancelled.(0019-MCAL-040) diff --git a/protocol/features.json b/protocol/features.json index 1c83ac15e..1c42f1fad 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -110,7 +110,15 @@ "0019-MCAL-056", "0019-MCAL-057", "0019-MCAL-058", - "0019-MCAL-059" + "0019-MCAL-059", + "0019-MCAL-060", + "0019-MCAL-061", + "0019-MCAL-062", + "0019-MCAL-063", + "0019-MCAL-064", + "0019-MCAL-065", + "0019-MCAL-066", + "0019-MCAL-067" ] }, "Quadratic slippage removal": { From 0b9a8af37b9571e2f656b2fcbc9c0cc66190e012 Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Tue, 28 Nov 2023 09:15:02 +0000 Subject: [PATCH 0769/1171] chore: markdown --- protocol/0019-MCAL-margin_calculator.md | 29 +++++++++++++------------ 1 file changed, 15 insertions(+), 14 deletions(-) diff --git a/protocol/0019-MCAL-margin_calculator.md b/protocol/0019-MCAL-margin_calculator.md index fcf839697..3ded29961 100644 --- a/protocol/0019-MCAL-margin_calculator.md +++ b/protocol/0019-MCAL-margin_calculator.md @@ -94,34 +94,35 @@ sell 10 @ 100 100 ``` - - when switching to isolated-margin mode and the `margin factor short = 0.11`, the maintenance margin should be updated to `average entry price x current position x new margin factor = 57500 x 1 x 0.11 = 6325`, the switching will be rejected. (0019-MCAL-032) + When switching to isolated-margin mode and the `margin factor short = 0.11`, the maintenance margin should be updated to `average entry price x current position x new margin factor = 57500 x 1 x 0.11 = 6325`, the switching will be rejected. (0019-MCAL-032) - - when switching to isolated-margin mode and the `margin factor short = 0.9`, the maintenance margin should be updated to `average entry price x current position x new margin factor = 15900 x 1 x 0.9 = 14310`, and margin account should be updated to `14310`. (0019-MCAL-033) + When switching to isolated-margin mode and the `margin factor short = 0.9`, the maintenance margin should be updated to `average entry price x current position x new margin factor = 15900 x 1 x 0.9 = 14310`, and margin account should be updated to `14310`. (0019-MCAL-033) - - when decreasing the `margin factor short` from `0.9` to `0.7`, the maintenance margin should be updated to `average entry price x current position x new margin factor = 15900 x 1 x 0.7 = 11130`, and margin account should be updated to `11130`. (0019-MCAL-031) + When decreasing the `margin factor short` from `0.9` to `0.7`, the maintenance margin should be updated to `average entry price x current position x new margin factor = 15900 x 1 x 0.7 = 11130`, and margin account should be updated to `11130`. (0019-MCAL-031) - - when increasing the `margin factor short` from `0.7` to `0.9`, the maintenance margin should be updated to `average entry price x current position x new margin factor = 15900 x 1 x 0.9 = 14310`, and margin account should be updated to `14310`. (0019-MCAL-059) + When increasing the `margin factor short` from `0.7` to `0.9`, the maintenance margin should be updated to `average entry price x current position x new margin factor = 15900 x 1 x 0.9 = 14310`, and margin account should be updated to `14310`. (0019-MCAL-059) - - Switch to isolated margin mode will be rejected if the party does not have enough asset in the general account(0019-MCAL-066) + Switch to isolated margin mode will be rejected if the party does not have enough asset in the general account(0019-MCAL-066) - When the party place a new short order of `10` with price `15910` which does not offset the existing position, and the market is in continuous trading. - - The margin account should have additional amount `limit price x size x margin factor = 15910 x 10 x 0.9 = 143190` transfered into "order margin" account if the party has enough asset in the general account(0019-MCAL-034) + The margin account should have additional amount `limit price x size x margin factor = 15910 x 10 x 0.9 = 143190` transfered into "order margin" account if the party has enough asset in the general account(0019-MCAL-034) - - The order will be rejected if the party does not have enough asset in the general account (0019-MCAL-035) + The order will be rejected if the party does not have enough asset in the general account (0019-MCAL-035) - - The party amend the order size to `5`, and the amount `limit price x size x margin factor = 15912 x 5 x 0.9 = 71604` will be transfered from "order margin" account into general account (0019-MCAL-060) + The party amend the order size to `5`, and the amount `limit price x size x margin factor = 15912 x 5 x 0.9 = 71604` will be transfered from "order margin" account into general account (0019-MCAL-060) - - Another trader placed a buy order of `3` with price `15912`, party's position becomes `4`, party's margin account should be updated to `15912 x 4 x 0.9 =57283` and order margin should be `15912x 2 x 0.9 = 28642` (0019-MCAL-061) + Another trader placed a buy order of `3` with price `15912`, party's position becomes `4`, party's margin account should be updated to `15912 x 4 x 0.9 =57283` and order margin should be `15912x 2 x 0.9 = 28642` (0019-MCAL-061) - - Switch margin mode from isolated margin to cross margin when party holds position only, the margin account should be updated to `average entry price x current position x new margin factor = 15900 x 1 x 0.9 = 14310` (0019-MCAL-065) + Switch margin mode from isolated margin to cross margin when party holds position only, the margin account should be updated to `average entry price x current position x new margin factor = 15900 x 1 x 0.9 = 14310` (0019-MCAL-065) - - Switch from isolated margin to cross margin mode, the margin account is only updated in the next MTM (0019-MCAL-063) + Switch from isolated margin to cross margin mode, the margin account is only updated in the next MTM (0019-MCAL-063) - - Switch from cross margin to isolated margin mode, check both margin account and order margin are updated (0019-MCAL-064) + Switch from cross margin to isolated margin mode, check both margin account and order margin are updated (0019-MCAL-064) - - When the party has no orders, their order margin account should be `0` (0019-MCAL-062) - - Create some MTM, the margin account should be updated while order margin account should not (0019-MCAL-067) + When the party has no orders, their order margin account should be `0` (0019-MCAL-062) + + Create some MTM, the margin account should be updated while order margin account should not (0019-MCAL-067) - When the party place a new long order of `2` with price `15912` which does offset the existing position, and the market is in continuous trading. From 81840f2169b9d5b03693334de7531879df272017 Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Tue, 28 Nov 2023 09:16:45 +0000 Subject: [PATCH 0770/1171] chore: markdown --- protocol/0019-MCAL-margin_calculator.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0019-MCAL-margin_calculator.md b/protocol/0019-MCAL-margin_calculator.md index 3ded29961..79bc4b795 100644 --- a/protocol/0019-MCAL-margin_calculator.md +++ b/protocol/0019-MCAL-margin_calculator.md @@ -121,7 +121,7 @@ Switch from cross margin to isolated margin mode, check both margin account and order margin are updated (0019-MCAL-064) When the party has no orders, their order margin account should be `0` (0019-MCAL-062) - + Create some MTM, the margin account should be updated while order margin account should not (0019-MCAL-067) - When the party place a new long order of `2` with price `15912` which does offset the existing position, and the market is in continuous trading. From f931448bcb42cb6a6fa2dcefbafe27d1a6147454 Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Tue, 28 Nov 2023 09:21:33 +0000 Subject: [PATCH 0771/1171] chore: typo --- protocol/0019-MCAL-margin_calculator.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/protocol/0019-MCAL-margin_calculator.md b/protocol/0019-MCAL-margin_calculator.md index 79bc4b795..e814c862c 100644 --- a/protocol/0019-MCAL-margin_calculator.md +++ b/protocol/0019-MCAL-margin_calculator.md @@ -106,11 +106,11 @@ - When the party place a new short order of `10` with price `15910` which does not offset the existing position, and the market is in continuous trading. - The margin account should have additional amount `limit price x size x margin factor = 15910 x 10 x 0.9 = 143190` transfered into "order margin" account if the party has enough asset in the general account(0019-MCAL-034) + The margin account should have additional amount `limit price x size x margin factor = 15910 x 10 x 0.9 = 143190` transferred into "order margin" account if the party has enough asset in the general account(0019-MCAL-034) The order will be rejected if the party does not have enough asset in the general account (0019-MCAL-035) - The party amend the order size to `5`, and the amount `limit price x size x margin factor = 15912 x 5 x 0.9 = 71604` will be transfered from "order margin" account into general account (0019-MCAL-060) + The party amend the order size to `5`, and the amount `limit price x size x margin factor = 15912 x 5 x 0.9 = 71604` will be transferred from "order margin" account into general account (0019-MCAL-060) Another trader placed a buy order of `3` with price `15912`, party's position becomes `4`, party's margin account should be updated to `15912 x 4 x 0.9 =57283` and order margin should be `15912x 2 x 0.9 = 28642` (0019-MCAL-061) @@ -128,7 +128,7 @@ - The margin account should not change as no additional margin is required (0019-MCAL-038) - - When the party switch to cross margin mode, the margin accounts will not updated till nect MTM(0019-MCAL-036) + - When the party switch to cross margin mode, the margin accounts will not updated till next MTM(0019-MCAL-036) - The order will be rejected if the party does not have enough asset in the general account(0019-MCAL-037) From 310af14e79c238d7a825fe9a29bdc57deb475d5d Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Tue, 28 Nov 2023 10:48:04 +0000 Subject: [PATCH 0772/1171] feat: address comments --- protocol/0019-MCAL-margin_calculator.md | 20 +++++++++----------- protocol/features.json | 1 - 2 files changed, 9 insertions(+), 12 deletions(-) diff --git a/protocol/0019-MCAL-margin_calculator.md b/protocol/0019-MCAL-margin_calculator.md index e814c862c..59252b579 100644 --- a/protocol/0019-MCAL-margin_calculator.md +++ b/protocol/0019-MCAL-margin_calculator.md @@ -102,37 +102,35 @@ When increasing the `margin factor short` from `0.7` to `0.9`, the maintenance margin should be updated to `average entry price x current position x new margin factor = 15900 x 1 x 0.9 = 14310`, and margin account should be updated to `14310`. (0019-MCAL-059) - Switch to isolated margin mode will be rejected if the party does not have enough asset in the general account(0019-MCAL-066) + Switching to isolated margin mode will be rejected if the party does not have enough asset in the general account(0019-MCAL-066) -- When the party place a new short order of `10` with price `15910` which does not offset the existing position, and the market is in continuous trading. +- When the party places a new short order of `10` with price `15910` which does not offset the existing position, and the market is in continuous trading. The margin account should have additional amount `limit price x size x margin factor = 15910 x 10 x 0.9 = 143190` transferred into "order margin" account if the party has enough asset in the general account(0019-MCAL-034) The order will be rejected if the party does not have enough asset in the general account (0019-MCAL-035) - The party amend the order size to `5`, and the amount `limit price x size x margin factor = 15912 x 5 x 0.9 = 71604` will be transferred from "order margin" account into general account (0019-MCAL-060) + The party amends the order size to `5`, and the amount `limit price x size x margin factor = 15912 x 5 x 0.9 = 71604` will be transferred from "order margin" account into general account (0019-MCAL-060) - Another trader placed a buy order of `3` with price `15912`, party's position becomes `4`, party's margin account should be updated to `15912 x 4 x 0.9 =57283` and order margin should be `15912x 2 x 0.9 = 28642` (0019-MCAL-061) + Another trader places a buy order of `3` with price `15912`, party's position becomes `4`, party's margin account should be updated to `15912 x 4 x 0.9 =57283` and order margin should be `15912x 2 x 0.9 = 28642` (0019-MCAL-061) - Switch margin mode from isolated margin to cross margin when party holds position only, the margin account should be updated to `average entry price x current position x new margin factor = 15900 x 1 x 0.9 = 14310` (0019-MCAL-065) + Switch margin mode from isolated margin to cross margin when party holds position only, the margin account should be updated to intial margin level in cross margin mode(0019-MCAL-065) - Switch from isolated margin to cross margin mode, the margin account is only updated in the next MTM (0019-MCAL-063) - - Switch from cross margin to isolated margin mode, check both margin account and order margin are updated (0019-MCAL-064) + Switch from cross margin to isolated margin mode, both margin account and order margin should be updated (0019-MCAL-064) When the party has no orders, their order margin account should be `0` (0019-MCAL-062) Create some MTM, the margin account should be updated while order margin account should not (0019-MCAL-067) -- When the party place a new long order of `2` with price `15912` which does offset the existing position, and the market is in continuous trading. +- When the party places a new long order of `2` with price `15912` which does offset the existing position, and the market is in continuous trading. - The margin account should not change as no additional margin is required (0019-MCAL-038) - - When the party switch to cross margin mode, the margin accounts will not updated till next MTM(0019-MCAL-036) + - When the party switches to cross margin mode, the margin accounts will not be updated untill the next MTM(0019-MCAL-036) - The order will be rejected if the party does not have enough asset in the general account(0019-MCAL-037) - - When the party place a new long order of `10` with price `145000` and the party has existing short position of `3`, and the market is in continuous trading. The margin account should have additional amount `limit price * size * margin factor = 145000 x (10-3) x 0.3 = 304500` added if the party has enough asset in the general account(0019-MCAL-039) + - When the party place a new long order of `10` with price `145000` and the party has existing short position of `3`, and the market is in continuous trading. The margin account should have additional amount `limit price * size * margin factor = 145000 x (10-3) x 0.9 = 913500` added if the party has enough asset in the general account(0019-MCAL-039) - Margin levels are correctly calculated in the case of an open position dropping below maintenance margin levels active orders will remain active as these are margined separately and will not be cancelled.(0019-MCAL-040) diff --git a/protocol/features.json b/protocol/features.json index 1c42f1fad..482f1a019 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -114,7 +114,6 @@ "0019-MCAL-060", "0019-MCAL-061", "0019-MCAL-062", - "0019-MCAL-063", "0019-MCAL-064", "0019-MCAL-065", "0019-MCAL-066", From 78c3026ea2843f5e2afe898e5a15d3730b5a71db Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Tue, 28 Nov 2023 11:00:39 +0000 Subject: [PATCH 0773/1171] chore: typo --- protocol/0019-MCAL-margin_calculator.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/protocol/0019-MCAL-margin_calculator.md b/protocol/0019-MCAL-margin_calculator.md index 59252b579..4563a1241 100644 --- a/protocol/0019-MCAL-margin_calculator.md +++ b/protocol/0019-MCAL-margin_calculator.md @@ -114,7 +114,7 @@ Another trader places a buy order of `3` with price `15912`, party's position becomes `4`, party's margin account should be updated to `15912 x 4 x 0.9 =57283` and order margin should be `15912x 2 x 0.9 = 28642` (0019-MCAL-061) - Switch margin mode from isolated margin to cross margin when party holds position only, the margin account should be updated to intial margin level in cross margin mode(0019-MCAL-065) + Switch margin mode from isolated margin to cross margin when party holds position only, the margin account should be updated to initial margin level in cross margin mode(0019-MCAL-065) Switch from cross margin to isolated margin mode, both margin account and order margin should be updated (0019-MCAL-064) @@ -126,7 +126,7 @@ - The margin account should not change as no additional margin is required (0019-MCAL-038) - - When the party switches to cross margin mode, the margin accounts will not be updated untill the next MTM(0019-MCAL-036) + - When the party switches to cross margin mode, the margin accounts will not be updated until the next MTM(0019-MCAL-036) - The order will be rejected if the party does not have enough asset in the general account(0019-MCAL-037) From 4f6a5dd0e91f4ac72486bc678d176f18cfcea281 Mon Sep 17 00:00:00 2001 From: Pete Barrow <62435083+peterbarrow@users.noreply.github.com> Date: Fri, 1 Dec 2023 16:02:36 +0000 Subject: [PATCH 0774/1171] Remove a duplicate AC (#2073) * fix: Removed duplicate AC * fix: Removed duplicate AC --- protocol/0057-TRAN-transfers.md | 1 - protocol/features.json | 5 ++--- 2 files changed, 2 insertions(+), 4 deletions(-) diff --git a/protocol/0057-TRAN-transfers.md b/protocol/0057-TRAN-transfers.md index 4336f0595..7592dcb74 100644 --- a/protocol/0057-TRAN-transfers.md +++ b/protocol/0057-TRAN-transfers.md @@ -287,7 +287,6 @@ message CancelTransfer { - when a party paid taker fee `f` in previous epoch, and `transfer.feeDiscountDecayFraction = 0.9`, then in 3 epochs the fee-free discount amount would be `c = 0.9^3 x f`, when a party makes a transfer and the theoretical fee the party should pay is `f1`, and `f1 <= 0.729 x f`, then no amount is paid for transfer (0057-TRAN-023) - when a party received maker fee `f` in previous epoch, and `transfer.feeDiscountDecayFraction = 0.9`, then in 3 epochs the fee-free discount amount would be `c = 0.9^3 x f`, when a party makes a transfer and the theoretical fee the party should pay is `f1`, and `f1 <= 0.729 x f`, then no amount is paid for transfer (0057-TRAN-024) - when a party makes a transfer and `f` would be the theoretical fee the party should pay then the fee on the transfer that is actually charged is `-min(f-c,0)`. The system subsequently updates `c <- max(0,c-f)`. At the end of epoch, update `c <- c x D` and `c <- c + all_trading_fees_for_trades_involved_in`, if `c < M x quantum`(M is `transfer.feeDiscountMinimumTrackedAmount`), then set `c <- 0` (0057-TRAN-027) -- when a party makes a transfer and `f` would be the theoretical fee the party should pay then the fee on the transfer that is actually charged is `-min(f-c,0)`. The system subsequently updates `c <- max(0,c-f)`. At the end of epoch, update `c <- c x D` and `c <- c + all_trading_fees_for_trades_involved_in`, if `c < M x quantum`(M is `transfer.feeDiscountMinimumTrackedAmount`), then set `c <- 0` (0057-TRAN-028) - As a user I can do a transfer from a vested account to a general account held by the same key without incurring any fees (0057-TRAN-066). - If a user transfers funds from their vested account to any valid account other than their general account for that asset, they will incur fees. This includes accounts not owned by the user. (0057-TRAN-069). - As a user, I **can not** transfer a quantum amount less than `transfer.minTransferQuantumAmount` from any of the valid accounts excluding a vested account (0057-TRAN-067). diff --git a/protocol/features.json b/protocol/features.json index 482f1a019..d92389b97 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -184,7 +184,6 @@ "0057-TRAN-023", "0057-TRAN-024", "0057-TRAN-027", - "0057-TRAN-028", "0057-TRAN-064", "0057-TRAN-065" ] @@ -230,6 +229,6 @@ }, "Unknown": { "milestone": "unknown", - "acs": [ ] + "acs": [] } -} +} \ No newline at end of file From aad410a8dae8b7859b6f9b1ae299b75fb50c250e Mon Sep 17 00:00:00 2001 From: Sohill-Patel <85170301+Sohill-Patel@users.noreply.github.com> Date: Mon, 27 Nov 2023 10:45:21 +0000 Subject: [PATCH 0775/1171] fix: formula in ac --- 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 06ff19756..730a81286 100644 --- a/protocol/0053-PERP-product_builtin_perpetual_future.md +++ b/protocol/0053-PERP-product_builtin_perpetual_future.md @@ -295,7 +295,7 @@ Assume the last known spot price before this funding period is `11`. Then assume Then, assuming no auctions during the period we get: $\text{internal TWAP}= \frac{10\cdot(1-0)+11\cdot(3-1)+10\cdot(5-3)+9\cdot(7-5)+8\cdot(9-7)+7\cdot(10-9)}{10}=9.3$, -$\text{external TWAP}=\frac{11\cdot(1-0)+9\cdot(3-1)+10\cdot(5-3)+12\cdot(6-5)+11\cdot(7-6)+8\cdot(9-7)+14\cdot(10-9)}{10}=10.3$. (0053-PERP-027) +$\text{external TWAP}=\frac{11\cdot(1-0)+9\cdot(3-1)+10\cdot(5-3)+12\cdot(6-5)+11\cdot(7-6)+8\cdot(9-7)+14\cdot(10-9)}{10}=10.2$. (0053-PERP-027) 1. Assume a 10 minute funding period. Assume a few funding periods have already passed for this market. Furthermore, assume that in this period that market is in an auction which starts 5 minutes into the period and ends 7 minutes into the period. @@ -320,7 +320,7 @@ Assume the last known spot price before this funding period is `11`. Then assume Then, taking the auction into account we get: $\text{internal TWAP}= \frac{10\cdot(1-0)+11\cdot(3-1)+10\cdot(5-3)+9\cdot(8-7)+8\cdot(10-8)+30\cdot(10-10)}{8}=9.625$, -$\text{external TWAP}=\frac{11\cdot(1-0)+9\cdot(3-1)+10\cdot(5-3)+11\cdot(8-7)+8\cdot(9-8)+14\cdot(10-9)}{10}=10.25$. (0053-PERP-028) +$\text{external TWAP}=\frac{11\cdot(1-0)+9\cdot(3-1)+10\cdot(5-3)+11\cdot(8-7)+8\cdot(9-8)+14\cdot(10-9)}{8}=10.25$. (0053-PERP-028) When $\text{clamp_lower_bound}=\text{clamp_upper_bound}=0$, $\text{scaling factor}=2.5$ and the funding period ends with $\text{internal TWAP}=99$, $\text{external TWAP} = 100$ then the resulting funding rate equals $-0.025$. (0053-PERP-029) From 533062f83216c8da602b06c4c3f1130c4e705e86 Mon Sep 17 00:00:00 2001 From: Sohill-Patel <85170301+Sohill-Patel@users.noreply.github.com> Date: Mon, 27 Nov 2023 11:33:06 +0000 Subject: [PATCH 0776/1171] fix: diff twap if auct was included --- 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 730a81286..e518b2486 100644 --- a/protocol/0053-PERP-product_builtin_perpetual_future.md +++ b/protocol/0053-PERP-product_builtin_perpetual_future.md @@ -303,7 +303,7 @@ Assume the last known mark price before the start of the period to be `10` and t | Time (min) since period start | mark price | | ----------------------------- | ----------- | | 1 | 11 | -| 3 | 10 | +| 3 | 11 | | 7 | 9 | | 8 | 8 | | 10 | 30 | @@ -313,13 +313,13 @@ Assume the last known spot price before this funding period is `11`. Then assume | ----------------------------- | ----------- | | 1 | 9 | | 3 | 10 | -| 5 | 12 | +| 5 | 30 | | 6 | 11 | | 8 | 8 | | 9 | 14 | Then, taking the auction into account we get: -$\text{internal TWAP}= \frac{10\cdot(1-0)+11\cdot(3-1)+10\cdot(5-3)+9\cdot(8-7)+8\cdot(10-8)+30\cdot(10-10)}{8}=9.625$, +$\text{internal TWAP}= \frac{10\cdot(1-0)+11\cdot(3-1)+11\cdot(5-3)+9\cdot(8-7)+8\cdot(10-8)+30\cdot(10-10)}{8}=9.875$, $\text{external TWAP}=\frac{11\cdot(1-0)+9\cdot(3-1)+10\cdot(5-3)+11\cdot(8-7)+8\cdot(9-8)+14\cdot(10-9)}{8}=10.25$. (0053-PERP-028) When $\text{clamp_lower_bound}=\text{clamp_upper_bound}=0$, $\text{scaling factor}=2.5$ and the funding period ends with $\text{internal TWAP}=99$, $\text{external TWAP} = 100$ then the resulting funding rate equals $-0.025$. (0053-PERP-029) From 173c3d3a20b7464f686e1c9f0a9cdcd47cb87c3a Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Thu, 30 Nov 2023 11:22:44 +0000 Subject: [PATCH 0777/1171] feat: tidy up and add more ACS --- protocol/0019-MCAL-margin_calculator.md | 75 ++++++++++++++++++++----- 1 file changed, 61 insertions(+), 14 deletions(-) diff --git a/protocol/0019-MCAL-margin_calculator.md b/protocol/0019-MCAL-margin_calculator.md index 4563a1241..6022eff8b 100644 --- a/protocol/0019-MCAL-margin_calculator.md +++ b/protocol/0019-MCAL-margin_calculator.md @@ -82,7 +82,9 @@ - Thus, with `margin funding factor = 0.5`, `total margin requirement = futures margin + funding margin = 5565 + 0.5 * max(0, -90 * 1) = 5565` (0019-MCAL-028) - However is position is instead `-1`, with the same margin requirement, if `margin funding factor = 0.5`, `total margin requirement = futures margin + funding margin = 5565 + 0.5 * max(0, -90 * -1) = 5610`(0019-MCAL-029) -## Acceptance Criteria (under Isolated-margin modes) +## Acceptance Criteria (Isolated-margin) + +**When party has a newly created short position:** - If a party has a newly created short position of `1` and the mark price is `15 900` and `market.linearSlippageFactor = 0.25`, `RF short = 0.1` and `Initial margin factor = 1.5` and order book is @@ -104,6 +106,8 @@ Switching to isolated margin mode will be rejected if the party does not have enough asset in the general account(0019-MCAL-066) +**When party has a position and a order which does not offset the position:** + - When the party places a new short order of `10` with price `15910` which does not offset the existing position, and the market is in continuous trading. The margin account should have additional amount `limit price x size x margin factor = 15910 x 10 x 0.9 = 143190` transferred into "order margin" account if the party has enough asset in the general account(0019-MCAL-034) @@ -122,39 +126,81 @@ Create some MTM, the margin account should be updated while order margin account should not (0019-MCAL-067) -- When the party places a new long order of `2` with price `15912` which does offset the existing position, and the market is in continuous trading. +**Amending order:** + + - When the party cancels the order, the order magin should be `0`(0019-MCAL-041) + + - When the party reduces the order size only, the order magin should be reduced (0019-MCAL-042) + - When the party reduces the order price only, the order magin should be reduced (0019-MCAL-043) + + - When the party increases the order size and the party's general account does not contain sufficient funds to cover any increases to the order margin account to be equal to side margin then the order should be stopped (0019-MCAL-044) + + - When the party increases the order price and the party's general account does not contain sufficient funds to cover any increases to the order margin account to be equal to side margin then the order should be stopped (0019-MCAL-045) + + - When the party increases the order size while decreases the order price and the party's general account does not contain sufficient funds to cover any increases to the order margin account to be equal to side margin then the order should be stopped (0019-MCAL-046) + + - When the party increases the order price while decreases the order price and the party's general account does not contain sufficient funds to cover any increases to the order margin account to be equal to side margin then the order should be stopped (0019-MCAL-047) + + - When the party's order is partially filled, the order margin and general margin should be updated accordingly (0019-MCAL-048) + + - When the party cancels the pegged order, the order magin should be `0`(0019-MCAL-049) + + - When the party reduces the pegged order size only, the order magin should be reduced (0019-MCAL-050) + + - When the party reduces the pegged order price only, the order magin should be reduced (0019-MCAL-042)(0019-MCAL-051) + + - When the party increases the pegged order size and the party's general account does not contain sufficient funds to cover any increases to the order margin account to be equal to side margin then the order should be stopped (0019-MCAL-052) + + - When the party increases the pegged order price and the party's general account does not contain sufficient funds to cover any increases to the order margin account to be equal to side margin then the order should be stopped (0019-MCAL-075) + + - When the party increases the pegged order size while decreases the order price and the party's general account does not contain sufficient funds to cover any increases to the order margin account to be equal to side margin then the order should be stopped (0019-MCAL-076) + + - When the party increases the pegged order price while decreases the order price and the party's general account does not contain sufficient funds to cover any increases to the order margin account to be equal to side margin then the order should be stopped (0019-MCAL-077) + + - When the party's pegged order is partially filled, the order margin and general margin should be updated accordingly (0019-MCAL-078) + +**When a party has a position and an order which offsets the position:** + +- When the party places a new long order of `2` with price `15912` which offsets the existing position, and the market is in continuous trading. - The margin account should not change as no additional margin is required (0019-MCAL-038) - - When the party switches to cross margin mode, the margin accounts will not be updated until the next MTM(0019-MCAL-036) + - When the party switches to cross margin mode, the margin accounts will not be updated until the next MTM (0019-MCAL-036) - - The order will be rejected if the party does not have enough asset in the general account(0019-MCAL-037) + - The order will be rejected if the party does not have enough asset in the general account (0019-MCAL-037) - When the party place a new long order of `10` with price `145000` and the party has existing short position of `3`, and the market is in continuous trading. The margin account should have additional amount `limit price * size * margin factor = 145000 x (10-3) x 0.9 = 913500` added if the party has enough asset in the general account(0019-MCAL-039) -- Margin levels are correctly calculated in the case of an open position dropping below maintenance margin levels active orders will remain active as these are margined separately and will not be cancelled.(0019-MCAL-040) + - When increasing the `margin factor` and the party does not have enough asset in the general account to cover the new maintenance margin, then the new margin factor will be rejected (0019-MCAL-040) -- Zero position and zero orders results in all zero margin levels. (0019-MCAL-041) +**When a party is distressed:** -- If a trader has a long position 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-042) +- Margin levels are correctly calculated in the case of an open position dropping below maintenance margin levels active orders will remain active as these are margined separately and will not be cancelled.(0019-MCAL-070) -- If a trader's `long position > 0 && 0 < *sum of volume of order book bids* < long position`, the `exit price` is equal to infinity. (0019-MCAL-043) +- When the party (who holds open positions and orders) gets distressed, orders will be canceled, if party is still distressed, clseout will be triggered(0019-MCAL-071) -- If a trader's `short position < 0 && 0 < *sum of absolute volume of order book offers* < short position`, the `exit price` is equal to infinity. (0019-MCAL-044) +- When the party (who holds open positions and bond account) gets closed out, the bond account will be emptied (0019-MCAL-072) -- If a trader's `long position > 0 && long position < *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-045) +- When the party (who holds open orders and bond account) gets distressed, the bond account will be emptied (0019-MCAL-073) -- If a trader's `short position < 0 && 0 < abs(short position) < *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-046) +- When the party is closeout, insurance pool should be updated accordingly (0019-MCAL-074) + +**When market is in auction mode:** + +- When the market is in auctions, switch from cross margin mode to isolated margin mode (0019-MCAL-080) + +- When the market is in auctions, switch from cross margin mode to isolated margin mode (0019-MCAL-081) + +**Check decimals:** - A feature test that checks margin in case market PDP > 0 is created and passes. (0019-MCAL-047) - A feature test that checks margin in case market PDP < 0 is created and passes. (0019-MCAL-057) +**Check decimals:** - For each market and each party which has either orders or positions on the market, the API provides the maintenance margin levels. (0019-MCAL-049) -- In the same situation as above, if `market.linearSlippageFactor = 100`, (i.e. 10 000%) instead, then the margin for the party is `min(1 x (100000-15900), 15900 x 100 x 1) + 0.1 x 1 x 15900 = 85690`. (0019-MCAL-051) - -- If the `market.linearSlippageFactor` 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-052) +## Acceptance Criteria (perpetural market) - 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.linearSlippageFactor = 0.25` and `RF long = 0.1` and order book is @@ -610,3 +656,4 @@ riskiest short: -1 ## SCENARIOS Scenarios found [here](https://docs.google.com/spreadsheets/d/1VXMdpgyyA9jp0hoWcIQTUFrhOdtu-fak/edit#gid=1586131462) + From ac3457366788a5ac81a4160ba8ba4adb1820577b Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Thu, 30 Nov 2023 11:26:03 +0000 Subject: [PATCH 0778/1171] chore: reorder --- protocol/0019-MCAL-margin_calculator.md | 30 ++++++++++++------------- 1 file changed, 15 insertions(+), 15 deletions(-) diff --git a/protocol/0019-MCAL-margin_calculator.md b/protocol/0019-MCAL-margin_calculator.md index 6022eff8b..083862305 100644 --- a/protocol/0019-MCAL-margin_calculator.md +++ b/protocol/0019-MCAL-margin_calculator.md @@ -1,6 +1,6 @@ # Margin Calculator -## Acceptance Criteria (under Cross-margin modes) +## Acceptance Criteria (Cross margin) - Get four margin levels for one or more parties (0019-MCAL-001) @@ -126,6 +126,20 @@ Create some MTM, the margin account should be updated while order margin account should not (0019-MCAL-067) +**When a party has a position and an order which offsets the position:** + +- When the party places a new long order of `2` with price `15912` which offsets the existing position, and the market is in continuous trading. + + - The margin account should not change as no additional margin is required (0019-MCAL-038) + + - When the party switches to cross margin mode, the margin accounts will not be updated until the next MTM (0019-MCAL-036) + + - The order will be rejected if the party does not have enough asset in the general account (0019-MCAL-037) + + - When the party place a new long order of `10` with price `145000` and the party has existing short position of `3`, and the market is in continuous trading. The margin account should have additional amount `limit price * size * margin factor = 145000 x (10-3) x 0.9 = 913500` added if the party has enough asset in the general account(0019-MCAL-039) + + - When increasing the `margin factor` and the party does not have enough asset in the general account to cover the new maintenance margin, then the new margin factor will be rejected (0019-MCAL-040) + **Amending order:** - When the party cancels the order, the order magin should be `0`(0019-MCAL-041) @@ -159,20 +173,6 @@ - When the party's pegged order is partially filled, the order margin and general margin should be updated accordingly (0019-MCAL-078) -**When a party has a position and an order which offsets the position:** - -- When the party places a new long order of `2` with price `15912` which offsets the existing position, and the market is in continuous trading. - - - The margin account should not change as no additional margin is required (0019-MCAL-038) - - - When the party switches to cross margin mode, the margin accounts will not be updated until the next MTM (0019-MCAL-036) - - - The order will be rejected if the party does not have enough asset in the general account (0019-MCAL-037) - - - When the party place a new long order of `10` with price `145000` and the party has existing short position of `3`, and the market is in continuous trading. The margin account should have additional amount `limit price * size * margin factor = 145000 x (10-3) x 0.9 = 913500` added if the party has enough asset in the general account(0019-MCAL-039) - - - When increasing the `margin factor` and the party does not have enough asset in the general account to cover the new maintenance margin, then the new margin factor will be rejected (0019-MCAL-040) - **When a party is distressed:** - Margin levels are correctly calculated in the case of an open position dropping below maintenance margin levels active orders will remain active as these are margined separately and will not be cancelled.(0019-MCAL-070) From cd3facfc5c0ef6a77b422293f35dabaabc95663b Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Thu, 30 Nov 2023 11:31:18 +0000 Subject: [PATCH 0779/1171] chore: format --- protocol/0019-MCAL-margin_calculator.md | 76 ++++++++++++------------- 1 file changed, 37 insertions(+), 39 deletions(-) diff --git a/protocol/0019-MCAL-margin_calculator.md b/protocol/0019-MCAL-margin_calculator.md index 083862305..3df5aa583 100644 --- a/protocol/0019-MCAL-margin_calculator.md +++ b/protocol/0019-MCAL-margin_calculator.md @@ -96,82 +96,80 @@ sell 10 @ 100 100 ``` - When switching to isolated-margin mode and the `margin factor short = 0.11`, the maintenance margin should be updated to `average entry price x current position x new margin factor = 57500 x 1 x 0.11 = 6325`, the switching will be rejected. (0019-MCAL-032) +- When switching to isolated-margin mode and the `margin factor short = 0.11`, the maintenance margin should be updated to `average entry price x current position x new margin factor = 57500 x 1 x 0.11 = 6325`, the switching will be rejected. (0019-MCAL-032) - When switching to isolated-margin mode and the `margin factor short = 0.9`, the maintenance margin should be updated to `average entry price x current position x new margin factor = 15900 x 1 x 0.9 = 14310`, and margin account should be updated to `14310`. (0019-MCAL-033) +- When switching to isolated-margin mode and the `margin factor short = 0.9`, the maintenance margin should be updated to `average entry price x current position x new margin factor = 15900 x 1 x 0.9 = 14310`, and margin account should be updated to `14310`. (0019-MCAL-033) - When decreasing the `margin factor short` from `0.9` to `0.7`, the maintenance margin should be updated to `average entry price x current position x new margin factor = 15900 x 1 x 0.7 = 11130`, and margin account should be updated to `11130`. (0019-MCAL-031) +- When decreasing the `margin factor short` from `0.9` to `0.7`, the maintenance margin should be updated to `average entry price x current position x new margin factor = 15900 x 1 x 0.7 = 11130`, and margin account should be updated to `11130`. (0019-MCAL-031) - When increasing the `margin factor short` from `0.7` to `0.9`, the maintenance margin should be updated to `average entry price x current position x new margin factor = 15900 x 1 x 0.9 = 14310`, and margin account should be updated to `14310`. (0019-MCAL-059) +- When increasing the `margin factor short` from `0.7` to `0.9`, the maintenance margin should be updated to `average entry price x current position x new margin factor = 15900 x 1 x 0.9 = 14310`, and margin account should be updated to `14310`. (0019-MCAL-059) - Switching to isolated margin mode will be rejected if the party does not have enough asset in the general account(0019-MCAL-066) +- Switching to isolated margin mode will be rejected if the party does not have enough asset in the general account(0019-MCAL-066) -**When party has a position and a order which does not offset the position:** +**When party has a position and an order which does not offset the position:** - When the party places a new short order of `10` with price `15910` which does not offset the existing position, and the market is in continuous trading. +The margin account should have additional amount `limit price x size x margin factor = 15910 x 10 x 0.9 = 143190` transferred into "order margin" account if the party has enough asset in the general account(0019-MCAL-034) - The margin account should have additional amount `limit price x size x margin factor = 15910 x 10 x 0.9 = 143190` transferred into "order margin" account if the party has enough asset in the general account(0019-MCAL-034) +- The order will be rejected if the party does not have enough asset in the general account (0019-MCAL-035) - The order will be rejected if the party does not have enough asset in the general account (0019-MCAL-035) +- The party amends the order size to `5`, and the amount `limit price x size x margin factor = 15912 x 5 x 0.9 = 71604` will be transferred from "order margin" account into general account (0019-MCAL-060) - The party amends the order size to `5`, and the amount `limit price x size x margin factor = 15912 x 5 x 0.9 = 71604` will be transferred from "order margin" account into general account (0019-MCAL-060) +- Another trader places a buy order of `3` with price `15912`, party's position becomes `4`, party's margin account should be updated to `15912 x 4 x 0.9 =57283` and order margin should be `15912x 2 x 0.9 = 28642` (0019-MCAL-061) - Another trader places a buy order of `3` with price `15912`, party's position becomes `4`, party's margin account should be updated to `15912 x 4 x 0.9 =57283` and order margin should be `15912x 2 x 0.9 = 28642` (0019-MCAL-061) +- Switch margin mode from isolated margin to cross margin when party holds position only, the margin account should be updated to initial margin level in cross margin mode(0019-MCAL-065) - Switch margin mode from isolated margin to cross margin when party holds position only, the margin account should be updated to initial margin level in cross margin mode(0019-MCAL-065) +- Switch from cross margin to isolated margin mode, both margin account and order margin should be updated (0019-MCAL-064) - Switch from cross margin to isolated margin mode, both margin account and order margin should be updated (0019-MCAL-064) +- When the party has no orders, their order margin account should be `0` (0019-MCAL-062) - When the party has no orders, their order margin account should be `0` (0019-MCAL-062) - - Create some MTM, the margin account should be updated while order margin account should not (0019-MCAL-067) +- Create some MTM, the margin account should be updated while order margin account should not (0019-MCAL-067) **When a party has a position and an order which offsets the position:** -- When the party places a new long order of `2` with price `15912` which offsets the existing position, and the market is in continuous trading. - - - The margin account should not change as no additional margin is required (0019-MCAL-038) +- When the party places a new long order of `2` with price `15912` which offsets the existing position, and the market is in continuous trading. The margin account should not change as no additional margin is required (0019-MCAL-038) - - When the party switches to cross margin mode, the margin accounts will not be updated until the next MTM (0019-MCAL-036) +- When the party switches to cross margin mode, the margin accounts will not be updated until the next MTM (0019-MCAL-036) - - The order will be rejected if the party does not have enough asset in the general account (0019-MCAL-037) +- The order will be rejected if the party does not have enough asset in the general account (0019-MCAL-037) - - When the party place a new long order of `10` with price `145000` and the party has existing short position of `3`, and the market is in continuous trading. The margin account should have additional amount `limit price * size * margin factor = 145000 x (10-3) x 0.9 = 913500` added if the party has enough asset in the general account(0019-MCAL-039) +- When the party place a new long order of `10` with price `145000` and the party has existing short position of `3`, and the market is in continuous trading. The margin account should have additional amount `limit price * size * margin factor = 145000 x (10-3) x 0.9 = 913500` added if the party has enough asset in the general account(0019-MCAL-039) - - When increasing the `margin factor` and the party does not have enough asset in the general account to cover the new maintenance margin, then the new margin factor will be rejected (0019-MCAL-040) +- When increasing the `margin factor` and the party does not have enough asset in the general account to cover the new maintenance margin, then the new margin factor will be rejected (0019-MCAL-040) **Amending order:** - - When the party cancels the order, the order magin should be `0`(0019-MCAL-041) +- When the party cancels the order, the order magin should be `0`(0019-MCAL-041) + +- When the party reduces the order size only, the order magin should be reduced (0019-MCAL-042) - - When the party reduces the order size only, the order magin should be reduced (0019-MCAL-042) - - When the party reduces the order price only, the order magin should be reduced (0019-MCAL-043) +- When the party reduces the order price only, the order magin should be reduced (0019-MCAL-043) - - When the party increases the order size and the party's general account does not contain sufficient funds to cover any increases to the order margin account to be equal to side margin then the order should be stopped (0019-MCAL-044) +- When the party increases the order size and the party's general account does not contain sufficient funds to cover any increases to the order margin account to be equal to side margin then the order should be stopped (0019-MCAL-044) - - When the party increases the order price and the party's general account does not contain sufficient funds to cover any increases to the order margin account to be equal to side margin then the order should be stopped (0019-MCAL-045) +- When the party increases the order price and the party's general account does not contain sufficient funds to cover any increases to the order margin account to be equal to side margin then the order should be stopped (0019-MCAL-045) - - When the party increases the order size while decreases the order price and the party's general account does not contain sufficient funds to cover any increases to the order margin account to be equal to side margin then the order should be stopped (0019-MCAL-046) +- When the party increases the order size while decreases the order price and the party's general account does not contain sufficient funds to cover any increases to the order margin account to be equal to side margin then the order should be stopped (0019-MCAL-046) - - When the party increases the order price while decreases the order price and the party's general account does not contain sufficient funds to cover any increases to the order margin account to be equal to side margin then the order should be stopped (0019-MCAL-047) +- When the party increases the order price while decreases the order price and the party's general account does not contain sufficient funds to cover any increases to the order margin account to be equal to side margin then the order should be stopped (0019-MCAL-047) - - When the party's order is partially filled, the order margin and general margin should be updated accordingly (0019-MCAL-048) +- When the party's order is partially filled, the order margin and general margin should be updated accordingly (0019-MCAL-048) - - When the party cancels the pegged order, the order magin should be `0`(0019-MCAL-049) +- When the party cancels the pegged order, the order magin should be `0`(0019-MCAL-049) - - When the party reduces the pegged order size only, the order magin should be reduced (0019-MCAL-050) +- When the party reduces the pegged order size only, the order magin should be reduced (0019-MCAL-050) - - When the party reduces the pegged order price only, the order magin should be reduced (0019-MCAL-042)(0019-MCAL-051) +- When the party reduces the pegged order price only, the order magin should be reduced (0019-MCAL-042)(0019-MCAL-051) - - When the party increases the pegged order size and the party's general account does not contain sufficient funds to cover any increases to the order margin account to be equal to side margin then the order should be stopped (0019-MCAL-052) +- When the party increases the pegged order size and the party's general account does not contain sufficient funds to cover any increases to the order margin account to be equal to side margin then the order should be stopped (0019-MCAL-052) - - When the party increases the pegged order price and the party's general account does not contain sufficient funds to cover any increases to the order margin account to be equal to side margin then the order should be stopped (0019-MCAL-075) +- When the party increases the pegged order price and the party's general account does not contain sufficient funds to cover any increases to the order margin account to be equal to side margin then the order should be stopped (0019-MCAL-075) - - When the party increases the pegged order size while decreases the order price and the party's general account does not contain sufficient funds to cover any increases to the order margin account to be equal to side margin then the order should be stopped (0019-MCAL-076) +- When the party increases the pegged order size while decreases the order price and the party's general account does not contain sufficient funds to cover any increases to the order margin account to be equal to side margin then the order should be stopped (0019-MCAL-076) - - When the party increases the pegged order price while decreases the order price and the party's general account does not contain sufficient funds to cover any increases to the order margin account to be equal to side margin then the order should be stopped (0019-MCAL-077) +- When the party increases the pegged order price while decreases the order price and the party's general account does not contain sufficient funds to cover any increases to the order margin account to be equal to side margin then the order should be stopped (0019-MCAL-077) - - When the party's pegged order is partially filled, the order margin and general margin should be updated accordingly (0019-MCAL-078) +- When the party's pegged order is partially filled, the order margin and general margin should be updated accordingly (0019-MCAL-078) **When a party is distressed:** @@ -200,7 +198,7 @@ **Check decimals:** - For each market and each party which has either orders or positions on the market, the API provides the maintenance margin levels. (0019-MCAL-049) -## Acceptance Criteria (perpetural market) +## Acceptance Criteria (perpetural market in isolated margin mode) - 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.linearSlippageFactor = 0.25` and `RF long = 0.1` and order book is From 88a9a50fae7783b2016bfde8081dde1bf471adf9 Mon Sep 17 00:00:00 2001 From: gordsport Date: Thu, 30 Nov 2023 13:09:39 +0000 Subject: [PATCH 0780/1171] fix: MD and spelling checks --- protocol/0019-MCAL-margin_calculator.md | 22 +++++++++++----------- 1 file changed, 11 insertions(+), 11 deletions(-) diff --git a/protocol/0019-MCAL-margin_calculator.md b/protocol/0019-MCAL-margin_calculator.md index 3df5aa583..b48f6d3df 100644 --- a/protocol/0019-MCAL-margin_calculator.md +++ b/protocol/0019-MCAL-margin_calculator.md @@ -93,7 +93,7 @@ buy 10 @ 14 900 and sell 1 @ 100 000 - sell 10 @ 100 100 + sell 10 @ 100 100 ``` - When switching to isolated-margin mode and the `margin factor short = 0.11`, the maintenance margin should be updated to `average entry price x current position x new margin factor = 57500 x 1 x 0.11 = 6325`, the switching will be rejected. (0019-MCAL-032) @@ -139,11 +139,11 @@ The margin account should have additional amount `limit price x size x margin fa **Amending order:** -- When the party cancels the order, the order magin should be `0`(0019-MCAL-041) +- When the party cancels the order, the order margin should be `0`(0019-MCAL-041) -- When the party reduces the order size only, the order magin should be reduced (0019-MCAL-042) +- When the party reduces the order size only, the order margin should be reduced (0019-MCAL-042) -- When the party reduces the order price only, the order magin should be reduced (0019-MCAL-043) +- When the party reduces the order price only, the order margin should be reduced (0019-MCAL-043) - When the party increases the order size and the party's general account does not contain sufficient funds to cover any increases to the order margin account to be equal to side margin then the order should be stopped (0019-MCAL-044) @@ -155,11 +155,11 @@ The margin account should have additional amount `limit price x size x margin fa - When the party's order is partially filled, the order margin and general margin should be updated accordingly (0019-MCAL-048) -- When the party cancels the pegged order, the order magin should be `0`(0019-MCAL-049) +- When the party cancels the pegged order, the order margin should be `0`(0019-MCAL-049) + +- When the party reduces the pegged order size only, the order margin should be reduced (0019-MCAL-050) -- When the party reduces the pegged order size only, the order magin should be reduced (0019-MCAL-050) - -- When the party reduces the pegged order price only, the order magin should be reduced (0019-MCAL-042)(0019-MCAL-051) +- When the party reduces the pegged order price only, the order margin should be reduced (0019-MCAL-042)(0019-MCAL-051) - When the party increases the pegged order size and the party's general account does not contain sufficient funds to cover any increases to the order margin account to be equal to side margin then the order should be stopped (0019-MCAL-052) @@ -175,7 +175,7 @@ The margin account should have additional amount `limit price x size x margin fa - Margin levels are correctly calculated in the case of an open position dropping below maintenance margin levels active orders will remain active as these are margined separately and will not be cancelled.(0019-MCAL-070) -- When the party (who holds open positions and orders) gets distressed, orders will be canceled, if party is still distressed, clseout will be triggered(0019-MCAL-071) +- When the party (who holds open positions and orders) gets distressed, orders will be cancelled, if party is still distressed, closeout will be triggered(0019-MCAL-071) - When the party (who holds open positions and bond account) gets closed out, the bond account will be emptied (0019-MCAL-072) @@ -196,9 +196,10 @@ The margin account should have additional amount `limit price x size x margin fa - A feature test that checks margin in case market PDP < 0 is created and passes. (0019-MCAL-057) **Check decimals:** + - For each market and each party which has either orders or positions on the market, the API provides the maintenance margin levels. (0019-MCAL-049) -## Acceptance Criteria (perpetural market in isolated margin mode) +## Acceptance Criteria (perpetual market in isolated margin mode) - 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.linearSlippageFactor = 0.25` and `RF long = 0.1` and order book is @@ -654,4 +655,3 @@ riskiest short: -1 ## SCENARIOS Scenarios found [here](https://docs.google.com/spreadsheets/d/1VXMdpgyyA9jp0hoWcIQTUFrhOdtu-fak/edit#gid=1586131462) - From 6ef47fb25ff680d6e25c3cac9b819a1f64edae6a Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Thu, 30 Nov 2023 17:27:22 +0000 Subject: [PATCH 0781/1171] feat: add ACs for switch margin modes --- protocol/0019-MCAL-margin_calculator.md | 97 +++++++++++++++++++++++-- 1 file changed, 89 insertions(+), 8 deletions(-) diff --git a/protocol/0019-MCAL-margin_calculator.md b/protocol/0019-MCAL-margin_calculator.md index b48f6d3df..ee13f1e74 100644 --- a/protocol/0019-MCAL-margin_calculator.md +++ b/protocol/0019-MCAL-margin_calculator.md @@ -159,7 +159,7 @@ The margin account should have additional amount `limit price x size x margin fa - When the party reduces the pegged order size only, the order margin should be reduced (0019-MCAL-050) -- When the party reduces the pegged order price only, the order margin should be reduced (0019-MCAL-042)(0019-MCAL-051) +- When the party reduces the pegged order price only, the order margin should be reduced (0019-MCAL-051) - When the party increases the pegged order size and the party's general account does not contain sufficient funds to cover any increases to the order margin account to be equal to side margin then the order should be stopped (0019-MCAL-052) @@ -183,21 +183,102 @@ The margin account should have additional amount `limit price x size x margin fa - When the party is closeout, insurance pool should be updated accordingly (0019-MCAL-074) -**When market is in auction mode:** +**Switch between margin modes:** -- When the market is in auctions, switch from cross margin mode to isolated margin mode (0019-MCAL-080) +- switch to isolated margin with no position and no order (before the first order ever has been sent) in continuous mode(0019-MCAL-100) -- When the market is in auctions, switch from cross margin mode to isolated margin mode (0019-MCAL-081) +- switch back to cross margin with no position and no order in continuous mode(0019-MCAL-101) -**Check decimals:** +- switch to isolated margin with no position and no order (before the first order ever has been sent) in auction(0019-MCAL-102) + +- switch back to cross margin with no position and no order in continuous mode in auction(0019-MCAL-103) + +- switch to isolated margin with position and no orders with margin factor such that position margin is < initial should fail in continuous(0019-MCAL-104) + +- switch to isolated margin with position and no orders with margin factor such that position margin is < initial should fail in auction(0019-MCAL-105) + +- switch to isolated margin without position and with orders with margin factor such that position margin is < initial should fail in continuous(0019-MCAL-106) + +- switch to isolated margin without position and with orders with margin factor such that position margin is < initial should fail in auction(0019-MCAL-107) + +- switch to isolated margin with position and with orders with margin factor such that position margin is < initial should fail in continuous(0019-MCAL-108) + +- switch to isolated margin with position and with orders with margin factor such that position margin is < initial should fail in auction(0019-MCAL-109) + +- switch to isolated margin without position and no orders with margin factor such that there is insufficient balance in the general account in continuous mode(0019-MCAL-110) + +- switch to isolated margin without position and no orders with margin factor such that there is insufficient balance in the general account in auction mode(0019-MCAL-111) + +- switch to isolated margin with position and no orders with margin factor such that there is insufficient balance in the general account in continuous mode(0019-MCAL-112) + +- switch to isolated margin with position and no orders with margin factor such that there is insufficient balance in the general account in auction mode(0019-MCAL-113) + +- switch to isolated margin with position and with orders with margin factor such that there is insufficient balance in the general account in continuous mode(0019-MCAL-114) + +- switch to isolated margin with position and with orders with margin factor such that there is insufficient balance in the general account in auction mode +- switch to isolate margin with out of range margin factor(0019-MCAL-115) + +- submit update margin mode transaction with no state change (already in cross margin, "change" to cross margin, or already in isolated, submit with same margin factor)(0019-MCAL-116) + +- update margin factor when already in isolated mode to the same cases as in switch to isolated failures.(0019-MCAL-117) + +- switch to isolated margin without position and no orders successful in continuous mode(0019-MCAL-118) + +- switch to isolated margin without position and no orders successful in auction(0019-MCAL-119) + +- switch to isolated margin with position and no orders successful in continuous mode(0019-MCAL-120) + +- switch to isolated margin with position and no orders successful in auction(0019-MCAL-121) + +- switch to isolated margin without position and with orders successful in continuous mode(0019-MCAL-122) -- A feature test that checks margin in case market PDP > 0 is created and passes. (0019-MCAL-047) +- switch to isolated margin without position and with orders successful in auction(0019-MCAL-123) -- A feature test that checks margin in case market PDP < 0 is created and passes. (0019-MCAL-057) +- switch to isolated margin with position and with orders successful in continuous mode(0019-MCAL-124) + +- switch to isolated margin with position and with orders successful in auction(0019-MCAL-125) + +- increase margin factor in isolated margin without position and no orders successful in continuous mode(0019-MCAL-126) + +- increase margin factor in isolated margin without position and no orders successful in auction(0019-MCAL-127) + +- increase margin factor in isolated margin with position and no orders successful in continuous mode(0019-MCAL-128) + +- increase margin factor in isolated margin with position and no orders successful in auction(0019-MCAL-129) + +- increase margin factor in isolated margin without position and with orders successful in continuous mode(0019-MCAL-130) + +- increase margin factor in isolated margin without position and with orders successful in auction(0019-MCAL-131) + +- increase margin factor in isolated margin with position and with orders successful in continuous mode(0019-MCAL-132) + +- increase margin factor in isolated margin with position and with orders successful in auction(0019-MCAL-133) + +- switch to cross margin without position and no orders successful in continuous mode(0019-MCAL-134) + +- switch to cross margin without position and no orders successful in auction(0019-MCAL-135) + +- switch to cross margin with position and no orders successful in continuous mode(0019-MCAL-136) + +- switch to cross margin with position and no orders successful in auction(0019-MCAL-137) + +- switch to cross margin without position and with orders successful in continuous mode(0019-MCAL-138) + +- switch to cross margin without position and with orders successful in auction(0019-MCAL-139) + +- switch to cross margin with position and with orders successful in continuous mode(0019-MCAL-140) + +- switch to cross margin with position and with orders successful in auction(0019-MCAL-141) **Check decimals:** -- For each market and each party which has either orders or positions on the market, the API provides the maintenance margin levels. (0019-MCAL-049) +- A feature test that checks margin in case market PDP > 0 is created and passes. (0019-MCAL-090) + +- A feature test that checks margin in case market PDP < 0 is created and passes. (0019-MCAL-091) + +**Check API:** + +- For each market and each party which has either orders or positions on the market, the API provides the maintenance margin levels. (0019-MCAL-092) ## Acceptance Criteria (perpetual market in isolated margin mode) From 7715fec920072264dff67f61088d1befd282e162 Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Fri, 1 Dec 2023 10:21:29 +0000 Subject: [PATCH 0782/1171] feat: update closeout --- protocol/0019-MCAL-margin_calculator.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/protocol/0019-MCAL-margin_calculator.md b/protocol/0019-MCAL-margin_calculator.md index ee13f1e74..b31b5cea9 100644 --- a/protocol/0019-MCAL-margin_calculator.md +++ b/protocol/0019-MCAL-margin_calculator.md @@ -173,15 +173,15 @@ The margin account should have additional amount `limit price x size x margin fa **When a party is distressed:** -- Margin levels are correctly calculated in the case of an open position dropping below maintenance margin levels active orders will remain active as these are margined separately and will not be cancelled.(0019-MCAL-070) +- Open positions should be closed in the case of open positions dropping below maintenance margin level, active orders will remain active if closing positions does not lead order margin level to increase.(0019-MCAL-070) -- When the party (who holds open positions and orders) gets distressed, orders will be cancelled, if party is still distressed, closeout will be triggered(0019-MCAL-071) +- Open positions should be closed in the case of open positions dropping below maintenance margin level, active orders will be cancelled if closing positions lead order margin level to increase.(0019-MCAL-071) -- When the party (who holds open positions and bond account) gets closed out, the bond account will be emptied (0019-MCAL-072) +- When a party (who holds open positions and bond account) gets closed out, the bond account will be emptied (0019-MCAL-072) -- When the party (who holds open orders and bond account) gets distressed, the bond account will be emptied (0019-MCAL-073) +- When a party (who holds open orders and bond account) gets distressed, the bond account will be emptied (0019-MCAL-073) -- When the party is closeout, insurance pool should be updated accordingly (0019-MCAL-074) +- When a party is closeout, insurance pool should be updated accordingly (0019-MCAL-074) **Switch between margin modes:** From e00f3522a94b9ba89101403a8dee6207c02f4d59 Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Fri, 1 Dec 2023 10:39:21 +0000 Subject: [PATCH 0783/1171] feat: update closeout --- protocol/0019-MCAL-margin_calculator.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/protocol/0019-MCAL-margin_calculator.md b/protocol/0019-MCAL-margin_calculator.md index b31b5cea9..cc3e3de0e 100644 --- a/protocol/0019-MCAL-margin_calculator.md +++ b/protocol/0019-MCAL-margin_calculator.md @@ -177,11 +177,11 @@ The margin account should have additional amount `limit price x size x margin fa - Open positions should be closed in the case of open positions dropping below maintenance margin level, active orders will be cancelled if closing positions lead order margin level to increase.(0019-MCAL-071) -- When a party (who holds open positions and bond account) gets closed out, the bond account will be emptied (0019-MCAL-072) +- When a party (who holds open positions and bond account) gets distressed, open positions will be closed, the bond account will be emptied (0019-MCAL-072) -- When a party (who holds open orders and bond account) gets distressed, the bond account will be emptied (0019-MCAL-073) +- When a party (who holds open positions, open orders and bond account) gets distressed, the bond account will be emptied, active orders will remain active if closing positions does not lead order margin level to increase. (0019-MCAL-073) -- When a party is closeout, insurance pool should be updated accordingly (0019-MCAL-074) +- When a party (who holds open positions, open orders and bond account) gets distressed, the bond account will be emptied, active orders will be cancelled if closing positions lead order margin level to increase. (0019-MCAL-074) **Switch between margin modes:** From 40bc8552e9b332c93f8dae02c9e010b96e131469 Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Mon, 4 Dec 2023 11:11:10 +0000 Subject: [PATCH 0784/1171] chore: remove mystery AC --- protocol/features.json | 1 - 1 file changed, 1 deletion(-) diff --git a/protocol/features.json b/protocol/features.json index d92389b97..bd576e5b1 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -108,7 +108,6 @@ "0019-MCAL-054", "0019-MCAL-055", "0019-MCAL-056", - "0019-MCAL-057", "0019-MCAL-058", "0019-MCAL-059", "0019-MCAL-060", From 0a848ad28c92f77a074d6d0f4ae5ff1208017d83 Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Tue, 5 Dec 2023 14:53:59 +0000 Subject: [PATCH 0785/1171] feat: address commments from Tom --- protocol/0019-MCAL-margin_calculator.md | 25 ++++++++------ protocol/features.json | 46 ++++++++++++++++++++++++- 2 files changed, 59 insertions(+), 12 deletions(-) diff --git a/protocol/0019-MCAL-margin_calculator.md b/protocol/0019-MCAL-margin_calculator.md index cc3e3de0e..c5dc5aab8 100644 --- a/protocol/0019-MCAL-margin_calculator.md +++ b/protocol/0019-MCAL-margin_calculator.md @@ -96,7 +96,7 @@ sell 10 @ 100 100 ``` -- When switching to isolated-margin mode and the `margin factor short = 0.11`, the maintenance margin should be updated to `average entry price x current position x new margin factor = 57500 x 1 x 0.11 = 6325`, the switching will be rejected. (0019-MCAL-032) +- When switching to isolated-margin mode and the `margin factor short = 0.11`, the maintenance margin should be updated to `average entry price x current position x new margin factor = 57500 x 1 x 0.11 = 6325`, the switching will be rejected with message "required position margin must be greater than initial margin". (0019-MCAL-032) - When switching to isolated-margin mode and the `margin factor short = 0.9`, the maintenance margin should be updated to `average entry price x current position x new margin factor = 15900 x 1 x 0.9 = 14310`, and margin account should be updated to `14310`. (0019-MCAL-033) @@ -104,18 +104,18 @@ - When increasing the `margin factor short` from `0.7` to `0.9`, the maintenance margin should be updated to `average entry price x current position x new margin factor = 15900 x 1 x 0.9 = 14310`, and margin account should be updated to `14310`. (0019-MCAL-059) -- Switching to isolated margin mode will be rejected if the party does not have enough asset in the general account(0019-MCAL-066) +- Switching to isolated margin mode will be rejected if the party does not have enough asset in the general account to top up the margin account to the new required level (0019-MCAL-066) **When party has a position and an order which does not offset the position:** - When the party places a new short order of `10` with price `15910` which does not offset the existing position, and the market is in continuous trading. -The margin account should have additional amount `limit price x size x margin factor = 15910 x 10 x 0.9 = 143190` transferred into "order margin" account if the party has enough asset in the general account(0019-MCAL-034) +There should be an additional amount `limit price x size x margin factor = 15910 x 10 x 0.9 = 143190` transferred into "order margin" account if the party has enough asset in the general account(0019-MCAL-034) - The order will be rejected if the party does not have enough asset in the general account (0019-MCAL-035) - The party amends the order size to `5`, and the amount `limit price x size x margin factor = 15912 x 5 x 0.9 = 71604` will be transferred from "order margin" account into general account (0019-MCAL-060) -- Another trader places a buy order of `3` with price `15912`, party's position becomes `4`, party's margin account should be updated to `15912 x 4 x 0.9 =57283` and order margin should be `15912x 2 x 0.9 = 28642` (0019-MCAL-061) +- Another trader places a buy order of `3` with price `15912`, party's position changes from `1` to `4`, party's margin account should have additional `15912 x 3 x 0.9 =42962` transfered from general account and order margin should be reduced to `15912x 2 x 0.9 = 28642`since party's order size has been reduced from `5` to `2` after the trade (0019-MCAL-061) - Switch margin mode from isolated margin to cross margin when party holds position only, the margin account should be updated to initial margin level in cross margin mode(0019-MCAL-065) @@ -123,7 +123,7 @@ The margin account should have additional amount `limit price x size x margin fa - When the party has no orders, their order margin account should be `0` (0019-MCAL-062) -- Create some MTM, the margin account should be updated while order margin account should not (0019-MCAL-067) +- When the mark price moves, the margin account should be updated while order margin account should not (0019-MCAL-067) **When a party has a position and an order which offsets the position:** @@ -139,7 +139,7 @@ The margin account should have additional amount `limit price x size x margin fa **Amending order:** -- When the party cancels the order, the order margin should be `0`(0019-MCAL-041) +- When the party cancels all orders, the order margin should be `0`(0019-MCAL-041) - When the party reduces the order size only, the order margin should be reduced (0019-MCAL-042) @@ -151,15 +151,17 @@ The margin account should have additional amount `limit price x size x margin fa - When the party increases the order size while decreases the order price and the party's general account does not contain sufficient funds to cover any increases to the order margin account to be equal to side margin then the order should be stopped (0019-MCAL-046) -- When the party increases the order price while decreases the order price and the party's general account does not contain sufficient funds to cover any increases to the order margin account to be equal to side margin then the order should be stopped (0019-MCAL-047) +- When the party increases the order price while decreases the order size and the party's general account does not contain sufficient funds to cover any increases to the order margin account to be equal to side margin then the order should be stopped (0019-MCAL-047) - When the party's order is partially filled, the order margin and general margin should be updated accordingly (0019-MCAL-048) -- When the party cancels the pegged order, the order margin should be `0`(0019-MCAL-049) +- When the party cancels a pegged order, which was their only order, the order margin should be `0`(0019-MCAL-049) - When the party reduces the pegged order size only, the order margin should be reduced (0019-MCAL-050) -- When the party reduces the pegged order price only, the order margin should be reduced (0019-MCAL-051) +- When the party reduces the pegged buy order offset price, the order margin should be reduced (0019-MCAL-051) + +- When the party increases the pegged sell order offset price, the order margin should be reduced (0019-MCAL-057) - When the party increases the pegged order size and the party's general account does not contain sufficient funds to cover any increases to the order margin account to be equal to side margin then the order should be stopped (0019-MCAL-052) @@ -179,7 +181,7 @@ The margin account should have additional amount `limit price x size x margin fa - When a party (who holds open positions and bond account) gets distressed, open positions will be closed, the bond account will be emptied (0019-MCAL-072) -- When a party (who holds open positions, open orders and bond account) gets distressed, the bond account will be emptied, active orders will remain active if closing positions does not lead order margin level to increase. (0019-MCAL-073) +- When a party (who holds open positions, open orders and bond account) gets distressed, the bond account will be treated as in cross margin mode, however active orders will remain active if closing positions does not lead order margin level to increase. (0019-MCAL-073) - When a party (who holds open positions, open orders and bond account) gets distressed, the bond account will be emptied, active orders will be cancelled if closing positions lead order margin level to increase. (0019-MCAL-074) @@ -215,7 +217,7 @@ The margin account should have additional amount `limit price x size x margin fa - switch to isolated margin with position and with orders with margin factor such that there is insufficient balance in the general account in continuous mode(0019-MCAL-114) -- switch to isolated margin with position and with orders with margin factor such that there is insufficient balance in the general account in auction mode +- switch to isolated margin with position and with orders with margin factor such that there is insufficient balance in the general account in auction mode(0019-MCAL-142/a>) - switch to isolate margin with out of range margin factor(0019-MCAL-115) - submit update margin mode transaction with no state change (already in cross margin, "change" to cross margin, or already in isolated, submit with same margin factor)(0019-MCAL-116) @@ -736,3 +738,4 @@ riskiest short: -1 ## SCENARIOS Scenarios found [here](https://docs.google.com/spreadsheets/d/1VXMdpgyyA9jp0hoWcIQTUFrhOdtu-fak/edit#gid=1586131462) + diff --git a/protocol/features.json b/protocol/features.json index bd576e5b1..89613dd9f 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -108,6 +108,7 @@ "0019-MCAL-054", "0019-MCAL-055", "0019-MCAL-056", + "0019-MCAL-057", "0019-MCAL-058", "0019-MCAL-059", "0019-MCAL-060", @@ -116,7 +117,50 @@ "0019-MCAL-064", "0019-MCAL-065", "0019-MCAL-066", - "0019-MCAL-067" + "0019-MCAL-067", + "0019-MCAL-100", + "0019-MCAL-101", + "0019-MCAL-102", + "0019-MCAL-103", + "0019-MCAL-104", + "0019-MCAL-105", + "0019-MCAL-106", + "0019-MCAL-107", + "0019-MCAL-108", + "0019-MCAL-109", + "0019-MCAL-110", + "0019-MCAL-111", + "0019-MCAL-112", + "0019-MCAL-113", + "0019-MCAL-114", + "0019-MCAL-115", + "0019-MCAL-116", + "0019-MCAL-117", + "0019-MCAL-118", + "0019-MCAL-119", + "0019-MCAL-120", + "0019-MCAL-121", + "0019-MCAL-122", + "0019-MCAL-123", + "0019-MCAL-124", + "0019-MCAL-125", + "0019-MCAL-126", + "0019-MCAL-127", + "0019-MCAL-128", + "0019-MCAL-129", + "0019-MCAL-130", + "0019-MCAL-131", + "0019-MCAL-132", + "0019-MCAL-133", + "0019-MCAL-134", + "0019-MCAL-135", + "0019-MCAL-136", + "0019-MCAL-137", + "0019-MCAL-138", + "0019-MCAL-139", + "0019-MCAL-140", + "0019-MCAL-141", + "0019-MCAL-142" ] }, "Quadratic slippage removal": { From 3e09455e2752e0e21991763f33df40475255aa19 Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Tue, 5 Dec 2023 16:01:39 +0000 Subject: [PATCH 0786/1171] chore: typo --- protocol/0019-MCAL-margin_calculator.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0019-MCAL-margin_calculator.md b/protocol/0019-MCAL-margin_calculator.md index c5dc5aab8..d0e0633d4 100644 --- a/protocol/0019-MCAL-margin_calculator.md +++ b/protocol/0019-MCAL-margin_calculator.md @@ -115,7 +115,7 @@ There should be an additional amount `limit price x size x margin factor = 15910 - The party amends the order size to `5`, and the amount `limit price x size x margin factor = 15912 x 5 x 0.9 = 71604` will be transferred from "order margin" account into general account (0019-MCAL-060) -- Another trader places a buy order of `3` with price `15912`, party's position changes from `1` to `4`, party's margin account should have additional `15912 x 3 x 0.9 =42962` transfered from general account and order margin should be reduced to `15912x 2 x 0.9 = 28642`since party's order size has been reduced from `5` to `2` after the trade (0019-MCAL-061) +- Another trader places a buy order of `3` with price `15912`, party's position changes from `1` to `4`, party's margin account should have additional `15912 x 3 x 0.9 =42962` transferred from general account and order margin should be reduced to `15912x 2 x 0.9 = 28642`since party's order size has been reduced from `5` to `2` after the trade (0019-MCAL-061) - Switch margin mode from isolated margin to cross margin when party holds position only, the margin account should be updated to initial margin level in cross margin mode(0019-MCAL-065) From 88953c6171f331a00284994fa4b5d1ceaf5a890b Mon Sep 17 00:00:00 2001 From: wwestgarth Date: Mon, 4 Dec 2023 10:38:52 +0000 Subject: [PATCH 0787/1171] fix: AC 0053-PERP-030 now flexes the boundary --- 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 e518b2486..fed4dd7a6 100644 --- a/protocol/0053-PERP-product_builtin_perpetual_future.md +++ b/protocol/0053-PERP-product_builtin_perpetual_future.md @@ -324,7 +324,7 @@ $\text{external TWAP}=\frac{11\cdot(1-0)+9\cdot(3-1)+10\cdot(5-3)+11\cdot(8-7)+8 When $\text{clamp_lower_bound}=\text{clamp_upper_bound}=0$, $\text{scaling factor}=2.5$ and the funding period ends with $\text{internal TWAP}=99$, $\text{external TWAP} = 100$ then the resulting funding rate equals $-0.025$. (0053-PERP-029) -When $\text{clamp_lower_bound}=\text{clamp_upper_bound}=0$, $\text{scaling factor}=1$, $\text{rate_lower_bound}=-0.015$, $\text{rate_upper_bound}=0.005$ and the funding period ends with $\text{internal TWAP}=99$, $\text{external TWAP} = 100$ then the resulting funding rate equals $-0.015$. (0053-PERP-030) +When $\text{clamp_lower_bound}=\text{clamp_upper_bound}=0$, $\text{scaling factor}=1$, $\text{rate_lower_bound}=-0.005$, $\text{rate_upper_bound}=0.015$ and the funding period ends with $\text{internal TWAP}=99$, $\text{external TWAP} = 100$ then the resulting funding rate equals $-0.005$. (0053-PERP-030) When $\text{clamp_lower_bound}=\text{clamp_upper_bound}=0$, $\text{scaling factor}=1$, $\text{rate_lower_bound}=-0.015$, $\text{rate_upper_bound}=0.005$ and the funding period ends with $\text{internal TWAP}=101$, $\text{external TWAP} = 100$ then the resulting funding rate equals $0.005$. (0053-PERP-031) From 0b0e443da752892d7aeb8c100cd738b12951941c Mon Sep 17 00:00:00 2001 From: wwestgarth Date: Mon, 4 Dec 2023 10:42:51 +0000 Subject: [PATCH 0788/1171] fix: formatting --- 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 fed4dd7a6..68267d62a 100644 --- a/protocol/0053-PERP-product_builtin_perpetual_future.md +++ b/protocol/0053-PERP-product_builtin_perpetual_future.md @@ -322,11 +322,11 @@ Then, taking the auction into account we get: $\text{internal TWAP}= \frac{10\cdot(1-0)+11\cdot(3-1)+11\cdot(5-3)+9\cdot(8-7)+8\cdot(10-8)+30\cdot(10-10)}{8}=9.875$, $\text{external TWAP}=\frac{11\cdot(1-0)+9\cdot(3-1)+10\cdot(5-3)+11\cdot(8-7)+8\cdot(9-8)+14\cdot(10-9)}{8}=10.25$. (0053-PERP-028) -When $\text{clamp_lower_bound}=\text{clamp_upper_bound}=0$, $\text{scaling factor}=2.5$ and the funding period ends with $\text{internal TWAP}=99$, $\text{external TWAP} = 100$ then the resulting funding rate equals $-0.025$. (0053-PERP-029) +When $\text{clamp lower bound}=\text{clamp upper bound}=0$, $\text{scaling factor}=2.5$ and the funding period ends with $\text{internal TWAP}=99$, $\text{external TWAP} = 100$ then the resulting funding rate equals $-0.025$. (0053-PERP-029) -When $\text{clamp_lower_bound}=\text{clamp_upper_bound}=0$, $\text{scaling factor}=1$, $\text{rate_lower_bound}=-0.005$, $\text{rate_upper_bound}=0.015$ and the funding period ends with $\text{internal TWAP}=99$, $\text{external TWAP} = 100$ then the resulting funding rate equals $-0.005$. (0053-PERP-030) +When $\text{clamp lower bound}=\text{clamp upper bound}=0$, $\text{scaling factor}=1$, $\text{rate_lower_bound}=-0.005$, $\text{rate upper_bound}=0.015$ and the funding period ends with $\text{internal TWAP}=99$, $\text{external TWAP} = 100$ then the resulting funding rate equals $-0.005$. (0053-PERP-030) -When $\text{clamp_lower_bound}=\text{clamp_upper_bound}=0$, $\text{scaling factor}=1$, $\text{rate_lower_bound}=-0.015$, $\text{rate_upper_bound}=0.005$ and the funding period ends with $\text{internal TWAP}=101$, $\text{external TWAP} = 100$ then the resulting funding rate equals $0.005$. (0053-PERP-031) +When $\text{clamp lower bound}=\text{clamp upper bound}=0$, $\text{scaling factor}=1$, $\text{rate lower bound}=-0.015$, $\text{rate upper bound}=0.005$ and the funding period ends with $\text{internal TWAP}=101$, $\text{external TWAP} = 100$ then the resulting funding rate equals $0.005$. (0053-PERP-031) When migrating the market existing prior to introduction of the additional parameters their values get set to: From 7d2e43179a50b223de26008b71d004c06956cbca Mon Sep 17 00:00:00 2001 From: wwestgarth Date: Mon, 4 Dec 2023 13:03:18 +0000 Subject: [PATCH 0789/1171] Update protocol/0053-PERP-product_builtin_perpetual_future.md Co-authored-by: Gordsport <83510148+gordsport@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 68267d62a..ec56e9b26 100644 --- a/protocol/0053-PERP-product_builtin_perpetual_future.md +++ b/protocol/0053-PERP-product_builtin_perpetual_future.md @@ -324,7 +324,7 @@ $\text{external TWAP}=\frac{11\cdot(1-0)+9\cdot(3-1)+10\cdot(5-3)+11\cdot(8-7)+8 When $\text{clamp lower bound}=\text{clamp upper bound}=0$, $\text{scaling factor}=2.5$ and the funding period ends with $\text{internal TWAP}=99$, $\text{external TWAP} = 100$ then the resulting funding rate equals $-0.025$. (0053-PERP-029) -When $\text{clamp lower bound}=\text{clamp upper bound}=0$, $\text{scaling factor}=1$, $\text{rate_lower_bound}=-0.005$, $\text{rate upper_bound}=0.015$ and the funding period ends with $\text{internal TWAP}=99$, $\text{external TWAP} = 100$ then the resulting funding rate equals $-0.005$. (0053-PERP-030) +When $\text{clamp lower bound}=\text{clamp upper bound}=0$, $\text{scaling factor}=1$, $\text{rate_lower_bound}=-0.005$, $\text{rate upper bound}=0.015$ and the funding period ends with $\text{internal TWAP}=99$, $\text{external TWAP} = 100$ then the resulting funding rate equals $-0.005$. (0053-PERP-030) When $\text{clamp lower bound}=\text{clamp upper bound}=0$, $\text{scaling factor}=1$, $\text{rate lower bound}=-0.015$, $\text{rate upper bound}=0.005$ and the funding period ends with $\text{internal TWAP}=101$, $\text{external TWAP} = 100$ then the resulting funding rate equals $0.005$. (0053-PERP-031) From 66c6a474510e30e6337ed100f301129c909828ee Mon Sep 17 00:00:00 2001 From: wwestgarth Date: Mon, 4 Dec 2023 13:04:54 +0000 Subject: [PATCH 0790/1171] fix: another formatting issue --- 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 ec56e9b26..348ebe9a7 100644 --- a/protocol/0053-PERP-product_builtin_perpetual_future.md +++ b/protocol/0053-PERP-product_builtin_perpetual_future.md @@ -324,7 +324,7 @@ $\text{external TWAP}=\frac{11\cdot(1-0)+9\cdot(3-1)+10\cdot(5-3)+11\cdot(8-7)+8 When $\text{clamp lower bound}=\text{clamp upper bound}=0$, $\text{scaling factor}=2.5$ and the funding period ends with $\text{internal TWAP}=99$, $\text{external TWAP} = 100$ then the resulting funding rate equals $-0.025$. (0053-PERP-029) -When $\text{clamp lower bound}=\text{clamp upper bound}=0$, $\text{scaling factor}=1$, $\text{rate_lower_bound}=-0.005$, $\text{rate upper bound}=0.015$ and the funding period ends with $\text{internal TWAP}=99$, $\text{external TWAP} = 100$ then the resulting funding rate equals $-0.005$. (0053-PERP-030) +When $\text{clamp lower bound}=\text{clamp upper bound}=0$, $\text{scaling factor}=1$, $\text{rate lower bound}=-0.005$, $\text{rate upper bound}=0.015$ and the funding period ends with $\text{internal TWAP}=99$, $\text{external TWAP} = 100$ then the resulting funding rate equals $-0.005$. (0053-PERP-030) When $\text{clamp lower bound}=\text{clamp upper bound}=0$, $\text{scaling factor}=1$, $\text{rate lower bound}=-0.015$, $\text{rate upper bound}=0.005$ and the funding period ends with $\text{internal TWAP}=101$, $\text{external TWAP} = 100$ then the resulting funding rate equals $0.005$. (0053-PERP-031) From d424efc5e5d74500efe91b68ac5c3011f2bef705 Mon Sep 17 00:00:00 2001 From: Tom Date: Fri, 8 Dec 2023 18:43:51 +0800 Subject: [PATCH 0791/1171] feat: A couple more ACs, API clarifications and Removing excessive margin check (#2076) --- protocol/0019-MCAL-margin_calculator.md | 8 +- .../0074-BTCH-batch-market-instructions.md | 4 +- protocol/features.json | 134 +++++++----------- 3 files changed, 62 insertions(+), 84 deletions(-) diff --git a/protocol/0019-MCAL-margin_calculator.md b/protocol/0019-MCAL-margin_calculator.md index d0e0633d4..b5621c545 100644 --- a/protocol/0019-MCAL-margin_calculator.md +++ b/protocol/0019-MCAL-margin_calculator.md @@ -282,6 +282,8 @@ There should be an additional amount `limit price x size x margin factor = 15910 - For each market and each party which has either orders or positions on the market, the API provides the maintenance margin levels. (0019-MCAL-092) +- For each market and each party which has either orders or positions on the market, the API provides the current margin mode and, when in isolated margin mode, margin factor. (0019-MCAL-143) + ## Acceptance Criteria (perpetual market in isolated margin mode) - 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: @@ -394,10 +396,10 @@ When submitting, amending, or deleting an order in isolated margin mode and cont 1. Sort all orders by price, starting from first to execute (highest price for buying, lowest price for selling). 1. If the party currently has a position `x`, assign `0` margin requirement the first-to-trade `x` of volume on the opposite side as this would reduce their position (for example, if a party had a long position `10` and sell orders of `15` at a price of `$100` and `10` at a price of `$150`, the first `10` of the sell order at `$100` would not require any order margin). 1. For any remaining volume, sum `side margin = limit price * size * margin factor` for each price level, as this is the worst-case trade price of the remaining component. - 1. Take the maximum margin from the two `side margin`s as the margin required in the order margin account. Now the full margin requirement for all orders, including any new one, and open position should be run through the full margin calculator to obtain a `maintenance margin` value. If the new `side margin + margin account balance < maintenance margin`, or if the party's `general` account does not contain sufficient funds to cover any increases to the `order margin` account to be equal to `side margin` then: + 2. Take the maximum margin from the two `side margin`s as the margin required in the order margin account. If the party's `general` account does not contain sufficient funds to cover any increases to the `order margin` account to be equal to `side margin` then: 1. If a newly placed order is being evaluated, that order is `stopped` - 1. If the evaluation is the result of any other position/order update, all open orders are `stopped` and margin re-evaluated. - 1. The `order margin` account is now updated to the new `side margin` value and any new orders can be placed on the book. + 2. If the evaluation is the result of any other position/order update, all open orders are `stopped` and margin re-evaluated. + 3. The `order margin` account is now updated to the new `side margin` value and any new orders can be placed on the book. NB: This means that a party's order could partially match, with a trade executed and some funds moved to the margin account with correct leverage whilst the rest of the order is immediately stopped. diff --git a/protocol/0074-BTCH-batch-market-instructions.md b/protocol/0074-BTCH-batch-market-instructions.md index 193b20a25..286d58f29 100644 --- a/protocol/0074-BTCH-batch-market-instructions.md +++ b/protocol/0074-BTCH-batch-market-instructions.md @@ -25,7 +25,7 @@ Overall, building the ability to handle batches of market instructions in a sing - **Cancellations**: this is a list (repeated field) of Cancel Order instructions - **Amendments**: this is a list (repeated field) of Amend Order instructions - **Submissions**: this is a list (repeated field) of Submit Order instructions -- Additionally the batch may contain a single transaction to change the current margin mode. +- Additionally the batch may contain a single transaction to change the current margin mode. If this transaction fails, all later transactions within the batch (cancellations/amendments/submissions) for the market referred to in the update are Stopped for reason MARGIN_MODE_UPDATE_FAILED. - The total number of instructions across all three lists (i.e. sum of the lengths of the lists) must be less than or equal to the current value of the network parameter `network.spam_protection.max.batch.size`. The margin mode update transaction is not included in this limit. ### Processing a batch @@ -61,3 +61,5 @@ After entering or exiting an auction mid-batch, the full batch must be processed - 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) +- If the margin mode update transaction fails all transactions in the batch referring to the same market are Stopped. (0074-BTCH-020) +- If the margin mode update transaction fails all transactions in the batch referring to a different market are attempted as usual. (0074-BTCH-021) diff --git a/protocol/features.json b/protocol/features.json index 89613dd9f..fe4fd46e0 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -1,29 +1,19 @@ { "Iceberg Orders": { "milestone": "cosmic-carryover", - "acs": [ - "0014-ORDT-069" - ] + "acs": ["0014-ORDT-069"] }, "Successor Markets": { "milestone": "cosmic-carryover", - "acs": [ - "0001-MKTF-008" - ] + "acs": ["0001-MKTF-008"] }, "Ethereum oracles": { "milestone": "cosmic-carryover", - "acs": [ - "0082-ETHD-035", - "0082-ETHD-041" - ] + "acs": ["0082-ETHD-035", "0082-ETHD-041"] }, "Stop Orders": { "milestone": "cosmic-carryover", - "acs": [ - "0079-TGAP-004", - "0079-TGAP-005" - ] + "acs": ["0079-TGAP-004", "0079-TGAP-005"] }, "Perpetuals": { "milestone": "palazzo", @@ -70,12 +60,7 @@ }, "Fixed size amendments": { "milestone": "palazzo", - "acs": [ - "0004-AMND-056", - "0004-AMND-057", - "0004-AMND-058", - "0004-AMND-059" - ] + "acs": ["0004-AMND-056", "0004-AMND-057", "0004-AMND-058", "0004-AMND-059"] }, "Ethereum heartbeat": { "milestone": "palazzo", @@ -108,7 +93,6 @@ "0019-MCAL-054", "0019-MCAL-055", "0019-MCAL-056", - "0019-MCAL-057", "0019-MCAL-058", "0019-MCAL-059", "0019-MCAL-060", @@ -118,49 +102,51 @@ "0019-MCAL-065", "0019-MCAL-066", "0019-MCAL-067", - "0019-MCAL-100", - "0019-MCAL-101", - "0019-MCAL-102", - "0019-MCAL-103", - "0019-MCAL-104", - "0019-MCAL-105", - "0019-MCAL-106", - "0019-MCAL-107", - "0019-MCAL-108", - "0019-MCAL-109", - "0019-MCAL-110", - "0019-MCAL-111", - "0019-MCAL-112", - "0019-MCAL-113", - "0019-MCAL-114", - "0019-MCAL-115", - "0019-MCAL-116", - "0019-MCAL-117", - "0019-MCAL-118", - "0019-MCAL-119", - "0019-MCAL-120", - "0019-MCAL-121", - "0019-MCAL-122", - "0019-MCAL-123", - "0019-MCAL-124", - "0019-MCAL-125", - "0019-MCAL-126", - "0019-MCAL-127", - "0019-MCAL-128", - "0019-MCAL-129", - "0019-MCAL-130", - "0019-MCAL-131", - "0019-MCAL-132", - "0019-MCAL-133", - "0019-MCAL-134", - "0019-MCAL-135", - "0019-MCAL-136", - "0019-MCAL-137", - "0019-MCAL-138", - "0019-MCAL-139", - "0019-MCAL-140", - "0019-MCAL-141", - "0019-MCAL-142" + "0019-MCAL-100", + "0019-MCAL-101", + "0019-MCAL-102", + "0019-MCAL-103", + "0019-MCAL-104", + "0019-MCAL-105", + "0019-MCAL-106", + "0019-MCAL-107", + "0019-MCAL-108", + "0019-MCAL-109", + "0019-MCAL-110", + "0019-MCAL-111", + "0019-MCAL-112", + "0019-MCAL-113", + "0019-MCAL-114", + "0019-MCAL-115", + "0019-MCAL-116", + "0019-MCAL-117", + "0019-MCAL-118", + "0019-MCAL-119", + "0019-MCAL-120", + "0019-MCAL-121", + "0019-MCAL-122", + "0019-MCAL-123", + "0019-MCAL-124", + "0019-MCAL-125", + "0019-MCAL-126", + "0019-MCAL-127", + "0019-MCAL-128", + "0019-MCAL-129", + "0019-MCAL-130", + "0019-MCAL-131", + "0019-MCAL-132", + "0019-MCAL-133", + "0019-MCAL-134", + "0019-MCAL-135", + "0019-MCAL-136", + "0019-MCAL-137", + "0019-MCAL-138", + "0019-MCAL-139", + "0019-MCAL-140", + "0019-MCAL-141", + "0019-MCAL-142", + "0074-BTCH-020", + "0074-BTCH-021" ] }, "Quadratic slippage removal": { @@ -233,27 +219,15 @@ }, "Transfers from vesting": { "milestone": "palazzo", - "acs": [ - "0057-TRAN-066", - "0057-TRAN-067", - "0057-TRAN-068", - "0057-TRAN-069" - ] + "acs": ["0057-TRAN-066", "0057-TRAN-067", "0057-TRAN-068", "0057-TRAN-069"] }, "Liquidity fee setting": { "milestone": "palazzo", - "acs": [ - "0042-LIQF-056", - "0042-LIQF-057", - "0042-LIQF-058" - ] + "acs": ["0042-LIQF-056", "0042-LIQF-057", "0042-LIQF-058"] }, "Governance market name change": { "milestone": "palazzo", - "acs": [ - "0028-GOVE-159", - "0028-GOVE-166" - ] + "acs": ["0028-GOVE-159", "0028-GOVE-166"] }, "Insurance pools redistribution": { "milestone": "palazzo", @@ -274,4 +248,4 @@ "milestone": "unknown", "acs": [] } -} \ No newline at end of file +} From 719d80bbdb548b862fc920335cab87424808b9e8 Mon Sep 17 00:00:00 2001 From: Charlie Date: Wed, 15 Nov 2023 09:40:27 +0000 Subject: [PATCH 0792/1171] feat: add alias to public keys --- protocol/0083-RFPR-on_chain_referral_program.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/protocol/0083-RFPR-on_chain_referral_program.md b/protocol/0083-RFPR-on_chain_referral_program.md index 2ab645d82..569170bc4 100644 --- a/protocol/0083-RFPR-on_chain_referral_program.md +++ b/protocol/0083-RFPR-on_chain_referral_program.md @@ -213,10 +213,12 @@ To apply a referral code and become a referee, a party must fulfil the following To become a referee, a referee must submit a signed `ApplyReferralCode` transaction with the following fields: - `referral_code`: the referral code they wish to apply +- `alias`: Optional string defining an alias which should be associated with the key applying the referral code and should appear on leaderboards in the keys place. ```protobuf message ApplyReferralCode{ id: "mYr3f3rra1c0d3" + alias: "myPuBlicA1ias" } ``` From db1982d49dafdd3f3c4779f153d3aebd0f9a2909 Mon Sep 17 00:00:00 2001 From: Charlie Date: Mon, 20 Nov 2023 11:20:33 +0000 Subject: [PATCH 0793/1171] feat: add allow list to teams --- .../0083-RFPR-on_chain_referral_program.md | 29 +++++++++++++++++-- 1 file changed, 26 insertions(+), 3 deletions(-) diff --git a/protocol/0083-RFPR-on_chain_referral_program.md b/protocol/0083-RFPR-on_chain_referral_program.md index 569170bc4..82c7843a6 100644 --- a/protocol/0083-RFPR-on_chain_referral_program.md +++ b/protocol/0083-RFPR-on_chain_referral_program.md @@ -144,6 +144,7 @@ To create a referral set and generate a referral code, the party must submit a s - `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`: optional string of a link to an image to be used as the teams avatar (defaults to empty string / none-type) + - `allow_list`: optional list of public keys which are allowed to join the team. If empty, all public keys are allowed to join the team. - `closed`: optional boolean, defines whether a team is accepting new members (defaults to false) *Example: if party wants to create a simple referral set.* @@ -169,6 +170,21 @@ message CreateReferralSet{ } ``` +*Example: if party wants to create a referral set and team.* + +```protobuf +message CreateReferralSet{ + is_team: True + team_details: { + name: "VegaRocks", + team_url: "https://discord.com/channels/vegarocks", + avatar_url: "https://vega-rocks/logo-360x360.jpg", + allow_list: ["publ1ck3y001", "publ1ck3y002", publ1ck3y003] + 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. ### Updating a referral set @@ -186,6 +202,7 @@ To update a referral set the party submit a signed `UpdateReferralSet` transacti - `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 + - `allow_list`: optional list of public keys which are allowed to join the team. If empty, all public keys are allowed to join the team. - `closed`: optional boolean, defines whether a team is accepting new members ```protobuf @@ -202,6 +219,8 @@ message UpdateReferralSet{ 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. +Note, if a referrer updates the `allow_list` defining the parties which are allowed to join the team, the updated list is only used to validate attempts to join the team, i.e. if an existing member is removed from the list, they are not removed from the team. + 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 @@ -444,24 +463,28 @@ The Estimate Fees API should now calculate the following additional information: 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). +1. If a referrer updates the `allow_list` associated with the team, existing members who are no longer on the allow_list should **not** be removed from the team. #### Applying a referral code 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). + - the party **will** be added to the associated team (if one exists, the team is not closed, and the party is allowed by the `allow_list`). 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). + - the party **will** be added to the associated team (if one exists and the team is not closed, and the party is allowed by the `allow_list`). 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). + - the party **will** be added to the associated team (if one exists and the team is not closed, and the party is allowed by the `allow_list`). +1. If a party submits an `ApplyReferralCode` transaction, a team exists for the specified `id` and the team has **no** `allow_list` specified, then the party **should** be added to the team. +1. If a party submits an `ApplyReferralCode` transaction, a team exists for the specified `id`, and the parties key **is** specified in the teams `allow_list`, then the party **should** be added to the team. +1. If a party submits an `ApplyReferralCode` transaction, a team exists for the specified `id`, but the party key **is not** specified in the teams `allow_list`, then the party **should not** be added to the team. 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). From a61a228a9cfd9ac7f6a1d80adff46ad92987a4f9 Mon Sep 17 00:00:00 2001 From: Charlie Date: Mon, 20 Nov 2023 11:29:10 +0000 Subject: [PATCH 0794/1171] feat: align spec with core change adding JoinTeam --- .../0083-RFPR-on_chain_referral_program.md | 38 ++++++++++++++++--- 1 file changed, 32 insertions(+), 6 deletions(-) diff --git a/protocol/0083-RFPR-on_chain_referral_program.md b/protocol/0083-RFPR-on_chain_referral_program.md index 82c7843a6..cf1e846b2 100644 --- a/protocol/0083-RFPR-on_chain_referral_program.md +++ b/protocol/0083-RFPR-on_chain_referral_program.md @@ -228,6 +228,7 @@ 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 currently be a **referee** associated with a valid referral set (Note: for a set to be valid, the sets referrer must be meeting the staking requirement.) To become a referee, a referee must submit a signed `ApplyReferralCode` transaction with the following fields: @@ -241,9 +242,30 @@ 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 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 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. If a team exists for this referral set, they will also be added to that team. -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. + +If a party is already a referee, and submits another `ApplyReferralCode` transaction, the transaction will be rejected unless the referrer of the current referral set is not meeting the [staking requirement](#creating-a-referral-set). In this case, the party will be removed from the current referral set and added to the new referral set. + + +### Joining a team + +If a party is already a referee in a valid set, to join or move between teams, a party can submit a `JoinTeam` transaction with the following fields: + +- `id`: the id of the team they wish to join +- `alias`: Optional string defining an alias which should be associated with the key and should appear on leaderboards in the keys place. + +```protobuf +message JoinTeam{ + id: "mYr3f3rra1c0d3" + alias: "myPuBlicA1ias" +} +``` + +The party will be added to the team providing the following criteria are met. + +- the team is not `closed` +- the team has no `allow_list` or the party is specified in the teams `allow_list` ### Party volumes @@ -472,22 +494,26 @@ The Estimate Fees API should now calculate the following additional information: - the party **will** be added to the associated referral set. - the party **will** be added to the associated team (if one exists, the team is not closed, and the party is allowed by the `allow_list`). -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, and the party is allowed by the `allow_list`). 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, and the party is allowed by the `allow_list`). +1. If a party **is** currently a **referee** (and the referrer **is** meeting the staking requirement), if they submit a signed `ApplyReferralCode` transaction then the transaction will be rejected. + 1. If a party submits an `ApplyReferralCode` transaction, a team exists for the specified `id` and the team has **no** `allow_list` specified, then the party **should** be added to the team. 1. If a party submits an `ApplyReferralCode` transaction, a team exists for the specified `id`, and the parties key **is** specified in the teams `allow_list`, then the party **should** be added to the team. 1. If a party submits an `ApplyReferralCode` transaction, a team exists for the specified `id`, but the party key **is not** specified in the teams `allow_list`, then the party **should not** be added to the team. 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). +### Joining a team + +1. If a party submits a `JoinTeam` transaction and the team has **no** `allow_list` specified, then the party **should** be added to the team. +1. If a party submits a `JoinTeam` transaction and the parties key **is** specified in the teams `allow_list`, then the party **should** be added to the team. +1. If a party submits a `JoinTeam` transaction and the party key **is not** specified in the teams `allow_list`, then the party **should not** be added to the team. + #### 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). From 9cb143ce50b8b3961db957e468e348dc29ae7af3 Mon Sep 17 00:00:00 2001 From: Charlie Date: Mon, 20 Nov 2023 11:32:12 +0000 Subject: [PATCH 0795/1171] chore: assign ac codes --- protocol/0083-RFPR-on_chain_referral_program.md | 14 +++++++------- protocol/features.json | 9 ++++++++- 2 files changed, 15 insertions(+), 8 deletions(-) diff --git a/protocol/0083-RFPR-on_chain_referral_program.md b/protocol/0083-RFPR-on_chain_referral_program.md index cf1e846b2..a3dfff4fd 100644 --- a/protocol/0083-RFPR-on_chain_referral_program.md +++ b/protocol/0083-RFPR-on_chain_referral_program.md @@ -500,19 +500,19 @@ The Estimate Fees API should now calculate the following additional information: - 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, and the party is allowed by the `allow_list`). -1. If a party **is** currently a **referee** (and the referrer **is** meeting the staking requirement), if they submit a signed `ApplyReferralCode` transaction then the transaction will be rejected. +1. If a party **is** currently a **referee** (and the referrer **is** meeting the staking requirement), if they submit a signed `ApplyReferralCode` transaction then the transaction will be rejected. (0083-RFPR-052). -1. If a party submits an `ApplyReferralCode` transaction, a team exists for the specified `id` and the team has **no** `allow_list` specified, then the party **should** be added to the team. -1. If a party submits an `ApplyReferralCode` transaction, a team exists for the specified `id`, and the parties key **is** specified in the teams `allow_list`, then the party **should** be added to the team. -1. If a party submits an `ApplyReferralCode` transaction, a team exists for the specified `id`, but the party key **is not** specified in the teams `allow_list`, then the party **should not** be added to the team. +1. If a party submits an `ApplyReferralCode` transaction, a team exists for the specified `id` and the team has **no** `allow_list` specified, then the party **should** be added to the team. (0083-RFPR-053). +1. If a party submits an `ApplyReferralCode` transaction, a team exists for the specified `id`, and the parties key **is** specified in the teams `allow_list`, then the party **should** be added to the team. (0083-RFPR-054). +1. If a party submits an `ApplyReferralCode` transaction, a team exists for the specified `id`, but the party key **is not** specified in the teams `allow_list`, then the party **should not** be added to the team. (0083-RFPR-055). 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). ### Joining a team -1. If a party submits a `JoinTeam` transaction and the team has **no** `allow_list` specified, then the party **should** be added to the team. -1. If a party submits a `JoinTeam` transaction and the parties key **is** specified in the teams `allow_list`, then the party **should** be added to the team. -1. If a party submits a `JoinTeam` transaction and the party key **is not** specified in the teams `allow_list`, then the party **should not** be added to the team. +1. If a party submits a `JoinTeam` transaction and the team has **no** `allow_list` specified, then the party **should** be added to the team. (0083-RFPR-056). +1. If a party submits a `JoinTeam` transaction and the parties key **is** specified in the teams `allow_list`, then the party **should** be added to the team. (0083-RFPR-057). +1. If a party submits a `JoinTeam` transaction and the party key **is not** specified in the teams `allow_list`, then the party **should not** be added to the team. (0083-RFPR-058). #### Epoch and running volumes diff --git a/protocol/features.json b/protocol/features.json index fe4fd46e0..17f63c230 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -55,7 +55,14 @@ "0056-REWA-105", "0056-REWA-106", "0056-REWA-107", - "0056-REWA-108" + "0056-REWA-108", + "0083-RFPR-052", + "0056-REWA-053", + "0056-REWA-054", + "0056-REWA-055", + "0056-REWA-056", + "0056-REWA-057", + "0056-REWA-058" ] }, "Fixed size amendments": { From f7b954b1b1e524983fd53d1ef6b6497e2cf6d5e6 Mon Sep 17 00:00:00 2001 From: Charlie Date: Fri, 8 Dec 2023 13:32:25 +0000 Subject: [PATCH 0796/1171] chore: remove mentions of alias --- protocol/0083-RFPR-on_chain_referral_program.md | 4 ---- 1 file changed, 4 deletions(-) diff --git a/protocol/0083-RFPR-on_chain_referral_program.md b/protocol/0083-RFPR-on_chain_referral_program.md index a3dfff4fd..668724958 100644 --- a/protocol/0083-RFPR-on_chain_referral_program.md +++ b/protocol/0083-RFPR-on_chain_referral_program.md @@ -233,12 +233,10 @@ To apply a referral code and become a referee, a party must fulfil the following To become a referee, a referee must submit a signed `ApplyReferralCode` transaction with the following fields: - `referral_code`: the referral code they wish to apply -- `alias`: Optional string defining an alias which should be associated with the key applying the referral code and should appear on leaderboards in the keys place. ```protobuf message ApplyReferralCode{ id: "mYr3f3rra1c0d3" - alias: "myPuBlicA1ias" } ``` @@ -253,12 +251,10 @@ If a party is already a referee, and submits another `ApplyReferralCode` transac If a party is already a referee in a valid set, to join or move between teams, a party can submit a `JoinTeam` transaction with the following fields: - `id`: the id of the team they wish to join -- `alias`: Optional string defining an alias which should be associated with the key and should appear on leaderboards in the keys place. ```protobuf message JoinTeam{ id: "mYr3f3rra1c0d3" - alias: "myPuBlicA1ias" } ``` From 2b7c5d95040b87432ebc5eb726408d1cb0fcd16a Mon Sep 17 00:00:00 2001 From: Tom Date: Tue, 12 Dec 2023 19:13:52 +0800 Subject: [PATCH 0797/1171] feat: stop order position linked (#2043) * feat: Stop order changes --- protocol/0014-ORDT-order_types.md | 22 ++++++++++++++++++---- protocol/features.json | 10 ++++++++++ 2 files changed, 28 insertions(+), 4 deletions(-) diff --git a/protocol/0014-ORDT-order_types.md b/protocol/0014-ORDT-order_types.md index 9b83d992d..64adfd7b4 100644 --- a/protocol/0014-ORDT-order_types.md +++ b/protocol/0014-ORDT-order_types.md @@ -51,12 +51,12 @@ Notes on scope of current version of this spec: ### Stop orders -In addition to normal immediately executing order, Vega should accept the submission of stop orders. +In addition to normal immediately executing orders, 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. -A stop order submission can be made (stop loss or take profit are probably both just called a stop order internally). +A stop order submission can be made (stop loss or take profit are 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. @@ -71,10 +71,16 @@ 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. - + - An OCO submission can be set to have one of three different behaviours at expiry, either triggering one side, triggering the other, or expire without any action. This is configured through the setting of the expiry behaviour on each leg. Setting each leg to trade at expiration will result in the OCO being rejected. + - The stop order submission wraps a normal order submission. +- A stop order submission may have an optional `Size Override`: + - If unset, the size within the contained normal order submission will be used + - If set to `Position`, triggering should override the contained order's size with the trader's entire current position on the market. + - The `Position` override configuration should also include the option `position_fraction` which determines what proportion of the position is closed when the stop order is triggered. At time of triggering the size of the order will be determined by $fraction \cdot position$. + - All `Position` stop orders existing should be cancelled if a trader's position changes from long to short (or vice versa). + - 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. @@ -347,6 +353,8 @@ In Spot market, for multiple iceberg orders submitted as a batch of orders with - 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) + - An OCO stop order with expiration time `T` with one side set to execute at that time will execute at time `T` if reached without being triggered, with the specified side triggering and the other side cancelling. (0014-ORDT-131) + - An OCO stop order with expiration time `T` with both sides set to execute at that time will be rejected on submission (0014-ORDT-130) - 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) @@ -388,6 +396,12 @@ 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) +## Stop Orders - Linked + +- A stop order with a size override linked to the position of the trader will use the current position as an override of the triggered order size. (0014-ORDT-127) +- All stop orders with a position size override should be cancelled if the trader's position flips sides (long->short or short->long). (0014-ORDT-128) +- A stop order with a position size override with a position_fraction set to 0.75, for a trader with long position 20, should create a stop order for selling size 15 when triggered (0014-ORDT-129) + ## 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: diff --git a/protocol/features.json b/protocol/features.json index 17f63c230..6e6b8ad40 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -251,6 +251,16 @@ "0081-SUCM-036" ] }, + "Position Linked Stop-Orders": { + "milestone": "palazzo", + "acs": [ + "0014-ORDT-127", + "0014-ORDT-128", + "0014-ORDT-129", + "0014-ORDT-130", + "0014-ORDT-131" + ] + }, "Unknown": { "milestone": "unknown", "acs": [] From 88b911cb2685ff92b747f7df11da6fcfb023896c Mon Sep 17 00:00:00 2001 From: Sohill-Patel <85170301+Sohill-Patel@users.noreply.github.com> Date: Mon, 11 Dec 2023 14:47:16 +0000 Subject: [PATCH 0798/1171] fix: correct expected behaviour --- protocol/0019-MCAL-margin_calculator.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/protocol/0019-MCAL-margin_calculator.md b/protocol/0019-MCAL-margin_calculator.md index b5621c545..7df983c64 100644 --- a/protocol/0019-MCAL-margin_calculator.md +++ b/protocol/0019-MCAL-margin_calculator.md @@ -163,13 +163,13 @@ There should be an additional amount `limit price x size x margin factor = 15910 - When the party increases the pegged sell order offset price, the order margin should be reduced (0019-MCAL-057) -- When the party increases the pegged order size and the party's general account does not contain sufficient funds to cover any increases to the order margin account to be equal to side margin then the order should be stopped (0019-MCAL-052) +- When the party increases the pegged order size and the party's general account does not contain sufficient funds to cover any increases to the order margin account to be equal to side margin then the amendment is rejected and the original order is not effected (0019-MCAL-052) -- When the party increases the pegged order price and the party's general account does not contain sufficient funds to cover any increases to the order margin account to be equal to side margin then the order should be stopped (0019-MCAL-075) +- When the party increases the pegged order price and the party's general account does not contain sufficient funds to cover any increases to the order margin account to be equal to side margin then the amendment is rejected and the original order is not effected (0019-MCAL-075) -- When the party increases the pegged order size while decreases the order price and the party's general account does not contain sufficient funds to cover any increases to the order margin account to be equal to side margin then the order should be stopped (0019-MCAL-076) +- When the party increases the pegged order size while decreases the order price and the party's general account does not contain sufficient funds to cover any increases to the order margin account to be equal to side margin then the amendment is rejected and the original order is not effected (0019-MCAL-076) -- When the party increases the pegged order price while decreases the order price and the party's general account does not contain sufficient funds to cover any increases to the order margin account to be equal to side margin then the order should be stopped (0019-MCAL-077) +- When the party increases the pegged order price while decreases the order price and the party's general account does not contain sufficient funds to cover any increases to the order margin account to be equal to side margin then the amendment is rejected and the original order is not effected (0019-MCAL-077) - When the party's pegged order is partially filled, the order margin and general margin should be updated accordingly (0019-MCAL-078) From f2e8b3d5ce1a93c823f88295f6d2141bdd149cb6 Mon Sep 17 00:00:00 2001 From: Sohill-Patel <85170301+Sohill-Patel@users.noreply.github.com> Date: Mon, 11 Dec 2023 16:02:45 +0000 Subject: [PATCH 0799/1171] chore: duplicate ac --- protocol/0019-MCAL-margin_calculator.md | 2 -- 1 file changed, 2 deletions(-) diff --git a/protocol/0019-MCAL-margin_calculator.md b/protocol/0019-MCAL-margin_calculator.md index 7df983c64..eb1872c20 100644 --- a/protocol/0019-MCAL-margin_calculator.md +++ b/protocol/0019-MCAL-margin_calculator.md @@ -169,8 +169,6 @@ There should be an additional amount `limit price x size x margin factor = 15910 - When the party increases the pegged order size while decreases the order price and the party's general account does not contain sufficient funds to cover any increases to the order margin account to be equal to side margin then the amendment is rejected and the original order is not effected (0019-MCAL-076) -- When the party increases the pegged order price while decreases the order price and the party's general account does not contain sufficient funds to cover any increases to the order margin account to be equal to side margin then the amendment is rejected and the original order is not effected (0019-MCAL-077) - - When the party's pegged order is partially filled, the order margin and general margin should be updated accordingly (0019-MCAL-078) **When a party is distressed:** From 9d6e746379e60066a8d5f68d342b1aae00974a5e Mon Sep 17 00:00:00 2001 From: Sohill-Patel <85170301+Sohill-Patel@users.noreply.github.com> Date: Tue, 12 Dec 2023 09:59:06 +0000 Subject: [PATCH 0800/1171] fix: address comments --- protocol/0019-MCAL-margin_calculator.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/protocol/0019-MCAL-margin_calculator.md b/protocol/0019-MCAL-margin_calculator.md index eb1872c20..eaa9a3f36 100644 --- a/protocol/0019-MCAL-margin_calculator.md +++ b/protocol/0019-MCAL-margin_calculator.md @@ -163,11 +163,11 @@ There should be an additional amount `limit price x size x margin factor = 15910 - When the party increases the pegged sell order offset price, the order margin should be reduced (0019-MCAL-057) -- When the party increases the pegged order size and the party's general account does not contain sufficient funds to cover any increases to the order margin account to be equal to side margin then the amendment is rejected and the original order is not effected (0019-MCAL-052) +- When the party increases the pegged order size and the party's general account does not contain sufficient funds to cover any increases to the order margin account to be equal to side margin then the amendment is rejected and the original order is not affected (0019-MCAL-052) -- When the party increases the pegged order price and the party's general account does not contain sufficient funds to cover any increases to the order margin account to be equal to side margin then the amendment is rejected and the original order is not effected (0019-MCAL-075) +- When the party increases the pegged order price and the party's general account does not contain sufficient funds to cover any increases to the order margin account to be equal to side margin then the amendment is rejected and the original order is not affected (0019-MCAL-075) -- When the party increases the pegged order size while decreases the order price and the party's general account does not contain sufficient funds to cover any increases to the order margin account to be equal to side margin then the amendment is rejected and the original order is not effected (0019-MCAL-076) +- When the party increases the pegged order size while decreases the order price and the party's general account does not contain sufficient funds to cover any increases to the order margin account to be equal to side margin then the amendment is rejected and the original order is not affected (0019-MCAL-076) - When the party's pegged order is partially filled, the order margin and general margin should be updated accordingly (0019-MCAL-078) From b5bc413a2d003c2531427f81b69cfc5421b68409 Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Wed, 13 Dec 2023 09:52:50 +0000 Subject: [PATCH 0801/1171] feat: update for pegged order in isolated margin --- protocol/0019-MCAL-margin_calculator.md | 18 +++++------------- 1 file changed, 5 insertions(+), 13 deletions(-) diff --git a/protocol/0019-MCAL-margin_calculator.md b/protocol/0019-MCAL-margin_calculator.md index eaa9a3f36..05cb794f1 100644 --- a/protocol/0019-MCAL-margin_calculator.md +++ b/protocol/0019-MCAL-margin_calculator.md @@ -155,21 +155,11 @@ There should be an additional amount `limit price x size x margin factor = 15910 - When the party's order is partially filled, the order margin and general margin should be updated accordingly (0019-MCAL-048) -- When the party cancels a pegged order, which was their only order, the order margin should be `0`(0019-MCAL-049) +- When the party submit a pegged order, it should be rejected(0019-MCAL-049) -- When the party reduces the pegged order size only, the order margin should be reduced (0019-MCAL-050) +- When the party has pegged orders and switches from cross margin mode to isolated margin mode, all the pegged orders will be stoped. (0019-MCAL-050) -- When the party reduces the pegged buy order offset price, the order margin should be reduced (0019-MCAL-051) - -- When the party increases the pegged sell order offset price, the order margin should be reduced (0019-MCAL-057) - -- When the party increases the pegged order size and the party's general account does not contain sufficient funds to cover any increases to the order margin account to be equal to side margin then the amendment is rejected and the original order is not affected (0019-MCAL-052) - -- When the party increases the pegged order price and the party's general account does not contain sufficient funds to cover any increases to the order margin account to be equal to side margin then the amendment is rejected and the original order is not affected (0019-MCAL-075) - -- When the party increases the pegged order size while decreases the order price and the party's general account does not contain sufficient funds to cover any increases to the order margin account to be equal to side margin then the amendment is rejected and the original order is not affected (0019-MCAL-076) - -- When the party's pegged order is partially filled, the order margin and general margin should be updated accordingly (0019-MCAL-078) +- When the party has iceberg pegged orders and switches from cross margin mode to isolated margin mode, all the iceberg pegged orders will be stoped. (0019-MCAL-051) **When a party is distressed:** @@ -403,6 +393,8 @@ NB: This means that a party's order could partially match, with a trade executed When submitting, amending, or deleting an order in isolated margin mode and an auction is active there is no concept of an order trading immediately on entry, however the case of someone putting in a sell order for a very low price must be handled (as it is likely to execute at a much higher price). To handle this, when in an auction the amount taken into the order margin account should be the larger of either `limit price * size * margin factor` or `max(mark price, indicative uncrossing price) * size * margin factor`. After uncrossing, all remaining open order volume should be rebased back to simply `limit price * size * margin factor` in the order margin account. All other steps are as above. +Pegged orders are not supported in isolated margin mode. + ### Increasing Position When an order trades which increases the position (increasing the absolute value of the trader's position), the target amount to be transferred is calculated as: From cb406f42629f4fdfbdb2f5aeeb1c6b49fca12066 Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Wed, 13 Dec 2023 09:56:33 +0000 Subject: [PATCH 0802/1171] feat: update json --- protocol/features.json | 1 - 1 file changed, 1 deletion(-) diff --git a/protocol/features.json b/protocol/features.json index 6e6b8ad40..430d180aa 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -95,7 +95,6 @@ "0019-MCAL-047", "0019-MCAL-049", "0019-MCAL-051", - "0019-MCAL-052", "0019-MCAL-053", "0019-MCAL-054", "0019-MCAL-055", From 7c1c8590653ac667d1d220e751ce35bb9311dc74 Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Wed, 13 Dec 2023 10:11:18 +0000 Subject: [PATCH 0803/1171] chore: markdown --- protocol/0019-MCAL-margin_calculator.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/protocol/0019-MCAL-margin_calculator.md b/protocol/0019-MCAL-margin_calculator.md index 05cb794f1..34b311ef4 100644 --- a/protocol/0019-MCAL-margin_calculator.md +++ b/protocol/0019-MCAL-margin_calculator.md @@ -157,9 +157,9 @@ There should be an additional amount `limit price x size x margin factor = 15910 - When the party submit a pegged order, it should be rejected(0019-MCAL-049) -- When the party has pegged orders and switches from cross margin mode to isolated margin mode, all the pegged orders will be stoped. (0019-MCAL-050) +- When the party has pegged orders and switches from cross margin mode to isolated margin mode, all the pegged orders will be stopped. (0019-MCAL-050) -- When the party has iceberg pegged orders and switches from cross margin mode to isolated margin mode, all the iceberg pegged orders will be stoped. (0019-MCAL-051) +- When the party has iceberg pegged orders and switches from cross margin mode to isolated margin mode, all the iceberg pegged orders will be stopped. (0019-MCAL-051) **When a party is distressed:** @@ -393,7 +393,7 @@ NB: This means that a party's order could partially match, with a trade executed When submitting, amending, or deleting an order in isolated margin mode and an auction is active there is no concept of an order trading immediately on entry, however the case of someone putting in a sell order for a very low price must be handled (as it is likely to execute at a much higher price). To handle this, when in an auction the amount taken into the order margin account should be the larger of either `limit price * size * margin factor` or `max(mark price, indicative uncrossing price) * size * margin factor`. After uncrossing, all remaining open order volume should be rebased back to simply `limit price * size * margin factor` in the order margin account. All other steps are as above. -Pegged orders are not supported in isolated margin mode. +Pegged orders are not supported in isolated margin mode. ### Increasing Position From 58f6ccde446ac99a52ba24a35bc248eaf7755daa Mon Sep 17 00:00:00 2001 From: Sohill-Patel <85170301+Sohill-Patel@users.noreply.github.com> Date: Thu, 14 Dec 2023 13:53:31 +0000 Subject: [PATCH 0804/1171] feat: more margin pegged order acs --- protocol/0019-MCAL-margin_calculator.md | 26 +++++++++++++++++++++++-- protocol/features.json | 11 +++++++++++ 2 files changed, 35 insertions(+), 2 deletions(-) diff --git a/protocol/0019-MCAL-margin_calculator.md b/protocol/0019-MCAL-margin_calculator.md index 34b311ef4..2b6a13d1e 100644 --- a/protocol/0019-MCAL-margin_calculator.md +++ b/protocol/0019-MCAL-margin_calculator.md @@ -155,11 +155,33 @@ There should be an additional amount `limit price x size x margin factor = 15910 - When the party's order is partially filled, the order margin and general margin should be updated accordingly (0019-MCAL-048) +**Pegged Orders:** + - When the party submit a pegged order, it should be rejected(0019-MCAL-049) -- When the party has pegged orders and switches from cross margin mode to isolated margin mode, all the pegged orders will be stopped. (0019-MCAL-050) +- When the party submit a iceberg pegged order, it should be rejected(0019-MCAL-052) + +- When the party has pegged orders and switches from cross margin mode to isolated margin mode, all the pegged orders will be cancelled. (0019-MCAL-050) + +- When the party has iceberg pegged orders and switches from cross margin mode to isolated margin mode, all the iceberg pegged orders will be cancelled. (0019-MCAL-051) + +- A party with multiple types of orders in cross margin mode switches to isolated margin only their pegged orders are cancelled. (0019-MCAL-057) + +- A market in continuous trading and a party with a partially filled pegged order in cross marging mode switches to isolated margin mode the unfilled portion of the pegged order is cancelled (0019-MCAL-075) + +- A market in continuous trading and a party with a partially filled iceberg pegged order in cross marging mode switches to isolated margin mode the unfilled portion of the pegged order is cancelled (0019-MCAL-078) + +- A market in auction trading and a party with a partially filled pegged order in cross marging mode switches to isolated margin mode the unfilled portion of the pegged order is cancelled (0019-MCAL-147) + +- A market in auction trading and a party with a partially filled iceberg pegged order in cross marging mode switches to isolated margin mode the unfilled portion of the pegged order is cancelled (0019-MCAL-148) + +- A party with a parked pegged order switches from cross margin mode to isolated margin mode, the parked pegged order is cancelled (0019-MCAL-143) + +- A party with a parked iceberg pegged order switches from cross margin mode to isolated margin mode, the parked iceberg pegged order is cancelled (0019-MCAL-144) + +- A market in auction and party with a partially filled pegged order switches from cross marging mode to isolated margin mode the unfilled portion of the pegged order is cancelled (0019-MCAL-145) -- When the party has iceberg pegged orders and switches from cross margin mode to isolated margin mode, all the iceberg pegged orders will be stopped. (0019-MCAL-051) +- A market in an auction and party with a partially filled iceberg pegged order switches from cross marging mode to isolated margin mode the unfilled portion of the iceberg pegged order is cancelled (0019-MCAL-146) **When a party is distressed:** diff --git a/protocol/features.json b/protocol/features.json index 430d180aa..61faafc1f 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -94,11 +94,14 @@ "0019-MCAL-046", "0019-MCAL-047", "0019-MCAL-049", + "0019-MCAL-050", "0019-MCAL-051", + "0019-MCAL-052", "0019-MCAL-053", "0019-MCAL-054", "0019-MCAL-055", "0019-MCAL-056", + "0019-MCAL-057", "0019-MCAL-058", "0019-MCAL-059", "0019-MCAL-060", @@ -108,6 +111,8 @@ "0019-MCAL-065", "0019-MCAL-066", "0019-MCAL-067", + "0019-MCAL-075", + "0019-MCAL-078", "0019-MCAL-100", "0019-MCAL-101", "0019-MCAL-102", @@ -151,6 +156,12 @@ "0019-MCAL-140", "0019-MCAL-141", "0019-MCAL-142", + "0019-MCAL-143", + "0019-MCAL-144", + "0019-MCAL-145", + "0019-MCAL-146", + "0019-MCAL-147", + "0019-MCAL-148", "0074-BTCH-020", "0074-BTCH-021" ] From dbcd9ae367165bbc0121fcdd9c0c27e586ecece7 Mon Sep 17 00:00:00 2001 From: Sohill-Patel <85170301+Sohill-Patel@users.noreply.github.com> Date: Thu, 14 Dec 2023 16:17:52 +0000 Subject: [PATCH 0805/1171] fix: typo marging > margin --- protocol/0019-MCAL-margin_calculator.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/protocol/0019-MCAL-margin_calculator.md b/protocol/0019-MCAL-margin_calculator.md index 2b6a13d1e..7d7fe2e72 100644 --- a/protocol/0019-MCAL-margin_calculator.md +++ b/protocol/0019-MCAL-margin_calculator.md @@ -179,9 +179,9 @@ There should be an additional amount `limit price x size x margin factor = 15910 - A party with a parked iceberg pegged order switches from cross margin mode to isolated margin mode, the parked iceberg pegged order is cancelled (0019-MCAL-144) -- A market in auction and party with a partially filled pegged order switches from cross marging mode to isolated margin mode the unfilled portion of the pegged order is cancelled (0019-MCAL-145) +- A market in auction and party with a partially filled pegged order switches from cross margin mode to isolated margin mode the unfilled portion of the pegged order is cancelled (0019-MCAL-145) -- A market in an auction and party with a partially filled iceberg pegged order switches from cross marging mode to isolated margin mode the unfilled portion of the iceberg pegged order is cancelled (0019-MCAL-146) +- A market in an auction and party with a partially filled iceberg pegged order switches from cross margin mode to isolated margin mode the unfilled portion of the iceberg pegged order is cancelled (0019-MCAL-146) **When a party is distressed:** From 61fc5f426c8779467d5936ce87bd050303c0bcdc Mon Sep 17 00:00:00 2001 From: Sohill-Patel <85170301+Sohill-Patel@users.noreply.github.com> Date: Thu, 14 Dec 2023 16:19:37 +0000 Subject: [PATCH 0806/1171] fix: duplicate ac code --- protocol/0019-MCAL-margin_calculator.md | 2 +- protocol/features.json | 1 + 2 files changed, 2 insertions(+), 1 deletion(-) diff --git a/protocol/0019-MCAL-margin_calculator.md b/protocol/0019-MCAL-margin_calculator.md index 7d7fe2e72..74df44808 100644 --- a/protocol/0019-MCAL-margin_calculator.md +++ b/protocol/0019-MCAL-margin_calculator.md @@ -175,7 +175,7 @@ There should be an additional amount `limit price x size x margin factor = 15910 - A market in auction trading and a party with a partially filled iceberg pegged order in cross marging mode switches to isolated margin mode the unfilled portion of the pegged order is cancelled (0019-MCAL-148) -- A party with a parked pegged order switches from cross margin mode to isolated margin mode, the parked pegged order is cancelled (0019-MCAL-143) +- A party with a parked pegged order switches from cross margin mode to isolated margin mode, the parked pegged order is cancelled (0019-MCAL-149) - A party with a parked iceberg pegged order switches from cross margin mode to isolated margin mode, the parked iceberg pegged order is cancelled (0019-MCAL-144) diff --git a/protocol/features.json b/protocol/features.json index 61faafc1f..7a7442d1b 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -162,6 +162,7 @@ "0019-MCAL-146", "0019-MCAL-147", "0019-MCAL-148", + "0019-MCAL-149", "0074-BTCH-020", "0074-BTCH-021" ] From 84bb696bda01fc5610ba2896ec2d4bf6b43f768e Mon Sep 17 00:00:00 2001 From: Sohill-Patel <85170301+Sohill-Patel@users.noreply.github.com> Date: Thu, 14 Dec 2023 16:21:31 +0000 Subject: [PATCH 0807/1171] fix: more marging typo --- protocol/0019-MCAL-margin_calculator.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/protocol/0019-MCAL-margin_calculator.md b/protocol/0019-MCAL-margin_calculator.md index 74df44808..4a42b5569 100644 --- a/protocol/0019-MCAL-margin_calculator.md +++ b/protocol/0019-MCAL-margin_calculator.md @@ -167,13 +167,13 @@ There should be an additional amount `limit price x size x margin factor = 15910 - A party with multiple types of orders in cross margin mode switches to isolated margin only their pegged orders are cancelled. (0019-MCAL-057) -- A market in continuous trading and a party with a partially filled pegged order in cross marging mode switches to isolated margin mode the unfilled portion of the pegged order is cancelled (0019-MCAL-075) +- A market in continuous trading and a party with a partially filled pegged order in cross margin mode switches to isolated margin mode the unfilled portion of the pegged order is cancelled (0019-MCAL-075) -- A market in continuous trading and a party with a partially filled iceberg pegged order in cross marging mode switches to isolated margin mode the unfilled portion of the pegged order is cancelled (0019-MCAL-078) +- A market in continuous trading and a party with a partially filled iceberg pegged order in cross margin mode switches to isolated margin mode the unfilled portion of the pegged order is cancelled (0019-MCAL-078) -- A market in auction trading and a party with a partially filled pegged order in cross marging mode switches to isolated margin mode the unfilled portion of the pegged order is cancelled (0019-MCAL-147) +- A market in auction trading and a party with a partially filled pegged order in cross margin mode switches to isolated margin mode the unfilled portion of the pegged order is cancelled (0019-MCAL-147) -- A market in auction trading and a party with a partially filled iceberg pegged order in cross marging mode switches to isolated margin mode the unfilled portion of the pegged order is cancelled (0019-MCAL-148) +- A market in auction trading and a party with a partially filled iceberg pegged order in cross margin mode switches to isolated margin mode the unfilled portion of the pegged order is cancelled (0019-MCAL-148) - A party with a parked pegged order switches from cross margin mode to isolated margin mode, the parked pegged order is cancelled (0019-MCAL-149) From ecae56ad46e869bcac0cf8680183a2c77c6e285b Mon Sep 17 00:00:00 2001 From: Sohill-Patel <85170301+Sohill-Patel@users.noreply.github.com> Date: Fri, 15 Dec 2023 12:28:32 +0000 Subject: [PATCH 0808/1171] refactor: remove two acs --- protocol/0028-GOVE-governance.md | 5 ----- protocol/features.json | 4 +--- 2 files changed, 1 insertion(+), 8 deletions(-) diff --git a/protocol/0028-GOVE-governance.md b/protocol/0028-GOVE-governance.md index 0649406e4..62e3eedc7 100644 --- a/protocol/0028-GOVE-governance.md +++ b/protocol/0028-GOVE-governance.md @@ -715,15 +715,10 @@ On top of that signed bundles for changing withdrawal delay and threshold on the - A batch proposal can be submitted changing the same network parameter twice to two different values with two different enactment timestamps. The voting to approve the batch happens, the batch passes, both changes are observed at the desired time. (0028-GOVE-161) -A batch proposal submission must not contain a batch proposal submission (0028-GOVE-162) - A vote cannot be submitted for an individual component in a batch (0028-GOVE-163) When a batch contains two proposals with identical enactment timestamps, they are executed in the order the appear in the batch. For example two network parameter update proposals in the same batch with the same enactment timestamp will both be executed, in the order specified. (0028-GOVE-164) -- A batch proposal can be submitted changing the same network parameter twice to two different values with the same enactment timestamps. -The voting to approve the batch happens, the batch passes, the value of the proposal appearing later in the batch is observed at the desired time. (0028-GOVE-165) - ##### Network History diff --git a/protocol/features.json b/protocol/features.json index 7a7442d1b..8351a4c24 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -208,10 +208,8 @@ "0028-GOVE-149", "0028-GOVE-160", "0028-GOVE-161", - "0028-GOVE-162", "0028-GOVE-163", - "0028-GOVE-164", - "0028-GOVE-165" + "0028-GOVE-164" ] }, "Transfer fee cap": { From 6c9b178e9f7c09281755e72a1d9768ed217d411c Mon Sep 17 00:00:00 2001 From: Sohill-Patel <85170301+Sohill-Patel@users.noreply.github.com> Date: Fri, 15 Dec 2023 12:49:37 +0000 Subject: [PATCH 0809/1171] chore: add 165 back in --- protocol/0028-GOVE-governance.md | 3 +++ protocol/features.json | 3 ++- 2 files changed, 5 insertions(+), 1 deletion(-) diff --git a/protocol/0028-GOVE-governance.md b/protocol/0028-GOVE-governance.md index 62e3eedc7..fdc21a1ac 100644 --- a/protocol/0028-GOVE-governance.md +++ b/protocol/0028-GOVE-governance.md @@ -717,6 +717,9 @@ The voting to approve the batch happens, the batch passes, both changes are obse A vote cannot be submitted for an individual component in a batch (0028-GOVE-163) +- A batch proposal can be submitted changing the same network parameter twice to two different values with the same enactment timestamps. +The voting to approve the batch happens, the batch passes, the value of the proposal appearing later in the batch is observed at the desired time. (0028-GOVE-165) + When a batch contains two proposals with identical enactment timestamps, they are executed in the order the appear in the batch. For example two network parameter update proposals in the same batch with the same enactment timestamp will both be executed, in the order specified. (0028-GOVE-164) diff --git a/protocol/features.json b/protocol/features.json index 8351a4c24..029390334 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -209,7 +209,8 @@ "0028-GOVE-160", "0028-GOVE-161", "0028-GOVE-163", - "0028-GOVE-164" + "0028-GOVE-164", + "0028-GOVE-165" ] }, "Transfer fee cap": { From bb510731e438a86e566e88f5c0de4179d74fd0aa Mon Sep 17 00:00:00 2001 From: Sohill-Patel <85170301+Sohill-Patel@users.noreply.github.com> Date: Fri, 15 Dec 2023 12:52:25 +0000 Subject: [PATCH 0810/1171] chore: position of ac corrected for diff --- 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 fdc21a1ac..6134ac7cc 100644 --- a/protocol/0028-GOVE-governance.md +++ b/protocol/0028-GOVE-governance.md @@ -717,11 +717,11 @@ The voting to approve the batch happens, the batch passes, both changes are obse A vote cannot be submitted for an individual component in a batch (0028-GOVE-163) +When a batch contains two proposals with identical enactment timestamps, they are executed in the order the appear in the batch. For example two network parameter update proposals in the same batch with the same enactment timestamp will both be executed, in the order specified. (0028-GOVE-164) + - A batch proposal can be submitted changing the same network parameter twice to two different values with the same enactment timestamps. The voting to approve the batch happens, the batch passes, the value of the proposal appearing later in the batch is observed at the desired time. (0028-GOVE-165) -When a batch contains two proposals with identical enactment timestamps, they are executed in the order the appear in the batch. For example two network parameter update proposals in the same batch with the same enactment timestamp will both be executed, in the order specified. (0028-GOVE-164) - ##### Network History From 3eecd8875e5f13c74679636a1fad14c5145b1948 Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Tue, 19 Dec 2023 13:01:14 +0000 Subject: [PATCH 0811/1171] feat: update AC --- protocol/0019-MCAL-margin_calculator.md | 92 +++++++++++++------------ protocol/features.json | 23 ++++++- 2 files changed, 69 insertions(+), 46 deletions(-) diff --git a/protocol/0019-MCAL-margin_calculator.md b/protocol/0019-MCAL-margin_calculator.md index 4a42b5569..4d0e750ad 100644 --- a/protocol/0019-MCAL-margin_calculator.md +++ b/protocol/0019-MCAL-margin_calculator.md @@ -125,6 +125,8 @@ There should be an additional amount `limit price x size x margin factor = 15910 - When the mark price moves, the margin account should be updated while order margin account should not (0019-MCAL-067) +- Amend the order (change size) so that new side margin + margin account balance < maintenance margin, the remainding should be stopped (0019-MCAL-068) + **When a party has a position and an order which offsets the position:** - When the party places a new long order of `2` with price `15912` which offsets the existing position, and the market is in continuous trading. The margin account should not change as no additional margin is required (0019-MCAL-038) @@ -139,49 +141,11 @@ There should be an additional amount `limit price x size x margin factor = 15910 **Amending order:** -- When the party cancels all orders, the order margin should be `0`(0019-MCAL-041) - -- When the party reduces the order size only, the order margin should be reduced (0019-MCAL-042) - -- When the party reduces the order price only, the order margin should be reduced (0019-MCAL-043) - -- When the party increases the order size and the party's general account does not contain sufficient funds to cover any increases to the order margin account to be equal to side margin then the order should be stopped (0019-MCAL-044) - -- When the party increases the order price and the party's general account does not contain sufficient funds to cover any increases to the order margin account to be equal to side margin then the order should be stopped (0019-MCAL-045) - -- When the party increases the order size while decreases the order price and the party's general account does not contain sufficient funds to cover any increases to the order margin account to be equal to side margin then the order should be stopped (0019-MCAL-046) - -- When the party increases the order price while decreases the order size and the party's general account does not contain sufficient funds to cover any increases to the order margin account to be equal to side margin then the order should be stopped (0019-MCAL-047) - -- When the party's order is partially filled, the order margin and general margin should be updated accordingly (0019-MCAL-048) - -**Pegged Orders:** - - When the party submit a pegged order, it should be rejected(0019-MCAL-049) -- When the party submit a iceberg pegged order, it should be rejected(0019-MCAL-052) - -- When the party has pegged orders and switches from cross margin mode to isolated margin mode, all the pegged orders will be cancelled. (0019-MCAL-050) - -- When the party has iceberg pegged orders and switches from cross margin mode to isolated margin mode, all the iceberg pegged orders will be cancelled. (0019-MCAL-051) +- When the party has pegged orders and switches from cross margin mode to isolated margin mode, all the pegged orders will be stopped. (0019-MCAL-050) -- A party with multiple types of orders in cross margin mode switches to isolated margin only their pegged orders are cancelled. (0019-MCAL-057) - -- A market in continuous trading and a party with a partially filled pegged order in cross margin mode switches to isolated margin mode the unfilled portion of the pegged order is cancelled (0019-MCAL-075) - -- A market in continuous trading and a party with a partially filled iceberg pegged order in cross margin mode switches to isolated margin mode the unfilled portion of the pegged order is cancelled (0019-MCAL-078) - -- A market in auction trading and a party with a partially filled pegged order in cross margin mode switches to isolated margin mode the unfilled portion of the pegged order is cancelled (0019-MCAL-147) - -- A market in auction trading and a party with a partially filled iceberg pegged order in cross margin mode switches to isolated margin mode the unfilled portion of the pegged order is cancelled (0019-MCAL-148) - -- A party with a parked pegged order switches from cross margin mode to isolated margin mode, the parked pegged order is cancelled (0019-MCAL-149) - -- A party with a parked iceberg pegged order switches from cross margin mode to isolated margin mode, the parked iceberg pegged order is cancelled (0019-MCAL-144) - -- A market in auction and party with a partially filled pegged order switches from cross margin mode to isolated margin mode the unfilled portion of the pegged order is cancelled (0019-MCAL-145) - -- A market in an auction and party with a partially filled iceberg pegged order switches from cross margin mode to isolated margin mode the unfilled portion of the iceberg pegged order is cancelled (0019-MCAL-146) +- When the party has iceberg pegged orders and switches from cross margin mode to isolated margin mode, all the iceberg pegged orders will be stopped. (0019-MCAL-051) **When a party is distressed:** @@ -219,8 +183,6 @@ There should be an additional amount `limit price x size x margin factor = 15910 - switch to isolated margin without position and no orders with margin factor such that there is insufficient balance in the general account in continuous mode(0019-MCAL-110) -- switch to isolated margin without position and no orders with margin factor such that there is insufficient balance in the general account in auction mode(0019-MCAL-111) - - switch to isolated margin with position and no orders with margin factor such that there is insufficient balance in the general account in continuous mode(0019-MCAL-112) - switch to isolated margin with position and no orders with margin factor such that there is insufficient balance in the general account in auction mode(0019-MCAL-113) @@ -234,8 +196,6 @@ There should be an additional amount `limit price x size x margin factor = 15910 - update margin factor when already in isolated mode to the same cases as in switch to isolated failures.(0019-MCAL-117) -- switch to isolated margin without position and no orders successful in continuous mode(0019-MCAL-118) - - switch to isolated margin without position and no orders successful in auction(0019-MCAL-119) - switch to isolated margin with position and no orders successful in continuous mode(0019-MCAL-120) @@ -282,6 +242,49 @@ There should be an additional amount `limit price x size x margin factor = 15910 - switch to cross margin with position and with orders successful in auction(0019-MCAL-141) +**Check order margin:** + +- when party has no position, and place 2 short orders during auction, order margin should be updated(0019-MCAL-200) + +- when party has no position, and place short orders size -3 during auction, and long order size 1 which can offset, order margin should be updated using max(price, markPrice, indicativePrice)(0019-MCAL-201) + +- when party has no position, and place short orders size -3 during auction, and long orders size 2 which can offset, order margin should be updated using max(price, markPrice, indicativePrice)(0019-MCAL-202) + +- when party has no position, and place short orders size -3 during auction, and long orders size 3 which can offset, order margin should be updated using max(price, markPrice, indicativePrice)(0019-MCAL-203) + +- when party has no position, and place short orders size -3 during auction, and long orders size 4, which is over the offset size, order margin should be updated using max(price, markPrice, indicativePrice)(0019-MCAL-204) + +- When the party changes the order price during auction, order margin should be updated using max(price, markPrice, indicativePrice)(0019-MCAL-205) + +- When the party reduces the order size only during auction, the order margin should be reduced (0019-MCAL-206) + +- when party has no position, and place 2 short orders size 3 and 4 long orders of size 4, which is over the offset size, order margin should be updated using max(price, markPrice, indicativePrice)(0019-MCAL-207) + +- GFA order added during auction should not be used to count order margin in continuous(0019-MCAL-220) + +- when party has no position, and place 2 short orders during auction, order margin should be updated(0019-MCAL-221) + +- When the party cancel one of the two orders during continunous, order margin should be reducedWhen the party increases the order price during continunous, order margin should increase(0019-MCAL-222) + +- When the party decreases the order price during continunous, order margin should decrease(0019-MCAL-223) + +- When the party decreases the order volume during continunous, order margin should decrease(0019-MCAL-224) + +- When the party increases the order volume while decrease price during continunous, order margin should update accordingly(0019-MCAL-225) + +- When the party's order is partially filled during continunous, order margin should update accordingly(0019-MCAL-226) + +- When the party cancel one of the two orders during continunous, order margin should be reduced(0019-MCAL-227) + +- place a GFA order duing continuous, order should be rejected(0019-MCAL-228) + +- When the party has position -1 and order -3, and new long order with size 1 will be offset(0019-MCAL-229) + +- When the party has position -1 and order -3, and new long orders with size 2 will be offset(0019-MCAL-230) + +- When the party has position -1 and order -3, and new long orders with size 3 will be offset(0019-MCAL-231) + + **Check decimals:** - A feature test that checks margin in case market PDP > 0 is created and passes. (0019-MCAL-090) @@ -753,3 +756,4 @@ riskiest short: -1 Scenarios found [here](https://docs.google.com/spreadsheets/d/1VXMdpgyyA9jp0hoWcIQTUFrhOdtu-fak/edit#gid=1586131462) + diff --git a/protocol/features.json b/protocol/features.json index 029390334..be58bd876 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -111,6 +111,7 @@ "0019-MCAL-065", "0019-MCAL-066", "0019-MCAL-067", + "0019-MCAL-068", "0019-MCAL-075", "0019-MCAL-078", "0019-MCAL-100", @@ -124,14 +125,12 @@ "0019-MCAL-108", "0019-MCAL-109", "0019-MCAL-110", - "0019-MCAL-111", "0019-MCAL-112", "0019-MCAL-113", "0019-MCAL-114", "0019-MCAL-115", "0019-MCAL-116", "0019-MCAL-117", - "0019-MCAL-118", "0019-MCAL-119", "0019-MCAL-120", "0019-MCAL-121", @@ -163,6 +162,26 @@ "0019-MCAL-147", "0019-MCAL-148", "0019-MCAL-149", + "0019-MCAL-200", + "0019-MCAL-201", + "0019-MCAL-202", + "0019-MCAL-203", + "0019-MCAL-204", + "0019-MCAL-205", + "0019-MCAL-206", + "0019-MCAL-207", + "0019-MCAL-220", + "0019-MCAL-221", + "0019-MCAL-222", + "0019-MCAL-223", + "0019-MCAL-224", + "0019-MCAL-225", + "0019-MCAL-226", + "0019-MCAL-227", + "0019-MCAL-228", + "0019-MCAL-229", + "0019-MCAL-230", + "0019-MCAL-231", "0074-BTCH-020", "0074-BTCH-021" ] From 84cd4a5c4f836d8c2cd693878422505fa252dca1 Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Tue, 19 Dec 2023 13:09:07 +0000 Subject: [PATCH 0812/1171] feat: add back pegged order AC --- protocol/0019-MCAL-margin_calculator.md | 24 ++++++++++++++++++++++-- 1 file changed, 22 insertions(+), 2 deletions(-) diff --git a/protocol/0019-MCAL-margin_calculator.md b/protocol/0019-MCAL-margin_calculator.md index 4d0e750ad..2ed3e58ef 100644 --- a/protocol/0019-MCAL-margin_calculator.md +++ b/protocol/0019-MCAL-margin_calculator.md @@ -143,9 +143,29 @@ There should be an additional amount `limit price x size x margin factor = 15910 - When the party submit a pegged order, it should be rejected(0019-MCAL-049) -- When the party has pegged orders and switches from cross margin mode to isolated margin mode, all the pegged orders will be stopped. (0019-MCAL-050) +- When the party submit a iceberg pegged order, it should be rejected(0019-MCAL-052) -- When the party has iceberg pegged orders and switches from cross margin mode to isolated margin mode, all the iceberg pegged orders will be stopped. (0019-MCAL-051) +- When the party has pegged orders and switches from cross margin mode to isolated margin mode, all the pegged orders will be cancelled. (0019-MCAL-050) + +- When the party has iceberg pegged orders and switches from cross margin mode to isolated margin mode, all the iceberg pegged orders will be cancelled. (0019-MCAL-051) + +A party with multiple types of orders in cross margin mode switches to isolated margin only their pegged orders are cancelled. (0019-MCAL-057) + +- A market in continuous trading and a party with a partially filled pegged order in cross margin mode switches to isolated margin mode the unfilled portion of the pegged order is cancelled (0019-MCAL-075) + +- A market in continuous trading and a party with a partially filled iceberg pegged order in cross margin mode switches to isolated margin mode the unfilled portion of the pegged order is cancelled (0019-MCAL-078) + +- A market in auction trading and a party with a partially filled pegged order in cross margin mode switches to isolated margin mode the unfilled portion of the pegged order is cancelled (0019-MCAL-147) + +- A market in auction trading and a party with a partially filled iceberg pegged order in cross margin mode switches to isolated margin mode the unfilled portion of the pegged order is cancelled (0019-MCAL-148) + +- A party with a parked pegged order switches from cross margin mode to isolated margin mode, the parked pegged order is cancelled (0019-MCAL-149) + +- A party with a parked iceberg pegged order switches from cross margin mode to isolated margin mode, the parked iceberg pegged order is cancelled (0019-MCAL-144) + +- A market in auction and party with a partially filled pegged order switches from cross margin mode to isolated margin mode the unfilled portion of the pegged order is cancelled (0019-MCAL-145) + +- A market in an auction and party with a partially filled iceberg pegged order switches from cross margin mode to isolated margin mode the unfilled portion of the iceberg pegged order is cancelled (0019-MCAL-146) **When a party is distressed:** From 1360f22b6e1d825074d5aafef6883a1415b94756 Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Tue, 19 Dec 2023 13:14:30 +0000 Subject: [PATCH 0813/1171] chore: markdown --- protocol/0019-MCAL-margin_calculator.md | 32 ++++++++++++------------- protocol/features.json | 7 ------ 2 files changed, 15 insertions(+), 24 deletions(-) diff --git a/protocol/0019-MCAL-margin_calculator.md b/protocol/0019-MCAL-margin_calculator.md index 2ed3e58ef..de419b6cf 100644 --- a/protocol/0019-MCAL-margin_calculator.md +++ b/protocol/0019-MCAL-margin_calculator.md @@ -125,7 +125,7 @@ There should be an additional amount `limit price x size x margin factor = 15910 - When the mark price moves, the margin account should be updated while order margin account should not (0019-MCAL-067) -- Amend the order (change size) so that new side margin + margin account balance < maintenance margin, the remainding should be stopped (0019-MCAL-068) +- Amend the order (change size) so that new side margin + margin account balance < maintenance margin, the remaining should be stopped (0019-MCAL-068) **When a party has a position and an order which offsets the position:** @@ -149,7 +149,7 @@ There should be an additional amount `limit price x size x margin factor = 15910 - When the party has iceberg pegged orders and switches from cross margin mode to isolated margin mode, all the iceberg pegged orders will be cancelled. (0019-MCAL-051) -A party with multiple types of orders in cross margin mode switches to isolated margin only their pegged orders are cancelled. (0019-MCAL-057) +- A party with multiple types of orders in cross margin mode switches to isolated margin only their pegged orders are cancelled. (0019-MCAL-057) - A market in continuous trading and a party with a partially filled pegged order in cross margin mode switches to isolated margin mode the unfilled portion of the pegged order is cancelled (0019-MCAL-075) @@ -266,37 +266,37 @@ A party with multiple types of orders in cross margin mode switches to isolated - when party has no position, and place 2 short orders during auction, order margin should be updated(0019-MCAL-200) -- when party has no position, and place short orders size -3 during auction, and long order size 1 which can offset, order margin should be updated using max(price, markPrice, indicativePrice)(0019-MCAL-201) +- when party has no position, and place short orders size -3 during auction, and long order size 1 which can offset, order margin should be updated using max(price, mark Price, indicative Price)(0019-MCAL-201) -- when party has no position, and place short orders size -3 during auction, and long orders size 2 which can offset, order margin should be updated using max(price, markPrice, indicativePrice)(0019-MCAL-202) +- when party has no position, and place short orders size -3 during auction, and long orders size 2 which can offset, order margin should be updated using max(price, mark Price, indicative Price)(0019-MCAL-202) -- when party has no position, and place short orders size -3 during auction, and long orders size 3 which can offset, order margin should be updated using max(price, markPrice, indicativePrice)(0019-MCAL-203) +- when party has no position, and place short orders size -3 during auction, and long orders size 3 which can offset, order margin should be updated using max(price, mark Price, indicative Price)(0019-MCAL-203) -- when party has no position, and place short orders size -3 during auction, and long orders size 4, which is over the offset size, order margin should be updated using max(price, markPrice, indicativePrice)(0019-MCAL-204) +- when party has no position, and place short orders size -3 during auction, and long orders size 4, which is over the offset size, order margin should be updated using max(price, mark Price, indicative Price)(0019-MCAL-204) -- When the party changes the order price during auction, order margin should be updated using max(price, markPrice, indicativePrice)(0019-MCAL-205) +- When the party changes the order price during auction, order margin should be updated using max(price, mark Price, indicativePrice)(0019-MCAL-205) - When the party reduces the order size only during auction, the order margin should be reduced (0019-MCAL-206) -- when party has no position, and place 2 short orders size 3 and 4 long orders of size 4, which is over the offset size, order margin should be updated using max(price, markPrice, indicativePrice)(0019-MCAL-207) +- when party has no position, and place 2 short orders size 3 and 4 long orders of size 4, which is over the offset size, order margin should be updated using max(price, mark Price, indicativePrice)(0019-MCAL-207) - GFA order added during auction should not be used to count order margin in continuous(0019-MCAL-220) - when party has no position, and place 2 short orders during auction, order margin should be updated(0019-MCAL-221) -- When the party cancel one of the two orders during continunous, order margin should be reducedWhen the party increases the order price during continunous, order margin should increase(0019-MCAL-222) +- When the party cancel one of the two orders during continuous, order margin should be reduced. When the party increases the order price during continuous, order margin should increase(0019-MCAL-222) -- When the party decreases the order price during continunous, order margin should decrease(0019-MCAL-223) +- When the party decreases the order price during continuous, order margin should decrease(0019-MCAL-223) -- When the party decreases the order volume during continunous, order margin should decrease(0019-MCAL-224) +- When the party decreases the order volume during continuous, order margin should decrease(0019-MCAL-224) -- When the party increases the order volume while decrease price during continunous, order margin should update accordingly(0019-MCAL-225) +- When the party increases the order volume while decrease price during continuous, order margin should update accordingly(0019-MCAL-225) -- When the party's order is partially filled during continunous, order margin should update accordingly(0019-MCAL-226) +- When the party's order is partially filled during continuous, order margin should update accordingly(0019-MCAL-226) -- When the party cancel one of the two orders during continunous, order margin should be reduced(0019-MCAL-227) +- When the party cancel one of the two orders during continuous, order margin should be reduced(0019-MCAL-227) -- place a GFA order duing continuous, order should be rejected(0019-MCAL-228) +- place a GFA order during continuous, order should be rejected(0019-MCAL-228) - When the party has position -1 and order -3, and new long order with size 1 will be offset(0019-MCAL-229) @@ -775,5 +775,3 @@ riskiest short: -1 ## SCENARIOS Scenarios found [here](https://docs.google.com/spreadsheets/d/1VXMdpgyyA9jp0hoWcIQTUFrhOdtu-fak/edit#gid=1586131462) - - diff --git a/protocol/features.json b/protocol/features.json index be58bd876..9343b0786 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -86,13 +86,6 @@ "0019-MCAL-038", "0019-MCAL-039", "0019-MCAL-040", - "0019-MCAL-041", - "0019-MCAL-042", - "0019-MCAL-043", - "0019-MCAL-044", - "0019-MCAL-045", - "0019-MCAL-046", - "0019-MCAL-047", "0019-MCAL-049", "0019-MCAL-050", "0019-MCAL-051", From dbdda61f6cb305540a7079c8fc222e8ad7160db0 Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Tue, 19 Dec 2023 13:18:04 +0000 Subject: [PATCH 0814/1171] chore: typo --- protocol/0019-MCAL-margin_calculator.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/protocol/0019-MCAL-margin_calculator.md b/protocol/0019-MCAL-margin_calculator.md index de419b6cf..3896127ef 100644 --- a/protocol/0019-MCAL-margin_calculator.md +++ b/protocol/0019-MCAL-margin_calculator.md @@ -274,11 +274,11 @@ There should be an additional amount `limit price x size x margin factor = 15910 - when party has no position, and place short orders size -3 during auction, and long orders size 4, which is over the offset size, order margin should be updated using max(price, mark Price, indicative Price)(0019-MCAL-204) -- When the party changes the order price during auction, order margin should be updated using max(price, mark Price, indicativePrice)(0019-MCAL-205) +- When the party changes the order price during auction, order margin should be updated using max(price, mark Price, indicative Price)(0019-MCAL-205) - When the party reduces the order size only during auction, the order margin should be reduced (0019-MCAL-206) -- when party has no position, and place 2 short orders size 3 and 4 long orders of size 4, which is over the offset size, order margin should be updated using max(price, mark Price, indicativePrice)(0019-MCAL-207) +- when party has no position, and place 2 short orders size 3 and 4 long orders of size 4, which is over the offset size, order margin should be updated using max(price, mark Price, indicative Price)(0019-MCAL-207) - GFA order added during auction should not be used to count order margin in continuous(0019-MCAL-220) From 114d119cabe9b5cba1693e295d957db5cde1b52e Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Thu, 21 Dec 2023 10:23:37 +0000 Subject: [PATCH 0815/1171] feat: update market state duing name changing --- 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 6134ac7cc..1195fcf6d 100644 --- a/protocol/0028-GOVE-governance.md +++ b/protocol/0028-GOVE-governance.md @@ -546,8 +546,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 market change proposal that aims to modify the market name in any state will modify the market name at the time of vote enactment. (0028-GOVE-159) -- A market change proposal that aims to modify the market code in any state will modify the market code at the time of vote enactment. (0028-GOVE-166) +- A market change proposal that aims to modify the market name in any state (apart from closed/terminated) will modify the market name at the time of vote enactment. (0028-GOVE-159) +- A market change proposal that aims to modify the market code in any state (apart from closed/terminated) will modify the market code at the time of vote enactment. (0028-GOVE-166) - 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 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) From e78a80d4b19cc054f43149abb00203643e35c84a Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Thu, 21 Dec 2023 15:56:39 +0000 Subject: [PATCH 0816/1171] feat: address comment --- 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 1195fcf6d..64a7eb678 100644 --- a/protocol/0028-GOVE-governance.md +++ b/protocol/0028-GOVE-governance.md @@ -239,7 +239,7 @@ A market in Proposed state accepts [liquidity commitments](./0044-LIME-lp_mechan [Market parameters](./0001-MKTF-market_framework.md#market) that may be changed are described in the spec for the Market Framework, and additionally the specs for the Risk Model and Product being used by the market. See the [Market Framework spec](./0001-MKTF-market_framework.md#market) for details on these parameters, including those that cannot be changed and the category of the parameters. -To change any market parameter the proposer submits the same data as to create a market with the desired updates to the fields / structures that should change. +To change any market parameter the proposer submits the same data as to create a market with the desired updates to the fields / structures that should change. Changes for markets in a closed/canceled/terminated state should not be permitted. Ideally, it should be possible to not repeat things that are not changing or are immutable but we leave this to implementation detail. The following are immutable and cannot be changed: From e789dd499042dbacbd168c8421f22580034ab30a Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Thu, 21 Dec 2023 16:05:03 +0000 Subject: [PATCH 0817/1171] chore: typo --- 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 64a7eb678..9f3c3c2e4 100644 --- a/protocol/0028-GOVE-governance.md +++ b/protocol/0028-GOVE-governance.md @@ -239,7 +239,7 @@ A market in Proposed state accepts [liquidity commitments](./0044-LIME-lp_mechan [Market parameters](./0001-MKTF-market_framework.md#market) that may be changed are described in the spec for the Market Framework, and additionally the specs for the Risk Model and Product being used by the market. See the [Market Framework spec](./0001-MKTF-market_framework.md#market) for details on these parameters, including those that cannot be changed and the category of the parameters. -To change any market parameter the proposer submits the same data as to create a market with the desired updates to the fields / structures that should change. Changes for markets in a closed/canceled/terminated state should not be permitted. +To change any market parameter the proposer submits the same data as to create a market with the desired updates to the fields / structures that should change. Changes for markets in a closed/cancelled/terminated state should not be permitted. Ideally, it should be possible to not repeat things that are not changing or are immutable but we leave this to implementation detail. The following are immutable and cannot be changed: From 7b4bdc884bed9cd88d1c18b252d670bb289c9b20 Mon Sep 17 00:00:00 2001 From: David Siska <62546419+davidsiska-vega@users.noreply.github.com> Date: Sat, 30 Dec 2023 11:00:44 +0000 Subject: [PATCH 0818/1171] feat: mark price updates ACs --- protocol/0009-MRKP-mark_price.md | 74 +++++++++---------- ...3-PERP-product_builtin_perpetual_future.md | 14 +++- 2 files changed, 45 insertions(+), 43 deletions(-) diff --git a/protocol/0009-MRKP-mark_price.md b/protocol/0009-MRKP-mark_price.md index 353389907..d8c838b07 100644 --- a/protocol/0009-MRKP-mark_price.md +++ b/protocol/0009-MRKP-mark_price.md @@ -6,70 +6,62 @@ A *Mark Price* is a concept derived from traditional markets. It is a calculate Introduce a network parameter `network.markPriceUpdateMaximumFrequency` with minimum allowable value of `0s` maximum allowable value of `1h` and a default of `5s`. -## Acceptance criteria - -- 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) -- 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) - -## Guide-level explanation - The *Mark Price* represents the "current" market value for an instrument that is being traded on a market on Vega. It is a calculated value primarily used to value trader's open portfolios against the prices they executed their trades at. Specifically, it is used to calculate the cash flows for [mark-to-market settlement](./0003-MTMK-mark_to_market_settlement.md). -Note that a mark price may not be a true "price" in the financial sense of the word, i.e. if the `price` changes by `X` then the value of a position does not necessarily change by `X * position size`, instead, the product's quote-to-value function must be used to ascertain the change, i.e. `change_in_value == product.value(new_mark_price) - product.value(old_mark_price)`. - -## Reference-level explanation - The mark price is instantiated when a market opens via the [opening auction](./0026-AUCT-auctions.md). It will subsequently be calculated according to a methodology selected from a suite of algorithms. The selection of the algorithm for calculating the *Mark Price* is specified at the "market" level as a market parameter. -Mark price can also be adjusted by [product lifecycle events](./0051-PROD-product.md), in which case the mark price set by the product remains the mark price until it is next recalculated (e.g. if the methodology is last traded price, until there is a new trade). +## Algorithms for calculating the *Mark Price* -## Usage of the *Mark Price* +### 1. Last Traded Price of a Sequence with same time stamp with maximum frequency set by `network.markPriceUpdateMaximumFrequency` -The most recently calculated *Mark Price* is used in the [mark-to-market settlement](./0003-MTMK-mark_to_market_settlement.md). A change in the *Mark Price* is one of the triggers for the mark-to-market settlement to run. +The mark price for the instrument is set to the last trade price in the market following processing of each transaction (i.e. submit/amend/delete order) from a sequence of transactions with the same time stamp, provided that at least `network.markPriceUpdateMaximumFrequency` has elapsed since the last mark price update. -## Algorithms for calculating the *Mark Price* +>*Example:* Assume `network.markPriceUpdateMaximumFrequency = 10s`. -### 1. Last Traded Price of a Sequence with same time stamp with maximum frequency set by `network.markPriceUpdateMaximumFrequency` +Consider the situation where the mark price was last updated to $900 and this was 12s ago. There is a market sell order for -20 and a market buy order for +100 with the same time stamp. The sell order results in two trades: 15 @ 920 and 5 @ 910. The buy order results in 3 trades; 50 @ $1000, 25 @ $1100 and 25 @ $1200, the mark price changes **once** to a new value of $1200. - The mark price for the instrument is set to the last trade price in the market following processing of each transaction (i.e. submit/amend/delete order) from a sequence of transactions with the same time stamp, provided that at least `network.markPriceUpdateMaximumFrequency` has elapsed since the last mark price update. +Now 8s has elapsed since the last update and there is a market sell order for volume 3 which executes against book volume as 1 @ 1190 and 2 @ 1100. +The mark price isn't updated because `network.markPriceUpdateMaximumFrequency = 10s` has not elapsed yet. - >*Example:* Assume `network.markPriceUpdateMaximumFrequency = 10s`. +Now 10.1s has elapsed since the last update and there is a market buy order for volume 5 which executes against book volume as 1 @ 1220, 2 @ 1250 and 2 @ 1500. The mark price is updated to 1500. - Consider the situation where the mark price was last updated to $900 and this was 12s ago. There is a market sell order for -20 and a market buy order for +100 with the same time stamp. The sell order results in two trades: 15 @ 920 and 5 @ 910. The buy order results in 3 trades; 50 @ $1000, 25 @ $1100 and 25 @ $1200, the mark price changes **once** to a new value of $1200. - Now 8s has elapsed since the last update and there is a market sell order for volume 3 which executes against book volume as 1 @ 1190 and 2 @ 1100. - The mark price isn't updated because `network.markPriceUpdateMaximumFrequency = 10s` has not elapsed yet. +### 2. Flexible mark price methodology - Now 10.1s has elapsed since the last update and there is a market buy order for volume 5 which executes against book volume as 1 @ 1220, 2 @ 1250 and 2 @ 1500. The mark price is updated to 1500. +The calculations are specified in [markprice methodology research note](https://github.com/vegaprotocol/research/blob/markprice-updates/papers/markprice-methodology/markprice-methodology.tex). +Here, we only write the acceptance criteria. +Note that for calculating the median with an even number of entries we sort, pick out the two values that are in the middle of the list and average those. So in particular with two values a median is the same as the average for our purposes. -### 2. Last Traded Price + Order Book -The mark price is set to the higher / lower of the last traded price, bid/offer. +## Acceptance criteria + +- 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 (last trade price, excluding network trades): + +- 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) ->*Example a):* consider the last traded price was $1000 and the current best bid in the market is $1,100. The bid price is higher than the last traded price so the new Mark Price is $1,100. ->*Example b):* consider the last traded price was $1000 and the current best bid in the market is $999. The last traded price is higher than the bid price so the new Mark Price is $1,000. -### 3. Oracle +### Flexible mark price methodology, no combinations yet - An oracle source external to the market provides updates to the Mark Price. See the [data sourcing spec](./0045-DSRC-data_sourcing.md). +- It is possible to configure a cash settled futures market to use Algorithm 1 (ie last trade price) (0009-MRKP-007) and a perps market (0009-MRKP-008). +- It is possible to configure a cash settled futures market to use weighted average of trades over `network.markPriceUpdateMaximumFrequency` with decay weight `1` and power `1` (linear decay) (0009-MRKP-009) and a perps market (0009-MRKP-010). +- It is possible to configure a cash settled futures market to use impact of leveraged notional on the order book with the value of USDT `100` for mark price (0009-MRKP-011) and a perps market (0009-MRKP-012). +- It is possible to configure a cash settled futures market to use an oracle source for the mark price (0009-MRKP-013) and a perps market (with the oracle source different to that used for the external price in the perps market) (0009-MRKP-014). -### 4. Model +### Flexible mark price methodology, combinations - The *Mark Price* may be calculated using a built in model. +- It is possible to configure a cash settled futures market to use a weighted average of 1. weighted average of trades over `network.markPriceUpdateMaximumFrequency` and 2. impact of leveraged notional on the order book with the value of USDT `100` and 3. an oracle source and if last trade is last updated more than 1 minute ago then it is removed and the remaining re-weighted and if the oracle is last updated more than 5 minutes ago then it is removed and the remaining re-weighted (0009-MRKP-015) and a perps market (with the oracle source different to that used for the external price in the perps market) (0009-MRKP-016). - >*Example:* An option price will theoretically decay with time even if the market's order book or trade history does not reflect this. +- It is possible to configure a cash settled futures market to use a weighted average of 1. weighted average of trades over `network.markPriceUpdateMaximumFrequency` and 2. impact of leveraged notional on the order book with the value of USDT `100` and if last trade is last updated more than 1 minute ago then it is removed and the remaining re-weighted and if the oracle is last updated more than 5 minutes ago then it is removed and the remaining re-weighted and if both sources are stale than the mark price stops updating (0009-MRKP-017) and a perps market (0009-MRKP-018). -### 5. Defined as part of the product +- It is possible to configure a cash settled futures market to use a median of 1. weighted average of trades over `network.markPriceUpdateMaximumFrequency` and 2. impact of leveraged notional on the order book with the value of USDT `100` and 3. an oracle source and if last trade is last updated more than 1 minute ago then it is removed and if the oracle is last updated more than 5 minutes ago then it is removed (0009-MRKP-019) and a perps market (with the oracle source different to that used for the external price in the perps market) (0009-MRKP-020). - The *Mark Price* may be calculated using an algorithm defined by the product -- and 'selected' by a market parameter. diff --git a/protocol/0053-PERP-product_builtin_perpetual_future.md b/protocol/0053-PERP-product_builtin_perpetual_future.md index 348ebe9a7..1ae2529cd 100644 --- a/protocol/0053-PERP-product_builtin_perpetual_future.md +++ b/protocol/0053-PERP-product_builtin_perpetual_future.md @@ -4,9 +4,12 @@ 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 two 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 (funding payment) 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. +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 either: +- the mark price of the market to approximate $F_u$ or +- configure the "market price for funding purposes" as part of the market proposal and use this methodology 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 @@ -334,3 +337,10 @@ When migrating the market existing prior to introduction of the additional param - $\text{rate_lower_bound}= -\text{max supported value}$, - $\text{rate_upper_bound}= \text{max supported value}$ (0053-PERP-032). + +It is possible to create a perpetual futures market which uses the last traded price algorithm for its mark price but uses "impact volume of notional of 1000 USDT" for the purpose of calculating the TWAP of the market price for funding payments (0053-PERP-033). + +It is possible to create a perpetual futures market which uses an oraclo source (same as that used for funding) for the mark price determining the mark-to-market cashflows and that uses "impact volume of notional of 1000 USDT" for the purpose of calculating the TWAP of the market price for funding payments (0053-PERP-034). + +It is possible to create a perpetual futures market which uses an oraclo source (same as that used for funding) for the mark price determining the mark-to-market cashflows and that uses "time-weighted trade prices in over `network.markPriceUpdateMaximumFrequency` if these have been updated within the last 30s but falls back onto impact volume of notional of 1000 USDT" for the purpose of calculating the TWAP of the market price for funding payments (0053-PERP-034). + From 7c072d74d733ee45daf50bd2875e9ac49b2478aa Mon Sep 17 00:00:00 2001 From: Sohill-Patel <85170301+Sohill-Patel@users.noreply.github.com> Date: Wed, 3 Jan 2024 11:40:43 +0000 Subject: [PATCH 0819/1171] fix: replace withdrawal limit > maximumLifetimeDeposit --- 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 9f3c3c2e4..1f1bae558 100644 --- a/protocol/0028-GOVE-governance.md +++ b/protocol/0028-GOVE-governance.md @@ -701,7 +701,7 @@ It is NOT possible to submit a governance proposal where the source account is t - A batch proposal containing 1. freeform proposal, - 1. an update asset proposal changing the asset quantum, withdrawal delay and withdrawal delay threshold + 1. an update asset proposal changing the asset quantum, maximumLifetimeDeposit and withdrawal delay threshold 1. a network parameter change, 1. a market proposal, 1. a change proposal for another market, From d9dbef1b0e066a2ec265eab524b5c9e22b5baf24 Mon Sep 17 00:00:00 2001 From: Sohill-Patel <85170301+Sohill-Patel@users.noreply.github.com> Date: Wed, 3 Jan 2024 11:46:33 +0000 Subject: [PATCH 0820/1171] fix: spellcheck --- 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 1f1bae558..d29c11836 100644 --- a/protocol/0028-GOVE-governance.md +++ b/protocol/0028-GOVE-governance.md @@ -701,7 +701,7 @@ It is NOT possible to submit a governance proposal where the source account is t - A batch proposal containing 1. freeform proposal, - 1. an update asset proposal changing the asset quantum, maximumLifetimeDeposit and withdrawal delay threshold + 1. an update asset proposal changing the asset quantum, maximum lifetime deposit and withdrawal delay threshold 1. a network parameter change, 1. a market proposal, 1. a change proposal for another market, From acf524102574b20ecb58cbf33ce8646775858f1e Mon Sep 17 00:00:00 2001 From: Charlie <99198652+cdummett@users.noreply.github.com> Date: Wed, 3 Jan 2024 15:57:50 +0000 Subject: [PATCH 0821/1171] feat: update meaning of closed and allow_list team fields (#2090) * feat: change meaning of closed and allow_list * chore: reassign AC codes * fix: update wordlist --- .../0083-RFPR-on_chain_referral_program.md | 38 +++++++++---------- protocol/features.json | 14 ++++--- wordlist.txt | 1 + 3 files changed, 26 insertions(+), 27 deletions(-) diff --git a/protocol/0083-RFPR-on_chain_referral_program.md b/protocol/0083-RFPR-on_chain_referral_program.md index 668724958..a591de070 100644 --- a/protocol/0083-RFPR-on_chain_referral_program.md +++ b/protocol/0083-RFPR-on_chain_referral_program.md @@ -144,8 +144,8 @@ To create a referral set and generate a referral code, the party must submit a s - `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`: optional string of a link to an image to be used as the teams avatar (defaults to empty string / none-type) - - `allow_list`: optional list of public keys which are allowed to join the team. If empty, all public keys are allowed to join the team. - - `closed`: optional boolean, defines whether a team is accepting new members (defaults to false) + - `closed`: optional boolean, defines whether a team is closed to members not specified in the `allow_list`, i.e. when `True` the team is joinable by invite only. + - `allow_list`: optional list of public keys which defines which parties are allowed to join if the team is joinable by invite only. *Example: if party wants to create a simple referral set.* @@ -202,8 +202,8 @@ To update a referral set the party submit a signed `UpdateReferralSet` transacti - `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 - - `allow_list`: optional list of public keys which are allowed to join the team. If empty, all public keys are allowed to join the team. - - `closed`: optional boolean, defines whether a team is accepting new members + - `closed`: optional boolean, defines whether a team is closed to members not specified in the `allow_list`, i.e. when `True` the team can be joined by invite only. + - `allow_list`: optional list of public keys which defines which parties are allowed to join if the team is joinable by invite only. ```protobuf message UpdateReferralSet{ @@ -217,9 +217,9 @@ message UpdateReferralSet{ } ``` -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 not specified in the `allow_list` by setting the `closed` field to `True`. -Note, if a referrer updates the `allow_list` defining the parties which are allowed to join the team, the updated list is only used to validate attempts to join the team, i.e. if an existing member is removed from the list, they are not removed from the team. +Note, if a referrer updates `closed` or the `allow_list` defining the parties which are allowed to join the team, the updated list is only used to validate attempts to join the team, i.e. existing members are not removed from the team. 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. @@ -258,10 +258,7 @@ message JoinTeam{ } ``` -The party will be added to the team providing the following criteria are met. - -- the team is not `closed` -- the team has no `allow_list` or the party is specified in the teams `allow_list` +The party will be added to the team providing the team is not `closed` (anyone can join) or the team is `closed` (joinable by invite only) and the party is specified in the `allow_list`. ### Party volumes @@ -485,30 +482,29 @@ The Estimate Fees API should now calculate the following additional information: #### Applying a referral code -1. If a party **is not** currently a **referee**, if they submit a signed `ApplyReferralCode` transaction then: (0083-RFPR-025) +1. If a party **is not** currently a **referee**, if they submit a signed `ApplyReferralCode` transaction then: (0083-RFPR-059) - the party **will** be added to the associated referral set. - - the party **will** be added to the associated team (if one exists, the team is not closed, and the party is allowed by the `allow_list`). + - the party **will** be added to the associated team (if one exists) and the team is not `closed` or the team is `closed` and the party is allowed by the `allow_list`. -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). +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-060). - 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, and the party is allowed by the `allow_list`). + - the party **will** be added to the associated team (if one exists) and the team is not `closed` or the team is `closed` and the party is allowed by the `allow_list`. 1. If a party **is** currently a **referee** (and the referrer **is** meeting the staking requirement), if they submit a signed `ApplyReferralCode` transaction then the transaction will be rejected. (0083-RFPR-052). -1. If a party submits an `ApplyReferralCode` transaction, a team exists for the specified `id` and the team has **no** `allow_list` specified, then the party **should** be added to the team. (0083-RFPR-053). -1. If a party submits an `ApplyReferralCode` transaction, a team exists for the specified `id`, and the parties key **is** specified in the teams `allow_list`, then the party **should** be added to the team. (0083-RFPR-054). -1. If a party submits an `ApplyReferralCode` transaction, a team exists for the specified `id`, but the party key **is not** specified in the teams `allow_list`, then the party **should not** be added to the team. (0083-RFPR-055). +1. If a party submits an `ApplyReferralCode` transaction, a team exists for the specified `id` and the team is not `closed` then the party **should** be added to the team. (0083-RFPR-061). +1. If a party submits an `ApplyReferralCode` transaction, a team exists for the specified `id` and the team is `closed` then the party **will** be added to the team if **they are** specified in the `allow_list`. (0083-RFPR-062). +1. If a party submits an `ApplyReferralCode` transaction, a team exists for the specified `id` and the team is `closed` then the party **will not** be added to the team if **they are not** specified in the `allow_list`. (0083-RFPR-063). 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). ### Joining a team -1. If a party submits a `JoinTeam` transaction and the team has **no** `allow_list` specified, then the party **should** be added to the team. (0083-RFPR-056). -1. If a party submits a `JoinTeam` transaction and the parties key **is** specified in the teams `allow_list`, then the party **should** be added to the team. (0083-RFPR-057). -1. If a party submits a `JoinTeam` transaction and the party key **is not** specified in the teams `allow_list`, then the party **should not** be added to the team. (0083-RFPR-058). +1. If a party submits a `JoinTeam` transaction and the team is not `closed` then the party **should** be added to the team. (0083-RFPR-064). +1. If a party submits a `JoinTeam` transaction and the team is `closed` then the party **will** be added to the team if **they are** specified in the `allow_list`. (0083-RFPR-065). +1. If a party submits a `JoinTeam` transaction and the team is `closed` then the party **will not** be added to the team if **they are not** specified in the `allow_list`. (0083-RFPR-066). #### Epoch and running volumes diff --git a/protocol/features.json b/protocol/features.json index 9343b0786..fcd97c45d 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -57,12 +57,14 @@ "0056-REWA-107", "0056-REWA-108", "0083-RFPR-052", - "0056-REWA-053", - "0056-REWA-054", - "0056-REWA-055", - "0056-REWA-056", - "0056-REWA-057", - "0056-REWA-058" + "0083-RFPR-059", + "0083-RFPR-060", + "0083-RFPR-061", + "0083-RFPR-062", + "0083-RFPR-063", + "0083-RFPR-064", + "0083-RFPR-065", + "0083-RFPR-066" ] }, "Fixed size amendments": { diff --git a/wordlist.txt b/wordlist.txt index 4e8ae5725..9b3a9d1ca 100644 --- a/wordlist.txt +++ b/wordlist.txt @@ -325,3 +325,4 @@ wBTC wei whitepaper Yubikey +joinable From bcf6b3c9a391f813933340ef8f7d9ac1ab4792c7 Mon Sep 17 00:00:00 2001 From: Sohill-Patel <85170301+Sohill-Patel@users.noreply.github.com> Date: Thu, 7 Dec 2023 14:28:39 +0000 Subject: [PATCH 0822/1171] feat: add two system-test acs --- protocol/0019-MCAL-margin_calculator.md | 33 +++++++++++++++++++++++++ protocol/features.json | 4 ++- 2 files changed, 36 insertions(+), 1 deletion(-) diff --git a/protocol/0019-MCAL-margin_calculator.md b/protocol/0019-MCAL-margin_calculator.md index 3896127ef..e103b4945 100644 --- a/protocol/0019-MCAL-margin_calculator.md +++ b/protocol/0019-MCAL-margin_calculator.md @@ -246,6 +246,39 @@ There should be an additional amount `limit price x size x margin factor = 15910 - increase margin factor in isolated margin with position and with orders successful in auction(0019-MCAL-133) +- In cross margin mode, a party `short 1`, `mark price = 15 900`, `market.linearSlippageFactor = 0.25`, `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 + ``` + + the maintenance margin for the party is `min(1 x (100 000-159 00), 159 00 x 0.25 x 1) + 0.1 x 1 x 159 00 = 5565` + + for this market the party switches to isolated margin with `margin factor=0.9` then the party will have margin account balance of + `average entry price x current position x new margin factor = 57 500 x 1 x 0.9 = 6325` + the difference topped up from the party’s general account(0019-MCAL-143) + +- In isolated margin mode, a party `short 1@15 900`, `margin factor=0.9` and order book is + + ```book + buy 1 @ 15 000 + buy 10 @ 14 900 + and + sell 1 @ 100 000 + sell 10 @ 100 100 + ``` + + the margin account will hold `average entry price x current position x new margin factor = 57 500 x 1 x 0.9 = 6325` + + for this market the party switches to cross margin and the market has `market.linearSlippageFactor = 0.25`, `RF short = 0.1` then the maintenance margin for the party is `min(1 x (100 000-159 00), 159 00 x 0.25 x 1) + 0.1 x 1 x 159 00 = 5565` + but if `5565 < collatoral release level` the maintenance margin will remain unchanged at `6325` + + the difference topped up from the party’s general account(0019-MCAL-144) + - switch to cross margin without position and no orders successful in continuous mode(0019-MCAL-134) - switch to cross margin without position and no orders successful in auction(0019-MCAL-135) diff --git a/protocol/features.json b/protocol/features.json index fcd97c45d..5a83bcab6 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -178,7 +178,9 @@ "0019-MCAL-230", "0019-MCAL-231", "0074-BTCH-020", - "0074-BTCH-021" + "0074-BTCH-021", + "0019-MCAL-143", + "0019-MCAL-144" ] }, "Quadratic slippage removal": { From fb5371e4b3bae815a84a7a34ec90242b51a74114 Mon Sep 17 00:00:00 2001 From: Sohill-Patel <85170301+Sohill-Patel@users.noreply.github.com> Date: Wed, 3 Jan 2024 22:09:36 +0000 Subject: [PATCH 0823/1171] feat: clarify market has no pm params --- protocol/0019-MCAL-margin_calculator.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0019-MCAL-margin_calculator.md b/protocol/0019-MCAL-margin_calculator.md index e103b4945..ca1f640ff 100644 --- a/protocol/0019-MCAL-margin_calculator.md +++ b/protocol/0019-MCAL-margin_calculator.md @@ -246,7 +246,7 @@ There should be an additional amount `limit price x size x margin factor = 15910 - increase margin factor in isolated margin with position and with orders successful in auction(0019-MCAL-133) -- In cross margin mode, a party `short 1`, `mark price = 15 900`, `market.linearSlippageFactor = 0.25`, `RF short = 0.1` and order book is +- In cross margin mode for a market with no price monitoring, a party `short 1`, `mark price = 15 900`, `market.linearSlippageFactor = 0.25`, `RF short = 0.1` and order book is ```book buy 1 @ 15 000 From a84ee1dd9ac4b7ffa860320c3d7724ad69bce4df Mon Sep 17 00:00:00 2001 From: Sohill-Patel <85170301+Sohill-Patel@users.noreply.github.com> Date: Wed, 3 Jan 2024 22:15:24 +0000 Subject: [PATCH 0824/1171] fix: update ac numbers --- protocol/0019-MCAL-margin_calculator.md | 4 ++-- protocol/features.json | 4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/protocol/0019-MCAL-margin_calculator.md b/protocol/0019-MCAL-margin_calculator.md index ca1f640ff..a5c815b78 100644 --- a/protocol/0019-MCAL-margin_calculator.md +++ b/protocol/0019-MCAL-margin_calculator.md @@ -260,7 +260,7 @@ There should be an additional amount `limit price x size x margin factor = 15910 for this market the party switches to isolated margin with `margin factor=0.9` then the party will have margin account balance of `average entry price x current position x new margin factor = 57 500 x 1 x 0.9 = 6325` - the difference topped up from the party’s general account(0019-MCAL-143) + the difference topped up from the party’s general account(0019-MCAL-231) - In isolated margin mode, a party `short 1@15 900`, `margin factor=0.9` and order book is @@ -277,7 +277,7 @@ There should be an additional amount `limit price x size x margin factor = 15910 for this market the party switches to cross margin and the market has `market.linearSlippageFactor = 0.25`, `RF short = 0.1` then the maintenance margin for the party is `min(1 x (100 000-159 00), 159 00 x 0.25 x 1) + 0.1 x 1 x 159 00 = 5565` but if `5565 < collatoral release level` the maintenance margin will remain unchanged at `6325` - the difference topped up from the party’s general account(0019-MCAL-144) + the difference topped up from the party’s general account(0019-MCAL-232) - switch to cross margin without position and no orders successful in continuous mode(0019-MCAL-134) diff --git a/protocol/features.json b/protocol/features.json index 5a83bcab6..90a89a921 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -179,8 +179,8 @@ "0019-MCAL-231", "0074-BTCH-020", "0074-BTCH-021", - "0019-MCAL-143", - "0019-MCAL-144" + "0019-MCAL-231", + "0019-MCAL-232" ] }, "Quadratic slippage removal": { From e5da6db73f301532ec8b6eab054c2d76935eff50 Mon Sep 17 00:00:00 2001 From: Sohill-Patel <85170301+Sohill-Patel@users.noreply.github.com> Date: Wed, 3 Jan 2024 22:22:01 +0000 Subject: [PATCH 0825/1171] fix: still dup ac numbers --- protocol/0019-MCAL-margin_calculator.md | 2 +- protocol/features.json | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/protocol/0019-MCAL-margin_calculator.md b/protocol/0019-MCAL-margin_calculator.md index a5c815b78..b0ab2ac54 100644 --- a/protocol/0019-MCAL-margin_calculator.md +++ b/protocol/0019-MCAL-margin_calculator.md @@ -260,7 +260,7 @@ There should be an additional amount `limit price x size x margin factor = 15910 for this market the party switches to isolated margin with `margin factor=0.9` then the party will have margin account balance of `average entry price x current position x new margin factor = 57 500 x 1 x 0.9 = 6325` - the difference topped up from the party’s general account(0019-MCAL-231) + the difference topped up from the party’s general account(0019-MCAL-233) - In isolated margin mode, a party `short 1@15 900`, `margin factor=0.9` and order book is diff --git a/protocol/features.json b/protocol/features.json index 90a89a921..da841bfe7 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -179,8 +179,8 @@ "0019-MCAL-231", "0074-BTCH-020", "0074-BTCH-021", - "0019-MCAL-231", - "0019-MCAL-232" + "0019-MCAL-232", + "0019-MCAL-233" ] }, "Quadratic slippage removal": { From 8397d5276d2ad472b1082a192497a35a6cb57fc0 Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Thu, 4 Jan 2024 14:34:00 +0000 Subject: [PATCH 0826/1171] feat: update AC and add more AC --- protocol/0009-MRKP-mark_price.md | 33 +++++++++++++++++++++++++------- 1 file changed, 26 insertions(+), 7 deletions(-) diff --git a/protocol/0009-MRKP-mark_price.md b/protocol/0009-MRKP-mark_price.md index d8c838b07..bd6298ff9 100644 --- a/protocol/0009-MRKP-mark_price.md +++ b/protocol/0009-MRKP-mark_price.md @@ -51,17 +51,36 @@ Note that for calculating the median with an even number of entries we sort, pic ### Flexible mark price methodology, no combinations yet -- It is possible to configure a cash settled futures market to use Algorithm 1 (ie last trade price) (0009-MRKP-007) and a perps market (0009-MRKP-008). -- It is possible to configure a cash settled futures market to use weighted average of trades over `network.markPriceUpdateMaximumFrequency` with decay weight `1` and power `1` (linear decay) (0009-MRKP-009) and a perps market (0009-MRKP-010). -- It is possible to configure a cash settled futures market to use impact of leveraged notional on the order book with the value of USDT `100` for mark price (0009-MRKP-011) and a perps market (0009-MRKP-012). -- It is possible to configure a cash settled futures market to use an oracle source for the mark price (0009-MRKP-013) and a perps market (with the oracle source different to that used for the external price in the perps market) (0009-MRKP-014). +- It is possible to configure a cash settled futures market to use Algorithm 1 (ie last trade price) (0009-MRKP-010) and a perps market (0009-MRKP-011). +- It is possible to configure a cash settled futures market to use weighted average of trades over `network.markPriceUpdateMaximumFrequency` with decay weight `1` and power `1` (linear decay) (0009-MRKP-012) and a perps market (0009-MRKP-013). +- It is possible to configure a cash settled futures market to use impact of leveraged notional on the order book with the value of USDT `100` for mark price (0009-MRKP-014) and a perps market (0009-MRKP-014). +- It is possible to configure a cash settled futures market to use an oracle source for the mark price (0009-MRKP-015) and a perps market (with the oracle source different to that used for the external price in the perps market) (0009-MRKP-016). ### Flexible mark price methodology, combinations -- It is possible to configure a cash settled futures market to use a weighted average of 1. weighted average of trades over `network.markPriceUpdateMaximumFrequency` and 2. impact of leveraged notional on the order book with the value of USDT `100` and 3. an oracle source and if last trade is last updated more than 1 minute ago then it is removed and the remaining re-weighted and if the oracle is last updated more than 5 minutes ago then it is removed and the remaining re-weighted (0009-MRKP-015) and a perps market (with the oracle source different to that used for the external price in the perps market) (0009-MRKP-016). +- It is possible to configure a cash settled futures market to use a weighted average of 1. weighted average of trades over `network.markPriceUpdateMaximumFrequency` and 2. impact of leveraged notional on the order book with the value of USDT `100` and 3. an oracle source and if last trade is last updated more than 1 minute ago then it is removed and the remaining re-weighted and if the oracle is last updated more than 5 minutes ago then it is removed and the remaining re-weighted (0009-MRKP-017) and a perps market (with the oracle source different to that used for the external price in the perps market) (0009-MRKP-018). -- It is possible to configure a cash settled futures market to use a weighted average of 1. weighted average of trades over `network.markPriceUpdateMaximumFrequency` and 2. impact of leveraged notional on the order book with the value of USDT `100` and if last trade is last updated more than 1 minute ago then it is removed and the remaining re-weighted and if the oracle is last updated more than 5 minutes ago then it is removed and the remaining re-weighted and if both sources are stale than the mark price stops updating (0009-MRKP-017) and a perps market (0009-MRKP-018). +- It is possible to configure a cash settled futures market to use a weighted average of 1. weighted average of trades over `network.markPriceUpdateMaximumFrequency` and 2. impact of leveraged notional on the order book with the value of USDT `100` and if last trade is last updated more than 1 minute ago then it is removed and the remaining re-weighted and if the oracle is last updated more than 5 minutes ago then it is removed and the remaining re-weighted and if both sources are stale than the mark price stops updating (0009-MRKP-019) and a perps market (0009-MRKP-020). -- It is possible to configure a cash settled futures market to use a median of 1. weighted average of trades over `network.markPriceUpdateMaximumFrequency` and 2. impact of leveraged notional on the order book with the value of USDT `100` and 3. an oracle source and if last trade is last updated more than 1 minute ago then it is removed and if the oracle is last updated more than 5 minutes ago then it is removed (0009-MRKP-019) and a perps market (with the oracle source different to that used for the external price in the perps market) (0009-MRKP-020). +- It is possible to configure a cash settled futures market to use a median of 1. weighted average of trades over `network.markPriceUpdateMaximumFrequency` and 2. impact of leveraged notional on the order book with the value of USDT `100` and 3. an oracle source and if last trade is last updated more than 1 minute ago then it is removed and if the oracle is last updated more than 5 minutes ago then it is removed (0009-MRKP-021) and a perps market (with the oracle source different to that used for the external price in the perps market) (0009-MRKP-022). +### Example 1 - A typical path of a cash settled futures market from end of openning aucton till expiry (median mark price method)(0009-MRKP-023) + +1. Market is in openning auction, no mark price +2. Order uncrossed, ends of opening auction, market is in active state. New event is emited for new mark price. +3. New trade triggers new traded price, mark price recalcuated, new event is emited for new mark price. +4. New Oracle price comes, mark price recalcuated, new event is emited for new mark price. +5. Another Oracle price comes, mark price recalcuated, new event is emited for new mark price. +6. Traded price at step 2 is stale, and Oracle price at step 4 is stale, mark price recalcuated, new event is emited for new mark price. +7. market's status is set to trading terminated, An [oracle event occurs] that is eligible to settle the market, new event is emited for new mark price. + +### Example 2 - A typical path of a cash settled perps market from end of openning aucton till expiry (median mark price method)(0009-MRKP-024) + +1. Market is in openning auction, no mark price +2. Order uncrossed, ends of opening auction, market is in active state. New event is emited for new mark price. +3. New trade triggers new traded price, mark price recalcuated, new event is emited for new mark price. +4. New Oracle price comes, mark price recalcuated, new event is emited for new mark price. +5. Another Oracle price comes, mark price recalcuated, new event is emited for new mark price. +5. Oracle price comes for funding payments, mark price recalcuated, new event is emited for new mark price. +6. Traded price at step 2 is stale, and Oracle price at step 4 is stale, mark price recalcuated, new event is emited for new mark price. From c7f80cc971c00ebda2c1f4afc7e5f68d47a5f719 Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Thu, 4 Jan 2024 14:34:26 +0000 Subject: [PATCH 0827/1171] chore: tidy up --- protocol/0009-MRKP-mark_price.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0009-MRKP-mark_price.md b/protocol/0009-MRKP-mark_price.md index bd6298ff9..9b2c19656 100644 --- a/protocol/0009-MRKP-mark_price.md +++ b/protocol/0009-MRKP-mark_price.md @@ -74,7 +74,7 @@ Note that for calculating the median with an even number of entries we sort, pic 6. Traded price at step 2 is stale, and Oracle price at step 4 is stale, mark price recalcuated, new event is emited for new mark price. 7. market's status is set to trading terminated, An [oracle event occurs] that is eligible to settle the market, new event is emited for new mark price. -### Example 2 - A typical path of a cash settled perps market from end of openning aucton till expiry (median mark price method)(0009-MRKP-024) +### Example 2 - A typical path of a cash settled perps market from end of openning aucton (median mark price method)(0009-MRKP-024) 1. Market is in openning auction, no mark price 2. Order uncrossed, ends of opening auction, market is in active state. New event is emited for new mark price. From ab9fbf8accacc1d97c01b6043b2948cbd6b605cf Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Thu, 4 Jan 2024 14:49:40 +0000 Subject: [PATCH 0828/1171] chore: markdown --- protocol/0009-MRKP-mark_price.md | 50 +++++++++---------- ...3-PERP-product_builtin_perpetual_future.md | 7 +-- 2 files changed, 29 insertions(+), 28 deletions(-) diff --git a/protocol/0009-MRKP-mark_price.md b/protocol/0009-MRKP-mark_price.md index 9b2c19656..b1f1a1e7e 100644 --- a/protocol/0009-MRKP-mark_price.md +++ b/protocol/0009-MRKP-mark_price.md @@ -30,15 +30,15 @@ Now 10.1s has elapsed since the last update and there is a market buy order for ### 2. Flexible mark price methodology -The calculations are specified in [markprice methodology research note](https://github.com/vegaprotocol/research/blob/markprice-updates/papers/markprice-methodology/markprice-methodology.tex). -Here, we only write the acceptance criteria. -Note that for calculating the median with an even number of entries we sort, pick out the two values that are in the middle of the list and average those. So in particular with two values a median is the same as the average for our purposes. +The calculations are specified in [markprice methodology research note](https://github.com/vegaprotocol/research/blob/markprice-updates/papers/markprice-methodology/markprice-methodology.tex). +Here, we only write the acceptance criteria. +Note that for calculating the median with an even number of entries we sort, pick out the two values that are in the middle of the list and average those. So in particular with two values a median is the same as the average for our purposes. ## Acceptance criteria - 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) +- 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 (last trade price, excluding network trades): @@ -53,34 +53,34 @@ Note that for calculating the median with an even number of entries we sort, pic - It is possible to configure a cash settled futures market to use Algorithm 1 (ie last trade price) (0009-MRKP-010) and a perps market (0009-MRKP-011). - It is possible to configure a cash settled futures market to use weighted average of trades over `network.markPriceUpdateMaximumFrequency` with decay weight `1` and power `1` (linear decay) (0009-MRKP-012) and a perps market (0009-MRKP-013). -- It is possible to configure a cash settled futures market to use impact of leveraged notional on the order book with the value of USDT `100` for mark price (0009-MRKP-014) and a perps market (0009-MRKP-014). -- It is possible to configure a cash settled futures market to use an oracle source for the mark price (0009-MRKP-015) and a perps market (with the oracle source different to that used for the external price in the perps market) (0009-MRKP-016). +- It is possible to configure a cash settled futures market to use impact of leveraged notional on the order book with the value of USDT `100` for mark price (0009-MRKP-014) and a perps market (0009-MRKP-015). +- It is possible to configure a cash settled futures market to use an oracle source for the mark price (0009-MRKP-016) and a perps market (with the oracle source different to that used for the external price in the perps market) (0009-MRKP-017). ### Flexible mark price methodology, combinations -- It is possible to configure a cash settled futures market to use a weighted average of 1. weighted average of trades over `network.markPriceUpdateMaximumFrequency` and 2. impact of leveraged notional on the order book with the value of USDT `100` and 3. an oracle source and if last trade is last updated more than 1 minute ago then it is removed and the remaining re-weighted and if the oracle is last updated more than 5 minutes ago then it is removed and the remaining re-weighted (0009-MRKP-017) and a perps market (with the oracle source different to that used for the external price in the perps market) (0009-MRKP-018). +- It is possible to configure a cash settled futures market to use a weighted average of 1. weighted average of trades over `network.markPriceUpdateMaximumFrequency` and 2. impact of leveraged notional on the order book with the value of USDT `100` and 3. an oracle source and if last trade is last updated more than 1 minute ago then it is removed and the remaining re-weighted and if the oracle is last updated more than 5 minutes ago then it is removed and the remaining re-weighted (0009-MRKP-018) and a perps market (with the oracle source different to that used for the external price in the perps market) (0009-MRKP-019). -- It is possible to configure a cash settled futures market to use a weighted average of 1. weighted average of trades over `network.markPriceUpdateMaximumFrequency` and 2. impact of leveraged notional on the order book with the value of USDT `100` and if last trade is last updated more than 1 minute ago then it is removed and the remaining re-weighted and if the oracle is last updated more than 5 minutes ago then it is removed and the remaining re-weighted and if both sources are stale than the mark price stops updating (0009-MRKP-019) and a perps market (0009-MRKP-020). +- It is possible to configure a cash settled futures market to use a weighted average of 1. weighted average of trades over `network.markPriceUpdateMaximumFrequency` and 2. impact of leveraged notional on the order book with the value of USDT `100` and if last trade is last updated more than 1 minute ago then it is removed and the remaining re-weighted and if the oracle is last updated more than 5 minutes ago then it is removed and the remaining re-weighted and if both sources are stale than the mark price stops updating (0009-MRKP-020) and a perps market (0009-MRKP-021). -- It is possible to configure a cash settled futures market to use a median of 1. weighted average of trades over `network.markPriceUpdateMaximumFrequency` and 2. impact of leveraged notional on the order book with the value of USDT `100` and 3. an oracle source and if last trade is last updated more than 1 minute ago then it is removed and if the oracle is last updated more than 5 minutes ago then it is removed (0009-MRKP-021) and a perps market (with the oracle source different to that used for the external price in the perps market) (0009-MRKP-022). +- It is possible to configure a cash settled futures market to use a median of 1. weighted average of trades over `network.markPriceUpdateMaximumFrequency` and 2. impact of leveraged notional on the order book with the value of USDT `100` and 3. an oracle source and if last trade is last updated more than 1 minute ago then it is removed and if the oracle is last updated more than 5 minutes ago then it is removed (0009-MRKP-022) and a perps market (with the oracle source different to that used for the external price in the perps market) (0009-MRKP-023). -### Example 1 - A typical path of a cash settled futures market from end of openning aucton till expiry (median mark price method)(0009-MRKP-023) +### Example 1 - A typical path of a cash settled futures market from end of openning auction till expiry (median mark price method)(0009-MRKP-024) -1. Market is in openning auction, no mark price -2. Order uncrossed, ends of opening auction, market is in active state. New event is emited for new mark price. -3. New trade triggers new traded price, mark price recalcuated, new event is emited for new mark price. -4. New Oracle price comes, mark price recalcuated, new event is emited for new mark price. -5. Another Oracle price comes, mark price recalcuated, new event is emited for new mark price. -6. Traded price at step 2 is stale, and Oracle price at step 4 is stale, mark price recalcuated, new event is emited for new mark price. -7. market's status is set to trading terminated, An [oracle event occurs] that is eligible to settle the market, new event is emited for new mark price. +1. Market is in opening auction, no mark price. +2. Order uncrossed, ends of opening auction, market is in active state. New event is emitted for new mark price. +3. New trade triggers new traded price, mark price recalculated, new event is emitted for new mark price. +4. New Oracle price comes, mark price recalculated, new event is emitted for new mark price. +5. Another Oracle price comes, mark price recalculated, new event is emitted for new mark price. +6. Traded price at step 2 is stale, and Oracle price at step 4 is stale, mark price recalculated, new event is emitted for new mark price. +7. market's status is set to trading terminated, An [oracle event occurs] that is eligible to settle the market, new event is emitted for new mark price. -### Example 2 - A typical path of a cash settled perps market from end of openning aucton (median mark price method)(0009-MRKP-024) +### Example 2 - A typical path of a cash settled perps market from end of openning auction (median mark price method)(0009-MRKP-025) -1. Market is in openning auction, no mark price -2. Order uncrossed, ends of opening auction, market is in active state. New event is emited for new mark price. -3. New trade triggers new traded price, mark price recalcuated, new event is emited for new mark price. -4. New Oracle price comes, mark price recalcuated, new event is emited for new mark price. -5. Another Oracle price comes, mark price recalcuated, new event is emited for new mark price. -5. Oracle price comes for funding payments, mark price recalcuated, new event is emited for new mark price. -6. Traded price at step 2 is stale, and Oracle price at step 4 is stale, mark price recalcuated, new event is emited for new mark price. +1. Market is in opening auction, no mark price. +2. Order uncrossed, ends of opening auction, market is in active state. New event is emitted for new mark price. +3. New trade triggers new traded price, mark price recalculated, new event is emitted for new mark price. +4. New Oracle price comes, mark price recalculated, new event is emitted for new mark price. +5. Another Oracle price comes, mark price recalculated, new event is emitted for new mark price. +5. Oracle price comes for funding payments, mark price recalculated, new event is emitted for new mark price. +6. Traded price at step 2 is stale, and Oracle price at step 4 is stale, mark price recalculated, new event is emitted for new mark price. diff --git a/protocol/0053-PERP-product_builtin_perpetual_future.md b/protocol/0053-PERP-product_builtin_perpetual_future.md index 1ae2529cd..1e30f1de7 100644 --- a/protocol/0053-PERP-product_builtin_perpetual_future.md +++ b/protocol/0053-PERP-product_builtin_perpetual_future.md @@ -8,6 +8,7 @@ Perpetual futures are a simple "delta one" product. Mark-to-market settlement oc 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 either: + - the mark price of the market to approximate $F_u$ or - configure the "market price for funding purposes" as part of the market proposal and use this methodology 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. @@ -338,9 +339,9 @@ When migrating the market existing prior to introduction of the additional param - $\text{rate_upper_bound}= \text{max supported value}$ (0053-PERP-032). -It is possible to create a perpetual futures market which uses the last traded price algorithm for its mark price but uses "impact volume of notional of 1000 USDT" for the purpose of calculating the TWAP of the market price for funding payments (0053-PERP-033). +It is possible to create a perpetual futures market which uses the last traded price algorithm for its mark price but uses "impact volume of notional of 1000 USDT" for the purpose of calculating the TWAP of the market price for funding payments (0053-PERP-033). -It is possible to create a perpetual futures market which uses an oraclo source (same as that used for funding) for the mark price determining the mark-to-market cashflows and that uses "impact volume of notional of 1000 USDT" for the purpose of calculating the TWAP of the market price for funding payments (0053-PERP-034). +It is possible to create a perpetual futures market which uses an oracle source (same as that used for funding) for the mark price determining the mark-to-market cashflows and that uses "impact volume of notional of 1000 USDT" for the purpose of calculating the TWAP of the market price for funding payments (0053-PERP-034). -It is possible to create a perpetual futures market which uses an oraclo source (same as that used for funding) for the mark price determining the mark-to-market cashflows and that uses "time-weighted trade prices in over `network.markPriceUpdateMaximumFrequency` if these have been updated within the last 30s but falls back onto impact volume of notional of 1000 USDT" for the purpose of calculating the TWAP of the market price for funding payments (0053-PERP-034). +It is possible to create a perpetual futures market which uses an oracle source (same as that used for funding) for the mark price determining the mark-to-market cashflows and that uses "time-weighted trade prices in over `network.markPriceUpdateMaximumFrequency` if these have been updated within the last 30s but falls back onto impact volume of notional of 1000 USDT" for the purpose of calculating the TWAP of the market price for funding payments (0053-PERP-035). From 1604ec50329ff86f154d6bd906548c2c80e7d316 Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Thu, 4 Jan 2024 15:57:08 +0000 Subject: [PATCH 0829/1171] feat: address comments --- protocol/0009-MRKP-mark_price.md | 34 ++++++++++++++++++-------------- 1 file changed, 19 insertions(+), 15 deletions(-) diff --git a/protocol/0009-MRKP-mark_price.md b/protocol/0009-MRKP-mark_price.md index b1f1a1e7e..ccb7d9354 100644 --- a/protocol/0009-MRKP-mark_price.md +++ b/protocol/0009-MRKP-mark_price.md @@ -42,16 +42,13 @@ Note that for calculating the median with an even number of entries we sort, pic ### Algorithm 1 (last trade price, excluding network trades): -- 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) - +- It is possible to configure a cash settled futures market to use Algorithm 1 (ie last trade price) (0009-MRKP-010) and a perps market (0009-MRKP-011). ### Flexible mark price methodology, no combinations yet - -- It is possible to configure a cash settled futures market to use Algorithm 1 (ie last trade price) (0009-MRKP-010) and a perps market (0009-MRKP-011). - It is possible to configure a cash settled futures market to use weighted average of trades over `network.markPriceUpdateMaximumFrequency` with decay weight `1` and power `1` (linear decay) (0009-MRKP-012) and a perps market (0009-MRKP-013). - It is possible to configure a cash settled futures market to use impact of leveraged notional on the order book with the value of USDT `100` for mark price (0009-MRKP-014) and a perps market (0009-MRKP-015). - It is possible to configure a cash settled futures market to use an oracle source for the mark price (0009-MRKP-016) and a perps market (with the oracle source different to that used for the external price in the perps market) (0009-MRKP-017). @@ -64,23 +61,30 @@ Note that for calculating the median with an even number of entries we sort, pic - It is possible to configure a cash settled futures market to use a median of 1. weighted average of trades over `network.markPriceUpdateMaximumFrequency` and 2. impact of leveraged notional on the order book with the value of USDT `100` and 3. an oracle source and if last trade is last updated more than 1 minute ago then it is removed and if the oracle is last updated more than 5 minutes ago then it is removed (0009-MRKP-022) and a perps market (with the oracle source different to that used for the external price in the perps market) (0009-MRKP-023). -### Example 1 - A typical path of a cash settled futures market from end of openning auction till expiry (median mark price method)(0009-MRKP-024) +- When market is leaving auction, mark price should be recalculated (0009-MRKP-024) and a perps market (with the oracle source different to that used for the external price in the perps market) (0009-MRKP-025). + +- When market is at mornitoring auction, book price should be indicative uncrossing price, mark price should be recalculated (0009-MRKP-026) and a perps market (with the oracle source different to that used for the external price in the perps market) (0009-MRKP-027). + +- It is possible to configure a cash settled futures market to use a weighted average of 1. weighted average of trades over `network.markPriceUpdateMaximumFrequency` and 2. impact of leveraged notional on the order book with the value of USDT `100` and when the book does not have enough volume, then the book price should not be included (0009-MRKP-028) and a perps market (with the oracle source different to that used for the external price in the perps market) (0009-MRKP-029). + +- It is possible to configure a cash settled futures market to use a weighted average of 1. weighted average of trades over `network.markPriceUpdateMaximumFrequency` and 2. impact of leveraged notional on the order book with the value of USDT `0` and the book price should be mid price (0009-MRKP-030) and a perps market (with the oracle source different to that used for the external price in the perps market) (0009-MRKP-031). + +### Example 1 - A typical path of a cash settled futures market from end of opening auction till expiry (use Algorithm 2 (ie median price))(0009-MRKP-040) 1. Market is in opening auction, no mark price. 2. Order uncrossed, ends of opening auction, market is in active state. New event is emitted for new mark price. -3. New trade triggers new traded price, mark price recalculated, new event is emitted for new mark price. -4. New Oracle price comes, mark price recalculated, new event is emitted for new mark price. -5. Another Oracle price comes, mark price recalculated, new event is emitted for new mark price. -6. Traded price at step 2 is stale, and Oracle price at step 4 is stale, mark price recalculated, new event is emitted for new mark price. +3. New trade triggers new traded price, mark price recalculated when the time indicated by the mark price frequency is crossed, new event is emitted for new mark price. +4. New Oracle price comes, mark price recalculated when the time indicated by the mark price frequency is crossed, new event is emitted for new mark price. +5. Another Oracle price comes, mark price recalculated when the time indicated by the mark price frequency is crossed, new event is emitted for new mark price. +6. Traded price at step 2 is stale, and Oracle price at step 4 is stale, mark price recalculated when the time indicated by the mark price frequency is crossed, new event is emitted for new mark price. 7. market's status is set to trading terminated, An [oracle event occurs] that is eligible to settle the market, new event is emitted for new mark price. -### Example 2 - A typical path of a cash settled perps market from end of openning auction (median mark price method)(0009-MRKP-025) +### Example 2 - A typical path of a cash settled perps market from end of opening auction (use Algorithm 2 (ie median price))(0009-MRKP-041) 1. Market is in opening auction, no mark price. 2. Order uncrossed, ends of opening auction, market is in active state. New event is emitted for new mark price. -3. New trade triggers new traded price, mark price recalculated, new event is emitted for new mark price. -4. New Oracle price comes, mark price recalculated, new event is emitted for new mark price. -5. Another Oracle price comes, mark price recalculated, new event is emitted for new mark price. -5. Oracle price comes for funding payments, mark price recalculated, new event is emitted for new mark price. +3. New trade triggers new traded price, mark price recalculated when the time indicated by the mark price frequency is crossed, new event is emitted for new mark price. +4. New Oracle price comes, mark price recalculated when the time indicated by the mark price frequency is crossed, new event is emitted for new mark price. +5. Another Oracle price comes, mark price recalculated when the time indicated by the mark price frequency is crossed, new event is emitted for new mark price. +5. Oracle price comes for funding payments, mark price recalculated when the time indicated by the mark price frequency is crossed, new event is emitted for new mark price. 6. Traded price at step 2 is stale, and Oracle price at step 4 is stale, mark price recalculated, new event is emitted for new mark price. - From 543957e950ef583880cbd89360cf1e6b4c2f4e5d Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Thu, 4 Jan 2024 16:00:01 +0000 Subject: [PATCH 0830/1171] chore: markdown --- protocol/0009-MRKP-mark_price.md | 7 ++++--- protocol/0053-PERP-product_builtin_perpetual_future.md | 2 +- 2 files changed, 5 insertions(+), 4 deletions(-) diff --git a/protocol/0009-MRKP-mark_price.md b/protocol/0009-MRKP-mark_price.md index ccb7d9354..94ff46424 100644 --- a/protocol/0009-MRKP-mark_price.md +++ b/protocol/0009-MRKP-mark_price.md @@ -40,7 +40,7 @@ Note that for calculating the median with an even number of entries we sort, pic - 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 (last trade price, excluding network trades): +### Algorithm 1 (last trade price, excluding network trades) - 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) @@ -49,6 +49,7 @@ Note that for calculating the median with an even number of entries we sort, pic - It is possible to configure a cash settled futures market to use Algorithm 1 (ie last trade price) (0009-MRKP-010) and a perps market (0009-MRKP-011). ### Flexible mark price methodology, no combinations yet + - It is possible to configure a cash settled futures market to use weighted average of trades over `network.markPriceUpdateMaximumFrequency` with decay weight `1` and power `1` (linear decay) (0009-MRKP-012) and a perps market (0009-MRKP-013). - It is possible to configure a cash settled futures market to use impact of leveraged notional on the order book with the value of USDT `100` for mark price (0009-MRKP-014) and a perps market (0009-MRKP-015). - It is possible to configure a cash settled futures market to use an oracle source for the mark price (0009-MRKP-016) and a perps market (with the oracle source different to that used for the external price in the perps market) (0009-MRKP-017). @@ -86,5 +87,5 @@ Note that for calculating the median with an even number of entries we sort, pic 3. New trade triggers new traded price, mark price recalculated when the time indicated by the mark price frequency is crossed, new event is emitted for new mark price. 4. New Oracle price comes, mark price recalculated when the time indicated by the mark price frequency is crossed, new event is emitted for new mark price. 5. Another Oracle price comes, mark price recalculated when the time indicated by the mark price frequency is crossed, new event is emitted for new mark price. -5. Oracle price comes for funding payments, mark price recalculated when the time indicated by the mark price frequency is crossed, new event is emitted for new mark price. -6. Traded price at step 2 is stale, and Oracle price at step 4 is stale, mark price recalculated, new event is emitted for new mark price. +6. Oracle price comes for funding payments, mark price recalculated when the time indicated by the mark price frequency is crossed, new event is emitted for new mark price. +7. Traded price at step 2 is stale, and Oracle price at step 4 is stale, mark price recalculated, new event is emitted for new mark price. diff --git a/protocol/0053-PERP-product_builtin_perpetual_future.md b/protocol/0053-PERP-product_builtin_perpetual_future.md index 1e30f1de7..01b8f738b 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 (funding payment) 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$. +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 either: - the mark price of the market to approximate $F_u$ or From b83b7823bc5d732f4686aa7c0df817a6d1b414d1 Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Thu, 4 Jan 2024 16:03:19 +0000 Subject: [PATCH 0831/1171] chore: add timing --- protocol/0009-MRKP-mark_price.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/protocol/0009-MRKP-mark_price.md b/protocol/0009-MRKP-mark_price.md index 94ff46424..1b2bb8047 100644 --- a/protocol/0009-MRKP-mark_price.md +++ b/protocol/0009-MRKP-mark_price.md @@ -62,9 +62,9 @@ Note that for calculating the median with an even number of entries we sort, pic - It is possible to configure a cash settled futures market to use a median of 1. weighted average of trades over `network.markPriceUpdateMaximumFrequency` and 2. impact of leveraged notional on the order book with the value of USDT `100` and 3. an oracle source and if last trade is last updated more than 1 minute ago then it is removed and if the oracle is last updated more than 5 minutes ago then it is removed (0009-MRKP-022) and a perps market (with the oracle source different to that used for the external price in the perps market) (0009-MRKP-023). -- When market is leaving auction, mark price should be recalculated (0009-MRKP-024) and a perps market (with the oracle source different to that used for the external price in the perps market) (0009-MRKP-025). +- When market is leaving auction, mark price should be recalculated when the time indicated by the mark price frequency is crossed (0009-MRKP-024) and a perps market (with the oracle source different to that used for the external price in the perps market) (0009-MRKP-025). -- When market is at mornitoring auction, book price should be indicative uncrossing price, mark price should be recalculated (0009-MRKP-026) and a perps market (with the oracle source different to that used for the external price in the perps market) (0009-MRKP-027). +- When market is at mornitoring auction, book price should be indicative uncrossing price, mark price should be recalculated when the time indicated by the mark price frequency is crossed(0009-MRKP-026) and a perps market (with the oracle source different to that used for the external price in the perps market) (0009-MRKP-027). - It is possible to configure a cash settled futures market to use a weighted average of 1. weighted average of trades over `network.markPriceUpdateMaximumFrequency` and 2. impact of leveraged notional on the order book with the value of USDT `100` and when the book does not have enough volume, then the book price should not be included (0009-MRKP-028) and a perps market (with the oracle source different to that used for the external price in the perps market) (0009-MRKP-029). From d4ef5e1c2ab378622a2ce5fb20ad2f252afd6345 Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Thu, 4 Jan 2024 16:21:09 +0000 Subject: [PATCH 0832/1171] chore: typo --- protocol/0009-MRKP-mark_price.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0009-MRKP-mark_price.md b/protocol/0009-MRKP-mark_price.md index 1b2bb8047..e35a7ef92 100644 --- a/protocol/0009-MRKP-mark_price.md +++ b/protocol/0009-MRKP-mark_price.md @@ -64,7 +64,7 @@ Note that for calculating the median with an even number of entries we sort, pic - When market is leaving auction, mark price should be recalculated when the time indicated by the mark price frequency is crossed (0009-MRKP-024) and a perps market (with the oracle source different to that used for the external price in the perps market) (0009-MRKP-025). -- When market is at mornitoring auction, book price should be indicative uncrossing price, mark price should be recalculated when the time indicated by the mark price frequency is crossed(0009-MRKP-026) and a perps market (with the oracle source different to that used for the external price in the perps market) (0009-MRKP-027). +- When market is at monitoring auction, book price should be indicative uncrossing price, mark price should be recalculated when the time indicated by the mark price frequency is crossed(0009-MRKP-026) and a perps market (with the oracle source different to that used for the external price in the perps market) (0009-MRKP-027). - It is possible to configure a cash settled futures market to use a weighted average of 1. weighted average of trades over `network.markPriceUpdateMaximumFrequency` and 2. impact of leveraged notional on the order book with the value of USDT `100` and when the book does not have enough volume, then the book price should not be included (0009-MRKP-028) and a perps market (with the oracle source different to that used for the external price in the perps market) (0009-MRKP-029). From 20ace71de2646e188aee5590cf9f7f1643e77795 Mon Sep 17 00:00:00 2001 From: gordsport Date: Thu, 4 Jan 2024 20:29:57 +0000 Subject: [PATCH 0833/1171] chore: Add AC code to the featurtes.json Also sneaking in a categories tidy up --- protocol/categories.json | 7 +++++-- protocol/features.json | 34 ++++++++++++++++++++++++++++++++++ 2 files changed, 39 insertions(+), 2 deletions(-) diff --git a/protocol/categories.json b/protocol/categories.json index 1ec59f955..1aebfab68 100644 --- a/protocol/categories.json +++ b/protocol/categories.json @@ -3,10 +3,10 @@ "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"] + "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", "0081-SUCM"] }, "Settlement & Oracles": { - "specs": ["0002-STTL", "0003-MTMK", "0045-DSRC", "0046-DSRM", "0047-DSRF", "0048-DSRI"] + "specs": ["0002-STTL", "0003-MTMK", "0045-DSRC", "0046-DSRM", "0047-DSRF", "0048-DSRI", "0082-ETHD", "0087-EL2D"] }, "Protections": { "specs": ["0073-LIMN", "0072-SPPW", "0062-SPAM", "0060-WEND", "0003-NP-LIMI", "0072-SPPW", "0078-NWLI", "0079-TGAP"] @@ -35,6 +35,9 @@ "Data": { "specs": ["0076-DANO", "0020-APIS", "0007-POSN"] }, + "Referral": { + "specs": ["0083-RFPR", "0084-VDPR", "0085-RVST", "0086-ASPR"] + }, "UI": { "specs": ["1000-ASSO", "1001-VEST", "1002-STAK", "1003-INCO", "1004-VOTE", "3002-PROP", "1006-NETW", "1007-WALL", "3000-DEPO", "3001-WITH", "5000-MARK", "6000-COLL", "6001-SORD", "6002-MORD", "6003-POSI", "6004-FILL"] }, diff --git a/protocol/features.json b/protocol/features.json index da841bfe7..57c7d8ece 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -287,6 +287,40 @@ "0014-ORDT-131" ] }, + "Markprice updates": { + "milestone": "palazzo", + "acs": [ + "0009-MRKP-010", + "0009-MRKP-011", + "0009-MRKP-012", + "0009-MRKP-013", + "0009-MRKP-014", + "0009-MRKP-015", + "0009-MRKP-016", + "0009-MRKP-017", + "0009-MRKP-018", + "0009-MRKP-019", + "0009-MRKP-020", + "0009-MRKP-011", + "0009-MRKP-021", + "0009-MRKP-022", + "0009-MRKP-023", + "0009-MRKP-024", + "0009-MRKP-025", + "0009-MRKP-026", + "0009-MRKP-027", + "0009-MRKP-027", + "0009-MRKP-028", + "0009-MRKP-029", + "0009-MRKP-030", + "0009-MRKP-031", + "0009-MRKP-040", + "0009-MRKP-041", + "0053-PERP-033", + "0053-PERP-034", + "0053-PERP-035" + ] + }, "Unknown": { "milestone": "unknown", "acs": [] From 0c7239ee2fb1f47d1c1b9b0d6ffa9108ac9a42af Mon Sep 17 00:00:00 2001 From: gordsport Date: Thu, 4 Jan 2024 20:46:04 +0000 Subject: [PATCH 0834/1171] fix: duplicated AC codes in features.json --- protocol/features.json | 2 -- 1 file changed, 2 deletions(-) diff --git a/protocol/features.json b/protocol/features.json index 57c7d8ece..44cb19530 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -301,7 +301,6 @@ "0009-MRKP-018", "0009-MRKP-019", "0009-MRKP-020", - "0009-MRKP-011", "0009-MRKP-021", "0009-MRKP-022", "0009-MRKP-023", @@ -309,7 +308,6 @@ "0009-MRKP-025", "0009-MRKP-026", "0009-MRKP-027", - "0009-MRKP-027", "0009-MRKP-028", "0009-MRKP-029", "0009-MRKP-030", From f7ca9daca20ee22689c2a47e111d05a80abcae09 Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Fri, 5 Jan 2024 09:39:57 +0000 Subject: [PATCH 0835/1171] feat: address comment --- protocol/0009-MRKP-mark_price.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0009-MRKP-mark_price.md b/protocol/0009-MRKP-mark_price.md index e35a7ef92..6f1439fbb 100644 --- a/protocol/0009-MRKP-mark_price.md +++ b/protocol/0009-MRKP-mark_price.md @@ -62,7 +62,7 @@ Note that for calculating the median with an even number of entries we sort, pic - It is possible to configure a cash settled futures market to use a median of 1. weighted average of trades over `network.markPriceUpdateMaximumFrequency` and 2. impact of leveraged notional on the order book with the value of USDT `100` and 3. an oracle source and if last trade is last updated more than 1 minute ago then it is removed and if the oracle is last updated more than 5 minutes ago then it is removed (0009-MRKP-022) and a perps market (with the oracle source different to that used for the external price in the perps market) (0009-MRKP-023). -- When market is leaving auction, mark price should be recalculated when the time indicated by the mark price frequency is crossed (0009-MRKP-024) and a perps market (with the oracle source different to that used for the external price in the perps market) (0009-MRKP-025). +- When market is leaving auction (including opening auction and monitoring auction), mark price should be recalculated (0009-MRKP-024) and a perps market (with the oracle source different to that used for the external price in the perps market) (0009-MRKP-025). - When market is at monitoring auction, book price should be indicative uncrossing price, mark price should be recalculated when the time indicated by the mark price frequency is crossed(0009-MRKP-026) and a perps market (with the oracle source different to that used for the external price in the perps market) (0009-MRKP-027). From 209dc5cf374c1670b500bb433f4301a08f6866cb Mon Sep 17 00:00:00 2001 From: David Siska <62546419+davidsiska-vega@users.noreply.github.com> Date: Thu, 4 Jan 2024 15:29:04 +0000 Subject: [PATCH 0836/1171] feat: EthL2s --- protocol/0087-EL2D-ethereumL2-data-source.md | 55 ++++++++++++++++++++ 1 file changed, 55 insertions(+) create mode 100644 protocol/0087-EL2D-ethereumL2-data-source.md diff --git a/protocol/0087-EL2D-ethereumL2-data-source.md b/protocol/0087-EL2D-ethereumL2-data-source.md new file mode 100644 index 000000000..9126f7820 --- /dev/null +++ b/protocol/0087-EL2D-ethereumL2-data-source.md @@ -0,0 +1,55 @@ +# Ethereum L2s data sources + +## Summary + +This specification adds a new way of sourcing data from the Ethereum L2s to allow arbitrary data from the Ethereum L2s running EVM to be ingested as a [data source](./0045-DSRC-data_sourcing.md). +This is in addition to and building upon [Ethereum data source](./0082-ETHD-ethereum-data-source.md). + +## Decription + +In addition to listening to Ethereum events and reading from Ethereum contrants as described in [Ethereum data source](./0082-ETHD-ethereum-data-source.md) it will be possible for Vega nodes to listen to events from and read from other Ethereum L2s. + +The overarching principle is that the L2s incorporate the ethereum EVMs and thus contracts and ABIs are assumed to be functionally the same as on Ethereum itself. + +## Registration / removal + +A new network parameter, a JSDON list of network id / chain id / name one per L2 will be used for setting supported L2. This is set via [governance](./0028-GOVE-governance.md). +Name `blockchains.ethereumL2Configs`. +Example value: +``` +{"configs": [{"network_id": 10, "chain_id": 10, "confirmations": 3, "name":"optimism"}]} +``` +Duplicate values of "network_id": 10, "chain_id" or "name":"optimism" or not allowed (an update will be rejected at validation stage). +Any updat emust always change the entire JSON (it's not possible to change individual entries). +A proposal to *remove* a registered L2 must fail at enactment stage if a market is referencing an EthL2 data source. +A proposal for a new market will fail at enactment stage if it's referencing an EthL2 that's not registered. + + +## Acceptance criteria + +- It is possible to add EthL2 via governance. + +- It is possible to remove an EthL2 via governance. The proposal will fail at enactment stage if there is any market that's not settled / closed that reference the EthL2. + +- A market proposal that reference an EthL2 that's not active will fail at enactment stage. + +- It may happen that an EthL2 that cannot be read from is proposed (because not enough validator nodes have it configured etc.). In that case a proposed / enacted market will not see the oracle inputs but it must be possible to change the said market via on-chain governance. + +- Two different markets may reference two identical EthL2 contracts and ABIs, even with same contract address *but* on two different EthL2 and they each get the correct values i.e. if we have market 1 with +``` +source: EthereumEvent { + source_chain_id: 0x123 + contract: 0xDEADBEEF + ABI: "...JSON..." + event: "MyFaveEvent" +``` +and market 2 with +``` +source: EthereumEvent { + source_chain_id: 0x789 + contract: 0xDEADBEEF + ABI: "...JSON..." + event: "MyFaveEvent" +``` +Then market 1 only sees events of that type from EthL2 0x123 while market 2 only sees events of that type from EthL2 0x789. + From b4872ff89482a24c13600ae7240dba1b8b1aed5e Mon Sep 17 00:00:00 2001 From: David Siska <62546419+davidsiska-vega@users.noreply.github.com> Date: Fri, 5 Jan 2024 11:41:20 +0000 Subject: [PATCH 0837/1171] fix: better name --- ...L2-data-source.md => 0087-EVMD-eth-rpc-and-evm-data-source.md} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename protocol/{0087-EL2D-ethereumL2-data-source.md => 0087-EVMD-eth-rpc-and-evm-data-source.md} (100%) diff --git a/protocol/0087-EL2D-ethereumL2-data-source.md b/protocol/0087-EVMD-eth-rpc-and-evm-data-source.md similarity index 100% rename from protocol/0087-EL2D-ethereumL2-data-source.md rename to protocol/0087-EVMD-eth-rpc-and-evm-data-source.md From a756b41c8ab92e43059871e8f6dcf476ab5cfe62 Mon Sep 17 00:00:00 2001 From: David Siska <62546419+davidsiska-vega@users.noreply.github.com> Date: Fri, 5 Jan 2024 11:45:56 +0000 Subject: [PATCH 0838/1171] fix: clarity on what is meant by L2 --- .../0087-EVMD-eth-rpc-and-evm-data-source.md | 29 ++++++++++--------- 1 file changed, 15 insertions(+), 14 deletions(-) diff --git a/protocol/0087-EVMD-eth-rpc-and-evm-data-source.md b/protocol/0087-EVMD-eth-rpc-and-evm-data-source.md index 9126f7820..14152b730 100644 --- a/protocol/0087-EVMD-eth-rpc-and-evm-data-source.md +++ b/protocol/0087-EVMD-eth-rpc-and-evm-data-source.md @@ -1,19 +1,20 @@ -# Ethereum L2s data sources +# Ethereum RPC and EVM based data sources ## Summary -This specification adds a new way of sourcing data from the Ethereum L2s to allow arbitrary data from the Ethereum L2s running EVM to be ingested as a [data source](./0045-DSRC-data_sourcing.md). -This is in addition to and building upon [Ethereum data source](./0082-ETHD-ethereum-data-source.md). +This specification adds a new way of sourcing data from any chain or Ethereum L2 that supports Ethereum RPC calls and runs an EVM. +The data is to be ingested as an Ethereum [data source](./0045-DSRC-data_sourcing.md) but pointing at a different RPC endpoint. +Hence this is in addition to and building upon [Ethereum data source](./0082-ETHD-ethereum-data-source.md). ## Decription -In addition to listening to Ethereum events and reading from Ethereum contrants as described in [Ethereum data source](./0082-ETHD-ethereum-data-source.md) it will be possible for Vega nodes to listen to events from and read from other Ethereum L2s. +In addition to listening to Ethereum events and reading from Ethereum contrants as described in [Ethereum data source](./0082-ETHD-ethereum-data-source.md) it will be possible for Vega nodes to listen to events from and read from other chains that implement Ethereum RPC and run EVM, in particular Ethereum L2. -The overarching principle is that the L2s incorporate the ethereum EVMs and thus contracts and ABIs are assumed to be functionally the same as on Ethereum itself. +The overarching principle is that the chain provides ethereum RPC / EVMs and thus contracts and ABIs are assumed to be functionally the same as on Ethereum itself. ## Registration / removal -A new network parameter, a JSDON list of network id / chain id / name one per L2 will be used for setting supported L2. This is set via [governance](./0028-GOVE-governance.md). +A new network parameter, a JSON list of network id / chain id / name one per Ethereum RPC and EVM chain will be used for setting supported L2. This is set via [governance](./0028-GOVE-governance.md). Name `blockchains.ethereumL2Configs`. Example value: ``` @@ -21,21 +22,21 @@ Example value: ``` Duplicate values of "network_id": 10, "chain_id" or "name":"optimism" or not allowed (an update will be rejected at validation stage). Any updat emust always change the entire JSON (it's not possible to change individual entries). -A proposal to *remove* a registered L2 must fail at enactment stage if a market is referencing an EthL2 data source. -A proposal for a new market will fail at enactment stage if it's referencing an EthL2 that's not registered. +A proposal to *remove* a registered Ethereum RPC+EVM compatible chain / L2 must fail at enactment stage if a market is referencing an EthRpcEvmCompatible data source. +A proposal for a new market will fail at enactment stage if it's referencing an EthRpcEvmCompatible that's not registered. ## Acceptance criteria -- It is possible to add EthL2 via governance. +- It is possible to add EthRpcEvmCompatible via governance. -- It is possible to remove an EthL2 via governance. The proposal will fail at enactment stage if there is any market that's not settled / closed that reference the EthL2. +- It is possible to remove an EthRpcEvmCompatible via governance. The proposal will fail at enactment stage if there is any market that's not settled / closed that reference the EthRpcEvmCompatible. -- A market proposal that reference an EthL2 that's not active will fail at enactment stage. +- A market proposal that reference an EthRpcEvmCompatible that's not active will fail at enactment stage. -- It may happen that an EthL2 that cannot be read from is proposed (because not enough validator nodes have it configured etc.). In that case a proposed / enacted market will not see the oracle inputs but it must be possible to change the said market via on-chain governance. +- It may happen that an EthRpcEvmCompatible that cannot be read from is proposed (because not enough validator nodes have it configured etc.). In that case a proposed / enacted market will not see the oracle inputs but it must be possible to change the said market via on-chain governance. -- Two different markets may reference two identical EthL2 contracts and ABIs, even with same contract address *but* on two different EthL2 and they each get the correct values i.e. if we have market 1 with +- Two different markets may reference two identical EthRpcEvmCompatible contracts and ABIs, even with same contract address *but* on two different EthL2 and they each get the correct values i.e. if we have market 1 with ``` source: EthereumEvent { source_chain_id: 0x123 @@ -51,5 +52,5 @@ source: EthereumEvent { ABI: "...JSON..." event: "MyFaveEvent" ``` -Then market 1 only sees events of that type from EthL2 0x123 while market 2 only sees events of that type from EthL2 0x789. +Then market 1 only sees events of that type from EthRpcEvmCompatible 0x123 while market 2 only sees events of that type from EthRpcEvmCompatible 0x789. From 95b2e9c61c70fa1b47590ca764ac34f1532d28fa Mon Sep 17 00:00:00 2001 From: gordsport Date: Fri, 5 Jan 2024 12:07:46 +0000 Subject: [PATCH 0839/1171] chore: add initial AC codes and fix linting --- .../0087-EVMD-eth-rpc-and-evm-data-source.md | 45 ++++++++++--------- protocol/categories.json | 2 +- protocol/features.json | 10 +++++ wordlist.txt | 2 + 4 files changed, 38 insertions(+), 21 deletions(-) diff --git a/protocol/0087-EVMD-eth-rpc-and-evm-data-source.md b/protocol/0087-EVMD-eth-rpc-and-evm-data-source.md index 14152b730..f348b7ddf 100644 --- a/protocol/0087-EVMD-eth-rpc-and-evm-data-source.md +++ b/protocol/0087-EVMD-eth-rpc-and-evm-data-source.md @@ -1,56 +1,61 @@ # Ethereum RPC and EVM based data sources -## Summary +## Summary -This specification adds a new way of sourcing data from any chain or Ethereum L2 that supports Ethereum RPC calls and runs an EVM. +This specification adds a new way of sourcing data from any chain or Ethereum L2 that supports Ethereum RPC calls and runs an EVM. The data is to be ingested as an Ethereum [data source](./0045-DSRC-data_sourcing.md) but pointing at a different RPC endpoint. Hence this is in addition to and building upon [Ethereum data source](./0082-ETHD-ethereum-data-source.md). -## Decription +## Description -In addition to listening to Ethereum events and reading from Ethereum contrants as described in [Ethereum data source](./0082-ETHD-ethereum-data-source.md) it will be possible for Vega nodes to listen to events from and read from other chains that implement Ethereum RPC and run EVM, in particular Ethereum L2. +In addition to listening to Ethereum events and reading from Ethereum contracts as described in [Ethereum data source](./0082-ETHD-ethereum-data-source.md) it will be possible for Vega nodes to listen to events from and read from other chains that implement Ethereum RPC and run EVM, in particular Ethereum L2. -The overarching principle is that the chain provides ethereum RPC / EVMs and thus contracts and ABIs are assumed to be functionally the same as on Ethereum itself. +The overarching principle is that the chain provides ethereum RPC / EVMs and thus contracts and ABIs are assumed to be functionally the same as on Ethereum itself. ## Registration / removal -A new network parameter, a JSON list of network id / chain id / name one per Ethereum RPC and EVM chain will be used for setting supported L2. This is set via [governance](./0028-GOVE-governance.md). +A new network parameter, a JSON list of network id / chain id / name one per Ethereum RPC and EVM chain will be used for setting supported L2. This is set via [governance](./0028-GOVE-governance.md). Name `blockchains.ethereumL2Configs`. -Example value: -``` +Example value: + +```json {"configs": [{"network_id": 10, "chain_id": 10, "confirmations": 3, "name":"optimism"}]} ``` -Duplicate values of "network_id": 10, "chain_id" or "name":"optimism" or not allowed (an update will be rejected at validation stage). -Any updat emust always change the entire JSON (it's not possible to change individual entries). -A proposal to *remove* a registered Ethereum RPC+EVM compatible chain / L2 must fail at enactment stage if a market is referencing an EthRpcEvmCompatible data source. -A proposal for a new market will fail at enactment stage if it's referencing an EthRpcEvmCompatible that's not registered. + +Duplicate values of "network_id": 10, "chain_id" or "name":"optimism" are not allowed (an update will be rejected at validation stage). +Any update must always change the entire JSON (it's not possible to change individual entries). +A proposal to *remove* a registered Ethereum RPC+EVM compatible chain / L2 must fail at enactment stage if a market is referencing an `EthRpcEvmCompatible` data source. +A proposal for a new market will fail at enactment stage if it's referencing an `EthRpcEvmCompatible` that's not registered. ## Acceptance criteria -- It is possible to add EthRpcEvmCompatible via governance. +- It is possible to add `EthRpcEvmCompatible` via governance (0087-EVMD-001). -- It is possible to remove an EthRpcEvmCompatible via governance. The proposal will fail at enactment stage if there is any market that's not settled / closed that reference the EthRpcEvmCompatible. +- It is possible to remove an `EthRpcEvmCompatible` via governance. The proposal will fail at enactment stage if there is any market that's not settled / closed that reference the `EthRpcEvmCompatible` (0087-EVMD-002). -- A market proposal that reference an EthRpcEvmCompatible that's not active will fail at enactment stage. +- A market proposal that reference an `EthRpcEvmCompatible` that's not active will fail at enactment stage (0087-EVMD-003). -- It may happen that an EthRpcEvmCompatible that cannot be read from is proposed (because not enough validator nodes have it configured etc.). In that case a proposed / enacted market will not see the oracle inputs but it must be possible to change the said market via on-chain governance. +- It may happen that an `EthRpcEvmCompatible` that cannot be read from is proposed (because not enough validator nodes have it configured etc.). In that case a proposed / enacted market will not see the oracle inputs but it must be possible to change the said market via on-chain governance (0087-EVMD-004). -- Two different markets may reference two identical EthRpcEvmCompatible contracts and ABIs, even with same contract address *but* on two different EthL2 and they each get the correct values i.e. if we have market 1 with -``` +- Two different markets may reference two identical `EthRpcEvmCompatible` contracts and ABIs, even with same contract address *but* on two different Ethereum L2s and they each get the correct values i.e. if we have market 1 with + +```yaml source: EthereumEvent { source_chain_id: 0x123 contract: 0xDEADBEEF ABI: "...JSON..." event: "MyFaveEvent" ``` + and market 2 with -``` + +```yaml source: EthereumEvent { source_chain_id: 0x789 contract: 0xDEADBEEF ABI: "...JSON..." event: "MyFaveEvent" ``` -Then market 1 only sees events of that type from EthRpcEvmCompatible 0x123 while market 2 only sees events of that type from EthRpcEvmCompatible 0x789. +Then market 1 only sees events of that type from `EthRpcEvmCompatible` 0x123 while market 2 only sees events of that type from `EthRpcEvmCompatible` 0x789 (0087-EVMD-005). diff --git a/protocol/categories.json b/protocol/categories.json index 1aebfab68..3491d10f7 100644 --- a/protocol/categories.json +++ b/protocol/categories.json @@ -6,7 +6,7 @@ "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", "0081-SUCM"] }, "Settlement & Oracles": { - "specs": ["0002-STTL", "0003-MTMK", "0045-DSRC", "0046-DSRM", "0047-DSRF", "0048-DSRI", "0082-ETHD", "0087-EL2D"] + "specs": ["0002-STTL", "0003-MTMK", "0045-DSRC", "0046-DSRM", "0047-DSRF", "0048-DSRI", "0082-ETHD", "0087-EVMD"] }, "Protections": { "specs": ["0073-LIMN", "0072-SPPW", "0062-SPAM", "0060-WEND", "0003-NP-LIMI", "0072-SPPW", "0078-NWLI", "0079-TGAP"] diff --git a/protocol/features.json b/protocol/features.json index 44cb19530..b39403737 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -319,6 +319,16 @@ "0053-PERP-035" ] }, + "Ethereum RPC and EVM based data sources": { + "milestone": "unknown", + "acs": [ + "0087-EVMD-001", + "0087-EVMD-002", + "0087-EVMD-003", + "0087-EVMD-004", + "0087-EVMD-005" + ] + }, "Unknown": { "milestone": "unknown", "acs": [] diff --git a/wordlist.txt b/wordlist.txt index 9b3a9d1ca..4485d586b 100644 --- a/wordlist.txt +++ b/wordlist.txt @@ -2,6 +2,7 @@ $VEGA ABCI ABCI++ ABI +ABIs actioned Allowlist allowlisted @@ -97,6 +98,7 @@ ETHB Ethereum eventbus EVM +EVMs executables familiarise FBAs From 518f084bfeec21802b0cc36b09c3291d7efc05f2 Mon Sep 17 00:00:00 2001 From: gordsport Date: Fri, 5 Jan 2024 12:10:18 +0000 Subject: [PATCH 0840/1171] fix: codeblock formatting --- protocol/0087-EVMD-eth-rpc-and-evm-data-source.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/protocol/0087-EVMD-eth-rpc-and-evm-data-source.md b/protocol/0087-EVMD-eth-rpc-and-evm-data-source.md index f348b7ddf..4b85db59a 100644 --- a/protocol/0087-EVMD-eth-rpc-and-evm-data-source.md +++ b/protocol/0087-EVMD-eth-rpc-and-evm-data-source.md @@ -42,20 +42,20 @@ A proposal for a new market will fail at enactment stage if it's referencing an ```yaml source: EthereumEvent { - source_chain_id: 0x123 + source_chain_id: 0x123 contract: 0xDEADBEEF - ABI: "...JSON..." - event: "MyFaveEvent" + ABI: "...JSON..." + event: "MyFaveEvent" ``` and market 2 with ```yaml source: EthereumEvent { - source_chain_id: 0x789 + source_chain_id: 0x789 contract: 0xDEADBEEF - ABI: "...JSON..." - event: "MyFaveEvent" + ABI: "...JSON..." + event: "MyFaveEvent" ``` Then market 1 only sees events of that type from `EthRpcEvmCompatible` 0x123 while market 2 only sees events of that type from `EthRpcEvmCompatible` 0x789 (0087-EVMD-005). From da010284de86bd7bad5736e746df15367b4b1c82 Mon Sep 17 00:00:00 2001 From: gordsport Date: Fri, 5 Jan 2024 12:27:07 +0000 Subject: [PATCH 0841/1171] fix: milestone name --- protocol/features.json | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/features.json b/protocol/features.json index b39403737..3f06143ca 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -320,7 +320,7 @@ ] }, "Ethereum RPC and EVM based data sources": { - "milestone": "unknown", + "milestone": "palazzo", "acs": [ "0087-EVMD-001", "0087-EVMD-002", From 857aadd742a11187389cce76c8713ae1602037bd Mon Sep 17 00:00:00 2001 From: gordsport Date: Fri, 5 Jan 2024 14:11:13 +0000 Subject: [PATCH 0842/1171] chore: Add ACs from the Eth spec to the L2 spec --- .../0087-EVMD-eth-rpc-and-evm-data-source.md | 72 +++++++++++++++++-- protocol/features.json | 51 ++++++++----- 2 files changed, 103 insertions(+), 20 deletions(-) diff --git a/protocol/0087-EVMD-eth-rpc-and-evm-data-source.md b/protocol/0087-EVMD-eth-rpc-and-evm-data-source.md index 4b85db59a..b22561f5d 100644 --- a/protocol/0087-EVMD-eth-rpc-and-evm-data-source.md +++ b/protocol/0087-EVMD-eth-rpc-and-evm-data-source.md @@ -30,13 +30,37 @@ A proposal for a new market will fail at enactment stage if it's referencing an ## Acceptance criteria + +### External Oracles - Creation + - It is possible to add `EthRpcEvmCompatible` via governance (0087-EVMD-001). -- It is possible to remove an `EthRpcEvmCompatible` via governance. The proposal will fail at enactment stage if there is any market that's not settled / closed that reference the `EthRpcEvmCompatible` (0087-EVMD-002). -- A market proposal that reference an `EthRpcEvmCompatible` that's not active will fail at enactment stage (0087-EVMD-003). +### External Oracles - Deactivation (not implemented in Palazzo milestone) + +- It is possible to remove an `EthRpcEvmCompatible` via governance. The proposal will fail at enactment stage if there is any market that's not settled / closed that reference the `EthRpcEvmCompatible` (0087-NEBULA-002). + + +### External Oracles - Amendments + +- It may happen that an `EthRpcEvmCompatible` that cannot be read from is proposed (because not enough validator nodes have it configured etc.). In that case a proposed / enacted market will not see the oracle inputs but it must be possible to change the said market via on-chain governance (0087-EVMD-003). +- 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 (0087-EVMD-004) +- 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 (0087-EVMD-005) +- 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 (0087-EVMD-006) +- 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 (0087-EVMD-007) -- It may happen that an `EthRpcEvmCompatible` that cannot be read from is proposed (because not enough validator nodes have it configured etc.). In that case a proposed / enacted market will not see the oracle inputs but it must be possible to change the said market via on-chain governance (0087-EVMD-004). + +### External Oracles - Validations + +- A market proposal that reference an `EthRpcEvmCompatible` that's not active will fail at enactment stage (0087-EVMD-008). +- Validate if the smart contract address is valid (0087-EVMD-009) +- 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 (0087-EVMD-010) +- Validations for min / max frequency of listening for events / read a smart contract (0087-EVMD-011) +- 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 (0087-EVMD-012) +- Any mismatch between expected fields/field types and received fields/field types should emit an error event (0087-EVMD-013) + + +### Usage - Two different markets may reference two identical `EthRpcEvmCompatible` contracts and ABIs, even with same contract address *but* on two different Ethereum L2s and they each get the correct values i.e. if we have market 1 with @@ -58,4 +82,44 @@ source: EthereumEvent { event: "MyFaveEvent" ``` -Then market 1 only sees events of that type from `EthRpcEvmCompatible` 0x123 while market 2 only sees events of that type from `EthRpcEvmCompatible` 0x789 (0087-EVMD-005). +Then market 1 only sees events of that type from `EthRpcEvmCompatible` 0x123 while market 2 only sees events of that type from `EthRpcEvmCompatible` 0x789 (0087-EVMD-014). + +- It should be possible to use only `EthRpcEvmCompatible` data sources in a market proposal, or create any combination with any of the other types of currently existing external or internal data sources (0087-EVMD-015) +- Create a market to use an internal data source to terminate a market and an `EthRpcEvmCompatible` to settle the market (0087-EVMD-016) +- Create a market to use an external data source to terminate a market and an `EthRpcEvmCompatible` to settle the market (0087-EVMD-017) +- Create a market to use an open oracle data source to settle a market and an `EthRpcEvmCompatible` to terminate the market (0087-EVMD-018) +- `EthRpcEvmCompatible` 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) (0087-EVMD-019) +- `EthRpcEvmCompatible` data sources should only forward data after a configurable number of confirmations (0087-EVMD-020) +- Create 2 markets to use the same `EthRpcEvmCompatible` data source for termination say DS-T1 but two different `EthRpcEvmCompatible` data sources 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. (0087-EVMD-021) +- Create a market to use an `EthRpcEvmCompatible` data source 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. (0087-EVMD-022) +- 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 `EthRpcEvmCompatible` data source 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. (0087-EVMD-023) +- 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. (0087-EVMD-024) +- Network wide contract error should be reported via oracle data events (0087-EVMD-025) +12. Different contracts on different markets - Create 2 markets with `EthRpcEvmCompatible` 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. (0087-EVMD-026) +- Different contracts on different markets - Create 2 markets with `EthRpcEvmCompatible` 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. (0087-EVMD-027) + + +### Negative Tests + +- Set up a new data source with invalid contract address - should fail validations (0087-EVMD-028). +- 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 (0087-EVMD-029) +- Set up a network such that different vega nodes receive conflicting results from an identical `EthRpcEvmCompatible` 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 (0087-EVMD-030) + +### API + +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 (0087-EVMD-031) +2. Ability to query historic data sent by an ethereum oracle source, for settlement and termination, and processed by a market in vega network (0087-EVMD-032) + + +### Snapshots + +- 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 `EthRpcEvmCompatible` data sources. (0087-EVMD-033) + +### Protocol Upgrade + +- Have a network running with a couple of futures markets with a mix of internal, external, open ethereum and `EthRpcEvmCompatible` 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 (0087-EVMD-034) +- Have a network running with a couple of perpetual markets with a mix of internal, external, open, ethereum and `EthRpcEvmCompatible` 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 (0087-EVMD-035) +- Create a futures market with an `EthRpcEvmCompatible` 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. (0087-EVMD-036) +- Create a futures market with an `EthRpcEvmCompatible` 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. (0087-EVMD-037) +- Create a perpetual market with an `EthRpcEvmCompatible` 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. (0087-EVMD-038) +- Ensure that markets with `EthRpcEvmCompatible` termination and settlement data sources continue to successfully terminate and settle markets after the protocol upgrade. (0087-EVMD-039) diff --git a/protocol/features.json b/protocol/features.json index 3f06143ca..cb27d9f52 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -18,12 +18,6 @@ "Perpetuals": { "milestone": "palazzo", "acs": [ - "0073-LIMN-105", - "0073-LIMN-107", - "0073-LIMN-108", - "0073-LIMN-110", - "0073-LIMN-111", - "0081-SUCM-015", "0014-ORDT-120", "0014-ORDT-121", "0014-ORDT-122", @@ -71,10 +65,6 @@ "milestone": "palazzo", "acs": ["0004-AMND-056", "0004-AMND-057", "0004-AMND-058", "0004-AMND-059"] }, - "Ethereum heartbeat": { - "milestone": "palazzo", - "acs": [] - }, "Margin isolation": { "milestone": "palazzo", "acs": [ @@ -209,10 +199,6 @@ "0012-POSR-015" ] }, - "Passive liquidity": { - "milestone": "palazzo", - "acs": [] - }, "Batch governance proposals": { "milestone": "palazzo", "acs": [ @@ -323,10 +309,43 @@ "milestone": "palazzo", "acs": [ "0087-EVMD-001", - "0087-EVMD-002", "0087-EVMD-003", "0087-EVMD-004", - "0087-EVMD-005" + "0087-EVMD-005", + "0087-EVMD-006", + "0087-EVMD-007", + "0087-EVMD-008", + "0087-EVMD-009", + "0087-EVMD-010", + "0087-EVMD-011", + "0087-EVMD-012", + "0087-EVMD-013", + "0087-EVMD-014", + "0087-EVMD-015", + "0087-EVMD-016", + "0087-EVMD-017", + "0087-EVMD-018", + "0087-EVMD-019", + "0087-EVMD-020", + "0087-EVMD-021", + "0087-EVMD-022", + "0087-EVMD-023", + "0087-EVMD-024", + "0087-EVMD-025", + "0087-EVMD-026", + "0087-EVMD-027", + "0087-EVMD-028", + "0087-EVMD-029", + "0087-EVMD-030", + "0087-EVMD-031", + "0087-EVMD-032", + "0087-EVMD-033", + "0087-EVMD-034", + "0087-EVMD-035", + "0087-EVMD-036", + "0087-EVMD-037", + "0087-EVMD-038", + "0087-EVMD-039" ] }, "Unknown": { From fdd991dcad2a71b4960150acc90fa835387059c0 Mon Sep 17 00:00:00 2001 From: gordsport Date: Fri, 5 Jan 2024 14:12:40 +0000 Subject: [PATCH 0843/1171] fix: review comment --- protocol/0087-EVMD-eth-rpc-and-evm-data-source.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0087-EVMD-eth-rpc-and-evm-data-source.md b/protocol/0087-EVMD-eth-rpc-and-evm-data-source.md index b22561f5d..9eedf5a5d 100644 --- a/protocol/0087-EVMD-eth-rpc-and-evm-data-source.md +++ b/protocol/0087-EVMD-eth-rpc-and-evm-data-source.md @@ -22,7 +22,7 @@ Example value: {"configs": [{"network_id": 10, "chain_id": 10, "confirmations": 3, "name":"optimism"}]} ``` -Duplicate values of "network_id": 10, "chain_id" or "name":"optimism" are not allowed (an update will be rejected at validation stage). +Duplicate values of `network_id`, `chain_id` or `name` are not allowed (an update will be rejected at validation stage). Any update must always change the entire JSON (it's not possible to change individual entries). A proposal to *remove* a registered Ethereum RPC+EVM compatible chain / L2 must fail at enactment stage if a market is referencing an `EthRpcEvmCompatible` data source. A proposal for a new market will fail at enactment stage if it's referencing an `EthRpcEvmCompatible` that's not registered. From d277ea68c9166af12328174a600f6e832139ba85 Mon Sep 17 00:00:00 2001 From: gordsport Date: Fri, 5 Jan 2024 14:17:34 +0000 Subject: [PATCH 0844/1171] fix: MD linting --- protocol/0087-EVMD-eth-rpc-and-evm-data-source.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/protocol/0087-EVMD-eth-rpc-and-evm-data-source.md b/protocol/0087-EVMD-eth-rpc-and-evm-data-source.md index 9eedf5a5d..18c52b276 100644 --- a/protocol/0087-EVMD-eth-rpc-and-evm-data-source.md +++ b/protocol/0087-EVMD-eth-rpc-and-evm-data-source.md @@ -95,7 +95,7 @@ Then market 1 only sees events of that type from `EthRpcEvmCompatible` 0x123 whi - 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 `EthRpcEvmCompatible` data source 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. (0087-EVMD-023) - 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. (0087-EVMD-024) - Network wide contract error should be reported via oracle data events (0087-EVMD-025) -12. Different contracts on different markets - Create 2 markets with `EthRpcEvmCompatible` 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. (0087-EVMD-026) +- Different contracts on different markets - Create 2 markets with `EthRpcEvmCompatible` 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. (0087-EVMD-026) - Different contracts on different markets - Create 2 markets with `EthRpcEvmCompatible` 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. (0087-EVMD-027) @@ -107,8 +107,8 @@ Then market 1 only sees events of that type from `EthRpcEvmCompatible` 0x123 whi ### API -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 (0087-EVMD-031) -2. Ability to query historic data sent by an ethereum oracle source, for settlement and termination, and processed by a market in vega network (0087-EVMD-032) +- 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 (0087-EVMD-031) +- Ability to query historic data sent by an ethereum oracle source, for settlement and termination, and processed by a market in vega network (0087-EVMD-032) ### Snapshots From 3abad865fcdb0152f44d0c9b1b4a0c1ff9058b3f Mon Sep 17 00:00:00 2001 From: gordsport Date: Fri, 5 Jan 2024 14:20:03 +0000 Subject: [PATCH 0845/1171] fix: approbation linting --- protocol/0087-EVMD-eth-rpc-and-evm-data-source.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/protocol/0087-EVMD-eth-rpc-and-evm-data-source.md b/protocol/0087-EVMD-eth-rpc-and-evm-data-source.md index 18c52b276..bf144edf0 100644 --- a/protocol/0087-EVMD-eth-rpc-and-evm-data-source.md +++ b/protocol/0087-EVMD-eth-rpc-and-evm-data-source.md @@ -38,7 +38,7 @@ A proposal for a new market will fail at enactment stage if it's referencing an ### External Oracles - Deactivation (not implemented in Palazzo milestone) -- It is possible to remove an `EthRpcEvmCompatible` via governance. The proposal will fail at enactment stage if there is any market that's not settled / closed that reference the `EthRpcEvmCompatible` (0087-NEBULA-002). +- It is possible to remove an `EthRpcEvmCompatible` via governance. The proposal will fail at enactment stage if there is any market that's not settled / closed that reference the `EthRpcEvmCompatible`. ### External Oracles - Amendments @@ -47,7 +47,7 @@ A proposal for a new market will fail at enactment stage if it's referencing an - 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 (0087-EVMD-004) - 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 (0087-EVMD-005) - 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 (0087-EVMD-006) -- 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 (0087-EVMD-007) +- 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 (0087-EVMD-007) ### External Oracles - Validations From 7c581ddccb37ced0b98602b87376e9bd486d94a6 Mon Sep 17 00:00:00 2001 From: David Siska <62546419+davidsiska-vega@users.noreply.github.com> Date: Fri, 5 Jan 2024 13:40:36 +0000 Subject: [PATCH 0846/1171] fix: clarity on what is meant by L2 --- protocol/0087-EVMD-eth-rpc-and-evm-data-source.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/protocol/0087-EVMD-eth-rpc-and-evm-data-source.md b/protocol/0087-EVMD-eth-rpc-and-evm-data-source.md index bf144edf0..fa27e406d 100644 --- a/protocol/0087-EVMD-eth-rpc-and-evm-data-source.md +++ b/protocol/0087-EVMD-eth-rpc-and-evm-data-source.md @@ -31,9 +31,9 @@ A proposal for a new market will fail at enactment stage if it's referencing an ## Acceptance criteria -### External Oracles - Creation +- It is possible to remove an EthRpcEvmCompatible via governance. The proposal will fail at enactment stage if there is any market that's not settled / closed that reference the EthRpcEvmCompatible. This is a future requirement and does not have an AC code. -- It is possible to add `EthRpcEvmCompatible` via governance (0087-EVMD-001). +- A market proposal that reference an EthRpcEvmCompatible that's not registered will fail at enactment stage. ### External Oracles - Deactivation (not implemented in Palazzo milestone) From 50d0be20f6787a451ea1dcf6e9fba555293cb6d0 Mon Sep 17 00:00:00 2001 From: Sohill-Patel <85170301+Sohill-Patel@users.noreply.github.com> Date: Fri, 5 Jan 2024 16:23:32 +0000 Subject: [PATCH 0847/1171] feat: few acs for stop orders in auction --- protocol/0014-ORDT-order_types.md | 14 +++++++++++--- protocol/features.json | 2 +- 2 files changed, 12 insertions(+), 4 deletions(-) diff --git a/protocol/0014-ORDT-order_types.md b/protocol/0014-ORDT-order_types.md index 64adfd7b4..17de0b026 100644 --- a/protocol/0014-ORDT-order_types.md +++ b/protocol/0014-ORDT-order_types.md @@ -92,7 +92,9 @@ Therefore the trigger level of a stop order moves with the market allowing the t - 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. +- A stop order can be entered during an auction (except opening 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. + +- A stop order entered during opening auction will be rejected. - GFA is not a valid TIF for a stop order submission. @@ -370,8 +372,14 @@ In Spot market, for multiple iceberg orders submitted as a batch of orders with - 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) +- A stop order placed during an auction will not execute during an auction, nor will it participate in the uncrossing. (0014-ORDT-065) +- A stop order placed during an auction, where the uncrossing price is within the triggering range, will immediately execute following uncrossing. (0014-ORDT-066) + +- A stop order placed prior to an auction will not execute during an auction, nor will it participate in the uncrossing. (0014-ORDT-124) +- A stop order placed prior to an auction, where the uncrossing price is within the triggering range, will immediately execute following uncrossing. (0014-ORDT-125) + +- A party places a stop order on a market in continuous trading, the market moves to an auction and the party cancels the stop order. When the market exits the auction the party no longer has a stop order. (0014-ORDT-127) +- A stop order placed during the opening auction, will be rejected. (0014-ORDT-126) - 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) diff --git a/protocol/features.json b/protocol/features.json index 44cb19530..d0c2063e6 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -13,7 +13,7 @@ }, "Stop Orders": { "milestone": "cosmic-carryover", - "acs": ["0079-TGAP-004", "0079-TGAP-005"] + "acs": ["0079-TGAP-004", "0079-TGAP-005", "0014-ORDT-124", "0014-ORDT-125", "0014-ORDT-126", "0014-ORDT-127"] }, "Perpetuals": { "milestone": "palazzo", From 2366b5789c46683cc8ada275881eb42ad8cb55fd Mon Sep 17 00:00:00 2001 From: Sohill-Patel <85170301+Sohill-Patel@users.noreply.github.com> Date: Fri, 5 Jan 2024 16:28:13 +0000 Subject: [PATCH 0848/1171] fix: updated ac numbers --- protocol/0014-ORDT-order_types.md | 8 ++++---- protocol/features.json | 2 +- 2 files changed, 5 insertions(+), 5 deletions(-) diff --git a/protocol/0014-ORDT-order_types.md b/protocol/0014-ORDT-order_types.md index 17de0b026..c7164bd7e 100644 --- a/protocol/0014-ORDT-order_types.md +++ b/protocol/0014-ORDT-order_types.md @@ -375,11 +375,11 @@ In Spot market, for multiple iceberg orders submitted as a batch of orders with - A stop order placed during an auction will not execute during an auction, nor will it participate in the uncrossing. (0014-ORDT-065) - A stop order placed during an auction, where the uncrossing price is within the triggering range, will immediately execute following uncrossing. (0014-ORDT-066) -- A stop order placed prior to an auction will not execute during an auction, nor will it participate in the uncrossing. (0014-ORDT-124) -- A stop order placed prior to an auction, where the uncrossing price is within the triggering range, will immediately execute following uncrossing. (0014-ORDT-125) +- A stop order placed prior to an auction will not execute during an auction, nor will it participate in the uncrossing. (0014-ORDT-130) +- A stop order placed prior to an auction, where the uncrossing price is within the triggering range, will immediately execute following uncrossing. (0014-ORDT-131) -- A party places a stop order on a market in continuous trading, the market moves to an auction and the party cancels the stop order. When the market exits the auction the party no longer has a stop order. (0014-ORDT-127) -- A stop order placed during the opening auction, will be rejected. (0014-ORDT-126) +- A party places a stop order on a market in continuous trading, the market moves to an auction and the party cancels the stop order. When the market exits the auction the party no longer has a stop order. (0014-ORDT-132) +- A stop order placed during the opening auction, will be rejected. (0014-ORDT-133) - 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) diff --git a/protocol/features.json b/protocol/features.json index d0c2063e6..d7800168d 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -13,7 +13,7 @@ }, "Stop Orders": { "milestone": "cosmic-carryover", - "acs": ["0079-TGAP-004", "0079-TGAP-005", "0014-ORDT-124", "0014-ORDT-125", "0014-ORDT-126", "0014-ORDT-127"] + "acs": ["0079-TGAP-004", "0079-TGAP-005", "0014-ORDT-130", "0014-ORDT-131", "0014-ORDT-132", "0014-ORDT-133"] }, "Perpetuals": { "milestone": "palazzo", From f4212991826c082c0634eac2675455f9c0069b30 Mon Sep 17 00:00:00 2001 From: Sohill-Patel <85170301+Sohill-Patel@users.noreply.github.com> Date: Fri, 5 Jan 2024 16:30:42 +0000 Subject: [PATCH 0849/1171] fix: still dup acs --- protocol/0014-ORDT-order_types.md | 4 ++-- protocol/features.json | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/protocol/0014-ORDT-order_types.md b/protocol/0014-ORDT-order_types.md index c7164bd7e..0fafbcc4e 100644 --- a/protocol/0014-ORDT-order_types.md +++ b/protocol/0014-ORDT-order_types.md @@ -375,8 +375,8 @@ In Spot market, for multiple iceberg orders submitted as a batch of orders with - A stop order placed during an auction will not execute during an auction, nor will it participate in the uncrossing. (0014-ORDT-065) - A stop order placed during an auction, where the uncrossing price is within the triggering range, will immediately execute following uncrossing. (0014-ORDT-066) -- A stop order placed prior to an auction will not execute during an auction, nor will it participate in the uncrossing. (0014-ORDT-130) -- A stop order placed prior to an auction, where the uncrossing price is within the triggering range, will immediately execute following uncrossing. (0014-ORDT-131) +- A stop order placed prior to an auction will not execute during an auction, nor will it participate in the uncrossing. (0014-ORDT-134) +- A stop order placed prior to an auction, where the uncrossing price is within the triggering range, will immediately execute following uncrossing. (0014-ORDT-135) - A party places a stop order on a market in continuous trading, the market moves to an auction and the party cancels the stop order. When the market exits the auction the party no longer has a stop order. (0014-ORDT-132) - A stop order placed during the opening auction, will be rejected. (0014-ORDT-133) diff --git a/protocol/features.json b/protocol/features.json index d7800168d..fa32f8bdd 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -13,7 +13,7 @@ }, "Stop Orders": { "milestone": "cosmic-carryover", - "acs": ["0079-TGAP-004", "0079-TGAP-005", "0014-ORDT-130", "0014-ORDT-131", "0014-ORDT-132", "0014-ORDT-133"] + "acs": ["0079-TGAP-004", "0079-TGAP-005", "0014-ORDT-134", "0014-ORDT-135", "0014-ORDT-132", "0014-ORDT-133"] }, "Perpetuals": { "milestone": "palazzo", From 299d26cda39210f85fa1192413273f409420a63e Mon Sep 17 00:00:00 2001 From: gordsport Date: Fri, 5 Jan 2024 16:35:52 +0000 Subject: [PATCH 0850/1171] fix: removed AC codes and add L2 clarification --- protocol/0087-EVMD-eth-rpc-and-evm-data-source.md | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-) diff --git a/protocol/0087-EVMD-eth-rpc-and-evm-data-source.md b/protocol/0087-EVMD-eth-rpc-and-evm-data-source.md index fa27e406d..d949d84fc 100644 --- a/protocol/0087-EVMD-eth-rpc-and-evm-data-source.md +++ b/protocol/0087-EVMD-eth-rpc-and-evm-data-source.md @@ -2,7 +2,11 @@ ## Summary -This specification adds a new way of sourcing data from any chain or Ethereum L2 that supports Ethereum RPC calls and runs an EVM. +This specification adds a new way of sourcing data from any chain or Ethereum Layer 2 blockchain (L2) that supports Ethereum RPC calls and runs an EVM. + +> [!TIP] +> A Layer 2 blockchain refers to network protocols that are layered on top of a Layer 1 solution. Layer 2 protocols use the Layer 1 blockchain for network and security infrastructure. + The data is to be ingested as an Ethereum [data source](./0045-DSRC-data_sourcing.md) but pointing at a different RPC endpoint. Hence this is in addition to and building upon [Ethereum data source](./0082-ETHD-ethereum-data-source.md). @@ -31,14 +35,14 @@ A proposal for a new market will fail at enactment stage if it's referencing an ## Acceptance criteria -- It is possible to remove an EthRpcEvmCompatible via governance. The proposal will fail at enactment stage if there is any market that's not settled / closed that reference the EthRpcEvmCompatible. This is a future requirement and does not have an AC code. +### External Oracles - Creation -- A market proposal that reference an EthRpcEvmCompatible that's not registered will fail at enactment stage. +- It is possible to add `EthRpcEvmCompatible` via governance (0087-EVMD-001). ### External Oracles - Deactivation (not implemented in Palazzo milestone) -- It is possible to remove an `EthRpcEvmCompatible` via governance. The proposal will fail at enactment stage if there is any market that's not settled / closed that reference the `EthRpcEvmCompatible`. +- It is possible to remove an `EthRpcEvmCompatible` via governance. The proposal will fail at enactment stage if there is any market that's not settled / closed that reference the `EthRpcEvmCompatible`. This is a future requirement and does not have an AC code. ### External Oracles - Amendments From c34bd900d709ab38d97429d042bd9c967ebcfd22 Mon Sep 17 00:00:00 2001 From: Sohill-Patel <85170301+Sohill-Patel@users.noreply.github.com> Date: Fri, 5 Jan 2024 16:40:30 +0000 Subject: [PATCH 0851/1171] feat: added one more ac --- protocol/0014-ORDT-order_types.md | 1 + protocol/features.json | 2 +- 2 files changed, 2 insertions(+), 1 deletion(-) diff --git a/protocol/0014-ORDT-order_types.md b/protocol/0014-ORDT-order_types.md index 0fafbcc4e..ec5f61486 100644 --- a/protocol/0014-ORDT-order_types.md +++ b/protocol/0014-ORDT-order_types.md @@ -377,6 +377,7 @@ In Spot market, for multiple iceberg orders submitted as a batch of orders with - A stop order placed prior to an auction will not execute during an auction, nor will it participate in the uncrossing. (0014-ORDT-134) - A stop order placed prior to an auction, where the uncrossing price is within the triggering range, will immediately execute following uncrossing. (0014-ORDT-135) +- An order with a stop is placed during continuous trading. The market goes into auction. The market exits auction, the condition for triggering the stop is not met. The stop order is still present. (0014-ORDT-136) - A party places a stop order on a market in continuous trading, the market moves to an auction and the party cancels the stop order. When the market exits the auction the party no longer has a stop order. (0014-ORDT-132) - A stop order placed during the opening auction, will be rejected. (0014-ORDT-133) diff --git a/protocol/features.json b/protocol/features.json index fa32f8bdd..372371621 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -13,7 +13,7 @@ }, "Stop Orders": { "milestone": "cosmic-carryover", - "acs": ["0079-TGAP-004", "0079-TGAP-005", "0014-ORDT-134", "0014-ORDT-135", "0014-ORDT-132", "0014-ORDT-133"] + "acs": ["0079-TGAP-004", "0079-TGAP-005", "0014-ORDT-132", "0014-ORDT-133", "0014-ORDT-134", "0014-ORDT-135", "0014-ORDT-136"] }, "Perpetuals": { "milestone": "palazzo", From 3f8d620237ebfe648b7f44c81fabc37630bbcd24 Mon Sep 17 00:00:00 2001 From: Charlie Date: Fri, 5 Jan 2024 17:50:33 +0000 Subject: [PATCH 0852/1171] feat: add acs for network profit and loss --- protocol/0012-POSR-position_resolution.md | 12 ++++++++++++ protocol/features.json | 5 ++++- 2 files changed, 16 insertions(+), 1 deletion(-) diff --git a/protocol/0012-POSR-position_resolution.md b/protocol/0012-POSR-position_resolution.md index acaa18609..02f3f3505 100644 --- a/protocol/0012-POSR-position_resolution.md +++ b/protocol/0012-POSR-position_resolution.md @@ -27,6 +27,18 @@ - It is possible to check the time of the next liquidation trade attempt in any market via the API. (0012-POSR-015) +### Network Profit and Loss + +- Given the network starts with no position and does not dispose any of it's position during the scenario: (0012-POSR-016) + - The mark price moves to `100`, the network liquidates a distressed party with a long position of `1`. The network should report a position of `1` and a realised and unrealised pnl of `0` and `0` respectively. + - The mark price moves to `120`, the network liquidates a distressed party with a short position of `-1`. The network should report a position of `-1` and a realised and unrealised pnl of `20` and `0` respectively. + - The mark price moves to `60`. The network should report a position of `-1` and a realised and unrealised pnl of `20` and `60` respectively. + +- Given the network starts with no position and does not dispose any of it's position during the scenario: (0012-POSR-017) + - The mark price moves to `100`, the network liquidates a distressed party with a long position of `1`. The network should report a position of `1` and a realised and unrealised pnl of `0` and `0` respectively. + - The mark price moves to `90`, the network liquidates a distressed party with a long position of `1` (AEP now equals `95`). The network should report a position of `2` and a realised and unrealised pnl of `0` and `-10` respectively. + - The mark price moves to `60`. The network should report a position of `2` and a realised and unrealised pnl of `0` and `-70` respectively. + ## Summary Position resolution is the mechanism which deals with closing out distressed positions on a given market. It is instigated when one or more participant's margin account balance falls below their latest maintenance margin level. diff --git a/protocol/features.json b/protocol/features.json index 372371621..81e8563b1 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -206,7 +206,10 @@ "0012-POSR-012", "0012-POSR-013", "0012-POSR-014", - "0012-POSR-015" + "0012-POSR-015", + "0012-POSR-016", + "0012-POSR-017" + ] }, "Passive liquidity": { From 7bec25ab5a1943b2c50d3a11b9c08c625742258e Mon Sep 17 00:00:00 2001 From: Charlie Date: Fri, 5 Jan 2024 17:52:53 +0000 Subject: [PATCH 0853/1171] fix: update for markdownlint --- protocol/0012-POSR-position_resolution.md | 14 ++++++++------ 1 file changed, 8 insertions(+), 6 deletions(-) diff --git a/protocol/0012-POSR-position_resolution.md b/protocol/0012-POSR-position_resolution.md index 02f3f3505..832e81221 100644 --- a/protocol/0012-POSR-position_resolution.md +++ b/protocol/0012-POSR-position_resolution.md @@ -30,14 +30,16 @@ ### Network Profit and Loss - Given the network starts with no position and does not dispose any of it's position during the scenario: (0012-POSR-016) - - The mark price moves to `100`, the network liquidates a distressed party with a long position of `1`. The network should report a position of `1` and a realised and unrealised pnl of `0` and `0` respectively. - - The mark price moves to `120`, the network liquidates a distressed party with a short position of `-1`. The network should report a position of `-1` and a realised and unrealised pnl of `20` and `0` respectively. - - The mark price moves to `60`. The network should report a position of `-1` and a realised and unrealised pnl of `20` and `60` respectively. + + - The mark price moves to `100`, the network liquidates a distressed party with a long position of `1`. The network should report a position of `1` and a realised and unrealised pnl of `0` and `0` respectively. + - The mark price moves to `120`, the network liquidates a distressed party with a short position of `-1`. The network should report a position of `-1` and a realised and unrealised pnl of `20` and `0` respectively. + - The mark price moves to `60`. The network should report a position of `-1` and a realised and unrealised pnl of `20` and `60` respectively. - Given the network starts with no position and does not dispose any of it's position during the scenario: (0012-POSR-017) - - The mark price moves to `100`, the network liquidates a distressed party with a long position of `1`. The network should report a position of `1` and a realised and unrealised pnl of `0` and `0` respectively. - - The mark price moves to `90`, the network liquidates a distressed party with a long position of `1` (AEP now equals `95`). The network should report a position of `2` and a realised and unrealised pnl of `0` and `-10` respectively. - - The mark price moves to `60`. The network should report a position of `2` and a realised and unrealised pnl of `0` and `-70` respectively. + + - The mark price moves to `100`, the network liquidates a distressed party with a long position of `1`. The network should report a position of `1` and a realised and unrealised pnl of `0` and `0` respectively. + - The mark price moves to `90`, the network liquidates a distressed party with a long position of `1` (AEP now equals `95`). The network should report a position of `2` and a realised and unrealised pnl of `0` and `-10` respectively. + - The mark price moves to `60`. The network should report a position of `2` and a realised and unrealised pnl of `0` and `-70` respectively. ## Summary From 89df9e526ac0acae14d645bbc498bb2c288f6963 Mon Sep 17 00:00:00 2001 From: Charlie Date: Fri, 5 Jan 2024 17:56:46 +0000 Subject: [PATCH 0854/1171] fix: update for spellcheck --- protocol/0012-POSR-position_resolution.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0012-POSR-position_resolution.md b/protocol/0012-POSR-position_resolution.md index 832e81221..58b50d1b3 100644 --- a/protocol/0012-POSR-position_resolution.md +++ b/protocol/0012-POSR-position_resolution.md @@ -38,7 +38,7 @@ - Given the network starts with no position and does not dispose any of it's position during the scenario: (0012-POSR-017) - The mark price moves to `100`, the network liquidates a distressed party with a long position of `1`. The network should report a position of `1` and a realised and unrealised pnl of `0` and `0` respectively. - - The mark price moves to `90`, the network liquidates a distressed party with a long position of `1` (AEP now equals `95`). The network should report a position of `2` and a realised and unrealised pnl of `0` and `-10` respectively. + - The mark price moves to `90`, the network liquidates a distressed party with a long position of `1` (average entry price now equals `95`). The network should report a position of `2` and a realised and unrealised pnl of `0` and `-10` respectively. - The mark price moves to `60`. The network should report a position of `2` and a realised and unrealised pnl of `0` and `-70` respectively. ## Summary From 159061821d339e22687ae37cd67564eeab649a15 Mon Sep 17 00:00:00 2001 From: David Siska <62546419+davidsiska-vega@users.noreply.github.com> Date: Mon, 8 Jan 2024 10:03:30 +0000 Subject: [PATCH 0855/1171] fix: clarity on what is meant by L2 --- protocol/0087-EVMD-eth-rpc-and-evm-data-source.md | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/protocol/0087-EVMD-eth-rpc-and-evm-data-source.md b/protocol/0087-EVMD-eth-rpc-and-evm-data-source.md index d949d84fc..68305b3bc 100644 --- a/protocol/0087-EVMD-eth-rpc-and-evm-data-source.md +++ b/protocol/0087-EVMD-eth-rpc-and-evm-data-source.md @@ -48,12 +48,13 @@ A proposal for a new market will fail at enactment stage if it's referencing an ### External Oracles - Amendments - It may happen that an `EthRpcEvmCompatible` that cannot be read from is proposed (because not enough validator nodes have it configured etc.). In that case a proposed / enacted market will not see the oracle inputs but it must be possible to change the said market via on-chain governance (0087-EVMD-003). -- 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 (0087-EVMD-004) +- Update an existing futures market using the market update proposal to change the EthRpcEvmCompatible chain referenced, 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 (0087-EVMD-004) - 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 (0087-EVMD-005) - 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 (0087-EVMD-006) - 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 (0087-EVMD-007) + ### External Oracles - Validations - A market proposal that reference an `EthRpcEvmCompatible` that's not active will fail at enactment stage (0087-EVMD-008). @@ -127,3 +128,9 @@ Then market 1 only sees events of that type from `EthRpcEvmCompatible` 0x123 whi - Create a futures market with an `EthRpcEvmCompatible` 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. (0087-EVMD-037) - Create a perpetual market with an `EthRpcEvmCompatible` 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. (0087-EVMD-038) - Ensure that markets with `EthRpcEvmCompatible` termination and settlement data sources continue to successfully terminate and settle markets after the protocol upgrade. (0087-EVMD-039) + +### Perpetual futures focused tests + +- Update an existing perpetuals market using the market update proposal to change from Ethereum to EthRpcEvmCompatible chain referenced, 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 (0087-EVMD-040). +- Create a perpetual futures market which uses an EthRpcEvmCompatible chain reads/events contract data for settlement payment schedule from chain `A` and EthRpcEvmCompatible chain reads/events contract data for the index price from chain `B` (0087-EVMD-041). +- Create a perpetual futures market which uses an EthRpcEvmCompatible chain reads/events contract data for settlement payment schedule from; the trigger for the countdown to the first funding payment being publication of a valid value for the index price. The index price must not be available at the time the market is created and leaves opening auction; it must only become available sometime after. The aim is to test futures markets for underlyings that don't trade *yet* be where there is an agreed oracle source that will start publishing the price *once* they begin trading. (0087-EVMD-042). From e089f1862efdd57359709518f6113d7bf998c203 Mon Sep 17 00:00:00 2001 From: gordsport Date: Mon, 8 Jan 2024 10:16:57 +0000 Subject: [PATCH 0856/1171] fix: MD linting and add AC code to file --- protocol/0087-EVMD-eth-rpc-and-evm-data-source.md | 7 +++---- protocol/features.json | 5 ++++- 2 files changed, 7 insertions(+), 5 deletions(-) diff --git a/protocol/0087-EVMD-eth-rpc-and-evm-data-source.md b/protocol/0087-EVMD-eth-rpc-and-evm-data-source.md index 68305b3bc..68141b047 100644 --- a/protocol/0087-EVMD-eth-rpc-and-evm-data-source.md +++ b/protocol/0087-EVMD-eth-rpc-and-evm-data-source.md @@ -54,7 +54,6 @@ A proposal for a new market will fail at enactment stage if it's referencing an - 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 (0087-EVMD-007) - ### External Oracles - Validations - A market proposal that reference an `EthRpcEvmCompatible` that's not active will fail at enactment stage (0087-EVMD-008). @@ -129,8 +128,8 @@ Then market 1 only sees events of that type from `EthRpcEvmCompatible` 0x123 whi - Create a perpetual market with an `EthRpcEvmCompatible` 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. (0087-EVMD-038) - Ensure that markets with `EthRpcEvmCompatible` termination and settlement data sources continue to successfully terminate and settle markets after the protocol upgrade. (0087-EVMD-039) -### Perpetual futures focused tests +### Perpetual futures focused tests - Update an existing perpetuals market using the market update proposal to change from Ethereum to EthRpcEvmCompatible chain referenced, 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 (0087-EVMD-040). -- Create a perpetual futures market which uses an EthRpcEvmCompatible chain reads/events contract data for settlement payment schedule from chain `A` and EthRpcEvmCompatible chain reads/events contract data for the index price from chain `B` (0087-EVMD-041). -- Create a perpetual futures market which uses an EthRpcEvmCompatible chain reads/events contract data for settlement payment schedule from; the trigger for the countdown to the first funding payment being publication of a valid value for the index price. The index price must not be available at the time the market is created and leaves opening auction; it must only become available sometime after. The aim is to test futures markets for underlyings that don't trade *yet* be where there is an agreed oracle source that will start publishing the price *once* they begin trading. (0087-EVMD-042). +- Create a perpetual futures market which uses an EthRpcEvmCompatible chain reads/events contract data for settlement payment schedule from chain `A` and EthRpcEvmCompatible chain reads/events contract data for the index price from chain `B` (0087-EVMD-041). +- Create a perpetual futures market which uses an EthRpcEvmCompatible chain reads/events contract data for settlement payment schedule from; the trigger for the countdown to the first funding payment being publication of a valid value for the index price. The index price must not be available at the time the market is created and leaves opening auction; it must only become available sometime after. The aim is to test futures markets for underlyings that don't trade *yet* be where there is an agreed oracle source that will start publishing the price *once* they begin trading. (0087-EVMD-042). diff --git a/protocol/features.json b/protocol/features.json index cb27d9f52..089e4735b 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -345,7 +345,10 @@ "0087-EVMD-036", "0087-EVMD-037", "0087-EVMD-038", - "0087-EVMD-039" + "0087-EVMD-039", + "0087-EVMD-040", + "0087-EVMD-041", + "0087-EVMD-042" ] }, "Unknown": { From ec26c33627b358d20361c0fba38802fa34932fe6 Mon Sep 17 00:00:00 2001 From: gordsport Date: Mon, 8 Jan 2024 10:20:09 +0000 Subject: [PATCH 0857/1171] fix: MD linting and spellings --- protocol/0087-EVMD-eth-rpc-and-evm-data-source.md | 6 +++--- wordlist.txt | 1 + 2 files changed, 4 insertions(+), 3 deletions(-) diff --git a/protocol/0087-EVMD-eth-rpc-and-evm-data-source.md b/protocol/0087-EVMD-eth-rpc-and-evm-data-source.md index 68141b047..17665b945 100644 --- a/protocol/0087-EVMD-eth-rpc-and-evm-data-source.md +++ b/protocol/0087-EVMD-eth-rpc-and-evm-data-source.md @@ -130,6 +130,6 @@ Then market 1 only sees events of that type from `EthRpcEvmCompatible` 0x123 whi ### Perpetual futures focused tests -- Update an existing perpetuals market using the market update proposal to change from Ethereum to EthRpcEvmCompatible chain referenced, 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 (0087-EVMD-040). -- Create a perpetual futures market which uses an EthRpcEvmCompatible chain reads/events contract data for settlement payment schedule from chain `A` and EthRpcEvmCompatible chain reads/events contract data for the index price from chain `B` (0087-EVMD-041). -- Create a perpetual futures market which uses an EthRpcEvmCompatible chain reads/events contract data for settlement payment schedule from; the trigger for the countdown to the first funding payment being publication of a valid value for the index price. The index price must not be available at the time the market is created and leaves opening auction; it must only become available sometime after. The aim is to test futures markets for underlyings that don't trade *yet* be where there is an agreed oracle source that will start publishing the price *once* they begin trading. (0087-EVMD-042). +- Update an existing perpetuals market using the market update proposal to change from Ethereum to `EthRpcEvmCompatible` chain referenced, 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 (0087-EVMD-040). +- Create a perpetual futures market which uses an `EthRpcEvmCompatible` chain reads/events contract data for settlement payment schedule from chain `A` and `EthRpcEvmCompatible` chain reads/events contract data for the index price from chain `B` (0087-EVMD-041). +- Create a perpetual futures market which uses an `EthRpcEvmCompatible` chain reads/events contract data for settlement payment schedule from; the trigger for the countdown to the first funding payment being publication of a valid value for the index price. The index price must not be available at the time the market is created and leaves opening auction; it must only become available sometime after. The aim is to test futures markets for underlyings that don't trade *yet* be where there is an agreed oracle source that will start publishing the price *once* they begin trading. (0087-EVMD-042). diff --git a/wordlist.txt b/wordlist.txt index 4485d586b..9d2a6b610 100644 --- a/wordlist.txt +++ b/wordlist.txt @@ -292,6 +292,7 @@ undelegating undelegation undelegations undeployed +underlyings unencrypted unitless unmarshal From b44a4259aa5ce6d4efb1b43c203131c4595043aa Mon Sep 17 00:00:00 2001 From: gordsport Date: Mon, 8 Jan 2024 10:58:05 +0000 Subject: [PATCH 0858/1171] fix: spelling linting --- protocol/0087-EVMD-eth-rpc-and-evm-data-source.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0087-EVMD-eth-rpc-and-evm-data-source.md b/protocol/0087-EVMD-eth-rpc-and-evm-data-source.md index 17665b945..28d37572d 100644 --- a/protocol/0087-EVMD-eth-rpc-and-evm-data-source.md +++ b/protocol/0087-EVMD-eth-rpc-and-evm-data-source.md @@ -48,7 +48,7 @@ A proposal for a new market will fail at enactment stage if it's referencing an ### External Oracles - Amendments - It may happen that an `EthRpcEvmCompatible` that cannot be read from is proposed (because not enough validator nodes have it configured etc.). In that case a proposed / enacted market will not see the oracle inputs but it must be possible to change the said market via on-chain governance (0087-EVMD-003). -- Update an existing futures market using the market update proposal to change the EthRpcEvmCompatible chain referenced, 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 (0087-EVMD-004) +- Update an existing futures market using the market update proposal to change the `EthRpcEvmCompatible` chain referenced, 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 (0087-EVMD-004) - 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 (0087-EVMD-005) - 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 (0087-EVMD-006) - 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 (0087-EVMD-007) From 9c6c76b4baca468e1d89720ab3e2b85ce793be9c Mon Sep 17 00:00:00 2001 From: Gordsport <83510148+gordsport@users.noreply.github.com> Date: Tue, 9 Jan 2024 12:21:34 +0000 Subject: [PATCH 0859/1171] chore: add AC code to existing AC (#2102) Adds an AC code to an AC that had one missing. --- protocol/0083-RFPR-on_chain_referral_program.md | 2 +- protocol/features.json | 3 ++- 2 files changed, 3 insertions(+), 2 deletions(-) diff --git a/protocol/0083-RFPR-on_chain_referral_program.md b/protocol/0083-RFPR-on_chain_referral_program.md index a591de070..f959f00fe 100644 --- a/protocol/0083-RFPR-on_chain_referral_program.md +++ b/protocol/0083-RFPR-on_chain_referral_program.md @@ -478,7 +478,7 @@ The Estimate Fees API should now calculate the following additional information: 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). -1. If a referrer updates the `allow_list` associated with the team, existing members who are no longer on the allow_list should **not** be removed from the team. +1. If a referrer updates the `allow_list` associated with the team, existing members who are no longer on the allow_list should **not** be removed from the team (0083-RFPR-067). #### Applying a referral code diff --git a/protocol/features.json b/protocol/features.json index 81e8563b1..85fdd4dd9 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -64,7 +64,8 @@ "0083-RFPR-063", "0083-RFPR-064", "0083-RFPR-065", - "0083-RFPR-066" + "0083-RFPR-066", + "0083-RFPR-067" ] }, "Fixed size amendments": { From f65ff220aea55b8718bc3aa8d245031081a1844b Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Tue, 9 Jan 2024 14:37:30 +0000 Subject: [PATCH 0860/1171] feat: add more acs --- protocol/0009-MRKP-mark_price.md | 37 ++++++++++++++++++++++++++++++++ 1 file changed, 37 insertions(+) diff --git a/protocol/0009-MRKP-mark_price.md b/protocol/0009-MRKP-mark_price.md index 6f1439fbb..6ba557089 100644 --- a/protocol/0009-MRKP-mark_price.md +++ b/protocol/0009-MRKP-mark_price.md @@ -1,3 +1,6 @@ +Spec 0009 + + # Mark Price ## Summary @@ -50,10 +53,32 @@ Note that for calculating the median with an even number of entries we sort, pic ### Flexible mark price methodology, no combinations yet +#### Trade-size-weighted average price + - It is possible to configure a cash settled futures market to use weighted average of trades over `network.markPriceUpdateMaximumFrequency` with decay weight `1` and power `1` (linear decay) (0009-MRKP-012) and a perps market (0009-MRKP-013). +- when choosing price type `weight` and set weight on `trade-size-weight price` only, set decay weight to `0` and decay power to `1`, and set up trade at price `15920`, `15940`, `15960`, `15990` at various size, and check if the weighted average mark price is corrected calculated (0009-MRKP-110) +-when choosing price type `weight` and set weight on `trade-size-weight price` only, set decay weight to `0` and decay power to `1`, and set up trade at price `15940`, `15960`, `15990` at various size, and check if the weighted average mark price is corrected calculated (0009-MRKP-111) +- when choosing price type `weight` and set weight on `trade-size-weight price` only, set decay weight to `1` and decay power to `1`, and set up trade at price `15920`, `15940`, `15960`, `15990` at various size, and check if the weighted average mark price is corrected calculated (0009-MRKP-112) +- when choosing price type `weight` and set weight on `trade-size-weight price` only, set decay weight to `1` and decay power to `0`, and set up trade at price `15920`, `15940`, `15960`, `15990` at various size, and check if the weighted average mark price is corrected calculated (0009-MRKP-113) +- when choosing price type `weight` and set weight on `trade-size-weight price` only, set decay weight to `0.5` and decay power to `1`, and set up trade at price `15920`, `15940`, `15960`, `15990` at various size, and check if the weighted average mark price is corrected calculated (0009-MRKP-114) + +#### Leverage-notional book price + - It is possible to configure a cash settled futures market to use impact of leveraged notional on the order book with the value of USDT `100` for mark price (0009-MRKP-014) and a perps market (0009-MRKP-015). +- when choosing price type `weight` and set weight on `leverage-notional book price` only, set cash amount to `100` (which should make the notional volume at sell and buy round to `0`), and place a few orders on the book with best bid `15900` and best ask `16000` and the leverage-notional book price should be the mid-price (0009-MRKP-120) +- when choosing price type `weight` and set weight on `leverage-notional book price` only, set cash amount to `100,000` and place a few orders on the book with best bid `15900` and best ask `16000` and check if leverage-notional book price is corrected calculated (0009-MRKP-121) +- when choosing price type `weight` and set weight on `leverage-notional book price` only, set cash amount to `5,000,000` (which should make the notional volume too big for the book) and place a few orders on the book with best bid `15900` and best ask `16000` and the leverage-notional book price should be the mid-price (0009-MRKP-122) + +#### Oracle source price + - It is possible to configure a cash settled futures market to use an oracle source for the mark price (0009-MRKP-016) and a perps market (with the oracle source different to that used for the external price in the perps market) (0009-MRKP-017). +- when choosing price type `weight` and set weight on `oracle source price` only, set up 2 oracle prices at different time, and check if the oracle mark price is correctly calculated (0009-MRKP-130) + +- when choosing price type `weight` and set weight on `oracle source price` only, set up oracle prices at different time, and check if the oracle mark price updated according to is correctly calculated according to `network.markPriceUpdateMaximumFrequency` (0009-MRKP-131) + +- when choosing price type `weight` and set weight on `oracle source price` only, set up 3 oracle prices at different time with 1 of them becomes stale, and check if the oracle mark price updated according to is correctly calculated by using the right price (0009-MRKP-132) + ### Flexible mark price methodology, combinations - It is possible to configure a cash settled futures market to use a weighted average of 1. weighted average of trades over `network.markPriceUpdateMaximumFrequency` and 2. impact of leveraged notional on the order book with the value of USDT `100` and 3. an oracle source and if last trade is last updated more than 1 minute ago then it is removed and the remaining re-weighted and if the oracle is last updated more than 5 minutes ago then it is removed and the remaining re-weighted (0009-MRKP-018) and a perps market (with the oracle source different to that used for the external price in the perps market) (0009-MRKP-019). @@ -70,6 +95,16 @@ Note that for calculating the median with an even number of entries we sort, pic - It is possible to configure a cash settled futures market to use a weighted average of 1. weighted average of trades over `network.markPriceUpdateMaximumFrequency` and 2. impact of leveraged notional on the order book with the value of USDT `0` and the book price should be mid price (0009-MRKP-030) and a perps market (with the oracle source different to that used for the external price in the perps market) (0009-MRKP-031). +### Validation + +- Boundary values are respected for the market parameters + + - `markPriceConfiguration: decayWeight` valid values: `>=0`(0009-MRKP-050) + + - `markPriceConfiguration: decayPower` valid values: `natural numbers`(0009-MRKP-051) + + - `markPriceConfiguration: cashAmount` valid values: `>=`(0009-MRKP-052) + ### Example 1 - A typical path of a cash settled futures market from end of opening auction till expiry (use Algorithm 2 (ie median price))(0009-MRKP-040) 1. Market is in opening auction, no mark price. @@ -89,3 +124,5 @@ Note that for calculating the median with an even number of entries we sort, pic 5. Another Oracle price comes, mark price recalculated when the time indicated by the mark price frequency is crossed, new event is emitted for new mark price. 6. Oracle price comes for funding payments, mark price recalculated when the time indicated by the mark price frequency is crossed, new event is emitted for new mark price. 7. Traded price at step 2 is stale, and Oracle price at step 4 is stale, mark price recalculated, new event is emitted for new mark price. + + From fe19ff6aae4d4b18052f8538dbd47db1cf3e2096 Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Tue, 9 Jan 2024 14:41:25 +0000 Subject: [PATCH 0861/1171] feat: add ac for first mark price --- protocol/0009-MRKP-mark_price.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/protocol/0009-MRKP-mark_price.md b/protocol/0009-MRKP-mark_price.md index 6ba557089..a95678eba 100644 --- a/protocol/0009-MRKP-mark_price.md +++ b/protocol/0009-MRKP-mark_price.md @@ -42,6 +42,7 @@ Note that for calculating the median with an even number of entries we sort, pic - 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) +- Every market will wait in opening auction until the first mark price is available or it is certain that leaving the opening auction will set it.(0009-MRKP-001) ### Algorithm 1 (last trade price, excluding network trades) @@ -101,7 +102,7 @@ Note that for calculating the median with an even number of entries we sort, pic - `markPriceConfiguration: decayWeight` valid values: `>=0`(0009-MRKP-050) - - `markPriceConfiguration: decayPower` valid values: `natural numbers`(0009-MRKP-051) + - `markPriceConfiguration: decayPower` valid values: `natural numbers but not 0`(0009-MRKP-051) - `markPriceConfiguration: cashAmount` valid values: `>=`(0009-MRKP-052) From 838e1163c6c4961a2491546ceb7767722839751a Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Tue, 9 Jan 2024 15:55:59 +0000 Subject: [PATCH 0862/1171] chore: markdown --- protocol/0009-MRKP-mark_price.md | 7 ------- 1 file changed, 7 deletions(-) diff --git a/protocol/0009-MRKP-mark_price.md b/protocol/0009-MRKP-mark_price.md index a95678eba..51e3bca80 100644 --- a/protocol/0009-MRKP-mark_price.md +++ b/protocol/0009-MRKP-mark_price.md @@ -1,6 +1,3 @@ -Spec 0009 - - # Mark Price ## Summary @@ -30,14 +27,12 @@ The mark price isn't updated because `network.markPriceUpdateMaximumFrequency = Now 10.1s has elapsed since the last update and there is a market buy order for volume 5 which executes against book volume as 1 @ 1220, 2 @ 1250 and 2 @ 1500. The mark price is updated to 1500. - ### 2. Flexible mark price methodology The calculations are specified in [markprice methodology research note](https://github.com/vegaprotocol/research/blob/markprice-updates/papers/markprice-methodology/markprice-methodology.tex). Here, we only write the acceptance criteria. Note that for calculating the median with an even number of entries we sort, pick out the two values that are in the middle of the list and average those. So in particular with two values a median is the same as the average for our purposes. - ## Acceptance criteria - The mark price must be set when the market leaves opening auction. (0009-MRKP-002) @@ -125,5 +120,3 @@ Note that for calculating the median with an even number of entries we sort, pic 5. Another Oracle price comes, mark price recalculated when the time indicated by the mark price frequency is crossed, new event is emitted for new mark price. 6. Oracle price comes for funding payments, mark price recalculated when the time indicated by the mark price frequency is crossed, new event is emitted for new mark price. 7. Traded price at step 2 is stale, and Oracle price at step 4 is stale, mark price recalculated, new event is emitted for new mark price. - - From cf8a5b7a48f1cf3f81916f7aa5ae20f92ba692de Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Tue, 9 Jan 2024 16:13:01 +0000 Subject: [PATCH 0863/1171] feat: add more ac --- protocol/0009-MRKP-mark_price.md | 20 ++++++++++++-------- 1 file changed, 12 insertions(+), 8 deletions(-) diff --git a/protocol/0009-MRKP-mark_price.md b/protocol/0009-MRKP-mark_price.md index 51e3bca80..3c09c4aa0 100644 --- a/protocol/0009-MRKP-mark_price.md +++ b/protocol/0009-MRKP-mark_price.md @@ -52,18 +52,18 @@ Note that for calculating the median with an even number of entries we sort, pic #### Trade-size-weighted average price - It is possible to configure a cash settled futures market to use weighted average of trades over `network.markPriceUpdateMaximumFrequency` with decay weight `1` and power `1` (linear decay) (0009-MRKP-012) and a perps market (0009-MRKP-013). -- when choosing price type `weight` and set weight on `trade-size-weight price` only, set decay weight to `0` and decay power to `1`, and set up trade at price `15920`, `15940`, `15960`, `15990` at various size, and check if the weighted average mark price is corrected calculated (0009-MRKP-110) --when choosing price type `weight` and set weight on `trade-size-weight price` only, set decay weight to `0` and decay power to `1`, and set up trade at price `15940`, `15960`, `15990` at various size, and check if the weighted average mark price is corrected calculated (0009-MRKP-111) -- when choosing price type `weight` and set weight on `trade-size-weight price` only, set decay weight to `1` and decay power to `1`, and set up trade at price `15920`, `15940`, `15960`, `15990` at various size, and check if the weighted average mark price is corrected calculated (0009-MRKP-112) -- when choosing price type `weight` and set weight on `trade-size-weight price` only, set decay weight to `1` and decay power to `0`, and set up trade at price `15920`, `15940`, `15960`, `15990` at various size, and check if the weighted average mark price is corrected calculated (0009-MRKP-113) -- when choosing price type `weight` and set weight on `trade-size-weight price` only, set decay weight to `0.5` and decay power to `1`, and set up trade at price `15920`, `15940`, `15960`, `15990` at various size, and check if the weighted average mark price is corrected calculated (0009-MRKP-114) +- when choosing price type `weight` and set weight on `trade-size-weight price` only, set decay weight to `0` and decay power to `1`, and set up trade at price `15920`, `15940`, `15960`, `15990` at various size, and check if the weighted average mark price is corrected calculated (0009-MRKP-110) and on perp market (0009-MRKP-111) +-when choosing price type `weight` and set weight on `trade-size-weight price` only, set decay weight to `0` and decay power to `1`, and set up trade at price `15940`, `15960`, `15990` at various size, and check if the weighted average mark price is corrected calculated (0009-MRKP-112) and on perp market (0009-MRKP-113) +- when choosing price type `weight` and set weight on `trade-size-weight price` only, set decay weight to `1` and decay power to `1`, and set up trade at price `15920`, `15940`, `15960`, `15990` at various size, and check if the weighted average mark price is corrected calculated (0009-MRKP-114) and on perp market (0009-MRKP-115) +- when choosing price type `weight` and set weight on `trade-size-weight price` only, set decay weight to `1` and decay power to `0`, and set up trade at price `15920`, `15940`, `15960`, `15990` at various size, and check if the weighted average mark price is corrected calculated (0009-MRKP-116) and on perp market (0009-MRKP-117) +- when choosing price type `weight` and set weight on `trade-size-weight price` only, set decay weight to `0.5` and decay power to `1`, and set up trade at price `15920`, `15940`, `15960`, `15990` at various size, and check if the weighted average mark price is corrected calculated (0009-MRKP-118) and on perp market (0009-MRKP-119) #### Leverage-notional book price - It is possible to configure a cash settled futures market to use impact of leveraged notional on the order book with the value of USDT `100` for mark price (0009-MRKP-014) and a perps market (0009-MRKP-015). -- when choosing price type `weight` and set weight on `leverage-notional book price` only, set cash amount to `100` (which should make the notional volume at sell and buy round to `0`), and place a few orders on the book with best bid `15900` and best ask `16000` and the leverage-notional book price should be the mid-price (0009-MRKP-120) -- when choosing price type `weight` and set weight on `leverage-notional book price` only, set cash amount to `100,000` and place a few orders on the book with best bid `15900` and best ask `16000` and check if leverage-notional book price is corrected calculated (0009-MRKP-121) -- when choosing price type `weight` and set weight on `leverage-notional book price` only, set cash amount to `5,000,000` (which should make the notional volume too big for the book) and place a few orders on the book with best bid `15900` and best ask `16000` and the leverage-notional book price should be the mid-price (0009-MRKP-122) +- when choosing price type `weight` and set weight on `leverage-notional book price` only, set cash amount to `100` (which should make the notional volume at sell and buy round to `0`), and place a few orders on the book with best bid `15900` and best ask `16000` and the leverage-notional book price should be the mid-price (0009-MRKP-120) and on perp market (0009-MRKP-121) +- when choosing price type `weight` and set weight on `leverage-notional book price` only, set cash amount to `100,000` and place a few orders on the book with best bid `15900` and best ask `16000` and check if leverage-notional book price is corrected calculated (0009-MRKP-122) and on perp market (0009-MRKP-123) +- when choosing price type `weight` and set weight on `leverage-notional book price` only, set cash amount to `5,000,000` (which should make the notional volume too big for the book) and place a few orders on the book with best bid `15900` and best ask `16000` and the leverage-notional book price should be the mid-price (0009-MRKP-124) and on perp market (0009-MRKP-125) #### Oracle source price @@ -91,6 +91,10 @@ Note that for calculating the median with an even number of entries we sort, pic - It is possible to configure a cash settled futures market to use a weighted average of 1. weighted average of trades over `network.markPriceUpdateMaximumFrequency` and 2. impact of leveraged notional on the order book with the value of USDT `0` and the book price should be mid price (0009-MRKP-030) and a perps market (with the oracle source different to that used for the external price in the perps market) (0009-MRKP-031). +- Set price type to "median", only have data souce availabel from "Trade-size-weighted average price" and "Leverage-notional book price" and 1 trade at 15920, check the mark price is correctly calculated (0009-MRKP-032) and a perps market (0009-MRKP-033) + +- Set price type to "median", only have data souce availabel from "Trade-size-weighted average price" and "Leverage-notional book price" and 1 trade at 15920, and 1 trade at 15940, move time, and check stale price should not be included (0009-MRKP-032) and a perps market (0009-MRKP-033) + ### Validation - Boundary values are respected for the market parameters From bdc617e107cc0496b492301c0eee16dd6258f51e Mon Sep 17 00:00:00 2001 From: gordsport Date: Tue, 9 Jan 2024 17:48:41 +0000 Subject: [PATCH 0864/1171] chore: add branch to quality checks Adds the nebula branch to the quality check git hub actions --- .github/workflows/quality_check.yml | 1 + 1 file changed, 1 insertion(+) diff --git a/.github/workflows/quality_check.yml b/.github/workflows/quality_check.yml index 657a39b8a..bc8042d5a 100644 --- a/.github/workflows/quality_check.yml +++ b/.github/workflows/quality_check.yml @@ -9,6 +9,7 @@ name: "Quality checks" - master - cosmicelevator - palazzo + - nebula env: GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} From 34a64bc1307c8bd62482d16df7f06239c579f0d9 Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Tue, 9 Jan 2024 20:41:03 +0000 Subject: [PATCH 0865/1171] feat: update AC 001 --- protocol/0009-MRKP-mark_price.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0009-MRKP-mark_price.md b/protocol/0009-MRKP-mark_price.md index 3c09c4aa0..fecba16cc 100644 --- a/protocol/0009-MRKP-mark_price.md +++ b/protocol/0009-MRKP-mark_price.md @@ -37,7 +37,7 @@ Note that for calculating the median with an even number of entries we sort, pic - 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) -- Every market will wait in opening auction until the first mark price is available or it is certain that leaving the opening auction will set it.(0009-MRKP-001) +- When leaving the opening auction, if the mark price is undefined then use the opening auction uncrossing price.(0009-MRKP-001) ### Algorithm 1 (last trade price, excluding network trades) From 4b3a5b29216e0c71987ccaf16cf395593b440319 Mon Sep 17 00:00:00 2001 From: Jiajia-Cui <92106936+Jiajia-Cui@users.noreply.github.com> Date: Tue, 9 Jan 2024 20:56:10 +0000 Subject: [PATCH 0866/1171] chore: address comments Co-authored-by: David Siska <62546419+davidsiska-vega@users.noreply.github.com> --- protocol/0009-MRKP-mark_price.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/protocol/0009-MRKP-mark_price.md b/protocol/0009-MRKP-mark_price.md index fecba16cc..5a5317f0b 100644 --- a/protocol/0009-MRKP-mark_price.md +++ b/protocol/0009-MRKP-mark_price.md @@ -37,7 +37,8 @@ Note that for calculating the median with an even number of entries we sort, pic - 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) -- When leaving the opening auction, if the mark price is undefined then use the opening auction uncrossing price.(0009-MRKP-001) +- If a market mark price is configured in such a way that the mark price methodology hasn't provided a price at the +point of uncrossing the opening auction, then the auction uncrossing price is set as the first mark price, regardless of what the mark price methodology says. (0009-MRKP-001) ### Algorithm 1 (last trade price, excluding network trades) From 5a61586c79b1c19cf2a4361392a7e6ac4d5da6d4 Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Tue, 9 Jan 2024 20:59:48 +0000 Subject: [PATCH 0867/1171] chore: address comment --- protocol/0009-MRKP-mark_price.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/protocol/0009-MRKP-mark_price.md b/protocol/0009-MRKP-mark_price.md index 5a5317f0b..95e12853d 100644 --- a/protocol/0009-MRKP-mark_price.md +++ b/protocol/0009-MRKP-mark_price.md @@ -100,11 +100,11 @@ point of uncrossing the opening auction, then the auction uncrossing price is se - Boundary values are respected for the market parameters - - `markPriceConfiguration: decayWeight` valid values: `>=0`(0009-MRKP-050) + - `markPriceConfiguration: decayWeight` valid values: `[0,1]`(0009-MRKP-050) - - `markPriceConfiguration: decayPower` valid values: `natural numbers but not 0`(0009-MRKP-051) + - `markPriceConfiguration: decayPower` valid values: `(1,2,3)`(0009-MRKP-051) - - `markPriceConfiguration: cashAmount` valid values: `>=`(0009-MRKP-052) + - `markPriceConfiguration: cashAmount` valid values: `>=0`(0009-MRKP-052) ### Example 1 - A typical path of a cash settled futures market from end of opening auction till expiry (use Algorithm 2 (ie median price))(0009-MRKP-040) From b4e95406d8cbc1926ebd8f73f74ab963851c9e31 Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Tue, 9 Jan 2024 21:01:21 +0000 Subject: [PATCH 0868/1171] chore: typo --- protocol/0009-MRKP-mark_price.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0009-MRKP-mark_price.md b/protocol/0009-MRKP-mark_price.md index 95e12853d..8a31dc5f4 100644 --- a/protocol/0009-MRKP-mark_price.md +++ b/protocol/0009-MRKP-mark_price.md @@ -102,7 +102,7 @@ point of uncrossing the opening auction, then the auction uncrossing price is se - `markPriceConfiguration: decayWeight` valid values: `[0,1]`(0009-MRKP-050) - - `markPriceConfiguration: decayPower` valid values: `(1,2,3)`(0009-MRKP-051) + - `markPriceConfiguration: decayPower` valid values: `{1,2,3}`(0009-MRKP-051) - `markPriceConfiguration: cashAmount` valid values: `>=0`(0009-MRKP-052) From 4d1dac948bce8559dd485c1caa95e9be6ced0f78 Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Tue, 9 Jan 2024 21:10:50 +0000 Subject: [PATCH 0869/1171] feat: add more AC for validation --- protocol/0009-MRKP-mark_price.md | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/protocol/0009-MRKP-mark_price.md b/protocol/0009-MRKP-mark_price.md index 8a31dc5f4..e7eb45fde 100644 --- a/protocol/0009-MRKP-mark_price.md +++ b/protocol/0009-MRKP-mark_price.md @@ -106,6 +106,11 @@ point of uncrossing the opening auction, then the auction uncrossing price is se - `markPriceConfiguration: cashAmount` valid values: `>=0`(0009-MRKP-052) + - `markPriceConfiguration: source weight` valid values: `[0,1]`(0009-MRKP-053) + + - `markPriceConfiguration: source staleness tolerance ` valid values: `time format`(0009-MRKP-054) + + ### Example 1 - A typical path of a cash settled futures market from end of opening auction till expiry (use Algorithm 2 (ie median price))(0009-MRKP-040) 1. Market is in opening auction, no mark price. From 3d5de20abd274f6ef2bc4f7fcc97f8ba5059d2c1 Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Tue, 9 Jan 2024 21:11:40 +0000 Subject: [PATCH 0870/1171] chore: typo --- protocol/0009-MRKP-mark_price.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0009-MRKP-mark_price.md b/protocol/0009-MRKP-mark_price.md index e7eb45fde..f365147bc 100644 --- a/protocol/0009-MRKP-mark_price.md +++ b/protocol/0009-MRKP-mark_price.md @@ -108,7 +108,7 @@ point of uncrossing the opening auction, then the auction uncrossing price is se - `markPriceConfiguration: source weight` valid values: `[0,1]`(0009-MRKP-053) - - `markPriceConfiguration: source staleness tolerance ` valid values: `time format`(0009-MRKP-054) + - `markPriceConfiguration: source staleness tolerance` valid values: `time format: hms`(0009-MRKP-054) ### Example 1 - A typical path of a cash settled futures market from end of opening auction till expiry (use Algorithm 2 (ie median price))(0009-MRKP-040) From d234fb5afb39ce127eaed14e96c700e0191062a4 Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Tue, 9 Jan 2024 21:16:21 +0000 Subject: [PATCH 0871/1171] chore: markdown --- protocol/0009-MRKP-mark_price.md | 8 +++----- 1 file changed, 3 insertions(+), 5 deletions(-) diff --git a/protocol/0009-MRKP-mark_price.md b/protocol/0009-MRKP-mark_price.md index f365147bc..4bbbd74ad 100644 --- a/protocol/0009-MRKP-mark_price.md +++ b/protocol/0009-MRKP-mark_price.md @@ -37,8 +37,7 @@ Note that for calculating the median with an even number of entries we sort, pic - 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) -- If a market mark price is configured in such a way that the mark price methodology hasn't provided a price at the -point of uncrossing the opening auction, then the auction uncrossing price is set as the first mark price, regardless of what the mark price methodology says. (0009-MRKP-001) +- If a market mark price is configured in such a way that the mark price methodology hasn't provided a price at the point of uncrossing the opening auction, then the auction uncrossing price is set as the first mark price, regardless of what the mark price methodology says. (0009-MRKP-001) ### Algorithm 1 (last trade price, excluding network trades) @@ -91,10 +90,9 @@ point of uncrossing the opening auction, then the auction uncrossing price is se - It is possible to configure a cash settled futures market to use a weighted average of 1. weighted average of trades over `network.markPriceUpdateMaximumFrequency` and 2. impact of leveraged notional on the order book with the value of USDT `100` and when the book does not have enough volume, then the book price should not be included (0009-MRKP-028) and a perps market (with the oracle source different to that used for the external price in the perps market) (0009-MRKP-029). - It is possible to configure a cash settled futures market to use a weighted average of 1. weighted average of trades over `network.markPriceUpdateMaximumFrequency` and 2. impact of leveraged notional on the order book with the value of USDT `0` and the book price should be mid price (0009-MRKP-030) and a perps market (with the oracle source different to that used for the external price in the perps market) (0009-MRKP-031). +- Set price type to "median", only have data source available from "Trade-size-weighted average price" and "Leverage-notional book price" and 1 trade at 15920, check the mark price is correctly calculated (0009-MRKP-032) and a perps market (0009-MRKP-033) -- Set price type to "median", only have data souce availabel from "Trade-size-weighted average price" and "Leverage-notional book price" and 1 trade at 15920, check the mark price is correctly calculated (0009-MRKP-032) and a perps market (0009-MRKP-033) - -- Set price type to "median", only have data souce availabel from "Trade-size-weighted average price" and "Leverage-notional book price" and 1 trade at 15920, and 1 trade at 15940, move time, and check stale price should not be included (0009-MRKP-032) and a perps market (0009-MRKP-033) +- Set price type to "median", only have data source available from "Trade-size-weighted average price" and "Leverage-notional book price" and 1 trade at 15920, and 1 trade at 15940, move time, and check stale price should not be included (0009-MRKP-034) and a perps market (0009-MRKP-035) ### Validation From 85b712f25a3c736d6da54528116157e4dd750ed7 Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Wed, 10 Jan 2024 09:00:07 +0000 Subject: [PATCH 0872/1171] chore: address comment --- protocol/0009-MRKP-mark_price.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0009-MRKP-mark_price.md b/protocol/0009-MRKP-mark_price.md index 4bbbd74ad..153e058d2 100644 --- a/protocol/0009-MRKP-mark_price.md +++ b/protocol/0009-MRKP-mark_price.md @@ -106,7 +106,7 @@ Note that for calculating the median with an even number of entries we sort, pic - `markPriceConfiguration: source weight` valid values: `[0,1]`(0009-MRKP-053) - - `markPriceConfiguration: source staleness tolerance` valid values: `time format: hms`(0009-MRKP-054) + - `markPriceConfiguration: source staleness tolerance` valid values: `valid duration string, e.g. "5s", "24h"`(0009-MRKP-054) ### Example 1 - A typical path of a cash settled futures market from end of opening auction till expiry (use Algorithm 2 (ie median price))(0009-MRKP-040) From b79e2cbcb0c040f1b979cf06dcec9c7a06ddf7fa Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Wed, 10 Jan 2024 09:31:08 +0000 Subject: [PATCH 0873/1171] feat: add validation ac for mark price --- protocol/0009-MRKP-mark_price.md | 3 +++ 1 file changed, 3 insertions(+) diff --git a/protocol/0009-MRKP-mark_price.md b/protocol/0009-MRKP-mark_price.md index 153e058d2..f94341088 100644 --- a/protocol/0009-MRKP-mark_price.md +++ b/protocol/0009-MRKP-mark_price.md @@ -108,6 +108,9 @@ Note that for calculating the median with an even number of entries we sort, pic - `markPriceConfiguration: source staleness tolerance` valid values: `valid duration string, e.g. "5s", "24h"`(0009-MRKP-054) + - `markPriceConfiguration: source weight` and `markPriceConfiguration: source staleness tolerance` should have the same length(0009-MRKP-055) + + - `markPriceConfiguration: source weight` and `markPriceConfiguration: source staleness tolerance` length should be 3 plus number of oracle data sources (0009-MRKP-056) ### Example 1 - A typical path of a cash settled futures market from end of opening auction till expiry (use Algorithm 2 (ie median price))(0009-MRKP-040) From 179db947ffdf8597d4877671976f0e545cde1e90 Mon Sep 17 00:00:00 2001 From: David Siska <62546419+davidsiska-vega@users.noreply.github.com> Date: Wed, 10 Jan 2024 10:34:11 +0000 Subject: [PATCH 0874/1171] fix: post-research call edits --- .../0087-EVMD-eth-rpc-and-evm-data-source.md | 21 ++++++++++++------- 1 file changed, 14 insertions(+), 7 deletions(-) diff --git a/protocol/0087-EVMD-eth-rpc-and-evm-data-source.md b/protocol/0087-EVMD-eth-rpc-and-evm-data-source.md index 28d37572d..c755f473b 100644 --- a/protocol/0087-EVMD-eth-rpc-and-evm-data-source.md +++ b/protocol/0087-EVMD-eth-rpc-and-evm-data-source.md @@ -12,14 +12,14 @@ Hence this is in addition to and building upon [Ethereum data source](./0082-ETH ## Description -In addition to listening to Ethereum events and reading from Ethereum contracts as described in [Ethereum data source](./0082-ETHD-ethereum-data-source.md) it will be possible for Vega nodes to listen to events from and read from other chains that implement Ethereum RPC and run EVM, in particular Ethereum L2. +In addition to listening to Ethereum events and reading from Ethereum contracts as described in [Ethereum data source](./0082-ETHD-ethereum-data-source.md) it will be possible for Vega nodes to listen to events from and read from other chains that implement Ethereum RPC and run EVM, in particular Ethereum L2s. The overarching principle is that the chain provides ethereum RPC / EVMs and thus contracts and ABIs are assumed to be functionally the same as on Ethereum itself. ## Registration / removal A new network parameter, a JSON list of network id / chain id / name one per Ethereum RPC and EVM chain will be used for setting supported L2. This is set via [governance](./0028-GOVE-governance.md). -Name `blockchains.ethereumL2Configs`. +Name `blockchains.ethereumRpcAndEvmCompatDataSourcesConfig`. Example value: ```json @@ -28,28 +28,35 @@ Example value: Duplicate values of `network_id`, `chain_id` or `name` are not allowed (an update will be rejected at validation stage). Any update must always change the entire JSON (it's not possible to change individual entries). -A proposal to *remove* a registered Ethereum RPC+EVM compatible chain / L2 must fail at enactment stage if a market is referencing an `EthRpcEvmCompatible` data source. +In current minimal scope, at proposal validation, check that only change is +1. changing number of confirmation or +1. adding another source. + +For later release: A proposal to *remove* a registered Ethereum RPC+EVM compatible chain / L2 must fail at enactment stage if a market is referencing an `EthRpcEvmCompatible` data source. + A proposal for a new market will fail at enactment stage if it's referencing an `EthRpcEvmCompatible` that's not registered. ## Acceptance criteria - ### External Oracles - Creation - It is possible to add `EthRpcEvmCompatible` via governance (0087-EVMD-001). +### External Oracles - External Chain Config Changes + +- At network proposal validation step we check that the only change to `blockchains.ethereumRpcAndEvmCompatDataSourcesConfig` is to either change number of confirmations or add another external chain. (0087-EVMD-043) -### External Oracles - Deactivation (not implemented in Palazzo milestone) +### External Oracles - Deactivation (not scoped in Palazzo milestone) - It is possible to remove an `EthRpcEvmCompatible` via governance. The proposal will fail at enactment stage if there is any market that's not settled / closed that reference the `EthRpcEvmCompatible`. This is a future requirement and does not have an AC code. -### External Oracles - Amendments +### External Oracles - Market Amendments - It may happen that an `EthRpcEvmCompatible` that cannot be read from is proposed (because not enough validator nodes have it configured etc.). In that case a proposed / enacted market will not see the oracle inputs but it must be possible to change the said market via on-chain governance (0087-EVMD-003). - Update an existing futures market using the market update proposal to change the `EthRpcEvmCompatible` chain referenced, 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 (0087-EVMD-004) -- 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 (0087-EVMD-005) +- 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 (0087-EVMD-005) - 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 (0087-EVMD-006) - 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 (0087-EVMD-007) From 6f46bda8bcbd0c2c153d0c2e3ab088dbdd34d19d Mon Sep 17 00:00:00 2001 From: Witold Date: Wed, 10 Jan 2024 11:46:13 +0100 Subject: [PATCH 0875/1171] refactor: scale funding payment down (auction) --- ...3-PERP-product_builtin_perpetual_future.md | 28 +++++++++++-------- protocol/features.json | 2 +- 2 files changed, 18 insertions(+), 12 deletions(-) diff --git a/protocol/0053-PERP-product_builtin_perpetual_future.md b/protocol/0053-PERP-product_builtin_perpetual_future.md index 01b8f738b..b3b28243d 100644 --- a/protocol/0053-PERP-product_builtin_perpetual_future.md +++ b/protocol/0053-PERP-product_builtin_perpetual_future.md @@ -100,12 +100,7 @@ Every time a [mark to market settlement](./0003-MTMK-mark_to_market_settlement.m When the `settlement_schedule` event is received we need to calculate the funding payment. Store the current vega time as `funding_period_end`. -Skip the funding payment calculation (set payment to `0`) if any of the following conditions is met: - -- no spot (external) data has been ingested since market was created, -- market has been in auction throughout the entire funding period. - -Please refer to the following subsections for the details of calculation of the funding payment if none of the above conditions are met. +Skip the funding payment calculation (set payment to `0`) if no spot (external) data has been ingested since market was create, otherwise calculate the funding payment as outlined below. #### TWAP calculation @@ -169,6 +164,16 @@ funding_payment = f_twap - s_twap + min(clamp_upper_bound*s_twap,max(clamp_lower where `(1 + delta_t * interest_rate)` is the linearisation of `exp(delta_t*interest_rate)` and `delta_t` is expressed as a year fraction. +Furthermore, if any time was spent in auction during the funding period then the funding payment should be scaled down by the fraction of the period spent outside of auction: + +`period_duration = period_end - period_start` + +```go +funding_payment = (period_duration-time_spent_in_auction)/period_duration * funding_payment +``` + +Please note that this implies no funding payments for periods during which the market has been in auction for their entire duration. + If `scaling_factor` is specified set: ```go @@ -301,7 +306,7 @@ Then, assuming no auctions during the period we get: $\text{internal TWAP}= \frac{10\cdot(1-0)+11\cdot(3-1)+10\cdot(5-3)+9\cdot(7-5)+8\cdot(9-7)+7\cdot(10-9)}{10}=9.3$, $\text{external TWAP}=\frac{11\cdot(1-0)+9\cdot(3-1)+10\cdot(5-3)+12\cdot(6-5)+11\cdot(7-6)+8\cdot(9-7)+14\cdot(10-9)}{10}=10.2$. (0053-PERP-027) -1. Assume a 10 minute funding period. Assume a few funding periods have already passed for this market. Furthermore, assume that in this period that market is in an auction which starts 5 minutes into the period and ends 7 minutes into the period. +1. Assume a 10 minute funding period. Assume a few funding periods have already passed for this market. Furthermore, assume that in this period that market is in an auction which starts 5 minutes into the period and ends 7 minutes into the period. Assume `interest_rate`=`clamp_lower_bound`=`clamp_upper_bound`=`0`, `scaling_factor`=`1` and no rate upper or lower bound. Assume the last known mark price before the start of the period to be `10` and that it gets updated as follows: | Time (min) since period start | mark price | @@ -323,8 +328,9 @@ Assume the last known spot price before this funding period is `11`. Then assume | 9 | 14 | Then, taking the auction into account we get: -$\text{internal TWAP}= \frac{10\cdot(1-0)+11\cdot(3-1)+11\cdot(5-3)+9\cdot(8-7)+8\cdot(10-8)+30\cdot(10-10)}{8}=9.875$, -$\text{external TWAP}=\frac{11\cdot(1-0)+9\cdot(3-1)+10\cdot(5-3)+11\cdot(8-7)+8\cdot(9-8)+14\cdot(10-9)}{8}=10.25$. (0053-PERP-028) +$\text{internal TWAP}=\frac{10\cdot(1-0)+11\cdot(3-1)+11\cdot(5-3)+9\cdot(8-7)+8\cdot(10-8)+30\cdot(10-10)}{8}=9.875$, +$\text{external TWAP}=\frac{11\cdot(1-0)+9\cdot(3-1)+10\cdot(5-3)+11\cdot(8-7)+8\cdot(9-8)+14\cdot(10-9)}{8}=10.25$, +$\text{funding payment}=(10-(7-5))/10 * (9.875 - 10.25) = -0.3$. (0053-PERP-036) When $\text{clamp lower bound}=\text{clamp upper bound}=0$, $\text{scaling factor}=2.5$ and the funding period ends with $\text{internal TWAP}=99$, $\text{external TWAP} = 100$ then the resulting funding rate equals $-0.025$. (0053-PERP-029) @@ -335,8 +341,8 @@ When $\text{clamp lower bound}=\text{clamp upper bound}=0$, $\text{scaling facto When migrating the market existing prior to introduction of the additional parameters their values get set to: - $\text{scaling factor}=1$, -- $\text{rate_lower_bound}= -\text{max supported value}$, -- $\text{rate_upper_bound}= \text{max supported value}$ +- $\text{rate lower bound}= -\text{max supported value}$, +- $\text{rate upper bound}= \text{max supported value}$ (0053-PERP-032). It is possible to create a perpetual futures market which uses the last traded price algorithm for its mark price but uses "impact volume of notional of 1000 USDT" for the purpose of calculating the TWAP of the market price for funding payments (0053-PERP-033). diff --git a/protocol/features.json b/protocol/features.json index 85fdd4dd9..fa2c595e8 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -32,7 +32,7 @@ "0053-PERP-025", "0053-PERP-026", "0053-PERP-027", - "0053-PERP-028", + "0053-PERP-036", "0053-PERP-029", "0053-PERP-030", "0053-PERP-031", From e76a14001cdee48f2a4572d4af347ccf1a2a0ae7 Mon Sep 17 00:00:00 2001 From: Witold Date: Wed, 10 Jan 2024 11:52:54 +0100 Subject: [PATCH 0876/1171] refactor: apply suggestions from code review Co-authored-by: David Siska <62546419+davidsiska-vega@users.noreply.github.com> --- 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 b3b28243d..49b474d32 100644 --- a/protocol/0053-PERP-product_builtin_perpetual_future.md +++ b/protocol/0053-PERP-product_builtin_perpetual_future.md @@ -100,7 +100,7 @@ Every time a [mark to market settlement](./0003-MTMK-mark_to_market_settlement.m When the `settlement_schedule` event is received we need to calculate the funding payment. Store the current vega time as `funding_period_end`. -Skip the funding payment calculation (set payment to `0`) if no spot (external) data has been ingested since market was create, otherwise calculate the funding payment as outlined below. +Skip the funding payment calculation (set payment to `0`) if no spot (external) data has been ingested since market was created, otherwise calculate the funding payment as outlined below. #### TWAP calculation @@ -172,7 +172,7 @@ Furthermore, if any time was spent in auction during the funding period then the funding_payment = (period_duration-time_spent_in_auction)/period_duration * funding_payment ``` -Please note that this implies no funding payments for periods during which the market has been in auction for their entire duration. +Please note that this implies no funding payments for periods during which the market has been in auction / suspended for their entire duration. If `scaling_factor` is specified set: From de864edcf9a6777f5e9eee216bed1daa37e08730 Mon Sep 17 00:00:00 2001 From: Charlie Date: Mon, 8 Jan 2024 17:46:44 +0000 Subject: [PATCH 0877/1171] feat: add liquidation acs --- .../0003-MTMK-mark_to_market_settlement.md | 4 +++ protocol/0012-POSR-position_resolution.md | 26 +++++++++++++++++++ ...3-PERP-product_builtin_perpetual_future.md | 6 +++++ protocol/features.json | 21 +++++++++++++-- 4 files changed, 55 insertions(+), 2 deletions(-) diff --git a/protocol/0003-MTMK-mark_to_market_settlement.md b/protocol/0003-MTMK-mark_to_market_settlement.md index 7b7355f2b..08ce35ec5 100644 --- a/protocol/0003-MTMK-mark_to_market_settlement.md +++ b/protocol/0003-MTMK-mark_to_market_settlement.md @@ -22,6 +22,10 @@ 1. If the mark price hasn't changed: 1. A trader with no change in open position size has no transfers in or out of their margin account (0003-MTMK-012) 1. An aggressive order to buy 2 units at 1010 which matches with two passive orders each of size one resting on the book with prices of 1000 and 1010 results in a transfer of 10 flowing from the party with order priced at 1000 to the aggressive party during the next MTM settlement 0003-MTMK-013) +1. If the network party has a non-zero position and the mark-price moves in favour of the network's position gains from mark-to-market settlement should be paid into the market insurance pool. (0003-MTMK-015) +1. If the network party has a non-zero position and the mark-price moves against the network's position, losses from mark-to-market settlement should be paid from the market insurance pool. (0003-MTMK-016) +1. If the network does not have enough funds in the market insurance pool to cover its mark-to-market losses, loss-socialisation occurs. (0003-MTMK-017) + ## Market with position decimal places > 0 scenario diff --git a/protocol/0012-POSR-position_resolution.md b/protocol/0012-POSR-position_resolution.md index 58b50d1b3..a5e050644 100644 --- a/protocol/0012-POSR-position_resolution.md +++ b/protocol/0012-POSR-position_resolution.md @@ -27,6 +27,20 @@ - It is possible to check the time of the next liquidation trade attempt in any market via the API. (0012-POSR-015) +### Network position disposal + +- When calculating the available volume, the full remaining size of iceberg orders should be considered. (0012-POSR-019) +- When calculating the available volume, volume outside price monitoring bounds should be considered. (0012-POSR-020) +- When calculating the available volume, volume outside the liquidity price range should not be considered. (0012-POSR-021) +- Given a highly liquid market, if the network’s position is greater than `full disposal size`. The network must attempt to dispose `position * disposal fraction` at the next disposal step. (0012-POSR-022) +- Given a highly liquid market, if the network’s position is less than or equal to `full disposal size`. The network must attempt to dispose of its full position at the next disposal step. (0012-POSR-023) +- Given a highly liquid market, if the network’s `disposal fraction<1` and `full disposal size`=0, the network must still eventually dispose of its full position. (0012-POSR-024) +- The network must never dispose more than `available volume * max fraction of book side within liquidity bounds consumed` in a single order. (0012-POSR-025) +- A network disposal order which generates trades must not affect the mark price. (0012-POSR-026) +- A network disposal order can not cross with orders outside the liquidity price range. (0012-POSR-027) +- A network disposal order can cross with orders outside price monitoring bounds but must not trigger a price monitoring auction. (0012-POSR-028) +- A network disposal order which crosses multiple orders should generate multiple atomic trades. (0012-POSR-029) + ### Network Profit and Loss - Given the network starts with no position and does not dispose any of it's position during the scenario: (0012-POSR-016) @@ -41,6 +55,18 @@ - The mark price moves to `90`, the network liquidates a distressed party with a long position of `1` (average entry price now equals `95`). The network should report a position of `2` and a realised and unrealised pnl of `0` and `-10` respectively. - The mark price moves to `60`. The network should report a position of `2` and a realised and unrealised pnl of `0` and `-70` respectively. +- Given an empty insurance pool and the liquidation strategy `disposal time step = 5`, `disposal fraction = 0.5`, `full disposal size=0` and `max fraction of book side within liquidity bounds consumed = 0.01` during the below scenario: (0012-POSR-018) + - The mark price moves to 100, the network liquidates a distressed party with a long position of 2. The network should report a position of 2 and a realised and unrealised pnl of 0 and 0 respectively. + - Given the order book: + | side | price | size | + |------|-------|------| + | buy | 90 | 1000 | + | sell | 110 | 1000 | + - The time updates to the next disposal time, the network reduces its position by 1. The network should report a position of 1 and a realised and unrealised pnl of -10 and 0 respectively. + - The time updates to the next disposal time, the network reduces its position by 1. The network should report a position of 1 and a realised and unrealised pnl of -20 and 0 respectively. + - Loss socialisation should be applied and the accumulated balance for all accounts should be unchanged. + + ## Summary Position resolution is the mechanism which deals with closing out distressed positions on a given market. It is instigated when one or more participant's margin account balance falls below their latest maintenance margin level. diff --git a/protocol/0053-PERP-product_builtin_perpetual_future.md b/protocol/0053-PERP-product_builtin_perpetual_future.md index 49b474d32..db79f3ee4 100644 --- a/protocol/0053-PERP-product_builtin_perpetual_future.md +++ b/protocol/0053-PERP-product_builtin_perpetual_future.md @@ -351,3 +351,9 @@ It is possible to create a perpetual futures market which uses an oracle source It is possible to create a perpetual futures market which uses an oracle source (same as that used for funding) for the mark price determining the mark-to-market cashflows and that uses "time-weighted trade prices in over `network.markPriceUpdateMaximumFrequency` if these have been updated within the last 30s but falls back onto impact volume of notional of 1000 USDT" for the purpose of calculating the TWAP of the market price for funding payments (0053-PERP-035). +When funding payments are due to the network party they are paid into the market insurance pool (0053-PERP-036). + +When funding payments are due from the network party they are paid from the market insurance pool (0053-PERP-037). + +If a market insurance pool does not have enough funds to cover a funding payment, loss socialisation occurs and the total balances across the network remains constant (0053-PERP-038). + diff --git a/protocol/features.json b/protocol/features.json index fa2c595e8..ddf2d02af 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -209,8 +209,25 @@ "0012-POSR-014", "0012-POSR-015", "0012-POSR-016", - "0012-POSR-017" - + "0012-POSR-017", + "0012-POSR-018", + "0012-POSR-019", + "0012-POSR-020", + "0012-POSR-021", + "0012-POSR-022", + "0012-POSR-023", + "0012-POSR-024", + "0012-POSR-025", + "0012-POSR-026", + "0012-POSR-027", + "0012-POSR-028", + "0012-POSR-029", + "0003-MTMK-015", + "0003-MTMK-016", + "0003-MTMK-017", + "0053-PERP-036", + "0003-MTMK-037", + "0003-MTMK-038" ] }, "Passive liquidity": { From d4b8e82f1b7ba4a6e0cf2ee953a1f5aaf658b34b Mon Sep 17 00:00:00 2001 From: Charlie Date: Tue, 9 Jan 2024 08:58:51 +0000 Subject: [PATCH 0878/1171] fix: correct typo in features --- protocol/features.json | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/protocol/features.json b/protocol/features.json index ddf2d02af..72c9f5109 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -226,8 +226,8 @@ "0003-MTMK-016", "0003-MTMK-017", "0053-PERP-036", - "0003-MTMK-037", - "0003-MTMK-038" + "0053-PERP-037", + "0053-PERP-038" ] }, "Passive liquidity": { From 29dac52df2d07b39786e48972e9152f7968d46d0 Mon Sep 17 00:00:00 2001 From: Charlie Date: Wed, 10 Jan 2024 11:12:25 +0000 Subject: [PATCH 0879/1171] chore: update AC codes for rebase --- protocol/0053-PERP-product_builtin_perpetual_future.md | 6 +++--- protocol/features.json | 4 ++-- 2 files 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 db79f3ee4..db0c57cab 100644 --- a/protocol/0053-PERP-product_builtin_perpetual_future.md +++ b/protocol/0053-PERP-product_builtin_perpetual_future.md @@ -351,9 +351,9 @@ It is possible to create a perpetual futures market which uses an oracle source It is possible to create a perpetual futures market which uses an oracle source (same as that used for funding) for the mark price determining the mark-to-market cashflows and that uses "time-weighted trade prices in over `network.markPriceUpdateMaximumFrequency` if these have been updated within the last 30s but falls back onto impact volume of notional of 1000 USDT" for the purpose of calculating the TWAP of the market price for funding payments (0053-PERP-035). -When funding payments are due to the network party they are paid into the market insurance pool (0053-PERP-036). +When funding payments are due to the network party they are paid into the market insurance pool (0053-PERP-037). -When funding payments are due from the network party they are paid from the market insurance pool (0053-PERP-037). +When funding payments are due from the network party they are paid from the market insurance pool (0053-PERP-038). -If a market insurance pool does not have enough funds to cover a funding payment, loss socialisation occurs and the total balances across the network remains constant (0053-PERP-038). +If a market insurance pool does not have enough funds to cover a funding payment, loss socialisation occurs and the total balances across the network remains constant (0053-PERP-039). diff --git a/protocol/features.json b/protocol/features.json index 72c9f5109..2ee84ce7b 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -225,9 +225,9 @@ "0003-MTMK-015", "0003-MTMK-016", "0003-MTMK-017", - "0053-PERP-036", "0053-PERP-037", - "0053-PERP-038" + "0053-PERP-038", + "0053-PERP-039" ] }, "Passive liquidity": { From e2f694b8337477e3a84ae0046b793cc0ae649d3c Mon Sep 17 00:00:00 2001 From: gordsport Date: Tue, 9 Jan 2024 17:48:41 +0000 Subject: [PATCH 0880/1171] chore: add branch to quality checks Adds the nebula branch to the quality check git hub actions --- .github/workflows/quality_check.yml | 1 + 1 file changed, 1 insertion(+) diff --git a/.github/workflows/quality_check.yml b/.github/workflows/quality_check.yml index 657a39b8a..bc8042d5a 100644 --- a/.github/workflows/quality_check.yml +++ b/.github/workflows/quality_check.yml @@ -9,6 +9,7 @@ name: "Quality checks" - master - cosmicelevator - palazzo + - nebula env: GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} From f04ac1c771685ac52878103312ba02fce6a94c39 Mon Sep 17 00:00:00 2001 From: Tom Date: Wed, 10 Jan 2024 20:30:26 +0800 Subject: [PATCH 0881/1171] feat: Adding market tags proposal spec (#2103) --------- Co-authored-by: Gordsport <83510148+gordsport@users.noreply.github.com> --- .github/workflows/quality_check.yml | 2 +- makefile | 2 +- protocol/0001-MKTF-market_framework.md | 1 + protocol/0028-GOVE-governance.md | 43 +++++++++++++++++++++++++- protocol/nebula-features.json | 30 ++++++++++++++++++ 5 files changed, 75 insertions(+), 3 deletions(-) create mode 100644 protocol/nebula-features.json diff --git a/.github/workflows/quality_check.yml b/.github/workflows/quality_check.yml index bc8042d5a..c4869cb04 100644 --- a/.github/workflows/quality_check.yml +++ b/.github/workflows/quality_check.yml @@ -77,4 +77,4 @@ jobs: - name: "Run Check Features" run: | - npx github:vegaprotocol/approbation check-features --specs="{./non-protocol-specs/**/*.md,./protocol/**/*.md,./protocol/**/*.ipynb}" --features="./protocol/features.json" + npx github:vegaprotocol/approbation check-features --specs="{./non-protocol-specs/**/*.md,./protocol/**/*.md,./protocol/**/*.ipynb}" --features="./protocol/nebula-features.json" diff --git a/makefile b/makefile index ae9bcacd0..f2bc609ae 100644 --- a/makefile +++ b/makefile @@ -64,7 +64,7 @@ spellcheck: # Checks for duplicated ACs in the features.json file .PHONY: check-features check-features: - npx github:vegaprotocol/approbation check-features --specs="{./non-protocol-specs/**/*.md,./protocol/**/*.md,./protocol/**/*.ipynb}" --features="./protocol/features.json" + npx github:vegaprotocol/approbation check-features --specs="{./non-protocol-specs/**/*.md,./protocol/**/*.md,./protocol/**/*.ipynb}" --features="./protocol/nebula-features.json" clean: rm -rf $(TEMP) diff --git a/protocol/0001-MKTF-market_framework.md b/protocol/0001-MKTF-market_framework.md index 1f4bc30d5..5f16a0699 100644 --- a/protocol/0001-MKTF-market_framework.md +++ b/protocol/0001-MKTF-market_framework.md @@ -80,6 +80,7 @@ Data: - **Name:** full and fairly descriptive name for the instrument. - **Metadata fields:** A series of arbitrary strings that can be used in clients - **Product:** a reference to or instance of a fully specified product, including all required product parameters for that product. +- **Community Tags:** A list of string community tags assigning the market to certain categories. Each of these is a free text field of a network parameter defined maximum length. These are managed through a separate proposal type and cannot be set at market creation or changed in a normal market update proposal. ## Product diff --git a/protocol/0028-GOVE-governance.md b/protocol/0028-GOVE-governance.md index d29c11836..c4aba128b 100644 --- a/protocol/0028-GOVE-governance.md +++ b/protocol/0028-GOVE-governance.md @@ -249,6 +249,32 @@ The following are immutable and cannot be changed: - position decimal places - `settlementAsset` +### 2.1 Change community tags + +Separately to a general market change proposal, proposers can create a proposal to add or remove lists of free-text string community tags to a market. Although these proposals change only a single market, it is possible that these tags will be used to control external behaviour of systems interacting with the vega chain, therefore they do not allow for voting using ELS and instead must be voted through by the general pool of token holders as with any other proposal. The maximum length of a community tags is specified by the network parameter `governance.proposal.market.maxCommunityTagLength`. The community tags on a market are controlled by a single proposal type, `UpdateCommunityTags` with a structure akin to: + +```proto +message UpdateCommunityTags { + string marketId; + repeated string addTags; + repeated string removeTags; +} +``` + +allowing proposals to add and remove tags independently from others. + +The following network parameters will decide how these proposals are treated: +`governance.proposal.updateCommunityTags.maxClose` e.g. `720h`, +`governance.proposal.updateCommunityTags.minClose` e,g. `168h`, +`governance.proposal.updateCommunityTags.maxEnact` e.g. `720h`, +`governance.proposal.updateCommunityTags.minEnact` e,g. `168h`, +`governance.proposal.updateCommunityTags.minProposerBalance` e.g. `1000000000000000000` i.e. 1 VEGA, +`governance.proposal.updateCommunityTags.minVoterBalance` e.g. `1000000000000000000` i.e. 1 VEGA, +`governance.proposal.updateCommunityTags.requiredMajority` e.g. `0.66`, +`governance.proposal.updateCommunityTags.requiredParticipation` e.g. `0.05`. + +Note: Although community tags cannot be amended in an update market proposal, they may be included in the same batch proposal as one. + ## 3. Change network parameters [Network parameters](./0054-NETP-network_parameters.md) that may be changed are described in the _Network Parameters_ spec, this document for details on these parameters, including the category of the parameters. New network parameters require a code change, so there is no support for adding new network parameters. @@ -708,9 +734,10 @@ It is NOT possible to submit a governance proposal where the source account is t 1. volume discount program, 1. referral program, 1. governance transfer, + 1. a community tags proposal can be submitted, voted through and each proposal enacted. -On top of that signed bundles for changing withdrawal delay and threshold on the bridge are emitted (0028-GOVE-160) +On top of that signed bundles for changing withdrawal delay and threshold on the bridge are emitted (0028-GOVE-177) - A batch proposal can be submitted changing the same network parameter twice to two different values with two different enactment timestamps. The voting to approve the batch happens, the batch passes, both changes are observed at the desired time. (0028-GOVE-161) @@ -726,3 +753,17 @@ The voting to approve the batch happens, the batch passes, the value of the prop ##### 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) + +##### Community Market Tags + +- A proposal to add community tags to a market can be successfully submitted. (0028-GOVE-167) + - When that proposal is approved and enacted the community tags are immediately added to that market's community tags property. (0028-GOVE-168) +- A proposal to remove community tags from a market can be successfully submitted. (0028-GOVE-169) + - When that proposal is approved and enacted the community tags are immediately removed from that market's community tags property. (0028-GOVE-170) +- A proposal to add some and remove other community tags from a market can be successfully submitted. (0028-GOVE-171) + - When that proposal is approved and enacted the community tags are immediately removed and added to that market's community tags property. (0028-GOVE-172) +- Neither market creation nor market update proposals can change the community tags property on a market. (0028-GOVE-173) +- A voter's equity-like share does not give them any additional voting weight when voting on a market community tags update proposal. (0028-GOVE-174) +- A proposal to add community tags with any community tags longer than `governance.proposal.market.maxCommunityTagLength` is rejected as invalid (0028-GOVE-175) +- A proposal to remove community tags with any community tags longer than `governance.proposal.market.maxCommunityTagLength` is rejected as invalid (0028-GOVE-176) + diff --git a/protocol/nebula-features.json b/protocol/nebula-features.json new file mode 100644 index 000000000..9b201a88e --- /dev/null +++ b/protocol/nebula-features.json @@ -0,0 +1,30 @@ +{ + "TBC": { + "milestone": "cosmic-carryover", + "acs": [] + }, + "TBC": { + "milestone": "palazzo-carryover", + "acs": [] + }, + "Community Tags": { + "milestone": "nebula", + "acs": [ + "0028-GOVE-167", + "0028-GOVE-168", + "0028-GOVE-169", + "0028-GOVE-170", + "0028-GOVE-171", + "0028-GOVE-172", + "0028-GOVE-173", + "0028-GOVE-174", + "0028-GOVE-175", + "0028-GOVE-176", + "0028-GOVE-177" + ] + }, + "Unknown": { + "milestone": "unknown", + "acs": [] + } +} From 1605c45e717d61e1ebc5da498924916ed385c922 Mon Sep 17 00:00:00 2001 From: David Siska <62546419+davidsiska-vega@users.noreply.github.com> Date: Wed, 10 Jan 2024 13:06:31 +0000 Subject: [PATCH 0882/1171] fix: markdown --- protocol/0087-EVMD-eth-rpc-and-evm-data-source.md | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/protocol/0087-EVMD-eth-rpc-and-evm-data-source.md b/protocol/0087-EVMD-eth-rpc-and-evm-data-source.md index c755f473b..bbdf80d26 100644 --- a/protocol/0087-EVMD-eth-rpc-and-evm-data-source.md +++ b/protocol/0087-EVMD-eth-rpc-and-evm-data-source.md @@ -28,9 +28,10 @@ Example value: Duplicate values of `network_id`, `chain_id` or `name` are not allowed (an update will be rejected at validation stage). Any update must always change the entire JSON (it's not possible to change individual entries). -In current minimal scope, at proposal validation, check that only change is -1. changing number of confirmation or -1. adding another source. +In current minimal scope, at proposal validation, check that only change is + +1. changing number of confirmation or +1. adding another source. For later release: A proposal to *remove* a registered Ethereum RPC+EVM compatible chain / L2 must fail at enactment stage if a market is referencing an `EthRpcEvmCompatible` data source. From e332e2605ee9265c0b0476be45aca35e23655199 Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Wed, 10 Jan 2024 15:08:58 +0000 Subject: [PATCH 0883/1171] feat: add AC 126 --- protocol/0009-MRKP-mark_price.md | 1 + 1 file changed, 1 insertion(+) diff --git a/protocol/0009-MRKP-mark_price.md b/protocol/0009-MRKP-mark_price.md index f94341088..5d0a63bdc 100644 --- a/protocol/0009-MRKP-mark_price.md +++ b/protocol/0009-MRKP-mark_price.md @@ -64,6 +64,7 @@ Note that for calculating the median with an even number of entries we sort, pic - when choosing price type `weight` and set weight on `leverage-notional book price` only, set cash amount to `100` (which should make the notional volume at sell and buy round to `0`), and place a few orders on the book with best bid `15900` and best ask `16000` and the leverage-notional book price should be the mid-price (0009-MRKP-120) and on perp market (0009-MRKP-121) - when choosing price type `weight` and set weight on `leverage-notional book price` only, set cash amount to `100,000` and place a few orders on the book with best bid `15900` and best ask `16000` and check if leverage-notional book price is corrected calculated (0009-MRKP-122) and on perp market (0009-MRKP-123) - when choosing price type `weight` and set weight on `leverage-notional book price` only, set cash amount to `5,000,000` (which should make the notional volume too big for the book) and place a few orders on the book with best bid `15900` and best ask `16000` and the leverage-notional book price should be the mid-price (0009-MRKP-124) and on perp market (0009-MRKP-125) +- when choosing price type `weight` and set weight on `leverage-notional book price` only, set cash amount to `100,000` and place a few orders on the book with best bid `15900` and best ask `16000` and check leverage-notional book price, then change the order book by placing a trade, and check if the leverage-notional book price is updated when the time indicated by the mark price frequency is crossed(0009-MRKP-126) and on perp market (0009-MRKP-127) #### Oracle source price From 5d9d88d2cedd95fc0ea5abe3f665b6e15976a779 Mon Sep 17 00:00:00 2001 From: Gordsport <83510148+gordsport@users.noreply.github.com> Date: Wed, 10 Jan 2024 19:52:47 +0000 Subject: [PATCH 0884/1171] chore: Add more perps funding ACs (#2110) * chore: Add more perps funding ACs Adds more perps funding ACs from the AC review meeting Note the ACs mentioned for: - https://github.com/vegaprotocol/vega/issues/10254 - https://github.com/vegaprotocol/vega/issues/10255 Have NOT yet been added as the core side work has not been scheduled. A note has been added to the core issue * chore: Add AC code to the features.json file * fix: spelling * fix: spelling * fix: more spelling * fix: AC wording Co-authored-by: David Siska <62546419+davidsiska-vega@users.noreply.github.com> --------- Co-authored-by: David Siska <62546419+davidsiska-vega@users.noreply.github.com> --- protocol/0053-PERP-product_builtin_perpetual_future.md | 5 +++++ protocol/0082-ETHD-ethereum-data-source.md | 1 + protocol/features.json | 6 +++++- 3 files changed, 11 insertions(+), 1 deletion(-) diff --git a/protocol/0053-PERP-product_builtin_perpetual_future.md b/protocol/0053-PERP-product_builtin_perpetual_future.md index db0c57cab..80cf91914 100644 --- a/protocol/0053-PERP-product_builtin_perpetual_future.md +++ b/protocol/0053-PERP-product_builtin_perpetual_future.md @@ -357,3 +357,8 @@ When funding payments are due from the network party they are paid from the mark If a market insurance pool does not have enough funds to cover a funding payment, loss socialisation occurs and the total balances across the network remains constant (0053-PERP-039). +Assert that the scaling factor is applied before the funding cap is applied (0053-PERP-040). + +Assert all funding payments are correct when a perpetual market is suspended and then terminated via governance. (0053-PERP-041). + +The upper and lower clamp values are being correctly validated as per the [parameters defined in the spec](https://github.com/vegaprotocol/specs/blob/palazzo/protocol/0053-PERP-product_builtin_perpetual_future.md#1-product-parameters). (0053-PERP-042). diff --git a/protocol/0082-ETHD-ethereum-data-source.md b/protocol/0082-ETHD-ethereum-data-source.md index 4cb4bb620..314f96533 100644 --- a/protocol/0082-ETHD-ethereum-data-source.md +++ b/protocol/0082-ETHD-ethereum-data-source.md @@ -150,6 +150,7 @@ Select { 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) +16. Create a perpetual futures market which uses Ethereum oracle reads/events contract data for settlement payment schedule from; the trigger for the countdown to the first funding payment being publication of a valid value for the index price. The index price must not be available at the time the market is created and leaves opening auction; it must only become available sometime after. The aim is to test futures markets for underlyings that don't trade *yet* be where there is an agreed oracle source that will start publishing the price *once* they begin trading. (0082-ETHD-052). ### New Network parameters diff --git a/protocol/features.json b/protocol/features.json index 94841663d..2d44f6184 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -22,6 +22,7 @@ "0014-ORDT-121", "0014-ORDT-122", "0014-ORDT-123", + "0082-ETHD-052", "0053-PERP-024", "0053-PERP-025", "0053-PERP-026", @@ -30,7 +31,10 @@ "0053-PERP-029", "0053-PERP-030", "0053-PERP-031", - "0053-PERP-032" + "0053-PERP-032", + "0053-PERP-040", + "0053-PERP-041", + "0053-PERP-042" ] }, "Team rewards": { From 480a8d37f40641a9a8ef482a257fd954f08d858c Mon Sep 17 00:00:00 2001 From: gordsport Date: Wed, 10 Jan 2024 20:56:19 +0000 Subject: [PATCH 0885/1171] fix: add missing AC codes to the featurews.json file Adds in the missing margin, markprice and perp AC codes --- protocol/features.json | 42 +++++++++++++++++++++++++++++++++++++++--- 1 file changed, 39 insertions(+), 3 deletions(-) diff --git a/protocol/features.json b/protocol/features.json index 2d44f6184..2867adc0c 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -32,6 +32,7 @@ "0053-PERP-030", "0053-PERP-031", "0053-PERP-032", + "0053-PERP-039", "0053-PERP-040", "0053-PERP-041", "0053-PERP-042" @@ -102,6 +103,11 @@ "0019-MCAL-066", "0019-MCAL-067", "0019-MCAL-068", + "0019-MCAL-070", + "0019-MCAL-071", + "0019-MCAL-072", + "0019-MCAL-073", + "0019-MCAL-074", "0019-MCAL-075", "0019-MCAL-078", "0019-MCAL-100", @@ -172,10 +178,10 @@ "0019-MCAL-229", "0019-MCAL-230", "0019-MCAL-231", - "0074-BTCH-020", - "0074-BTCH-021", "0019-MCAL-232", - "0019-MCAL-233" + "0019-MCAL-233", + "0074-BTCH-020", + "0074-BTCH-021" ] }, "Quadratic slippage removal": { @@ -301,6 +307,7 @@ "Markprice updates": { "milestone": "palazzo", "acs": [ + "0009-MRKP-001", "0009-MRKP-010", "0009-MRKP-011", "0009-MRKP-012", @@ -323,8 +330,37 @@ "0009-MRKP-029", "0009-MRKP-030", "0009-MRKP-031", + "0009-MRKP-032", "0009-MRKP-040", "0009-MRKP-041", + "0009-MRKP-050", + "0009-MRKP-051", + "0009-MRKP-052", + "0009-MRKP-053", + "0009-MRKP-054", + "0009-MRKP-055", + "0009-MRKP-056", + "0009-MRKP-110", + "0009-MRKP-111", + "0009-MRKP-112", + "0009-MRKP-113", + "0009-MRKP-114", + "0009-MRKP-115", + "0009-MRKP-116", + "0009-MRKP-117", + "0009-MRKP-118", + "0009-MRKP-119", + "0009-MRKP-120", + "0009-MRKP-121", + "0009-MRKP-122", + "0009-MRKP-123", + "0009-MRKP-124", + "0009-MRKP-125", + "0009-MRKP-126", + "0009-MRKP-127", + "0009-MRKP-130", + "0009-MRKP-131", + "0009-MRKP-132", "0053-PERP-033", "0053-PERP-034", "0053-PERP-035" From 50a66c5150032a355429cd218a8b3ca2917e3b93 Mon Sep 17 00:00:00 2001 From: Gordsport <83510148+gordsport@users.noreply.github.com> Date: Thu, 11 Jan 2024 13:32:21 +0000 Subject: [PATCH 0886/1171] chore: Add ACs from the LP fee setting AC review meeting (#2115) * chore: Add ACs from the LP fee setting AC review meeting This PR adds new ACs from the LP fee setting AC review meeting. * fix: add codes to features.json * fix: add AC clarification * fix: wording from review comment Co-authored-by: David Siska <62546419+davidsiska-vega@users.noreply.github.com> * fix: fill in value --------- Co-authored-by: David Siska <62546419+davidsiska-vega@users.noreply.github.com> --- protocol/0042-LIQF-setting_fees_and_rewarding_lps.md | 7 ++++++- protocol/features.json | 10 +++++++++- 2 files changed, 15 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 22053904d..038d529b1 100644 --- a/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md +++ b/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md @@ -351,9 +351,14 @@ Each LP further gets a performance bonus: $b_i \times B$ with a transfer type th - Liquidity fee factors are recalculated every time the liquidity demand estimate changes. (0042-LIQF-005) - 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) -- A market can be proposed with a choice of liquidity fee settings. These settings can be updated by a subsequent market update proposal. (0042-LIQF-056) +- A market can be proposed with a choice of liquidity fee settings. These settings can be updated by a subsequent market update proposal. Moreover, the correct fee value and liquidity fee setting method can be read from the data node APIs. As liquidity fee factor only changes at the epoch boundary the API reports the current and upcoming value. The tests should be carried out with the following methods: + - Weighted average (0042-LIQF-056) + - Constant fee (0042-LIQF-061) + - Marginal cost (0042-LIQF-062) - The above example for the liquidity fee when the method is weighted-average results in a fee-factor of 1.5% (0042-LIQF-057) - The above example for the liquidity fee when the method is constant-fee results in a fee-factor of 0.8% (0042-LIQF-058) +- The above example for the liquidity fee when the method is marginal cost results in a fee-factor of `3.75%` (0042-LIQF-059) +- For the constant-fee method validate that the fee factor can only be between 0 and 1 inclusive (0042-LIQF-060) ### CHANGE OF NETWORK PARAMETERS TESTS diff --git a/protocol/features.json b/protocol/features.json index 2867adc0c..1bc7d475d 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -273,7 +273,15 @@ }, "Liquidity fee setting": { "milestone": "palazzo", - "acs": ["0042-LIQF-056", "0042-LIQF-057", "0042-LIQF-058"] + "acs": [ + "0042-LIQF-056", + "0042-LIQF-057", + "0042-LIQF-058", + "0042-LIQF-059", + "0042-LIQF-060", + "0042-LIQF-061", + "0042-LIQF-062" + ] }, "Governance market name change": { "milestone": "palazzo", From 5636b9c089ec275c17240701c6c11ac8581826fb Mon Sep 17 00:00:00 2001 From: David Siska <62546419+davidsiska-vega@users.noreply.github.com> Date: Fri, 12 Jan 2024 08:56:18 +0000 Subject: [PATCH 0887/1171] fix: liq fee setting method market update --- 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 038d529b1..d1154ebd9 100644 --- a/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md +++ b/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md @@ -351,7 +351,7 @@ Each LP further gets a performance bonus: $b_i \times B$ with a transfer type th - Liquidity fee factors are recalculated every time the liquidity demand estimate changes. (0042-LIQF-005) - 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) -- A market can be proposed with a choice of liquidity fee settings. These settings can be updated by a subsequent market update proposal. Moreover, the correct fee value and liquidity fee setting method can be read from the data node APIs. As liquidity fee factor only changes at the epoch boundary the API reports the current and upcoming value. The tests should be carried out with the following methods: +- A market can be proposed with a choice of liquidity fee settings. These settings can be updated by a subsequent market update proposal. Moreover, the correct fee value and liquidity fee setting method can be read from the data node APIs. Upon proposal enactment the new liquidity method is applied to recalculate the liquidity fee. The tests should be carried out with the following methods: - Weighted average (0042-LIQF-056) - Constant fee (0042-LIQF-061) - Marginal cost (0042-LIQF-062) From 3197d03138110770af42f1e6ddc6e32650c97971 Mon Sep 17 00:00:00 2001 From: Gordsport <83510148+gordsport@users.noreply.github.com> Date: Fri, 12 Jan 2024 09:18:11 +0000 Subject: [PATCH 0888/1171] chore: comment out the cosmic-carryover (#2120) * chore: comment out the cosmic-carryover This comments out the cosmic carry over ACs so that the approbation stats reflect just the palazzo ACs * fix: syntax error --- protocol/cosmic-features.json | 16 ++++++++++++++++ protocol/features.json | 16 ---------------- 2 files changed, 16 insertions(+), 16 deletions(-) diff --git a/protocol/cosmic-features.json b/protocol/cosmic-features.json index c4e898b64..571708e67 100644 --- a/protocol/cosmic-features.json +++ b/protocol/cosmic-features.json @@ -923,5 +923,21 @@ "Unknown": { "milestone": "unknown", "acs": [] + }, + "Iceberg Orders": { + "milestone": "cosmic-carryover", + "acs": ["0014-ORDT-069"] + }, + "Successor Markets": { + "milestone": "cosmic-carryover", + "acs": ["0001-MKTF-008"] + }, + "Ethereum oracles": { + "milestone": "cosmic-carryover", + "acs": ["0082-ETHD-035", "0082-ETHD-041"] + }, + "Stop Orders": { + "milestone": "cosmic-carryover", + "acs": ["0079-TGAP-004", "0079-TGAP-005", "0014-ORDT-132", "0014-ORDT-133", "0014-ORDT-134", "0014-ORDT-135", "0014-ORDT-136"] } } diff --git a/protocol/features.json b/protocol/features.json index 1bc7d475d..9291220a7 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -1,20 +1,4 @@ { - "Iceberg Orders": { - "milestone": "cosmic-carryover", - "acs": ["0014-ORDT-069"] - }, - "Successor Markets": { - "milestone": "cosmic-carryover", - "acs": ["0001-MKTF-008"] - }, - "Ethereum oracles": { - "milestone": "cosmic-carryover", - "acs": ["0082-ETHD-035", "0082-ETHD-041"] - }, - "Stop Orders": { - "milestone": "cosmic-carryover", - "acs": ["0079-TGAP-004", "0079-TGAP-005", "0014-ORDT-132", "0014-ORDT-133", "0014-ORDT-134", "0014-ORDT-135", "0014-ORDT-136"] - }, "Perpetuals": { "milestone": "palazzo", "acs": [ From acddc980b17330ffde9fdae0204a066fe9375269 Mon Sep 17 00:00:00 2001 From: Sohill-Patel <85170301+Sohill-Patel@users.noreply.github.com> Date: Thu, 11 Jan 2024 09:12:09 +0000 Subject: [PATCH 0889/1171] feat: more validation acs --- protocol/0009-MRKP-mark_price.md | 12 +++++++++++- protocol/features.json | 7 ++++++- 2 files changed, 17 insertions(+), 2 deletions(-) diff --git a/protocol/0009-MRKP-mark_price.md b/protocol/0009-MRKP-mark_price.md index 5d0a63bdc..86a7edf7e 100644 --- a/protocol/0009-MRKP-mark_price.md +++ b/protocol/0009-MRKP-mark_price.md @@ -95,6 +95,10 @@ Note that for calculating the median with an even number of entries we sort, pic - Set price type to "median", only have data source available from "Trade-size-weighted average price" and "Leverage-notional book price" and 1 trade at 15920, and 1 trade at 15940, move time, and check stale price should not be included (0009-MRKP-034) and a perps market (0009-MRKP-035) +- A market can be configured with `markPriceConfiguration: price type` is `Weighted` without oracles (0009-MRKP-060) + +- A market can be configured with `markPriceConfiguration: price type` is `Median` without oracles (0009-MRKP-061) + ### Validation - Boundary values are respected for the market parameters @@ -105,7 +109,7 @@ Note that for calculating the median with an even number of entries we sort, pic - `markPriceConfiguration: cashAmount` valid values: `>=0`(0009-MRKP-052) - - `markPriceConfiguration: source weight` valid values: `[0,1]`(0009-MRKP-053) + - `markPriceConfiguration: source weight` valid values: `>=0`(0009-MRKP-053) - `markPriceConfiguration: source staleness tolerance` valid values: `valid duration string, e.g. "5s", "24h"`(0009-MRKP-054) @@ -113,6 +117,12 @@ Note that for calculating the median with an even number of entries we sort, pic - `markPriceConfiguration: source weight` and `markPriceConfiguration: source staleness tolerance` length should be 3 plus number of oracle data sources (0009-MRKP-056) + - When `markPriceConfiguration: price type` is **not** `Last Trade Price`, the `markPriceConfiguration: source staleness tolerance`, `markPriceConfiguration: source weight`, `markPriceConfiguration: decayPower` and `markPriceConfiguration: cashAmount` must be provided + - new market (0009-MRKP-057) + - update market (0009-MRKP-058) + + - When `markPriceConfiguration: source weight` is provided then it must not be all `0` (0009-MRKP-059) + ### Example 1 - A typical path of a cash settled futures market from end of opening auction till expiry (use Algorithm 2 (ie median price))(0009-MRKP-040) 1. Market is in opening auction, no mark price. diff --git a/protocol/features.json b/protocol/features.json index 9291220a7..2c3b36529 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -355,7 +355,12 @@ "0009-MRKP-132", "0053-PERP-033", "0053-PERP-034", - "0053-PERP-035" + "0053-PERP-035", + "0009-MRKP-057", + "0009-MRKP-058", + "0009-MRKP-059", + "0009-MRKP-060", + "0009-MRKP-061" ] }, "Ethereum RPC and EVM based data sources": { From 4042f5a21e6f7b1360a2abebe03aa4dea357c725 Mon Sep 17 00:00:00 2001 From: Gordsport <83510148+gordsport@users.noreply.github.com> Date: Fri, 12 Jan 2024 14:42:09 +0000 Subject: [PATCH 0890/1171] fix: correct the AC requirement to match the correct behaviour (#2111) * fix: correct the AC requirement to match the correct behaviour * feat: corrected ac and added 2 more * fix: duplicated AC codes * fix: json syntax error * fix: Extra AC codes --------- Co-authored-by: Sohill-Patel <85170301+Sohill-Patel@users.noreply.github.com> --- protocol/0019-MCAL-margin_calculator.md | 8 ++++++-- protocol/features.json | 2 ++ 2 files changed, 8 insertions(+), 2 deletions(-) diff --git a/protocol/0019-MCAL-margin_calculator.md b/protocol/0019-MCAL-margin_calculator.md index b0ab2ac54..78e97802e 100644 --- a/protocol/0019-MCAL-margin_calculator.md +++ b/protocol/0019-MCAL-margin_calculator.md @@ -276,7 +276,7 @@ There should be an additional amount `limit price x size x margin factor = 15910 for this market the party switches to cross margin and the market has `market.linearSlippageFactor = 0.25`, `RF short = 0.1` then the maintenance margin for the party is `min(1 x (100 000-159 00), 159 00 x 0.25 x 1) + 0.1 x 1 x 159 00 = 5565` but if `5565 < collatoral release level` the maintenance margin will remain unchanged at `6325` - + the difference topped up from the party’s general account(0019-MCAL-232) - switch to cross margin without position and no orders successful in continuous mode(0019-MCAL-134) @@ -346,7 +346,11 @@ There should be an additional amount `limit price x size x margin factor = 15910 **Check API:** -- For each market and each party which has either orders or positions on the market, the API provides the maintenance margin levels. (0019-MCAL-092) +- For each market and each party which has positions or has switched between margin modes on the market, the API provides the maintenance margin levels. (0019-MCAL-092) + +- For each market and each party which has orders only and no positions or has switched between margin modes on the market + - cross margin to isolated margin, the API provides maintenance margin level of zero. (0019-MCAL-150) + - isolated margin to cross margin, the API provides expected maintenance margin level . (0019-MCAL-151) - For each market and each party which has either orders or positions on the market, the API provides the current margin mode and, when in isolated margin mode, margin factor. (0019-MCAL-143) diff --git a/protocol/features.json b/protocol/features.json index 9291220a7..161d0e704 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -142,6 +142,8 @@ "0019-MCAL-147", "0019-MCAL-148", "0019-MCAL-149", + "0019-MCAL-150", + "0019-MCAL-151", "0019-MCAL-200", "0019-MCAL-201", "0019-MCAL-202", From 65f98e170a50c307362bec73fd0525a13f2c5eb6 Mon Sep 17 00:00:00 2001 From: Gordsport <83510148+gordsport@users.noreply.github.com> Date: Tue, 16 Jan 2024 11:30:58 +0000 Subject: [PATCH 0891/1171] chore: update features.json (#2123) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit In order to have the correct reporting on palazzo AC coverage I have remove some ACs that will NOT be done: insurance pool re-dist:

 0073-LIMN-115 0073-LIMN-116 0073-LIMN-117 perps/sucessor markets: 0015-INSR-005 0081-SUCM-036 We do not support sucessor and perps and we are not supporting LNL --- protocol/features.json | 7 +------ 1 file changed, 1 insertion(+), 6 deletions(-) diff --git a/protocol/features.json b/protocol/features.json index a6885d955..dde5db6a5 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -280,12 +280,7 @@ "0002-STTL-012", "0002-STTL-013", "0013-ACCT-033", - "0015-INSR-005", - "0043-MKTL-010", - "0073-LIMN-115", - "0073-LIMN-116", - "0073-LIMN-117", - "0081-SUCM-036" + "0043-MKTL-010" ] }, "Position Linked Stop-Orders": { From 45385ae23163dd666fff65c37e6311816bdf798a Mon Sep 17 00:00:00 2001 From: gordsport Date: Tue, 9 Jan 2024 17:48:41 +0000 Subject: [PATCH 0892/1171] chore: add branch to quality checks Adds the nebula branch to the quality check git hub actions --- .github/workflows/quality_check.yml | 1 + 1 file changed, 1 insertion(+) diff --git a/.github/workflows/quality_check.yml b/.github/workflows/quality_check.yml index 657a39b8a..bc8042d5a 100644 --- a/.github/workflows/quality_check.yml +++ b/.github/workflows/quality_check.yml @@ -9,6 +9,7 @@ name: "Quality checks" - master - cosmicelevator - palazzo + - nebula env: GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} From 783ed703e9d295f8f58a0068e5b85fd046311f43 Mon Sep 17 00:00:00 2001 From: Tom Date: Wed, 10 Jan 2024 20:30:26 +0800 Subject: [PATCH 0893/1171] feat: Adding market tags proposal spec (#2103) --------- Co-authored-by: Gordsport <83510148+gordsport@users.noreply.github.com> --- .github/workflows/quality_check.yml | 2 +- makefile | 2 +- protocol/0001-MKTF-market_framework.md | 1 + protocol/0028-GOVE-governance.md | 43 +++++++++++++++++++++++++- protocol/nebula-features.json | 30 ++++++++++++++++++ 5 files changed, 75 insertions(+), 3 deletions(-) create mode 100644 protocol/nebula-features.json diff --git a/.github/workflows/quality_check.yml b/.github/workflows/quality_check.yml index bc8042d5a..c4869cb04 100644 --- a/.github/workflows/quality_check.yml +++ b/.github/workflows/quality_check.yml @@ -77,4 +77,4 @@ jobs: - name: "Run Check Features" run: | - npx github:vegaprotocol/approbation check-features --specs="{./non-protocol-specs/**/*.md,./protocol/**/*.md,./protocol/**/*.ipynb}" --features="./protocol/features.json" + npx github:vegaprotocol/approbation check-features --specs="{./non-protocol-specs/**/*.md,./protocol/**/*.md,./protocol/**/*.ipynb}" --features="./protocol/nebula-features.json" diff --git a/makefile b/makefile index ae9bcacd0..f2bc609ae 100644 --- a/makefile +++ b/makefile @@ -64,7 +64,7 @@ spellcheck: # Checks for duplicated ACs in the features.json file .PHONY: check-features check-features: - npx github:vegaprotocol/approbation check-features --specs="{./non-protocol-specs/**/*.md,./protocol/**/*.md,./protocol/**/*.ipynb}" --features="./protocol/features.json" + npx github:vegaprotocol/approbation check-features --specs="{./non-protocol-specs/**/*.md,./protocol/**/*.md,./protocol/**/*.ipynb}" --features="./protocol/nebula-features.json" clean: rm -rf $(TEMP) diff --git a/protocol/0001-MKTF-market_framework.md b/protocol/0001-MKTF-market_framework.md index 1f4bc30d5..5f16a0699 100644 --- a/protocol/0001-MKTF-market_framework.md +++ b/protocol/0001-MKTF-market_framework.md @@ -80,6 +80,7 @@ Data: - **Name:** full and fairly descriptive name for the instrument. - **Metadata fields:** A series of arbitrary strings that can be used in clients - **Product:** a reference to or instance of a fully specified product, including all required product parameters for that product. +- **Community Tags:** A list of string community tags assigning the market to certain categories. Each of these is a free text field of a network parameter defined maximum length. These are managed through a separate proposal type and cannot be set at market creation or changed in a normal market update proposal. ## Product diff --git a/protocol/0028-GOVE-governance.md b/protocol/0028-GOVE-governance.md index d29c11836..c4aba128b 100644 --- a/protocol/0028-GOVE-governance.md +++ b/protocol/0028-GOVE-governance.md @@ -249,6 +249,32 @@ The following are immutable and cannot be changed: - position decimal places - `settlementAsset` +### 2.1 Change community tags + +Separately to a general market change proposal, proposers can create a proposal to add or remove lists of free-text string community tags to a market. Although these proposals change only a single market, it is possible that these tags will be used to control external behaviour of systems interacting with the vega chain, therefore they do not allow for voting using ELS and instead must be voted through by the general pool of token holders as with any other proposal. The maximum length of a community tags is specified by the network parameter `governance.proposal.market.maxCommunityTagLength`. The community tags on a market are controlled by a single proposal type, `UpdateCommunityTags` with a structure akin to: + +```proto +message UpdateCommunityTags { + string marketId; + repeated string addTags; + repeated string removeTags; +} +``` + +allowing proposals to add and remove tags independently from others. + +The following network parameters will decide how these proposals are treated: +`governance.proposal.updateCommunityTags.maxClose` e.g. `720h`, +`governance.proposal.updateCommunityTags.minClose` e,g. `168h`, +`governance.proposal.updateCommunityTags.maxEnact` e.g. `720h`, +`governance.proposal.updateCommunityTags.minEnact` e,g. `168h`, +`governance.proposal.updateCommunityTags.minProposerBalance` e.g. `1000000000000000000` i.e. 1 VEGA, +`governance.proposal.updateCommunityTags.minVoterBalance` e.g. `1000000000000000000` i.e. 1 VEGA, +`governance.proposal.updateCommunityTags.requiredMajority` e.g. `0.66`, +`governance.proposal.updateCommunityTags.requiredParticipation` e.g. `0.05`. + +Note: Although community tags cannot be amended in an update market proposal, they may be included in the same batch proposal as one. + ## 3. Change network parameters [Network parameters](./0054-NETP-network_parameters.md) that may be changed are described in the _Network Parameters_ spec, this document for details on these parameters, including the category of the parameters. New network parameters require a code change, so there is no support for adding new network parameters. @@ -708,9 +734,10 @@ It is NOT possible to submit a governance proposal where the source account is t 1. volume discount program, 1. referral program, 1. governance transfer, + 1. a community tags proposal can be submitted, voted through and each proposal enacted. -On top of that signed bundles for changing withdrawal delay and threshold on the bridge are emitted (0028-GOVE-160) +On top of that signed bundles for changing withdrawal delay and threshold on the bridge are emitted (0028-GOVE-177) - A batch proposal can be submitted changing the same network parameter twice to two different values with two different enactment timestamps. The voting to approve the batch happens, the batch passes, both changes are observed at the desired time. (0028-GOVE-161) @@ -726,3 +753,17 @@ The voting to approve the batch happens, the batch passes, the value of the prop ##### 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) + +##### Community Market Tags + +- A proposal to add community tags to a market can be successfully submitted. (0028-GOVE-167) + - When that proposal is approved and enacted the community tags are immediately added to that market's community tags property. (0028-GOVE-168) +- A proposal to remove community tags from a market can be successfully submitted. (0028-GOVE-169) + - When that proposal is approved and enacted the community tags are immediately removed from that market's community tags property. (0028-GOVE-170) +- A proposal to add some and remove other community tags from a market can be successfully submitted. (0028-GOVE-171) + - When that proposal is approved and enacted the community tags are immediately removed and added to that market's community tags property. (0028-GOVE-172) +- Neither market creation nor market update proposals can change the community tags property on a market. (0028-GOVE-173) +- A voter's equity-like share does not give them any additional voting weight when voting on a market community tags update proposal. (0028-GOVE-174) +- A proposal to add community tags with any community tags longer than `governance.proposal.market.maxCommunityTagLength` is rejected as invalid (0028-GOVE-175) +- A proposal to remove community tags with any community tags longer than `governance.proposal.market.maxCommunityTagLength` is rejected as invalid (0028-GOVE-176) + diff --git a/protocol/nebula-features.json b/protocol/nebula-features.json new file mode 100644 index 000000000..9b201a88e --- /dev/null +++ b/protocol/nebula-features.json @@ -0,0 +1,30 @@ +{ + "TBC": { + "milestone": "cosmic-carryover", + "acs": [] + }, + "TBC": { + "milestone": "palazzo-carryover", + "acs": [] + }, + "Community Tags": { + "milestone": "nebula", + "acs": [ + "0028-GOVE-167", + "0028-GOVE-168", + "0028-GOVE-169", + "0028-GOVE-170", + "0028-GOVE-171", + "0028-GOVE-172", + "0028-GOVE-173", + "0028-GOVE-174", + "0028-GOVE-175", + "0028-GOVE-176", + "0028-GOVE-177" + ] + }, + "Unknown": { + "milestone": "unknown", + "acs": [] + } +} From 1ac48666e05929c1463c86e6f3faf5d041748a04 Mon Sep 17 00:00:00 2001 From: Gordsport <83510148+gordsport@users.noreply.github.com> Date: Tue, 16 Jan 2024 21:37:38 +0000 Subject: [PATCH 0894/1171] chore: split AC code 056 into 3 (#2126) Splits the AC code 056 into 3 parts and adds one new AC. All to be done as system tests --- protocol/0009-MRKP-mark_price.md | 10 ++++++++-- protocol/features.json | 21 ++++++++++++--------- 2 files changed, 20 insertions(+), 11 deletions(-) diff --git a/protocol/0009-MRKP-mark_price.md b/protocol/0009-MRKP-mark_price.md index 86a7edf7e..dbc84429b 100644 --- a/protocol/0009-MRKP-mark_price.md +++ b/protocol/0009-MRKP-mark_price.md @@ -115,12 +115,18 @@ Note that for calculating the median with an even number of entries we sort, pic - `markPriceConfiguration: source weight` and `markPriceConfiguration: source staleness tolerance` should have the same length(0009-MRKP-055) - - `markPriceConfiguration: source weight` and `markPriceConfiguration: source staleness tolerance` length should be 3 plus number of oracle data sources (0009-MRKP-056) + - Mark price configuration `source_weight` length should be 3 plus number of oracle data sources if the price type is weighted (0009-MRKP-056). + + - If the mark price type is not weighted the source weight must be empty (0009-MRKP-062). + + - Mark price configuration `source staleness tolerance` length must be 3 plus number of oracle data sources if price type is weighted or median (0009-MRKP-063). + + - If the mark price type is weighted, there must be at least one non zero weight (0009-MRKP-064). - When `markPriceConfiguration: price type` is **not** `Last Trade Price`, the `markPriceConfiguration: source staleness tolerance`, `markPriceConfiguration: source weight`, `markPriceConfiguration: decayPower` and `markPriceConfiguration: cashAmount` must be provided - new market (0009-MRKP-057) - update market (0009-MRKP-058) - + - When `markPriceConfiguration: source weight` is provided then it must not be all `0` (0009-MRKP-059) ### Example 1 - A typical path of a cash settled futures market from end of opening auction till expiry (use Algorithm 2 (ie median price))(0009-MRKP-040) diff --git a/protocol/features.json b/protocol/features.json index dde5db6a5..67ac7bb74 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -320,6 +320,9 @@ "0009-MRKP-030", "0009-MRKP-031", "0009-MRKP-032", + "0053-PERP-033", + "0053-PERP-034", + "0053-PERP-035", "0009-MRKP-040", "0009-MRKP-041", "0009-MRKP-050", @@ -329,6 +332,14 @@ "0009-MRKP-054", "0009-MRKP-055", "0009-MRKP-056", + "0009-MRKP-057", + "0009-MRKP-058", + "0009-MRKP-059", + "0009-MRKP-060", + "0009-MRKP-061", + "0009-MRKP-062", + "0009-MRKP-063", + "0009-MRKP-064", "0009-MRKP-110", "0009-MRKP-111", "0009-MRKP-112", @@ -349,15 +360,7 @@ "0009-MRKP-127", "0009-MRKP-130", "0009-MRKP-131", - "0009-MRKP-132", - "0053-PERP-033", - "0053-PERP-034", - "0053-PERP-035", - "0009-MRKP-057", - "0009-MRKP-058", - "0009-MRKP-059", - "0009-MRKP-060", - "0009-MRKP-061" + "0009-MRKP-132" ] }, "Ethereum RPC and EVM based data sources": { From bd6c942a19dfe03b221ab1d651d4d4c71a0532e1 Mon Sep 17 00:00:00 2001 From: Gordsport <83510148+gordsport@users.noreply.github.com> Date: Wed, 17 Jan 2024 09:18:50 +0000 Subject: [PATCH 0895/1171] chore: adds AC from the isolated margin AC review (#2125) * chore: adds AC from the isolated margin AC review Adds in protocol upgrade AC coverage for isolated margin as per the isolated margin AC review meeting * chore: Update AC to be more clear Co-authored-by: Sohill-Patel <85170301+Sohill-Patel@users.noreply.github.com> --------- Co-authored-by: Sohill-Patel <85170301+Sohill-Patel@users.noreply.github.com> --- protocol/0019-MCAL-margin_calculator.md | 6 ++++++ protocol/features.json | 2 ++ 2 files changed, 8 insertions(+) diff --git a/protocol/0019-MCAL-margin_calculator.md b/protocol/0019-MCAL-margin_calculator.md index 78e97802e..57889e518 100644 --- a/protocol/0019-MCAL-margin_calculator.md +++ b/protocol/0019-MCAL-margin_calculator.md @@ -398,6 +398,12 @@ There should be an additional amount `limit price x size x margin factor = 15910 - Thus, with `margin funding factor = 0.5`, `total margin requirement = futures margin + funding margin = 5565 + 0.5 * max(0, -90 * 1) = 5565` (0019-MCAL-055) - However is position is instead `-1`, with the same margin requirement, if `margin funding factor = 0.5`, `total margin requirement = futures margin + funding margin = 5565 + 0.5 * max(0, -90 * -1) = 5610`(0019-MCAL-056) + +## Acceptance Criteria (Protocol upgrade) + +- All order margin balances are restored after a protocol upgrade (0019-MCAL-152). +- The `margin mode` and `margin factor` of any given party must be preserved after a protocol upgrade (0019-MCAL-153). + ## Summary The *margin calculator* returns the set of margin levels for a given *actual position*, along with the amount of additional margin (if any) required to support the party's *potential position* (i.e. active orders including any that are parked/untriggered/undeployed). diff --git a/protocol/features.json b/protocol/features.json index 67ac7bb74..00f7c5945 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -144,6 +144,8 @@ "0019-MCAL-149", "0019-MCAL-150", "0019-MCAL-151", + "0019-MCAL-152", + "0019-MCAL-153", "0019-MCAL-200", "0019-MCAL-201", "0019-MCAL-202", From 6ef5f6f81ba9cc0c871828e4499c00c2819be778 Mon Sep 17 00:00:00 2001 From: Witold Date: Fri, 12 Jan 2024 15:07:45 +0100 Subject: [PATCH 0896/1171] refactor: update PM --- protocol/0032-PRIM-price_monitoring.md | 24 ++++++++++++++++++------ protocol/nebula-features.json | 5 ++++- 2 files changed, 22 insertions(+), 7 deletions(-) diff --git a/protocol/0032-PRIM-price_monitoring.md b/protocol/0032-PRIM-price_monitoring.md index 306daee1b..3ac8812d9 100644 --- a/protocol/0032-PRIM-price_monitoring.md +++ b/protocol/0032-PRIM-price_monitoring.md @@ -11,6 +11,8 @@ As mentioned above, price monitoring is meant to stop large market movements tha Please see the [auction spec](./0026-AUCT-auctions.md) for auction details. +Price monitoring engine should track mark price evolution within the market. It should be used to monitor trades as well as mark price update candidates. If any of these violates the bounds the market should go into auction and the transaction should get rejected. + ### Note Price monitoring likely won't be the only possible trigger of auction period e.g. governance action could be the other ones. Thus the framework put in place as part of this spec should be flexible enough to easily accommodate other types of triggers. @@ -20,11 +22,13 @@ Likewise, pre-processing transactions will be needed as part of the [fees spec]( ## Guide-level explanation - We need to emit a "significant price change" event if price move over the horizon τ turned out to be more than what the risk model implied at a probability level α. - - Take **arrival price of the next transaction** (the value that will be the last traded price if we process the next transaction): Vt, - - look-up mid-price St-τ, (prices aren't continuous so will need max(Ss : s ≤ t-τ), call it St-τ*, + - Take **arrival price of the next transaction** (the value that will be the last traded price if we process the next transaction or the mark price update value): Vt, + - look-up mark price St-τ, (prices aren't continuous so will need max(Ss : s ≤ t-τ), call it St-τ*, - get the bounds associated with St-τ*, at a probability level α: - if Vt falls within those bounds then transaction is processed in the current trading mode - - otherwise the transaction (along with the rest of order book) needs to be processed via a temporary auction. + - otherwise: + - the incoming aggressive order (along with the rest of order book) needs to be processed via a temporary auction, + - the mark price update value gets discarded and the market goes into auction, the value obtained upon uncrossing the auction (if any) gets used as the next mark price update value. Any other mark price updates arriving during the price monitoring auction get discarded. - We need to have "atomicity" in transaction processing: - When we process transaction we need to check what the arrival price Vt is. - If it results in "significant price change" event then we want the order book to maintain the state from before we started processing the transaction. @@ -73,20 +77,26 @@ There are several reasons why this maximum is enforced. - if no trigger gets activated then the transaction is processed in a regular fashion, otherwise: - the price protection auction commences and the transaction considered should be processed in this way (along with any other orders on the book and pending transactions that are valid for auction). +- Per mark price update: + - when the next mark price update value is received it gets checked against the price monitoring engine, + - price monitoring engine sends back signal informing if the price protection auction should be triggered (and if so how long the auction period should be), + - if no trigger gets activated then the mark price update candidate gets accepted, included in the internal price history tracked by the price monitoring engine and mark-to-market process carries on as usual, otherwise: + - the price protection auction commences, any other mark price update candidates received before the auction ends get discarded, if the auction ends and results in a price than that price gets used as the next mark price, it gets included in the internal price history tracked by the price monitoring engine and the mark-to-market process carries on as usual. + ### View from the price monitoring engine side -Price monitoring engine will interface between the matching engine and the risk model. It will communicate with the matching engine every time a new transaction is processed (to check it its' arrival price should trigger an auction). It will communicate with the risk model with a predefined frequency to inform the risk model of the latest price history and obtain a new set of scaling factors used to calculate min/max prices from the reference price. +Price monitoring engine will interface between the matching engine and the risk model. It will communicate with the matching engine every time a new transaction is processed (to check it its' arrival price should trigger an auction). It will communicate with the risk model with a predefined frequency to inform the risk model of the latest mark price history and obtain a new set of scaling factors used to calculate min/max prices from the reference price. Specifically: -- Price monitoring engine averages (weighted by volume) all the prices received from the matching engine that have the same timestamp. - It periodically (in a predefined, deterministic way) sends the: - the probability level α, - period τ, - the associated reference price 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. +- It holds the history of mark 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. +- Every time a new price is mark price candidate is available 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. 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, @@ -129,3 +139,5 @@ to the risk model and obtains the range of valid up/down price moves per each of - 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) +- For all available mark price calculation methodologies: the price history used by the price monitoring engine is in line with market's mark price history. (0032-PRIM-039) +- For all available mark-price calculation methodologies: the mark price update candidate gets rejected if it violates the price monitoring engine bounds. (0032-PRIM-040) diff --git a/protocol/nebula-features.json b/protocol/nebula-features.json index 9b201a88e..6793c3d46 100644 --- a/protocol/nebula-features.json +++ b/protocol/nebula-features.json @@ -5,7 +5,10 @@ }, "TBC": { "milestone": "palazzo-carryover", - "acs": [] + "acs": [ + "0032-PRIM-039", + "0032-PRIM-040" + ] }, "Community Tags": { "milestone": "nebula", From bcb1422f222e809ac4febf8c6de07c2a04e1e95e Mon Sep 17 00:00:00 2001 From: Gordsport <83510148+gordsport@users.noreply.github.com> Date: Wed, 17 Jan 2024 11:05:43 +0000 Subject: [PATCH 0897/1171] chore Update features.json to add missing AC code (#2127) * chore Update features.json to add missing AC code Adds the following missing AC to the features file: "0087-EVMD-043" * fix: remove "0053-PERP-036", as its a nebula AC --- protocol/features.json | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/protocol/features.json b/protocol/features.json index 00f7c5945..6bdac5936 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -11,7 +11,6 @@ "0053-PERP-025", "0053-PERP-026", "0053-PERP-027", - "0053-PERP-036", "0053-PERP-029", "0053-PERP-030", "0053-PERP-031", @@ -408,7 +407,8 @@ "0087-EVMD-039", "0087-EVMD-040", "0087-EVMD-041", - "0087-EVMD-042" + "0087-EVMD-042", + "0087-EVMD-043" ] }, "Unknown": { From 2cc7a1ef86b03d2ee7e5e654e09487828af2a54f Mon Sep 17 00:00:00 2001 From: Gordsport <83510148+gordsport@users.noreply.github.com> Date: Wed, 17 Jan 2024 11:06:49 +0000 Subject: [PATCH 0898/1171] chore: add AC thats pushed from palazzo milestone (#2128) As per: - https://github.com/vegaprotocol/specs/pull/2127 This adds inthe AC code that cant be tested in palazzo due to the following issue: - https://github.com/vegaprotocol/vega/issues/10360 --- protocol/nebula-features.json | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/protocol/nebula-features.json b/protocol/nebula-features.json index 6793c3d46..24c8e5aa3 100644 --- a/protocol/nebula-features.json +++ b/protocol/nebula-features.json @@ -26,6 +26,10 @@ "0028-GOVE-177" ] }, + "Perpetual funding rates": { + "milestone": "nebula", + "acs": ["0053-PERP-036"] + }, "Unknown": { "milestone": "unknown", "acs": [] From dc5d44d8b2841bd6c21ba97de9da7bbc6d77b339 Mon Sep 17 00:00:00 2001 From: Gordsport <83510148+gordsport@users.noreply.github.com> Date: Wed, 17 Jan 2024 11:45:04 +0000 Subject: [PATCH 0899/1171] chore: add more position stop order AC codes (#2109) * chore: add more position stop order AC codes Adds in ACs from the position stop orders feature AC review * fix: linting checks * fix: review comment --- protocol/0014-ORDT-order_types.md | 8 ++++++-- protocol/features.json | 5 ++++- 2 files changed, 10 insertions(+), 3 deletions(-) diff --git a/protocol/0014-ORDT-order_types.md b/protocol/0014-ORDT-order_types.md index ec5f61486..580f5317b 100644 --- a/protocol/0014-ORDT-order_types.md +++ b/protocol/0014-ORDT-order_types.md @@ -72,7 +72,7 @@ An OCO contains TWO stop order submissions, and must include one in each trigger 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 can be set to have one of three different behaviours at expiry, either triggering one side, triggering the other, or expire without any action. This is configured through the setting of the expiry behaviour on each leg. Setting each leg to trade at expiration will result in the OCO being rejected. - + - The stop order submission wraps a normal order submission. - A stop order submission may have an optional `Size Override`: @@ -355,7 +355,7 @@ In Spot market, for multiple iceberg orders submitted as a batch of orders with - 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) - - An OCO stop order with expiration time `T` with one side set to execute at that time will execute at time `T` if reached without being triggered, with the specified side triggering and the other side cancelling. (0014-ORDT-131) + - An OCO stop order with expiration time `T` with one side set to execute at that time will execute at time `T` if reached without being triggered, with the specified side triggering and the other side cancelling. This must be tested both sides (fall below and rise above). (0014-ORDT-131) - An OCO stop order with expiration time `T` with both sides set to execute at that time will be rejected on submission (0014-ORDT-130) - 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) @@ -388,6 +388,9 @@ In Spot market, for multiple iceberg orders submitted as a batch of orders with - 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) +- A party with a long position enters a buy stop order with position size override and is valid but at the time of trigger it is cancelled then the stop order should be cancelled. (0014-ORDT-137) +- If a stop order is placed with a position_fraction equal to 0.5 and the position size is 5 then the rounding should be equal to 3 (0014-ORDT-138) + ## Stop Orders - Negative Cases @@ -396,6 +399,7 @@ In Spot market, for multiple iceberg orders submitted as a batch of orders with - 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) +- If a stop order is placed with a position_fraction equal to 0 the order should be rejected. (0014-ORDT-139) ## Stop Orders - Snapshots diff --git a/protocol/features.json b/protocol/features.json index 6bdac5936..3d7e9ec78 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -291,7 +291,10 @@ "0014-ORDT-128", "0014-ORDT-129", "0014-ORDT-130", - "0014-ORDT-131" + "0014-ORDT-131", + "0014-ORDT-137", + "0014-ORDT-138", + "0014-ORDT-139" ] }, "Markprice updates": { From 19549e4eb5f36eff77753b72d0cf4d843e42ab2a Mon Sep 17 00:00:00 2001 From: David Siska <62546419+davidsiska-vega@users.noreply.github.com> Date: Wed, 17 Jan 2024 11:51:50 +0000 Subject: [PATCH 0900/1171] fix: reduce ethereum rpc data source flexibility --- protocol/0087-EVMD-eth-rpc-and-evm-data-source.md | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/protocol/0087-EVMD-eth-rpc-and-evm-data-source.md b/protocol/0087-EVMD-eth-rpc-and-evm-data-source.md index bbdf80d26..96e99f1bb 100644 --- a/protocol/0087-EVMD-eth-rpc-and-evm-data-source.md +++ b/protocol/0087-EVMD-eth-rpc-and-evm-data-source.md @@ -35,7 +35,9 @@ In current minimal scope, at proposal validation, check that only change is For later release: A proposal to *remove* a registered Ethereum RPC+EVM compatible chain / L2 must fail at enactment stage if a market is referencing an `EthRpcEvmCompatible` data source. -A proposal for a new market will fail at enactment stage if it's referencing an `EthRpcEvmCompatible` that's not registered. +In current minimal scope: A proposal for a new market will fail at validation stage if it's referencing an `EthRpcEvmCompatible` that's not registered. + +For later release: A proposal for a new market will fail at enactment stage if it's referencing an `EthRpcEvmCompatible` that's not registered. ## Acceptance criteria @@ -64,7 +66,8 @@ A proposal for a new market will fail at enactment stage if it's referencing an ### External Oracles - Validations -- A market proposal that reference an `EthRpcEvmCompatible` that's not active will fail at enactment stage (0087-EVMD-008). +- A new market proposal that reference an `EthRpcEvmCompatible` that's not active will fail at validation stage (0087-EVMD-008) +- A market change proposal that reference an `EthRpcEvmCompatible` that's not active will fail at validation stage (0087-EVMD-043) - Validate if the smart contract address is valid (0087-EVMD-009) - 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 (0087-EVMD-010) - Validations for min / max frequency of listening for events / read a smart contract (0087-EVMD-011) From de5541985e728fcb15bcdb68c1243c68e6339e53 Mon Sep 17 00:00:00 2001 From: David Siska <62546419+davidsiska-vega@users.noreply.github.com> Date: Wed, 17 Jan 2024 11:52:55 +0000 Subject: [PATCH 0901/1171] fix: reduce ethereum rpc data source flexibility --- protocol/0087-EVMD-eth-rpc-and-evm-data-source.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/protocol/0087-EVMD-eth-rpc-and-evm-data-source.md b/protocol/0087-EVMD-eth-rpc-and-evm-data-source.md index 96e99f1bb..f423c3c1d 100644 --- a/protocol/0087-EVMD-eth-rpc-and-evm-data-source.md +++ b/protocol/0087-EVMD-eth-rpc-and-evm-data-source.md @@ -66,8 +66,8 @@ For later release: A proposal for a new market will fail at enactment stage if i ### External Oracles - Validations -- A new market proposal that reference an `EthRpcEvmCompatible` that's not active will fail at validation stage (0087-EVMD-008) -- A market change proposal that reference an `EthRpcEvmCompatible` that's not active will fail at validation stage (0087-EVMD-043) +- A new market proposal that reference an `EthRpcEvmCompatible` that's not active will fail at validation stage (0087-EVMD-008) +- A market change proposal that reference an `EthRpcEvmCompatible` that's not active will fail at validation stage (0087-EVMD-043) - Validate if the smart contract address is valid (0087-EVMD-009) - 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 (0087-EVMD-010) - Validations for min / max frequency of listening for events / read a smart contract (0087-EVMD-011) From 90b8abe695698e7ff8fa876b0bcfad8104701eff Mon Sep 17 00:00:00 2001 From: gordsport Date: Wed, 17 Jan 2024 12:22:01 +0000 Subject: [PATCH 0902/1171] fix: AC code approbation check fail --- protocol/0087-EVMD-eth-rpc-and-evm-data-source.md | 2 +- protocol/features.json | 3 ++- 2 files changed, 3 insertions(+), 2 deletions(-) diff --git a/protocol/0087-EVMD-eth-rpc-and-evm-data-source.md b/protocol/0087-EVMD-eth-rpc-and-evm-data-source.md index f423c3c1d..55b12ffa3 100644 --- a/protocol/0087-EVMD-eth-rpc-and-evm-data-source.md +++ b/protocol/0087-EVMD-eth-rpc-and-evm-data-source.md @@ -67,7 +67,7 @@ For later release: A proposal for a new market will fail at enactment stage if i ### External Oracles - Validations - A new market proposal that reference an `EthRpcEvmCompatible` that's not active will fail at validation stage (0087-EVMD-008) -- A market change proposal that reference an `EthRpcEvmCompatible` that's not active will fail at validation stage (0087-EVMD-043) +- A market change proposal that reference an `EthRpcEvmCompatible` that's not active will fail at validation stage (0087-EVMD-044) - Validate if the smart contract address is valid (0087-EVMD-009) - 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 (0087-EVMD-010) - Validations for min / max frequency of listening for events / read a smart contract (0087-EVMD-011) diff --git a/protocol/features.json b/protocol/features.json index 3d7e9ec78..a7c80aeb2 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -411,7 +411,8 @@ "0087-EVMD-040", "0087-EVMD-041", "0087-EVMD-042", - "0087-EVMD-043" + "0087-EVMD-043", + "0087-EVMD-044" ] }, "Unknown": { From 0e85da9c2ded3e08b6cefa74d8ae3a08fcac62b1 Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Wed, 17 Jan 2024 14:22:46 +0000 Subject: [PATCH 0903/1171] feat: add AC 003 for mark price --- protocol/0009-MRKP-mark_price.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0009-MRKP-mark_price.md b/protocol/0009-MRKP-mark_price.md index dbc84429b..0ff154514 100644 --- a/protocol/0009-MRKP-mark_price.md +++ b/protocol/0009-MRKP-mark_price.md @@ -37,7 +37,7 @@ Note that for calculating the median with an even number of entries we sort, pic - 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) -- If a market mark price is configured in such a way that the mark price methodology hasn't provided a price at the point of uncrossing the opening auction, then the auction uncrossing price is set as the first mark price, regardless of what the mark price methodology says. (0009-MRKP-001) +- If a market mark price is configured in such a way that the mark price methodology hasn't provided a price at the point of uncrossing the opening auction, then the auction uncrossing price is set as the first mark price, regardless of what the mark price methodology says. (0009-MRKP-001) and a perps market (0009-MRKP-003) ### Algorithm 1 (last trade price, excluding network trades) From f63a9f4b0e27441fee32ac5496a1da226e4ca93d Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Wed, 17 Jan 2024 14:24:00 +0000 Subject: [PATCH 0904/1171] chore: update json file --- protocol/features.json | 1 + 1 file changed, 1 insertion(+) diff --git a/protocol/features.json b/protocol/features.json index a7c80aeb2..8158b7152 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -301,6 +301,7 @@ "milestone": "palazzo", "acs": [ "0009-MRKP-001", + "0009-MRKP-003", "0009-MRKP-010", "0009-MRKP-011", "0009-MRKP-012", From 35e4dba523f1fd4024e5378700896380f7ee4b83 Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Thu, 18 Jan 2024 09:52:52 +0000 Subject: [PATCH 0905/1171] feat: update ac 027 --- protocol/0009-MRKP-mark_price.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0009-MRKP-mark_price.md b/protocol/0009-MRKP-mark_price.md index 0ff154514..1982cbb9d 100644 --- a/protocol/0009-MRKP-mark_price.md +++ b/protocol/0009-MRKP-mark_price.md @@ -86,7 +86,7 @@ Note that for calculating the median with an even number of entries we sort, pic - When market is leaving auction (including opening auction and monitoring auction), mark price should be recalculated (0009-MRKP-024) and a perps market (with the oracle source different to that used for the external price in the perps market) (0009-MRKP-025). -- When market is at monitoring auction, book price should be indicative uncrossing price, mark price should be recalculated when the time indicated by the mark price frequency is crossed(0009-MRKP-026) and a perps market (with the oracle source different to that used for the external price in the perps market) (0009-MRKP-027). +- When market is at monitoring auction, book price should be indicative uncrossing price, mark price should only be recalculated when the auction exits from only the last period indicated by `network.markPriceUpdateMaximumFrequency` (0009-MRKP-026) and a perps market (with the oracle source different to that used for the external price in the perps market) (0009-MRKP-027). - It is possible to configure a cash settled futures market to use a weighted average of 1. weighted average of trades over `network.markPriceUpdateMaximumFrequency` and 2. impact of leveraged notional on the order book with the value of USDT `100` and when the book does not have enough volume, then the book price should not be included (0009-MRKP-028) and a perps market (with the oracle source different to that used for the external price in the perps market) (0009-MRKP-029). From 6e6573523ce28c2208cb4583126cdb15096c8095 Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Thu, 18 Jan 2024 09:55:04 +0000 Subject: [PATCH 0906/1171] chore: grammar --- protocol/0009-MRKP-mark_price.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0009-MRKP-mark_price.md b/protocol/0009-MRKP-mark_price.md index 1982cbb9d..dee85a9ed 100644 --- a/protocol/0009-MRKP-mark_price.md +++ b/protocol/0009-MRKP-mark_price.md @@ -86,7 +86,7 @@ Note that for calculating the median with an even number of entries we sort, pic - When market is leaving auction (including opening auction and monitoring auction), mark price should be recalculated (0009-MRKP-024) and a perps market (with the oracle source different to that used for the external price in the perps market) (0009-MRKP-025). -- When market is at monitoring auction, book price should be indicative uncrossing price, mark price should only be recalculated when the auction exits from only the last period indicated by `network.markPriceUpdateMaximumFrequency` (0009-MRKP-026) and a perps market (with the oracle source different to that used for the external price in the perps market) (0009-MRKP-027). +- When market is at monitoring auction, book price should be indicative uncrossing price, mark price should only be recalculated when the auction exits, starting from only the last period indicated by `network.markPriceUpdateMaximumFrequency` (0009-MRKP-026) and a perps market (with the oracle source different to that used for the external price in the perps market) (0009-MRKP-027). - It is possible to configure a cash settled futures market to use a weighted average of 1. weighted average of trades over `network.markPriceUpdateMaximumFrequency` and 2. impact of leveraged notional on the order book with the value of USDT `100` and when the book does not have enough volume, then the book price should not be included (0009-MRKP-028) and a perps market (with the oracle source different to that used for the external price in the perps market) (0009-MRKP-029). From a9f18facaa9c76d5ad7805401f332d2e221c08d6 Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Thu, 18 Jan 2024 10:57:24 +0000 Subject: [PATCH 0907/1171] feat: update initial margin level in isolated margin --- protocol/0019-MCAL-margin_calculator.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0019-MCAL-margin_calculator.md b/protocol/0019-MCAL-margin_calculator.md index 57889e518..77754c337 100644 --- a/protocol/0019-MCAL-margin_calculator.md +++ b/protocol/0019-MCAL-margin_calculator.md @@ -429,7 +429,7 @@ general account from the margin account. 1. **Collateral search level**: when in cross-margin mode, the margin account balance below which the system will seek to recollateralise the margin account back to the initial margin level. -1. **Initial margin**: when in cross-margin mode, the margin account balance initially allocated for the position, and the balance to which the margin account will be returned after collateral search and release, if possible. +1. **Initial margin**: when in cross-margin mode, the margin account balance initially allocated for the position, and the balance to which the margin account will be returned after collateral search and release, if possible. When in isolated margin mode, the margin account balance initially allocates for the position and the balance to which the margin account will not be returned as there is not collateral search and reseach. 1. **Collateral release level**: when in cross-margin mode, the margin account balance above which the system will return collateral from a profitable position to the party's general account for potential use elsewhere. From c44cb28f87ebad689537f68407b5a7dc221e6e31 Mon Sep 17 00:00:00 2001 From: Jiajia-Cui <92106936+Jiajia-Cui@users.noreply.github.com> Date: Thu, 18 Jan 2024 11:08:04 +0000 Subject: [PATCH 0908/1171] chore: grammar Co-authored-by: candida-d <62548908+candida-d@users.noreply.github.com> --- protocol/0019-MCAL-margin_calculator.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0019-MCAL-margin_calculator.md b/protocol/0019-MCAL-margin_calculator.md index 77754c337..620430f45 100644 --- a/protocol/0019-MCAL-margin_calculator.md +++ b/protocol/0019-MCAL-margin_calculator.md @@ -429,7 +429,7 @@ general account from the margin account. 1. **Collateral search level**: when in cross-margin mode, the margin account balance below which the system will seek to recollateralise the margin account back to the initial margin level. -1. **Initial margin**: when in cross-margin mode, the margin account balance initially allocated for the position, and the balance to which the margin account will be returned after collateral search and release, if possible. When in isolated margin mode, the margin account balance initially allocates for the position and the balance to which the margin account will not be returned as there is not collateral search and reseach. +1. **Initial margin**: when in cross-margin mode, the margin account balance initially allocated for the position, and the balance that will be returned to the margin account after collateral search and release, if possible. When in isolated margin mode, the margin account balance initially allocated for the position. The balance will not be returned to the margin account while the position is open, as there is no collateral search and reseach. 1. **Collateral release level**: when in cross-margin mode, the margin account balance above which the system will return collateral from a profitable position to the party's general account for potential use elsewhere. From 7f3648c11c628a15c9e2d58ee7f066f523142e9c Mon Sep 17 00:00:00 2001 From: Jiajia-Cui <92106936+Jiajia-Cui@users.noreply.github.com> Date: Thu, 18 Jan 2024 11:10:32 +0000 Subject: [PATCH 0909/1171] chore: typo Co-authored-by: candida-d <62548908+candida-d@users.noreply.github.com> --- protocol/0019-MCAL-margin_calculator.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0019-MCAL-margin_calculator.md b/protocol/0019-MCAL-margin_calculator.md index 620430f45..37d07545d 100644 --- a/protocol/0019-MCAL-margin_calculator.md +++ b/protocol/0019-MCAL-margin_calculator.md @@ -429,7 +429,7 @@ general account from the margin account. 1. **Collateral search level**: when in cross-margin mode, the margin account balance below which the system will seek to recollateralise the margin account back to the initial margin level. -1. **Initial margin**: when in cross-margin mode, the margin account balance initially allocated for the position, and the balance that will be returned to the margin account after collateral search and release, if possible. When in isolated margin mode, the margin account balance initially allocated for the position. The balance will not be returned to the margin account while the position is open, as there is no collateral search and reseach. +1. **Initial margin**: when in cross-margin mode, the margin account balance initially allocated for the position, and the balance that will be returned to the margin account after collateral search and release, if possible. When in isolated margin mode, the margin account balance initially allocated for the position. The balance will not be returned to the margin account while the position is open, as there is no collateral search and release. 1. **Collateral release level**: when in cross-margin mode, the margin account balance above which the system will return collateral from a profitable position to the party's general account for potential use elsewhere. From 9b627680424d9f5ea22d20a164f3bdfcde39f7b5 Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Thu, 18 Jan 2024 14:29:38 +0000 Subject: [PATCH 0910/1171] feat: change tau scaling bound --- protocol/0034-PROB-prob_weighted_liquidity_measure.ipynb | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0034-PROB-prob_weighted_liquidity_measure.ipynb b/protocol/0034-PROB-prob_weighted_liquidity_measure.ipynb index 69ad2b8db..e333fc23b 100644 --- a/protocol/0034-PROB-prob_weighted_liquidity_measure.ipynb +++ b/protocol/0034-PROB-prob_weighted_liquidity_measure.ipynb @@ -15,7 +15,7 @@ "This gives view of liquidity at one instant of time; we then use exponential weighted average over time to obtain the desired measure.\n", "\n", "## Inputs\n", - "- network parameter `market.liquidity.probabilityOfTrading.tau.scaling` which has to be $\\geq 1$.\n", + "- network parameter `market.liquidity.probabilityOfTrading.tau.scaling` which has to be $>0$.\n", "- risk model for the market but with $\\tau$ (`tau`) replaced with `market.liquidity.probabilityOfTrading.tau.scaling x tau`.\n", "- order book volume\n", "\n", From b56913538e1ee5c44dea8e02e2a14b3dc401e3a2 Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Thu, 18 Jan 2024 14:54:54 +0000 Subject: [PATCH 0911/1171] feat: update bound --- protocol/0034-PROB-prob_weighted_liquidity_measure.ipynb | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0034-PROB-prob_weighted_liquidity_measure.ipynb b/protocol/0034-PROB-prob_weighted_liquidity_measure.ipynb index e333fc23b..15bb53609 100644 --- a/protocol/0034-PROB-prob_weighted_liquidity_measure.ipynb +++ b/protocol/0034-PROB-prob_weighted_liquidity_measure.ipynb @@ -15,7 +15,7 @@ "This gives view of liquidity at one instant of time; we then use exponential weighted average over time to obtain the desired measure.\n", "\n", "## Inputs\n", - "- network parameter `market.liquidity.probabilityOfTrading.tau.scaling` which has to be $>0$.\n", + "- network parameter `market.liquidity.probabilityOfTrading.tau.scaling` which has to be $>10^{-4}$.\n", "- risk model for the market but with $\\tau$ (`tau`) replaced with `market.liquidity.probabilityOfTrading.tau.scaling x tau`.\n", "- order book volume\n", "\n", From 43a65b2c49fdada5e2da2105929fcfc900e5166b Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Thu, 18 Jan 2024 15:00:46 +0000 Subject: [PATCH 0912/1171] feat: update probability of trading in LP score --- 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 d1154ebd9..b0e24f767 100644 --- a/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md +++ b/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md @@ -220,7 +220,7 @@ An existing LP has `average entry valuation 1090.9` and `S=110`. Currently the s 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. -For orders outside the tightest price monitoring bounds set probability of trading to 0. +For orders outside the tightest price monitoring bounds set probability of trading to 0. For orders which have less than 10% [probability of trading], we set the probability to 0 when calculating liquidity score. 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: From d10b7e4e26cfed587f74e4251fc8c704c548aaae Mon Sep 17 00:00:00 2001 From: Jiajia-Cui <92106936+Jiajia-Cui@users.noreply.github.com> Date: Thu, 18 Jan 2024 15:37:01 +0000 Subject: [PATCH 0913/1171] chore: address comment Co-authored-by: David Siska <62546419+davidsiska-vega@users.noreply.github.com> --- protocol/0034-PROB-prob_weighted_liquidity_measure.ipynb | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0034-PROB-prob_weighted_liquidity_measure.ipynb b/protocol/0034-PROB-prob_weighted_liquidity_measure.ipynb index 15bb53609..e333fc23b 100644 --- a/protocol/0034-PROB-prob_weighted_liquidity_measure.ipynb +++ b/protocol/0034-PROB-prob_weighted_liquidity_measure.ipynb @@ -15,7 +15,7 @@ "This gives view of liquidity at one instant of time; we then use exponential weighted average over time to obtain the desired measure.\n", "\n", "## Inputs\n", - "- network parameter `market.liquidity.probabilityOfTrading.tau.scaling` which has to be $>10^{-4}$.\n", + "- network parameter `market.liquidity.probabilityOfTrading.tau.scaling` which has to be $>0$.\n", "- risk model for the market but with $\\tau$ (`tau`) replaced with `market.liquidity.probabilityOfTrading.tau.scaling x tau`.\n", "- order book volume\n", "\n", From eaa35bbf093d76a1b33c39a1e987f2c2bf8a5727 Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Thu, 18 Jan 2024 15:42:03 +0000 Subject: [PATCH 0914/1171] chore: markdown --- 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 b0e24f767..d489bff6b 100644 --- a/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md +++ b/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md @@ -220,7 +220,7 @@ An existing LP has `average entry valuation 1090.9` and `S=110`. Currently the s 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. -For orders outside the tightest price monitoring bounds set probability of trading to 0. For orders which have less than 10% [probability of trading], we set the probability to 0 when calculating liquidity score. +For orders outside the tightest price monitoring bounds set probability of trading to 0. For orders which have less than 10% [probability of trading], we set the probability to 0 when calculating liquidity score. 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: From a5f5504a929c91dc6abefb390353e97074388e0e Mon Sep 17 00:00:00 2001 From: Gordsport <83510148+gordsport@users.noreply.github.com> Date: Thu, 18 Jan 2024 16:51:28 +0000 Subject: [PATCH 0915/1171] chore: descope AC 0053-PERP-035 from Palazzo (#2135) based on a research / protocol design discussion this PR descopes AC 0053-PERP-035 from Palazzo --- protocol/0053-PERP-product_builtin_perpetual_future.md | 2 +- protocol/features.json | 1 - 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/protocol/0053-PERP-product_builtin_perpetual_future.md b/protocol/0053-PERP-product_builtin_perpetual_future.md index 80cf91914..703daad3f 100644 --- a/protocol/0053-PERP-product_builtin_perpetual_future.md +++ b/protocol/0053-PERP-product_builtin_perpetual_future.md @@ -349,7 +349,7 @@ It is possible to create a perpetual futures market which uses the last traded p It is possible to create a perpetual futures market which uses an oracle source (same as that used for funding) for the mark price determining the mark-to-market cashflows and that uses "impact volume of notional of 1000 USDT" for the purpose of calculating the TWAP of the market price for funding payments (0053-PERP-034). -It is possible to create a perpetual futures market which uses an oracle source (same as that used for funding) for the mark price determining the mark-to-market cashflows and that uses "time-weighted trade prices in over `network.markPriceUpdateMaximumFrequency` if these have been updated within the last 30s but falls back onto impact volume of notional of 1000 USDT" for the purpose of calculating the TWAP of the market price for funding payments (0053-PERP-035). +It is possible to create a perpetual futures market which uses an oracle source (same as that used for funding) for the mark price determining the mark-to-market cashflows and that uses "time-weighted trade prices in over `network.markPriceUpdateMaximumFrequency` if these have been updated within the last 30s but falls back onto impact volume of notional of 1000 USDT" for the purpose of calculating the TWAP of the market price for funding payments (0053-NEBULA-035). When funding payments are due to the network party they are paid into the market insurance pool (0053-PERP-037). diff --git a/protocol/features.json b/protocol/features.json index 8158b7152..0e6103828 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -327,7 +327,6 @@ "0009-MRKP-032", "0053-PERP-033", "0053-PERP-034", - "0053-PERP-035", "0009-MRKP-040", "0009-MRKP-041", "0009-MRKP-050", From f00473d91b0e16fabf8e88e9490b9aec076d004a Mon Sep 17 00:00:00 2001 From: Pete Barrow Date: Fri, 19 Jan 2024 10:53:33 +0000 Subject: [PATCH 0916/1171] fix: Updating AC to cover wrong side stop orders being rejected --- 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 580f5317b..4f08ab588 100644 --- a/protocol/0014-ORDT-order_types.md +++ b/protocol/0014-ORDT-order_types.md @@ -388,7 +388,6 @@ In Spot market, for multiple iceberg orders submitted as a batch of orders with - 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) -- A party with a long position enters a buy stop order with position size override and is valid but at the time of trigger it is cancelled then the stop order should be cancelled. (0014-ORDT-137) - If a stop order is placed with a position_fraction equal to 0.5 and the position size is 5 then the rounding should be equal to 3 (0014-ORDT-138) @@ -400,6 +399,7 @@ In Spot market, for multiple iceberg orders submitted as a batch of orders with - GFA Stop orders submitted are rejected. (0014-ORDT-077) - Stop orders once triggered can not be cancelled. (0014-ORDT-078) - If a stop order is placed with a position_fraction equal to 0 the order should be rejected. (0014-ORDT-139) +- A party with a long position cannot enter a buy stop order, and a party with a short position cannot enter a sell stop order (0014-ORDT-137) ## Stop Orders - Snapshots From 9cb45b6ea5866bfc2be09dcc3f7707e27242063d Mon Sep 17 00:00:00 2001 From: Charlie Date: Tue, 23 Jan 2024 10:24:51 +0000 Subject: [PATCH 0917/1171] feat: add party profile feature --- protocol/0062-SPAM-spam_protection.md | 13 ++++++++++ protocol/0088-PPRF-party_profile.md | 37 +++++++++++++++++++++++++++ protocol/features.json | 10 +++++++- 3 files changed, 59 insertions(+), 1 deletion(-) create mode 100644 protocol/0088-PPRF-party_profile.md diff --git a/protocol/0062-SPAM-spam_protection.md b/protocol/0062-SPAM-spam_protection.md index 938b1f93d..fce3680e4 100644 --- a/protocol/0062-SPAM-spam_protection.md +++ b/protocol/0062-SPAM-spam_protection.md @@ -69,6 +69,16 @@ To avoid spamming of `ApplyReferralCode`, a party must meet the deposited funds 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`). +### Party Profile spam + +The [party profile feature](./0088-PPRF-party_profile.md) adds a transaction types which can be submitted with no cost/risk to the party: + +- `UpdatePartyProfile` + +To avoid spamming of `UpdatePartyProfile`, a party must meet the deposited funds threshold set by the network parameter `spam.protection.updatePartyProfile.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 the transaction type (`spam.protection.max.updatePartyProfile`). + ### Related topics - [Spam protection: Proof of work](https://github.com/vegaprotocol/specs/blob/master/protocol/0072-SPPW-spam-protection-PoW.md) @@ -104,6 +114,9 @@ More than 360 delegation changes in one epoch (or, respectively, the value of `s - 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 **pre-block** rejected (0062-SPAM-034). - 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 **pre-block** rejected (0062-SPAM-036). +- Given longer than `spam.protection.balanceSnapshotFrequency` has elapsed since a party deposited or transferred funds, a party who has less then `spam.protection.updatePartyProfile.min.funds` in their accounts should have any `UpdatePartyProfile` transactions **pre-block** rejected. All assets count towards this threshold and balances should be scaled appropriately by the assets quantum. (0062-SPAM-037). +- A party who has submitted strictly more than `spam.protection.max.updatePartyProfile` `UpdatePartyProfile` transactions in an epoch should have any future `UpdatePartyProfile` transactions in that epoch **pre-block** rejected (0062-SPAM-038). +- A party who has submitted more than `spam.protection.max.updatePartyProfile` `UpdatePartyProfile` transactions in the current epoch plus in the current block, should have their `UpdatePartyProfile` transactions submitted in the current block **pre-block** rejected (0062-SPAM-039). > **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/0088-PPRF-party_profile.md b/protocol/0088-PPRF-party_profile.md new file mode 100644 index 000000000..4af6765db --- /dev/null +++ b/protocol/0088-PPRF-party_profile.md @@ -0,0 +1,37 @@ +# On-chain Party Profile + +The on-chain party profile feature allows users to associate a unique alias and free-form metadata with a public key they own. This data is stored on-chain and is exposed to anyone through APIs. + + +## Updating a party profile + +Any user with a public key is able to update their party profile by submitting a signed `UpdatePartyProfile` transaction. + +To prevent spam attacks, the number of transactions which can be sent in an epoch per party is restricted and a parties total balance across all assets (expressed in quantum) must exceed `spam.protection.updatePartyProfile.min.funds`. Refer to the [spam protection specification](./0062-SPAM-spam_protection.md#party-profile-spam) for further details on these restrictions. + +An `UpdatePartyProfile` has the following fields. + +- `alias`: an optional string which can be as an alternative identifier for the public key in any dApp (e.g. in competition leaderboards). +- `metadata`: an optional list of metadata key value pairs to further describe a public key. + +If metadata is specified, the metadata must adhere to the following rules: + +- no more than 10 key value pairs can be specified +- a key must be no longer than 33 characters +- a value must be no longer than 256 characters + +If an alias is specified, it must adhere to the following rules: + +- the alias must be no longer than 32 characters +- the alias must be unique (i.e. the alias must not already be associated with an existing party profile) + +**Note:** +In order to validate uniqueness of an alias, core must keep a record of the aliases associated with each party. If a party is no longer active. + +### Acceptance Criteria + +- If a party updates there profile with an alias of a length greater than 32 characters, the transaction is rejected. (0088-PPRF-001) +- If a party updates there profile with an alias which is already associated with another key, the transaction is rejected. (0088-PPRF-002) +- If a party update there profile with metadata with more then 10 key pairs, the transaction is rejected. (0088-PPRF-003) +- If a party update there profile with metadata with a key of a length more than 33 characters, the transaction is rejected. (0088-PPRF-004) +- If a party update there profile with metadata with a value of a length more than 256 characters, the transaction is rejected. (0088-PPRF-005) diff --git a/protocol/features.json b/protocol/features.json index 0e6103828..808b4b74c 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -47,7 +47,15 @@ "0083-RFPR-064", "0083-RFPR-065", "0083-RFPR-066", - "0083-RFPR-067" + "0083-RFPR-067", + "0088-PPRF-001", + "0088-PPRF-002", + "0088-PPRF-003", + "0088-PPRF-004", + "0088-PPRF-005", + "0062-SPAM-037", + "0062-SPAM-038", + "0062-SPAM-039" ] }, "Fixed size amendments": { From 6c3f548c773cd1344d55d76e987e1330ae70d03f Mon Sep 17 00:00:00 2001 From: Charlie Date: Tue, 23 Jan 2024 10:25:41 +0000 Subject: [PATCH 0918/1171] feat: add anti alias squatting feature --- protocol/0088-PPRF-party_profile.md | 7 +++++++ protocol/features.json | 1 + 2 files changed, 8 insertions(+) diff --git a/protocol/0088-PPRF-party_profile.md b/protocol/0088-PPRF-party_profile.md index 4af6765db..633b075bb 100644 --- a/protocol/0088-PPRF-party_profile.md +++ b/protocol/0088-PPRF-party_profile.md @@ -28,6 +28,12 @@ If an alias is specified, it must adhere to the following rules: **Note:** In order to validate uniqueness of an alias, core must keep a record of the aliases associated with each party. If a party is no longer active. +### Alias Squatting + +To prevent alias squatting the network will track the number of consecutive epochs each party has funds totalling less than `spam.protection.updatePartyProfile.min.funds` (quantum) across all their accounts. + +If the number of consecutive epochs is greater than or equal to `spam.protection.updatePartyProfile.maxInactiveEpochs` the network will no longer associate the alias and metadata with the key. + ### Acceptance Criteria - If a party updates there profile with an alias of a length greater than 32 characters, the transaction is rejected. (0088-PPRF-001) @@ -35,3 +41,4 @@ In order to validate uniqueness of an alias, core must keep a record of the alia - If a party update there profile with metadata with more then 10 key pairs, the transaction is rejected. (0088-PPRF-003) - If a party update there profile with metadata with a key of a length more than 33 characters, the transaction is rejected. (0088-PPRF-004) - If a party update there profile with metadata with a value of a length more than 256 characters, the transaction is rejected. (0088-PPRF-005) +- If a parties balance across all accounts is less than `spam.protection.updatePartyProfile.min.funds` for `spam.protection.updatePartyProfile.maxInactiveEpochs` consecutive epochs, then the network no longer stores their alias and it becomes available to any other party. (0088-PPRF-006). diff --git a/protocol/features.json b/protocol/features.json index 808b4b74c..a314d495a 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -53,6 +53,7 @@ "0088-PPRF-003", "0088-PPRF-004", "0088-PPRF-005", + "0088-PPRF-006", "0062-SPAM-037", "0062-SPAM-038", "0062-SPAM-039" From 89b073f81da5d0cd65eeabfa3dd56af6f46c4da6 Mon Sep 17 00:00:00 2001 From: gordsport Date: Tue, 9 Jan 2024 17:48:41 +0000 Subject: [PATCH 0919/1171] chore: add branch to quality checks Adds the nebula branch to the quality check git hub actions --- .github/workflows/quality_check.yml | 1 + 1 file changed, 1 insertion(+) diff --git a/.github/workflows/quality_check.yml b/.github/workflows/quality_check.yml index 657a39b8a..bc8042d5a 100644 --- a/.github/workflows/quality_check.yml +++ b/.github/workflows/quality_check.yml @@ -9,6 +9,7 @@ name: "Quality checks" - master - cosmicelevator - palazzo + - nebula env: GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} From 383856c25644fb6c6e1dfc544f29b7d33d767fea Mon Sep 17 00:00:00 2001 From: Tom Date: Wed, 10 Jan 2024 20:30:26 +0800 Subject: [PATCH 0920/1171] feat: Adding market tags proposal spec (#2103) --------- Co-authored-by: Gordsport <83510148+gordsport@users.noreply.github.com> --- .github/workflows/quality_check.yml | 2 +- makefile | 2 +- protocol/0001-MKTF-market_framework.md | 1 + protocol/0028-GOVE-governance.md | 43 +++++++++++++++++++++++++- protocol/nebula-features.json | 30 ++++++++++++++++++ 5 files changed, 75 insertions(+), 3 deletions(-) create mode 100644 protocol/nebula-features.json diff --git a/.github/workflows/quality_check.yml b/.github/workflows/quality_check.yml index bc8042d5a..c4869cb04 100644 --- a/.github/workflows/quality_check.yml +++ b/.github/workflows/quality_check.yml @@ -77,4 +77,4 @@ jobs: - name: "Run Check Features" run: | - npx github:vegaprotocol/approbation check-features --specs="{./non-protocol-specs/**/*.md,./protocol/**/*.md,./protocol/**/*.ipynb}" --features="./protocol/features.json" + npx github:vegaprotocol/approbation check-features --specs="{./non-protocol-specs/**/*.md,./protocol/**/*.md,./protocol/**/*.ipynb}" --features="./protocol/nebula-features.json" diff --git a/makefile b/makefile index ae9bcacd0..f2bc609ae 100644 --- a/makefile +++ b/makefile @@ -64,7 +64,7 @@ spellcheck: # Checks for duplicated ACs in the features.json file .PHONY: check-features check-features: - npx github:vegaprotocol/approbation check-features --specs="{./non-protocol-specs/**/*.md,./protocol/**/*.md,./protocol/**/*.ipynb}" --features="./protocol/features.json" + npx github:vegaprotocol/approbation check-features --specs="{./non-protocol-specs/**/*.md,./protocol/**/*.md,./protocol/**/*.ipynb}" --features="./protocol/nebula-features.json" clean: rm -rf $(TEMP) diff --git a/protocol/0001-MKTF-market_framework.md b/protocol/0001-MKTF-market_framework.md index 1f4bc30d5..5f16a0699 100644 --- a/protocol/0001-MKTF-market_framework.md +++ b/protocol/0001-MKTF-market_framework.md @@ -80,6 +80,7 @@ Data: - **Name:** full and fairly descriptive name for the instrument. - **Metadata fields:** A series of arbitrary strings that can be used in clients - **Product:** a reference to or instance of a fully specified product, including all required product parameters for that product. +- **Community Tags:** A list of string community tags assigning the market to certain categories. Each of these is a free text field of a network parameter defined maximum length. These are managed through a separate proposal type and cannot be set at market creation or changed in a normal market update proposal. ## Product diff --git a/protocol/0028-GOVE-governance.md b/protocol/0028-GOVE-governance.md index d29c11836..c4aba128b 100644 --- a/protocol/0028-GOVE-governance.md +++ b/protocol/0028-GOVE-governance.md @@ -249,6 +249,32 @@ The following are immutable and cannot be changed: - position decimal places - `settlementAsset` +### 2.1 Change community tags + +Separately to a general market change proposal, proposers can create a proposal to add or remove lists of free-text string community tags to a market. Although these proposals change only a single market, it is possible that these tags will be used to control external behaviour of systems interacting with the vega chain, therefore they do not allow for voting using ELS and instead must be voted through by the general pool of token holders as with any other proposal. The maximum length of a community tags is specified by the network parameter `governance.proposal.market.maxCommunityTagLength`. The community tags on a market are controlled by a single proposal type, `UpdateCommunityTags` with a structure akin to: + +```proto +message UpdateCommunityTags { + string marketId; + repeated string addTags; + repeated string removeTags; +} +``` + +allowing proposals to add and remove tags independently from others. + +The following network parameters will decide how these proposals are treated: +`governance.proposal.updateCommunityTags.maxClose` e.g. `720h`, +`governance.proposal.updateCommunityTags.minClose` e,g. `168h`, +`governance.proposal.updateCommunityTags.maxEnact` e.g. `720h`, +`governance.proposal.updateCommunityTags.minEnact` e,g. `168h`, +`governance.proposal.updateCommunityTags.minProposerBalance` e.g. `1000000000000000000` i.e. 1 VEGA, +`governance.proposal.updateCommunityTags.minVoterBalance` e.g. `1000000000000000000` i.e. 1 VEGA, +`governance.proposal.updateCommunityTags.requiredMajority` e.g. `0.66`, +`governance.proposal.updateCommunityTags.requiredParticipation` e.g. `0.05`. + +Note: Although community tags cannot be amended in an update market proposal, they may be included in the same batch proposal as one. + ## 3. Change network parameters [Network parameters](./0054-NETP-network_parameters.md) that may be changed are described in the _Network Parameters_ spec, this document for details on these parameters, including the category of the parameters. New network parameters require a code change, so there is no support for adding new network parameters. @@ -708,9 +734,10 @@ It is NOT possible to submit a governance proposal where the source account is t 1. volume discount program, 1. referral program, 1. governance transfer, + 1. a community tags proposal can be submitted, voted through and each proposal enacted. -On top of that signed bundles for changing withdrawal delay and threshold on the bridge are emitted (0028-GOVE-160) +On top of that signed bundles for changing withdrawal delay and threshold on the bridge are emitted (0028-GOVE-177) - A batch proposal can be submitted changing the same network parameter twice to two different values with two different enactment timestamps. The voting to approve the batch happens, the batch passes, both changes are observed at the desired time. (0028-GOVE-161) @@ -726,3 +753,17 @@ The voting to approve the batch happens, the batch passes, the value of the prop ##### 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) + +##### Community Market Tags + +- A proposal to add community tags to a market can be successfully submitted. (0028-GOVE-167) + - When that proposal is approved and enacted the community tags are immediately added to that market's community tags property. (0028-GOVE-168) +- A proposal to remove community tags from a market can be successfully submitted. (0028-GOVE-169) + - When that proposal is approved and enacted the community tags are immediately removed from that market's community tags property. (0028-GOVE-170) +- A proposal to add some and remove other community tags from a market can be successfully submitted. (0028-GOVE-171) + - When that proposal is approved and enacted the community tags are immediately removed and added to that market's community tags property. (0028-GOVE-172) +- Neither market creation nor market update proposals can change the community tags property on a market. (0028-GOVE-173) +- A voter's equity-like share does not give them any additional voting weight when voting on a market community tags update proposal. (0028-GOVE-174) +- A proposal to add community tags with any community tags longer than `governance.proposal.market.maxCommunityTagLength` is rejected as invalid (0028-GOVE-175) +- A proposal to remove community tags with any community tags longer than `governance.proposal.market.maxCommunityTagLength` is rejected as invalid (0028-GOVE-176) + diff --git a/protocol/nebula-features.json b/protocol/nebula-features.json new file mode 100644 index 000000000..9b201a88e --- /dev/null +++ b/protocol/nebula-features.json @@ -0,0 +1,30 @@ +{ + "TBC": { + "milestone": "cosmic-carryover", + "acs": [] + }, + "TBC": { + "milestone": "palazzo-carryover", + "acs": [] + }, + "Community Tags": { + "milestone": "nebula", + "acs": [ + "0028-GOVE-167", + "0028-GOVE-168", + "0028-GOVE-169", + "0028-GOVE-170", + "0028-GOVE-171", + "0028-GOVE-172", + "0028-GOVE-173", + "0028-GOVE-174", + "0028-GOVE-175", + "0028-GOVE-176", + "0028-GOVE-177" + ] + }, + "Unknown": { + "milestone": "unknown", + "acs": [] + } +} From e47d4dec627fd85a871be43ce7c69268d1d9e300 Mon Sep 17 00:00:00 2001 From: Witold Date: Fri, 12 Jan 2024 15:07:45 +0100 Subject: [PATCH 0921/1171] refactor: update PM --- protocol/0032-PRIM-price_monitoring.md | 24 ++++++++++++++++++------ protocol/nebula-features.json | 5 ++++- 2 files changed, 22 insertions(+), 7 deletions(-) diff --git a/protocol/0032-PRIM-price_monitoring.md b/protocol/0032-PRIM-price_monitoring.md index 306daee1b..3ac8812d9 100644 --- a/protocol/0032-PRIM-price_monitoring.md +++ b/protocol/0032-PRIM-price_monitoring.md @@ -11,6 +11,8 @@ As mentioned above, price monitoring is meant to stop large market movements tha Please see the [auction spec](./0026-AUCT-auctions.md) for auction details. +Price monitoring engine should track mark price evolution within the market. It should be used to monitor trades as well as mark price update candidates. If any of these violates the bounds the market should go into auction and the transaction should get rejected. + ### Note Price monitoring likely won't be the only possible trigger of auction period e.g. governance action could be the other ones. Thus the framework put in place as part of this spec should be flexible enough to easily accommodate other types of triggers. @@ -20,11 +22,13 @@ Likewise, pre-processing transactions will be needed as part of the [fees spec]( ## Guide-level explanation - We need to emit a "significant price change" event if price move over the horizon τ turned out to be more than what the risk model implied at a probability level α. - - Take **arrival price of the next transaction** (the value that will be the last traded price if we process the next transaction): Vt, - - look-up mid-price St-τ, (prices aren't continuous so will need max(Ss : s ≤ t-τ), call it St-τ*, + - Take **arrival price of the next transaction** (the value that will be the last traded price if we process the next transaction or the mark price update value): Vt, + - look-up mark price St-τ, (prices aren't continuous so will need max(Ss : s ≤ t-τ), call it St-τ*, - get the bounds associated with St-τ*, at a probability level α: - if Vt falls within those bounds then transaction is processed in the current trading mode - - otherwise the transaction (along with the rest of order book) needs to be processed via a temporary auction. + - otherwise: + - the incoming aggressive order (along with the rest of order book) needs to be processed via a temporary auction, + - the mark price update value gets discarded and the market goes into auction, the value obtained upon uncrossing the auction (if any) gets used as the next mark price update value. Any other mark price updates arriving during the price monitoring auction get discarded. - We need to have "atomicity" in transaction processing: - When we process transaction we need to check what the arrival price Vt is. - If it results in "significant price change" event then we want the order book to maintain the state from before we started processing the transaction. @@ -73,20 +77,26 @@ There are several reasons why this maximum is enforced. - if no trigger gets activated then the transaction is processed in a regular fashion, otherwise: - the price protection auction commences and the transaction considered should be processed in this way (along with any other orders on the book and pending transactions that are valid for auction). +- Per mark price update: + - when the next mark price update value is received it gets checked against the price monitoring engine, + - price monitoring engine sends back signal informing if the price protection auction should be triggered (and if so how long the auction period should be), + - if no trigger gets activated then the mark price update candidate gets accepted, included in the internal price history tracked by the price monitoring engine and mark-to-market process carries on as usual, otherwise: + - the price protection auction commences, any other mark price update candidates received before the auction ends get discarded, if the auction ends and results in a price than that price gets used as the next mark price, it gets included in the internal price history tracked by the price monitoring engine and the mark-to-market process carries on as usual. + ### View from the price monitoring engine side -Price monitoring engine will interface between the matching engine and the risk model. It will communicate with the matching engine every time a new transaction is processed (to check it its' arrival price should trigger an auction). It will communicate with the risk model with a predefined frequency to inform the risk model of the latest price history and obtain a new set of scaling factors used to calculate min/max prices from the reference price. +Price monitoring engine will interface between the matching engine and the risk model. It will communicate with the matching engine every time a new transaction is processed (to check it its' arrival price should trigger an auction). It will communicate with the risk model with a predefined frequency to inform the risk model of the latest mark price history and obtain a new set of scaling factors used to calculate min/max prices from the reference price. Specifically: -- Price monitoring engine averages (weighted by volume) all the prices received from the matching engine that have the same timestamp. - It periodically (in a predefined, deterministic way) sends the: - the probability level α, - period τ, - the associated reference price 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. +- It holds the history of mark 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. +- Every time a new price is mark price candidate is available 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. 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, @@ -129,3 +139,5 @@ to the risk model and obtains the range of valid up/down price moves per each of - 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) +- For all available mark price calculation methodologies: the price history used by the price monitoring engine is in line with market's mark price history. (0032-PRIM-039) +- For all available mark-price calculation methodologies: the mark price update candidate gets rejected if it violates the price monitoring engine bounds. (0032-PRIM-040) diff --git a/protocol/nebula-features.json b/protocol/nebula-features.json index 9b201a88e..6793c3d46 100644 --- a/protocol/nebula-features.json +++ b/protocol/nebula-features.json @@ -5,7 +5,10 @@ }, "TBC": { "milestone": "palazzo-carryover", - "acs": [] + "acs": [ + "0032-PRIM-039", + "0032-PRIM-040" + ] }, "Community Tags": { "milestone": "nebula", From bbcad13563a6ac823ab5c3fa049e7c723b80235e Mon Sep 17 00:00:00 2001 From: Gordsport <83510148+gordsport@users.noreply.github.com> Date: Wed, 17 Jan 2024 11:06:49 +0000 Subject: [PATCH 0922/1171] chore: add AC thats pushed from palazzo milestone (#2128) As per: - https://github.com/vegaprotocol/specs/pull/2127 This adds inthe AC code that cant be tested in palazzo due to the following issue: - https://github.com/vegaprotocol/vega/issues/10360 --- protocol/nebula-features.json | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/protocol/nebula-features.json b/protocol/nebula-features.json index 6793c3d46..24c8e5aa3 100644 --- a/protocol/nebula-features.json +++ b/protocol/nebula-features.json @@ -26,6 +26,10 @@ "0028-GOVE-177" ] }, + "Perpetual funding rates": { + "milestone": "nebula", + "acs": ["0053-PERP-036"] + }, "Unknown": { "milestone": "unknown", "acs": [] From 474023e780debc1ad94555c852e62f0081851da9 Mon Sep 17 00:00:00 2001 From: Charlie Date: Wed, 24 Jan 2024 14:37:39 +0000 Subject: [PATCH 0923/1171] Revert "feat: add anti alias squatting feature" This reverts commit 6c3f548c773cd1344d55d76e987e1330ae70d03f. --- protocol/0088-PPRF-party_profile.md | 7 ------- protocol/features.json | 1 - 2 files changed, 8 deletions(-) diff --git a/protocol/0088-PPRF-party_profile.md b/protocol/0088-PPRF-party_profile.md index 633b075bb..4af6765db 100644 --- a/protocol/0088-PPRF-party_profile.md +++ b/protocol/0088-PPRF-party_profile.md @@ -28,12 +28,6 @@ If an alias is specified, it must adhere to the following rules: **Note:** In order to validate uniqueness of an alias, core must keep a record of the aliases associated with each party. If a party is no longer active. -### Alias Squatting - -To prevent alias squatting the network will track the number of consecutive epochs each party has funds totalling less than `spam.protection.updatePartyProfile.min.funds` (quantum) across all their accounts. - -If the number of consecutive epochs is greater than or equal to `spam.protection.updatePartyProfile.maxInactiveEpochs` the network will no longer associate the alias and metadata with the key. - ### Acceptance Criteria - If a party updates there profile with an alias of a length greater than 32 characters, the transaction is rejected. (0088-PPRF-001) @@ -41,4 +35,3 @@ If the number of consecutive epochs is greater than or equal to `spam.protection - If a party update there profile with metadata with more then 10 key pairs, the transaction is rejected. (0088-PPRF-003) - If a party update there profile with metadata with a key of a length more than 33 characters, the transaction is rejected. (0088-PPRF-004) - If a party update there profile with metadata with a value of a length more than 256 characters, the transaction is rejected. (0088-PPRF-005) -- If a parties balance across all accounts is less than `spam.protection.updatePartyProfile.min.funds` for `spam.protection.updatePartyProfile.maxInactiveEpochs` consecutive epochs, then the network no longer stores their alias and it becomes available to any other party. (0088-PPRF-006). diff --git a/protocol/features.json b/protocol/features.json index a314d495a..808b4b74c 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -53,7 +53,6 @@ "0088-PPRF-003", "0088-PPRF-004", "0088-PPRF-005", - "0088-PPRF-006", "0062-SPAM-037", "0062-SPAM-038", "0062-SPAM-039" From 6a561066b03b4f63d040301fad58eba4ff3315c6 Mon Sep 17 00:00:00 2001 From: Charlie Date: Wed, 24 Jan 2024 15:27:54 +0000 Subject: [PATCH 0924/1171] chore: correct restriction typos --- protocol/0088-PPRF-party_profile.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/protocol/0088-PPRF-party_profile.md b/protocol/0088-PPRF-party_profile.md index 4af6765db..9fb2e81ca 100644 --- a/protocol/0088-PPRF-party_profile.md +++ b/protocol/0088-PPRF-party_profile.md @@ -17,8 +17,8 @@ An `UpdatePartyProfile` has the following fields. If metadata is specified, the metadata must adhere to the following rules: - no more than 10 key value pairs can be specified -- a key must be no longer than 33 characters -- a value must be no longer than 256 characters +- a key must be no longer than 32 characters +- a value must be no longer than 255 characters If an alias is specified, it must adhere to the following rules: @@ -33,5 +33,5 @@ In order to validate uniqueness of an alias, core must keep a record of the alia - If a party updates there profile with an alias of a length greater than 32 characters, the transaction is rejected. (0088-PPRF-001) - If a party updates there profile with an alias which is already associated with another key, the transaction is rejected. (0088-PPRF-002) - If a party update there profile with metadata with more then 10 key pairs, the transaction is rejected. (0088-PPRF-003) -- If a party update there profile with metadata with a key of a length more than 33 characters, the transaction is rejected. (0088-PPRF-004) -- If a party update there profile with metadata with a value of a length more than 256 characters, the transaction is rejected. (0088-PPRF-005) +- If a party update there profile with metadata with a key of a length more than 32 characters, the transaction is rejected. (0088-PPRF-004) +- If a party update there profile with metadata with a value of a length more than 255 characters, the transaction is rejected. (0088-PPRF-005) From 90a235dfbeb2882209ce79b2c6227eb3a7f7be25 Mon Sep 17 00:00:00 2001 From: Charlie Date: Wed, 24 Jan 2024 15:36:52 +0000 Subject: [PATCH 0925/1171] feat: add validation and defaults for new network parameters --- protocol/0062-SPAM-spam_protection.md | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/protocol/0062-SPAM-spam_protection.md b/protocol/0062-SPAM-spam_protection.md index fce3680e4..eadf53d96 100644 --- a/protocol/0062-SPAM-spam_protection.md +++ b/protocol/0062-SPAM-spam_protection.md @@ -77,8 +77,13 @@ The [party profile feature](./0088-PPRF-party_profile.md) adds a transaction typ To avoid spamming of `UpdatePartyProfile`, a party must meet the deposited funds threshold set by the network parameter `spam.protection.updatePartyProfile.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`). +**Note** `spam.protection.updatePartyProfile.min.funds` must be an integer greater than or equal to `0` (and default to `10`). + Further, each party is allowed to submit up to `n` transactions per epoch where `n` is controlled by the respective network parameter for the transaction type (`spam.protection.max.updatePartyProfile`). +**Note** `spam.protection.max.updatePartyProfile` must be an integer greater than or equal to `0` (and default to `5`). + + ### Related topics - [Spam protection: Proof of work](https://github.com/vegaprotocol/specs/blob/master/protocol/0072-SPPW-spam-protection-PoW.md) From 51cdead3a59056a372258d717294cb498dd4a2b8 Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Thu, 25 Jan 2024 09:31:32 +0000 Subject: [PATCH 0926/1171] feat: add ac for price via data node --- protocol/0009-MRKP-mark_price.md | 5 ++++- protocol/0053-PERP-product_builtin_perpetual_future.md | 2 ++ 2 files changed, 6 insertions(+), 1 deletion(-) diff --git a/protocol/0009-MRKP-mark_price.md b/protocol/0009-MRKP-mark_price.md index dee85a9ed..49023be81 100644 --- a/protocol/0009-MRKP-mark_price.md +++ b/protocol/0009-MRKP-mark_price.md @@ -4,7 +4,7 @@ A *Mark Price* is a concept derived from traditional markets. It is a calculated value for the 'current market price' on a market. -Introduce a network parameter `network.markPriceUpdateMaximumFrequency` with minimum allowable value of `0s` maximum allowable value of `1h` and a default of `5s`. +Introduce a network parameter ` ` with minimum allowable value of `0s` maximum allowable value of `1h` and a default of `5s`. The *Mark Price* represents the "current" market value for an instrument that is being traded on a market on Vega. It is a calculated value primarily used to value trader's open portfolios against the prices they executed their trades at. Specifically, it is used to calculate the cash flows for [mark-to-market settlement](./0003-MTMK-mark_to_market_settlement.md). @@ -76,6 +76,9 @@ Note that for calculating the median with an even number of entries we sort, pic - when choosing price type `weight` and set weight on `oracle source price` only, set up 3 oracle prices at different time with 1 of them becomes stale, and check if the oracle mark price updated according to is correctly calculated by using the right price (0009-MRKP-132) +- It is possible to obtain a time series for the market mark price from the data node from the time of the market proposal enactment onwards (subject to data node retention policies).(0009-MRKP-133) + + ### Flexible mark price methodology, combinations - It is possible to configure a cash settled futures market to use a weighted average of 1. weighted average of trades over `network.markPriceUpdateMaximumFrequency` and 2. impact of leveraged notional on the order book with the value of USDT `100` and 3. an oracle source and if last trade is last updated more than 1 minute ago then it is removed and the remaining re-weighted and if the oracle is last updated more than 5 minutes ago then it is removed and the remaining re-weighted (0009-MRKP-018) and a perps market (with the oracle source different to that used for the external price in the perps market) (0009-MRKP-019). diff --git a/protocol/0053-PERP-product_builtin_perpetual_future.md b/protocol/0053-PERP-product_builtin_perpetual_future.md index 703daad3f..ad26ec955 100644 --- a/protocol/0053-PERP-product_builtin_perpetual_future.md +++ b/protocol/0053-PERP-product_builtin_perpetual_future.md @@ -281,6 +281,8 @@ In both cases the estimates are for a hypothetical position of size 1. 1. Assume the market has been in a long auction so that a funding period has started and ended while the market never went back into continuous trading. In that case the funding payment should be equal to 0 and no transfers should be exchanged. (0053-PERP-026) +- It is possible to obtain a time series for the price used for “vega side price” of the funding twap from the data node from the time of the market proposal enactment onwards (subject to data node retention policies).(0053-PERP-043) + 1. Assume a 10 minute funding period. Assume a few funding periods have already passed for this market. Assume the last known mark price before the start of the period to be `10` and that it gets updated every 2 minutes as follows: From 27a872aaa833b597e6901a93cf53c9538aa92ca1 Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Thu, 25 Jan 2024 09:34:30 +0000 Subject: [PATCH 0927/1171] feat: update json file --- protocol/0009-MRKP-mark_price.md | 2 +- protocol/features.json | 6 ++++-- 2 files changed, 5 insertions(+), 3 deletions(-) diff --git a/protocol/0009-MRKP-mark_price.md b/protocol/0009-MRKP-mark_price.md index 49023be81..dde1d7d92 100644 --- a/protocol/0009-MRKP-mark_price.md +++ b/protocol/0009-MRKP-mark_price.md @@ -4,7 +4,7 @@ A *Mark Price* is a concept derived from traditional markets. It is a calculated value for the 'current market price' on a market. -Introduce a network parameter ` ` with minimum allowable value of `0s` maximum allowable value of `1h` and a default of `5s`. +Introduce a network parameter `network.markPriceUpdateMaximumFrequency` with minimum allowable value of `0s` maximum allowable value of `1h` and a default of `5s`. The *Mark Price* represents the "current" market value for an instrument that is being traded on a market on Vega. It is a calculated value primarily used to value trader's open portfolios against the prices they executed their trades at. Specifically, it is used to calculate the cash flows for [mark-to-market settlement](./0003-MTMK-mark_to_market_settlement.md). diff --git a/protocol/features.json b/protocol/features.json index 808b4b74c..55e5ed995 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -18,7 +18,8 @@ "0053-PERP-039", "0053-PERP-040", "0053-PERP-041", - "0053-PERP-042" + "0053-PERP-042", + "0053-PERP-043" ] }, "Team rewards": { @@ -372,7 +373,8 @@ "0009-MRKP-127", "0009-MRKP-130", "0009-MRKP-131", - "0009-MRKP-132" + "0009-MRKP-132", + "0009-MRKP-133" ] }, "Ethereum RPC and EVM based data sources": { From 2c83dbaf38d1489905d3b595227bb0b5a5fb311b Mon Sep 17 00:00:00 2001 From: Gordsport <83510148+gordsport@users.noreply.github.com> Date: Thu, 25 Jan 2024 11:07:23 +0000 Subject: [PATCH 0928/1171] chore: remove ACs from palazzo (#2140) 0009-MRKP-133 and 0053-PERP-043 will be moved to Nebula in a new PR --- protocol/features.json | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/protocol/features.json b/protocol/features.json index 55e5ed995..808b4b74c 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -18,8 +18,7 @@ "0053-PERP-039", "0053-PERP-040", "0053-PERP-041", - "0053-PERP-042", - "0053-PERP-043" + "0053-PERP-042" ] }, "Team rewards": { @@ -373,8 +372,7 @@ "0009-MRKP-127", "0009-MRKP-130", "0009-MRKP-131", - "0009-MRKP-132", - "0009-MRKP-133" + "0009-MRKP-132" ] }, "Ethereum RPC and EVM based data sources": { From 05e202fa2fbddc03a0f18dc65e4384a6568c090a Mon Sep 17 00:00:00 2001 From: Gordsport <83510148+gordsport@users.noreply.github.com> Date: Thu, 25 Jan 2024 12:01:31 +0000 Subject: [PATCH 0929/1171] chore: update ACs moved from palazzo to nebula (#2141) * chore: update ACs moved from palazzo to nebula part 2 of: - https://github.com/vegaprotocol/specs/pull/2140 * fix: add the ACs into the specs * fix: MD linting --- protocol/0009-MRKP-mark_price.md | 2 ++ protocol/0053-PERP-product_builtin_perpetual_future.md | 2 ++ protocol/nebula-features.json | 10 ++++------ 3 files changed, 8 insertions(+), 6 deletions(-) diff --git a/protocol/0009-MRKP-mark_price.md b/protocol/0009-MRKP-mark_price.md index dee85a9ed..ee1192194 100644 --- a/protocol/0009-MRKP-mark_price.md +++ b/protocol/0009-MRKP-mark_price.md @@ -76,6 +76,8 @@ Note that for calculating the median with an even number of entries we sort, pic - when choosing price type `weight` and set weight on `oracle source price` only, set up 3 oracle prices at different time with 1 of them becomes stale, and check if the oracle mark price updated according to is correctly calculated by using the right price (0009-MRKP-132) +- It is possible to obtain a time series for the market mark price from the data node from the time of the market proposal enactment onwards (subject to data node retention policies).(0009-MRKP-133) + ### Flexible mark price methodology, combinations - It is possible to configure a cash settled futures market to use a weighted average of 1. weighted average of trades over `network.markPriceUpdateMaximumFrequency` and 2. impact of leveraged notional on the order book with the value of USDT `100` and 3. an oracle source and if last trade is last updated more than 1 minute ago then it is removed and the remaining re-weighted and if the oracle is last updated more than 5 minutes ago then it is removed and the remaining re-weighted (0009-MRKP-018) and a perps market (with the oracle source different to that used for the external price in the perps market) (0009-MRKP-019). diff --git a/protocol/0053-PERP-product_builtin_perpetual_future.md b/protocol/0053-PERP-product_builtin_perpetual_future.md index 703daad3f..016c2df4f 100644 --- a/protocol/0053-PERP-product_builtin_perpetual_future.md +++ b/protocol/0053-PERP-product_builtin_perpetual_future.md @@ -281,6 +281,8 @@ In both cases the estimates are for a hypothetical position of size 1. 1. Assume the market has been in a long auction so that a funding period has started and ended while the market never went back into continuous trading. In that case the funding payment should be equal to 0 and no transfers should be exchanged. (0053-PERP-026) +1. It is possible to obtain a time series for the price used for “vega side price” of the funding twap from the data node from the time of the market proposal enactment onwards (subject to data node retention policies) (0053-PERP-043) + 1. Assume a 10 minute funding period. Assume a few funding periods have already passed for this market. Assume the last known mark price before the start of the period to be `10` and that it gets updated every 2 minutes as follows: diff --git a/protocol/nebula-features.json b/protocol/nebula-features.json index 24c8e5aa3..d39b01838 100644 --- a/protocol/nebula-features.json +++ b/protocol/nebula-features.json @@ -1,11 +1,9 @@ { - "TBC": { - "milestone": "cosmic-carryover", - "acs": [] - }, - "TBC": { - "milestone": "palazzo-carryover", + "Markprice updates": { + "milestone": "nebula", "acs": [ + "0009-MRKP-132", + "0053-PERP-043", "0032-PRIM-039", "0032-PRIM-040" ] From 17cbd33b9a2998214efc5ebac7460402318ebabe Mon Sep 17 00:00:00 2001 From: Witold Date: Wed, 13 Dec 2023 10:29:23 +0100 Subject: [PATCH 0930/1171] refactor: update liquidation price estimate --- .../0012-NP-LIPE-liquidation-price-estimate.md | 9 +++++++++ 1 file changed, 9 insertions(+) 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 aedc68b83..d0bae4e2f 100644 --- a/non-protocol-specs/0012-NP-LIPE-liquidation-price-estimate.md +++ b/non-protocol-specs/0012-NP-LIPE-liquidation-price-estimate.md @@ -50,6 +50,14 @@ When including orders we sort the orders in the order they will get filled in (d - 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). +### Margin mode considerations + +Depending on the [margining mode](../protocol/0019-MCAL-margin_calculator.md#margining-modes) selected by the party for the market on which its position is being considered the $\text{collateral available}$ will differ. + +Cross-margin mode: $\text{collateral available} = \text{margin account balance} + \text{general account balance}$. + +Isolated margin mode: $\text{collateral available} = \text{margin account balance}$. + ### 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) @@ -58,3 +66,4 @@ 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 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) +1. When margining mode gets successfully changed and party has non-zero general account balance afterwards than its liquidation price estimate for all cases (position only, with buy orders, with sell orders) moves closer to the current mark price (compared to cross-margin figure). (0012-NP-LIPE-007) From c3c68704e1c0703761680c40f7860d2d05d4b4a7 Mon Sep 17 00:00:00 2001 From: gordsport Date: Fri, 26 Jan 2024 17:08:53 +0000 Subject: [PATCH 0931/1171] chore: add feature file for 0012-NP-LIPE ACs --- protocol/features.json | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/protocol/features.json b/protocol/features.json index 808b4b74c..4f0394cdf 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -423,6 +423,16 @@ "0087-EVMD-044" ] }, + "Price estimate": { + "milestone": "palazzo", + "acs": [ + "0012-NP-LIPE-001", + "0012-NP-LIPE-004", + "0012-NP-LIPE-005", + "0012-NP-LIPE-006", + "0012-NP-LIPE-007" + ] + }, "Unknown": { "milestone": "unknown", "acs": [] From bff07083c531bb1f0685f356a69c2151465417a4 Mon Sep 17 00:00:00 2001 From: Witold Date: Mon, 29 Jan 2024 10:13:38 +0100 Subject: [PATCH 0932/1171] refactor: add spec for position estimate --- ...0012-NP-LIPE-liquidation-price-estimate.md | 16 ++---- .../0013-NP-POSE-position-estimate.md | 55 +++++++++++++++++++ protocol/features.json | 10 +++- 3 files changed, 68 insertions(+), 13 deletions(-) create mode 100644 non-protocol-specs/0013-NP-POSE-position-estimate.md 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 d0bae4e2f..4371262ca 100644 --- a/non-protocol-specs/0012-NP-LIPE-liquidation-price-estimate.md +++ b/non-protocol-specs/0012-NP-LIPE-liquidation-price-estimate.md @@ -46,24 +46,16 @@ When including orders we sort the orders in the order they will get filled in (d - 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 $\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). -### Margin mode considerations - -Depending on the [margining mode](../protocol/0019-MCAL-margin_calculator.md#margining-modes) selected by the party for the market on which its position is being considered the $\text{collateral available}$ will differ. - -Cross-margin mode: $\text{collateral available} = \text{margin account balance} + \text{general account balance}$. - -Isolated margin mode: $\text{collateral available} = \text{margin account balance}$. - ### 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 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 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) -1. When margining mode gets successfully changed and party has non-zero general account balance afterwards than its liquidation price estimate for all cases (position only, with buy orders, with sell orders) moves closer to the current mark price (compared to cross-margin figure). (0012-NP-LIPE-007) +1. When margining mode gets successfully changed to isolated margin mode and party has non-zero general account balance afterwards than its liquidation price estimate for all cases (position only, with buy orders, with sell orders) moves closer to the current mark price (compared to cross-margin figure). (0012-NP-LIPE-007) diff --git a/non-protocol-specs/0013-NP-POSE-position-estimate.md b/non-protocol-specs/0013-NP-POSE-position-estimate.md new file mode 100644 index 000000000..49700a839 --- /dev/null +++ b/non-protocol-specs/0013-NP-POSE-position-estimate.md @@ -0,0 +1,55 @@ +# Position estimate + +## Summary + +Protocol provides an API endpoint which can estimate the following aspects of a theoretical position (open volume and open orders): + +- margin levels, +- expected collateral increase required to support the position, +- liquidation price. + +Each estimate is a range between a relevant figure obtained with the assumption of no slippage and maximum slippage configured for the market. + +## Details + +The endpoint does not access information related to any of the existing positions, it's based entirely on the information specified in the request. +The endpoint only distinguishes between market orders (these are assumed to fill instantly and in full at a current mark price) and limit orders (these are assumed to fill in full once mark price reaches their limit price). + +### Margin level + +Margin level estimate contains the levels specified in [0019-MCAL-margin_calculator](./../protocol/0019-MCAL-margin_calculator.md#reference-level-explanation) spec as well margin mode and margin factor (0 in cross margin mode). + +### Collateral increase estimate + +Collateral increase estimate provides an approximate amount of the additional funds above the specified margin and order margin account level balances required. + +In cross-margin mode it's the difference between the initial margin level estimate for the specified position and the margin account balance specified in the request. + +In isolated margin mode it's the difference between collateral required to support the specified position and orders with the margin factor provided and the balance of margin and order margin accounts specified in the request. + +Collateral increase estimate is always floored at 0, it only tries to estimate the increase in the collateral request, not the potential collateral release amount. If the request is made such that the account balances specified are equal to or greater than the required margin then 0 is returned. + +### Liquidation price estimate + +Liquidation price estimate as specified in [0012-NP-LIPE-liquidation-price-estimate](./0012-NP-LIPE-liquidation-price-estimate.md). + +Depending on the [margining mode](../protocol/0019-MCAL-margin_calculator.md#margining-modes) selected by the party for the market on which its position is being considered the $\text{collateral available}$ will differ. + +Cross-margin mode: $\text{collateral available} = \text{margin account balance} + \text{general account balance}$. + +Isolated margin mode: $\text{collateral available} = \text{margin account balance} + \text{order margin account balance}$. + +The position estimate request has an additional `include_collateral_increase_in_available_collateral` argument. It's relevant for the isolated margin mode: when set to `false` the collateral available used in liquidation price estimate will be the sum of the specified margin and order margin accounts only. When set to `true` the collateral increase estimated for the specified position will also be included in the available collateral. + +The endpoint request contains additional optional argument `scale_liquidation_price_to_market_decimals`. When set to `false` the liquidation price estimates are scaled to asset decimal places, when set to `true` these estimates are scaled to market decimal places. + +## Acceptance criteria + +1. In isolated margin mode the request with `0` open volume and one or more limit orders specified results in a non-zero order margin in the margin level estimate and margin mode correctly representing isolated margin mode. (0013-NP-POSE-001) +1. When account balances are set to `0` the collateral increase figure per specified theoretical position correctly approximates the actual margin and order margin account balances for a party which opens such a position. (0013-NP-POSE-002) +1. When response for a given request contains figure `x` as the collateral increase best case then resubmitting the request with margin account balance increased by `x` should result in `0` collateral increase estimate for the best case. When increasing the margin account balance in the request further the collateral increase should remain at `0`. Same should be true when the above is repeated for the worst case. (0013-NP-POSE-003) +1. In isolated margin mode increasing general account balance specified in the request has no impact on the collateral increase estimate and the liquidation price estimate. (0013-NP-POSE-004) +1. In isolated margin mode the liquidation price estimate for a position with non-zero additional margin requirement with `include_collateral_increase_in_available_collateral` argument set to `true` results in liquidation price which is closer to the current mark price than the result obtained with argument set to `false`. (0013-NP-POSE-005) +1. When market is set with different number of decimal places then its settlement asset then setting `scale_liquidation_price_to_market_decimals` to `false` results in liquidation price estimates scaled to asset decimal places, when set to `true` these estimates get scaled to market decimal places. (0013-NP-POSE-006) +1. The estimates for open volume of `1` and no orders are the same as those for open volume of `0` and a single buy market order of size `1`. (0013-NP-POSE-007) +1. The estimates for open volume of `-1` and no orders are the same as those for open volume of `0` and a single sell market order of size `1`. (0013-NP-POSE-008) diff --git a/protocol/features.json b/protocol/features.json index 4f0394cdf..967868506 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -430,7 +430,15 @@ "0012-NP-LIPE-004", "0012-NP-LIPE-005", "0012-NP-LIPE-006", - "0012-NP-LIPE-007" + "0012-NP-LIPE-007", + "0013-NP-POSE-001", + "0013-NP-POSE-002", + "0013-NP-POSE-003", + "0013-NP-POSE-004", + "0013-NP-POSE-005", + "0013-NP-POSE-006", + "0013-NP-POSE-007", + "0013-NP-POSE-008" ] }, "Unknown": { From 01745a489b4d4c1ca8ed22cb528d0362584fbf90 Mon Sep 17 00:00:00 2001 From: Gordsport <83510148+gordsport@users.noreply.github.com> Date: Mon, 29 Jan 2024 13:44:13 +0000 Subject: [PATCH 0933/1171] chore: Update features.json --- protocol/features.json | 2 ++ 1 file changed, 2 insertions(+) diff --git a/protocol/features.json b/protocol/features.json index 967868506..50a721321 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -427,6 +427,8 @@ "milestone": "palazzo", "acs": [ "0012-NP-LIPE-001", + "0012-NP-LIPE-002", + "0012-NP-LIPE-003", "0012-NP-LIPE-004", "0012-NP-LIPE-005", "0012-NP-LIPE-006", From 30264f8cd832e757e1f791c96804aadb5c9345fd Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Thu, 1 Feb 2024 10:49:41 +0000 Subject: [PATCH 0934/1171] feat: taker rewards capped by trading fees reward --- protocol/0056-REWA-rewards_overview.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/protocol/0056-REWA-rewards_overview.md b/protocol/0056-REWA-rewards_overview.md index 169ff1743..95e2c96d2 100644 --- a/protocol/0056-REWA-rewards_overview.md +++ b/protocol/0056-REWA-rewards_overview.md @@ -56,6 +56,8 @@ If the reward account balance is `0` at the end of the epoch for a given recurri 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. +The taker reward for each key is capped at `market.maxreward.taker * rewards_taker_paid_fee`. Whatever left in the reward pool will remain for the next epoch. + ### Average position metric The average position metric, $m_{ap}$, measures each parties time-weighted average position over a number of epochs. From 562e2944a90d5deb35dfd1ba4139eaa167766255 Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Thu, 1 Feb 2024 12:14:46 +0000 Subject: [PATCH 0935/1171] feat: update market parameter --- protocol/0056-REWA-rewards_overview.md | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/protocol/0056-REWA-rewards_overview.md b/protocol/0056-REWA-rewards_overview.md index 95e2c96d2..22fb216a3 100644 --- a/protocol/0056-REWA-rewards_overview.md +++ b/protocol/0056-REWA-rewards_overview.md @@ -58,6 +58,12 @@ Fee-based reward metrics (the total fees paid/received by each party as defined The taker reward for each key is capped at `market.maxreward.taker * rewards_taker_paid_fee`. Whatever left in the reward pool will remain for the next epoch. +The maker reward for each key is capped at `market.maxreward.maker * rewards_maker_fee`. Whatever left in the reward pool will remain for the next epoch. + +Market parameter `market.maxreward.taker` (decimal) — maximum fraction of `rewards_taker_paid_fee` each key can receive each epoch. This is a decimal number in the interval $[0,1]$, when set to $0$ then each key will not receive any taker fee reward, when set to $1$ and if the key is the only price taker on the market, then the key will get all the `rewards_taker_paid_fee` in the epoch. + +Market parameter `market.maxreward.maker` (decimal) — maximum fraction of `rewards_maker_fee` each key can receive each epoch. This is a decimal number in the interval $[0,1]$, when set to $0$ then each key will not receive any maker fee reward, when set to $1$ and if the key is the only market makers, then this key will get all the `maker_fee` in the epoch. + ### Average position metric The average position metric, $m_{ap}$, measures each parties time-weighted average position over a number of epochs. From 06e4fdcc89790fb485327481d900b170fd7fde2a Mon Sep 17 00:00:00 2001 From: Gordsport <83510148+gordsport@users.noreply.github.com> Date: Thu, 1 Feb 2024 14:22:15 +0000 Subject: [PATCH 0936/1171] chore: updates for approbation after the branch rename (#2150) After renaming the nebula branch to colosseo this will ensure that approbation runs as required on the CI --- .github/workflows/quality_check.yml | 4 ++-- protocol/{nebula-features.json => colosseo-features.json} | 0 2 files changed, 2 insertions(+), 2 deletions(-) rename protocol/{nebula-features.json => colosseo-features.json} (100%) diff --git a/.github/workflows/quality_check.yml b/.github/workflows/quality_check.yml index c4869cb04..c7ebd4e6f 100644 --- a/.github/workflows/quality_check.yml +++ b/.github/workflows/quality_check.yml @@ -9,7 +9,7 @@ name: "Quality checks" - master - cosmicelevator - palazzo - - nebula + - colosseo env: GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} @@ -77,4 +77,4 @@ jobs: - name: "Run Check Features" run: | - npx github:vegaprotocol/approbation check-features --specs="{./non-protocol-specs/**/*.md,./protocol/**/*.md,./protocol/**/*.ipynb}" --features="./protocol/nebula-features.json" + npx github:vegaprotocol/approbation check-features --specs="{./non-protocol-specs/**/*.md,./protocol/**/*.md,./protocol/**/*.ipynb}" --features="./protocol/colosseo-features.json" diff --git a/protocol/nebula-features.json b/protocol/colosseo-features.json similarity index 100% rename from protocol/nebula-features.json rename to protocol/colosseo-features.json From 2c7d4c5932bb03a257489b13f252256dde8afa44 Mon Sep 17 00:00:00 2001 From: Gordsport <83510148+gordsport@users.noreply.github.com> Date: Thu, 1 Feb 2024 16:38:01 +0000 Subject: [PATCH 0937/1171] chore: renove dupe AC from features file (#2151) --- protocol/features.json | 1 - 1 file changed, 1 deletion(-) diff --git a/protocol/features.json b/protocol/features.json index 50a721321..eea74613c 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -15,7 +15,6 @@ "0053-PERP-030", "0053-PERP-031", "0053-PERP-032", - "0053-PERP-039", "0053-PERP-040", "0053-PERP-041", "0053-PERP-042" From a62aab1f02550acf080c9497edfba6a83e9647d3 Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Thu, 1 Feb 2024 18:17:20 +0000 Subject: [PATCH 0938/1171] feat: move reward cap to 0057 --- protocol/0056-REWA-rewards_overview.md | 8 -------- protocol/0057-TRAN-transfers.md | 1 + 2 files changed, 1 insertion(+), 8 deletions(-) diff --git a/protocol/0056-REWA-rewards_overview.md b/protocol/0056-REWA-rewards_overview.md index 22fb216a3..169ff1743 100644 --- a/protocol/0056-REWA-rewards_overview.md +++ b/protocol/0056-REWA-rewards_overview.md @@ -56,14 +56,6 @@ If the reward account balance is `0` at the end of the epoch for a given recurri 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. -The taker reward for each key is capped at `market.maxreward.taker * rewards_taker_paid_fee`. Whatever left in the reward pool will remain for the next epoch. - -The maker reward for each key is capped at `market.maxreward.maker * rewards_maker_fee`. Whatever left in the reward pool will remain for the next epoch. - -Market parameter `market.maxreward.taker` (decimal) — maximum fraction of `rewards_taker_paid_fee` each key can receive each epoch. This is a decimal number in the interval $[0,1]$, when set to $0$ then each key will not receive any taker fee reward, when set to $1$ and if the key is the only price taker on the market, then the key will get all the `rewards_taker_paid_fee` in the epoch. - -Market parameter `market.maxreward.maker` (decimal) — maximum fraction of `rewards_maker_fee` each key can receive each epoch. This is a decimal number in the interval $[0,1]$, when set to $0$ then each key will not receive any maker fee reward, when set to $1$ and if the key is the only market makers, then this key will get all the `maker_fee` in the epoch. - ### Average position metric The average position metric, $m_{ap}$, measures each parties time-weighted average position over a number of epochs. diff --git a/protocol/0057-TRAN-transfers.md b/protocol/0057-TRAN-transfers.md index 7592dcb74..badcaaaa7 100644 --- a/protocol/0057-TRAN-transfers.md +++ b/protocol/0057-TRAN-transfers.md @@ -109,6 +109,7 @@ A party should be able to configure the distribution of rewards by specifying th - `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. +- `cap_reward` - maximum fraction of `reward` each key can receive each epoch from the reward pool each epoch. Once the cap is applied, whatever left in the reward pool will remain in the reward pool for the next epoch. - `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. From a6004ce69603e5ad15afba358e91aae50912a744 Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Thu, 1 Feb 2024 18:21:16 +0000 Subject: [PATCH 0939/1171] chore: typo --- 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 badcaaaa7..ce5955129 100644 --- a/protocol/0057-TRAN-transfers.md +++ b/protocol/0057-TRAN-transfers.md @@ -109,7 +109,7 @@ A party should be able to configure the distribution of rewards by specifying th - `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. -- `cap_reward` - maximum fraction of `reward` each key can receive each epoch from the reward pool each epoch. Once the cap is applied, whatever left in the reward pool will remain in the reward pool for the next epoch. +- `cap_reward` - maximum fraction of `reward` each key can receive each epoch from the reward pool. Once the cap is applied, whatever left in the reward pool will remain in the reward pool for the next epoch. - `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. From 0181f39697a51474f5dcc81de3c67cbd52675ed6 Mon Sep 17 00:00:00 2001 From: Jiajia-Cui <92106936+Jiajia-Cui@users.noreply.github.com> Date: Fri, 2 Feb 2024 11:00:52 +0000 Subject: [PATCH 0940/1171] feat: comment from Barney 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 ce5955129..a3b24fe47 100644 --- a/protocol/0057-TRAN-transfers.md +++ b/protocol/0057-TRAN-transfers.md @@ -109,7 +109,7 @@ A party should be able to configure the distribution of rewards by specifying th - `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. -- `cap_reward` - maximum fraction of `reward` each key can receive each epoch from the reward pool. Once the cap is applied, whatever left in the reward pool will remain in the reward pool for the next epoch. +- `cap_reward_fee_multiple` [optional] - if set, the actual amount of reward transferred to each public key during distribution for this transfer will be `min(calculated_reward, cap_reward_fee_multiple × fees_paid_this_epoch)`. If all keys are capped (i.e. the total amount of the transfer cannot be be sent to eligible keys without breaching the cap) then the remaining balance must either not leave the source account for an iteration of the recurring transfer, or be transferred back to the source account with no fee. If this occurs, and the total transferred in a given epoch this does not affect the size of the next iteration, which proceeds as normal (including decay factors etc.) as if the full transfer has been made. - `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. From 6764a423e90f2044b64299f3f37ac15a1cf6905f Mon Sep 17 00:00:00 2001 From: Jiajia-Cui <92106936+Jiajia-Cui@users.noreply.github.com> Date: Fri, 2 Feb 2024 11:41:21 +0000 Subject: [PATCH 0941/1171] feat: address comment from Barney 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 a3b24fe47..6806cca4a 100644 --- a/protocol/0057-TRAN-transfers.md +++ b/protocol/0057-TRAN-transfers.md @@ -109,7 +109,7 @@ A party should be able to configure the distribution of rewards by specifying th - `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. -- `cap_reward_fee_multiple` [optional] - if set, the actual amount of reward transferred to each public key during distribution for this transfer will be `min(calculated_reward, cap_reward_fee_multiple × fees_paid_this_epoch)`. If all keys are capped (i.e. the total amount of the transfer cannot be be sent to eligible keys without breaching the cap) then the remaining balance must either not leave the source account for an iteration of the recurring transfer, or be transferred back to the source account with no fee. If this occurs, and the total transferred in a given epoch this does not affect the size of the next iteration, which proceeds as normal (including decay factors etc.) as if the full transfer has been made. +- `cap_reward_fee_multiple` [optional] - if set, the actual amount of reward transferred to each public key during distribution for this transfer will be `min(calculated_reward, cap_reward_fee_multiple × fees_paid_this_epoch)`. If all keys are capped (i.e. the total amount of the transfer cannot be be sent to eligible keys without breaching the cap) then the remaining balance must be left in the reward pool and included in the distribution in future epochs. If this occurs, and the total transferred in a given epoch this does not affect the size of the next iteration, which proceeds as normal (including decay factors etc.) as if the full transfer has been made. - `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. From 4fde8c4235a18dad82eb8cf44fb6c6ab29c11ae6 Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Fri, 2 Feb 2024 13:50:00 +0000 Subject: [PATCH 0942/1171] feat: add details calculating reward --- 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 6806cca4a..46c1ab079 100644 --- a/protocol/0057-TRAN-transfers.md +++ b/protocol/0057-TRAN-transfers.md @@ -109,7 +109,7 @@ A party should be able to configure the distribution of rewards by specifying th - `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. -- `cap_reward_fee_multiple` [optional] - if set, the actual amount of reward transferred to each public key during distribution for this transfer will be `min(calculated_reward, cap_reward_fee_multiple × fees_paid_this_epoch)`. If all keys are capped (i.e. the total amount of the transfer cannot be be sent to eligible keys without breaching the cap) then the remaining balance must be left in the reward pool and included in the distribution in future epochs. If this occurs, and the total transferred in a given epoch this does not affect the size of the next iteration, which proceeds as normal (including decay factors etc.) as if the full transfer has been made. +- `cap_reward_fee_multiple` [optional] - if set, the actual amount of reward transferred to each public key during distribution for this transfer will be `min(calculated_reward, cap_reward_fee_multiple × fees_paid_this_epoch)`. When calculating how much of the reward each one is getting, if some is left from the applied cap, we recalculate on the remaining balance only for parties that have not reached their cap until the leftover is less than `transfer.fee.maxQuantumAmount x quantum`.If all keys are capped (i.e. the total amount of the transfer cannot be be sent to eligible keys without breaching the cap) then the remaining balance must be left in the reward pool and included in the distribution in future epochs. If this occurs, and the total transferred in a given epoch this does not affect the size of the next iteration, which proceeds as normal (including decay factors etc.) as if the full transfer has been made. - `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. From 2ebb67a2b64963715dd1e9c71afd158300a3e796 Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Fri, 2 Feb 2024 13:58:10 +0000 Subject: [PATCH 0943/1171] feat: add quantum --- 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 46c1ab079..48f790d70 100644 --- a/protocol/0057-TRAN-transfers.md +++ b/protocol/0057-TRAN-transfers.md @@ -109,7 +109,7 @@ A party should be able to configure the distribution of rewards by specifying th - `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. -- `cap_reward_fee_multiple` [optional] - if set, the actual amount of reward transferred to each public key during distribution for this transfer will be `min(calculated_reward, cap_reward_fee_multiple × fees_paid_this_epoch)`. When calculating how much of the reward each one is getting, if some is left from the applied cap, we recalculate on the remaining balance only for parties that have not reached their cap until the leftover is less than `transfer.fee.maxQuantumAmount x quantum`.If all keys are capped (i.e. the total amount of the transfer cannot be be sent to eligible keys without breaching the cap) then the remaining balance must be left in the reward pool and included in the distribution in future epochs. If this occurs, and the total transferred in a given epoch this does not affect the size of the next iteration, which proceeds as normal (including decay factors etc.) as if the full transfer has been made. +- `cap_reward_fee_multiple` [optional] - if set, the actual amount of reward transferred to each public key during distribution for this transfer will be `min(calculated_reward_in_quantum, cap_reward_fee_multiple × fees_paid_this_epoch_in_quantum)`. When calculating how much of the reward each one is getting, if some is left from the applied cap, we recalculate on the remaining balance only for parties that have not reached their cap until the leftover is less than `transfer.fee.maxQuantumAmount x quantum`.If all keys are capped (i.e. the total amount of the transfer cannot be be sent to eligible keys without breaching the cap) then the remaining balance must be left in the reward pool and included in the distribution in future epochs. If this occurs, and the total transferred in a given epoch this does not affect the size of the next iteration, which proceeds as normal (including decay factors etc.) as if the full transfer has been made. - `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. From 484e691d2e520e2c24e09a81b025aa55a5c68de1 Mon Sep 17 00:00:00 2001 From: gordsport Date: Fri, 2 Feb 2024 15:45:51 +0000 Subject: [PATCH 0944/1171] chore: add deatails about the max proposals in a batch This updates the spec to details the max number of proposals that can be submitted in a single batch proposal --- 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 d29c11836..ccb4473bd 100644 --- a/protocol/0028-GOVE-governance.md +++ b/protocol/0028-GOVE-governance.md @@ -472,6 +472,8 @@ If even one proposal within the batch would fail then the entire batch fails. 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: they enact in the order they appear in the batch. In particular asset update proposals may emit signed bundles to be submitted to the bridge on ethereum side (for withdrawal delay / threshold updates). +The number of individual proposals that can be submitted within a single batch is limited to 250. + ## APIs The core should expose via core APIs: From 2d30080697720f6d2027d58c390386e2ac6c6570 Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Mon, 5 Feb 2024 10:10:28 +0000 Subject: [PATCH 0945/1171] feat: remove redundant line --- 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 d489bff6b..083a82c18 100644 --- a/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md +++ b/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md @@ -56,7 +56,7 @@ In the example below there are 3 liquidity providers all bidding for their chose ### Stake-weighted-average method for setting the liquidity fee factor -The liquidity fee factor is set as the weighted average of the liquidity fee factors, with weights assigned based on the supplied stake from each liquidity provider, which can also account for the impact of one supplier's actions on others. +The liquidity fee factor is set as the weighted average of the liquidity fee factors, with weights assigned based on the supplied stake from each liquidity provider. #### Example for fee setting mechanism using the Stake-weighted-average method From 3557957530a7657821c316077ff60c8dbada9e71 Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Mon, 5 Feb 2024 12:30:28 +0000 Subject: [PATCH 0946/1171] feat: add minBalance parameter --- protocol/0062-SPAM-spam_protection.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/protocol/0062-SPAM-spam_protection.md b/protocol/0062-SPAM-spam_protection.md index 938b1f93d..33c8c84f7 100644 --- a/protocol/0062-SPAM-spam_protection.md +++ b/protocol/0062-SPAM-spam_protection.md @@ -63,7 +63,7 @@ The [on-chain referral program](./0083-RFPR-on_chain_referral_program.md) adds t - `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 `CreateReferralSet` and `UpdateReferralSet` transactions, a party must meet the staked governance tokens ($VEGA) threshold set by the network parameter `referralProgram.minStakedVegaTokens`. A party also must meet the balance holding threshold set by the network parameter `referralProgram.minBalance`. A party who does not meet this requirements 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 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`). @@ -97,6 +97,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.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). +- A party holding less than `referralProgram.minBalance x quantum` should have any `CreateReferralSet` transactions **pre-block** rejected (0062-SPAM-033) - 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 **pre-block** rejected (0062-SPAM-032). From 68ebc9eedde96da8372fd35f2dd66133dffff1db Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Mon, 5 Feb 2024 14:09:09 +0000 Subject: [PATCH 0947/1171] feat: address comments --- 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 33c8c84f7..29b62e1ac 100644 --- a/protocol/0062-SPAM-spam_protection.md +++ b/protocol/0062-SPAM-spam_protection.md @@ -63,9 +63,9 @@ The [on-chain referral program](./0083-RFPR-on_chain_referral_program.md) adds t - `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 also must meet the balance holding threshold set by the network parameter `referralProgram.minBalance`. A party who does not meet this requirements should have any transactions of the aforementioned types pre-block rejected. +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 also must meet the balance holding threshold set by the network parameter `spam.protection.referralProgram.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 requirements 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 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`). @@ -97,7 +97,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.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). -- A party holding less than `referralProgram.minBalance x quantum` should have any `CreateReferralSet` transactions **pre-block** rejected (0062-SPAM-033) +- A party holding less than `spam.protection.referralProgram.min.funds x quantum` should have any `CreateReferralSet` transactions **pre-block** rejected (0062-SPAM-033) - 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 **pre-block** rejected (0062-SPAM-032). From 587398b23701f12380d9c58c3c292b7cd7ade218 Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Mon, 5 Feb 2024 14:10:56 +0000 Subject: [PATCH 0948/1171] feat: add AC --- protocol/0062-SPAM-spam_protection.md | 1 + 1 file changed, 1 insertion(+) diff --git a/protocol/0062-SPAM-spam_protection.md b/protocol/0062-SPAM-spam_protection.md index 29b62e1ac..32529234f 100644 --- a/protocol/0062-SPAM-spam_protection.md +++ b/protocol/0062-SPAM-spam_protection.md @@ -98,6 +98,7 @@ More than 360 delegation changes in one epoch (or, respectively, the value of `s - 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). - A party holding less than `spam.protection.referralProgram.min.funds x quantum` should have any `CreateReferralSet` transactions **pre-block** rejected (0062-SPAM-033) +- A party holding no less than `spam.protection.referralProgram.min.funds x quantum` should not have any `CreateReferralSet` transactions **pre-block** rejected (0062-SPAM-035) - 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 **pre-block** rejected (0062-SPAM-032). From ef7ec48ff2543fcee0596f3b019499af962b2985 Mon Sep 17 00:00:00 2001 From: Gordsport <83510148+gordsport@users.noreply.github.com> Date: Mon, 5 Feb 2024 15:07:19 +0000 Subject: [PATCH 0949/1171] chore: add teams spam protection (#2157) Copies the changes made to the Colosseo branch here: - https://github.com/vegaprotocol/specs/pull/2156 --- protocol/0062-SPAM-spam_protection.md | 6 ++++-- protocol/features.json | 2 ++ 2 files changed, 6 insertions(+), 2 deletions(-) diff --git a/protocol/0062-SPAM-spam_protection.md b/protocol/0062-SPAM-spam_protection.md index eadf53d96..a9a5da152 100644 --- a/protocol/0062-SPAM-spam_protection.md +++ b/protocol/0062-SPAM-spam_protection.md @@ -63,9 +63,9 @@ The [on-chain referral program](./0083-RFPR-on_chain_referral_program.md) adds t - `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 `CreateReferralSet` and `UpdateReferralSet` transactions, a party must meet the staked governance tokens ($VEGA) threshold set by the network parameter `referralProgram.minStakedVegaTokens`. A party also must meet the balance holding threshold set by the network parameter `spam.protection.referralProgram.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 requirements 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 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`). @@ -112,6 +112,8 @@ 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.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). +- A party holding less than `spam.protection.referralProgram.min.funds x quantum` should have any `CreateReferralSet` transactions **pre-block** rejected (0062-SPAM-033). +- A party holding no less than `spam.protection.referralProgram.min.funds x quantum` should not have any `CreateReferralSet` transactions **pre-block** rejected (0062-SPAM-035). - 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 **pre-block** rejected (0062-SPAM-032). diff --git a/protocol/features.json b/protocol/features.json index eea74613c..9d42b9c14 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -52,6 +52,8 @@ "0088-PPRF-003", "0088-PPRF-004", "0088-PPRF-005", + "0062-SPAM-033", + "0062-SPAM-035", "0062-SPAM-037", "0062-SPAM-038", "0062-SPAM-039" From 5ff5625428fa027029e64a344538d696ff4d7d03 Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Mon, 5 Feb 2024 16:38:51 +0000 Subject: [PATCH 0950/1171] feat: add ac to 0019 --- protocol/0019-MCAL-margin_calculator.md | 29 +++++++++++++++++++++++++ 1 file changed, 29 insertions(+) diff --git a/protocol/0019-MCAL-margin_calculator.md b/protocol/0019-MCAL-margin_calculator.md index 37d07545d..9b264f713 100644 --- a/protocol/0019-MCAL-margin_calculator.md +++ b/protocol/0019-MCAL-margin_calculator.md @@ -167,6 +167,35 @@ There should be an additional amount `limit price x size x margin factor = 15910 - A market in an auction and party with a partially filled iceberg pegged order switches from cross margin mode to isolated margin mode the unfilled portion of the iceberg pegged order is cancelled (0019-MCAL-146) +- When a party holds only orders, increases the orders price, the orders will not uncross (0019-MCAL-160) + +- When a party holds orders and positions, and increases the orders price, the orders will not uncross (0019-MCAL-161) + +- When a party holds only orders, increases the orders size, the orders will not uncross (0019-MCAL-162) + +- When a party holds orders and positions, increases the order size, the orders will not uncross (0019-MCAL-163) + +- When a party holds only orders, decreases the orders price, the orders will not uncross (0019-MCAL-164) + +- When a party holds orders and positions, and decreases the orders price, the orders will not uncross (0019-MCAL-165) + +- When a party holds only orders, decreases the orders size, the orders will not uncross (0019-MCAL-166) + +- When a party holds orders and positions, decreases the order size, the orders will not uncross (0019-MCAL-167) + +- When a party holds orders and positions, decreases the orders price, the order will be stopped (becuase if the orders is fully filled and then party will distressed) (0019-MCAL-168) + +- When a party holds orders and positions, decreases the orders price, the order will be stopped (becuase if the orders is partially filled and then party will distressed) (0019-MCAL-169) + +- When a party holds orders and positions, decreases the orders price, the order will be fully filled (0019-MCAL-172) + +- When a party holds orders and positions, decreases the orders price, the order will be partially filled (0019-MCAL-173) + +- When a party holds orders and positions, decreases the orders price, the order will be stopped (becuase if the orders is fully filled and then their margin balance will be less than the margin maintenance level) (0019-MCAL-174) + +- When a party holds orders and positions, decreases the orders price, the order will be stopped (becuase if the orders is partially filled and then their margin balance will be less than the margin maintenance level) (0019-MCAL-175) + + **When a party is distressed:** - Open positions should be closed in the case of open positions dropping below maintenance margin level, active orders will remain active if closing positions does not lead order margin level to increase.(0019-MCAL-070) From 2d55aa4390491423145ef35bc289857957b71596 Mon Sep 17 00:00:00 2001 From: gordsport Date: Mon, 5 Feb 2024 16:56:13 +0000 Subject: [PATCH 0951/1171] chore: add features.json entries --- protocol/0019-MCAL-margin_calculator.md | 8 ++++---- protocol/features.json | 16 ++++++++++++++++ 2 files changed, 20 insertions(+), 4 deletions(-) diff --git a/protocol/0019-MCAL-margin_calculator.md b/protocol/0019-MCAL-margin_calculator.md index 9b264f713..94279897c 100644 --- a/protocol/0019-MCAL-margin_calculator.md +++ b/protocol/0019-MCAL-margin_calculator.md @@ -183,17 +183,17 @@ There should be an additional amount `limit price x size x margin factor = 15910 - When a party holds orders and positions, decreases the order size, the orders will not uncross (0019-MCAL-167) -- When a party holds orders and positions, decreases the orders price, the order will be stopped (becuase if the orders is fully filled and then party will distressed) (0019-MCAL-168) +- When a party holds orders and positions, decreases the orders price, the order will be stopped (because if the orders is fully filled and then party will distressed) (0019-MCAL-168) -- When a party holds orders and positions, decreases the orders price, the order will be stopped (becuase if the orders is partially filled and then party will distressed) (0019-MCAL-169) +- When a party holds orders and positions, decreases the orders price, the order will be stopped (because if the orders is partially filled and then party will distressed) (0019-MCAL-169) - When a party holds orders and positions, decreases the orders price, the order will be fully filled (0019-MCAL-172) - When a party holds orders and positions, decreases the orders price, the order will be partially filled (0019-MCAL-173) -- When a party holds orders and positions, decreases the orders price, the order will be stopped (becuase if the orders is fully filled and then their margin balance will be less than the margin maintenance level) (0019-MCAL-174) +- When a party holds orders and positions, decreases the orders price, the order will be stopped (because if the orders is fully filled and then their margin balance will be less than the margin maintenance level) (0019-MCAL-174) -- When a party holds orders and positions, decreases the orders price, the order will be stopped (becuase if the orders is partially filled and then their margin balance will be less than the margin maintenance level) (0019-MCAL-175) +- When a party holds orders and positions, decreases the orders price, the order will be stopped (because if the orders is partially filled and then their margin balance will be less than the margin maintenance level) (0019-MCAL-175) **When a party is distressed:** diff --git a/protocol/features.json b/protocol/features.json index 9d42b9c14..7217be25f 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -154,6 +154,22 @@ "0019-MCAL-151", "0019-MCAL-152", "0019-MCAL-153", + "0019-MCAL-160", + "0019-MCAL-160", + "0019-MCAL-160", + "0019-MCAL-161", + "0019-MCAL-162", + "0019-MCAL-163", + "0019-MCAL-164", + "0019-MCAL-165", + "0019-MCAL-166", + "0019-MCAL-167", + "0019-MCAL-168", + "0019-MCAL-169", + "0019-MCAL-172", + "0019-MCAL-173", + "0019-MCAL-174", + "0019-MCAL-175", "0019-MCAL-200", "0019-MCAL-201", "0019-MCAL-202", From 55a4c5bb98d62416f8c08a0f661d00de6562a400 Mon Sep 17 00:00:00 2001 From: gordsport Date: Mon, 5 Feb 2024 16:58:05 +0000 Subject: [PATCH 0952/1171] fix: dupe ACs --- protocol/features.json | 2 -- 1 file changed, 2 deletions(-) diff --git a/protocol/features.json b/protocol/features.json index 7217be25f..244806f4f 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -155,8 +155,6 @@ "0019-MCAL-152", "0019-MCAL-153", "0019-MCAL-160", - "0019-MCAL-160", - "0019-MCAL-160", "0019-MCAL-161", "0019-MCAL-162", "0019-MCAL-163", From f889c67edd2f98595d15af75b0b0ea6ec5aef408 Mon Sep 17 00:00:00 2001 From: Gordsport <83510148+gordsport@users.noreply.github.com> Date: Tue, 6 Feb 2024 10:54:44 +0000 Subject: [PATCH 0953/1171] chore: add update team spam ACs (#2159) * chore: add update team spam ACs Adds in ACs for also updating referral sets / teams and spam protection * fix: spelling * chore: Update protocol/0062-SPAM-spam_protection.md Co-authored-by: Jiajia-Cui <92106936+Jiajia-Cui@users.noreply.github.com> * chore: Update protocol/features.json Co-authored-by: Jiajia-Cui <92106936+Jiajia-Cui@users.noreply.github.com> * fix: net param name --------- Co-authored-by: Jiajia-Cui <92106936+Jiajia-Cui@users.noreply.github.com> --- protocol/0062-SPAM-spam_protection.md | 7 +++++-- protocol/features.json | 6 +++++- 2 files changed, 10 insertions(+), 3 deletions(-) diff --git a/protocol/0062-SPAM-spam_protection.md b/protocol/0062-SPAM-spam_protection.md index a9a5da152..fd5b559a6 100644 --- a/protocol/0062-SPAM-spam_protection.md +++ b/protocol/0062-SPAM-spam_protection.md @@ -112,8 +112,8 @@ 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.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). -- A party holding less than `spam.protection.referralProgram.min.funds x quantum` should have any `CreateReferralSet` transactions **pre-block** rejected (0062-SPAM-033). -- A party holding no less than `spam.protection.referralProgram.min.funds x quantum` should not have any `CreateReferralSet` transactions **pre-block** rejected (0062-SPAM-035). +- A party holding less than `spam.protection.referralSet.min.funds x quantum` should have any `CreateReferralSet` transactions **pre-block** rejected (0062-SPAM-033). +- A party holding no less than `spam.protection.referralSet.min.funds x quantum` should not have any `CreateReferralSet` transactions **pre-block** rejected (0062-SPAM-035). - 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 **pre-block** rejected (0062-SPAM-032). @@ -122,6 +122,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.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 **pre-block** rejected (0062-SPAM-036). - Given longer than `spam.protection.balanceSnapshotFrequency` has elapsed since a party deposited or transferred funds, a party who has less then `spam.protection.updatePartyProfile.min.funds` in their accounts should have any `UpdatePartyProfile` transactions **pre-block** rejected. All assets count towards this threshold and balances should be scaled appropriately by the assets quantum. (0062-SPAM-037). +- A party holding 2 assets, and each of the assets are less than `spam.protection.referralSet.min.funds` x quantum, but the sum of the 2 assets are greater than `spam.protection.referralSet.min.funds` x quantum, then the party should not have any `UpdateReferralSettransactions` pre-block rejected (0062-SPAM-042). +- A party holding less than `spam.protection.referralProgram.min.funds` x quantum should have any `UpdateReferralSettransactions` pre-block rejected (0062-SPAM-040). +- A party holding no less than `spam.protection.referralSet.min.funds` x quantum and staking no less than `referralProgram.minStakedVegaTokens` should not have any `UpdateReferralSettransactions` pre-block rejected (0062-SPAM-041). - A party who has submitted strictly more than `spam.protection.max.updatePartyProfile` `UpdatePartyProfile` transactions in an epoch should have any future `UpdatePartyProfile` transactions in that epoch **pre-block** rejected (0062-SPAM-038). - A party who has submitted more than `spam.protection.max.updatePartyProfile` `UpdatePartyProfile` transactions in the current epoch plus in the current block, should have their `UpdatePartyProfile` transactions submitted in the current block **pre-block** rejected (0062-SPAM-039). diff --git a/protocol/features.json b/protocol/features.json index 9d42b9c14..3312a49d4 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -54,9 +54,13 @@ "0088-PPRF-005", "0062-SPAM-033", "0062-SPAM-035", + "0062-SPAM-036", "0062-SPAM-037", "0062-SPAM-038", - "0062-SPAM-039" + "0062-SPAM-039", + "0062-SPAM-040", + "0062-SPAM-041", + "0062-SPAM-042" ] }, "Fixed size amendments": { From 9318b8b2fa92c68cf0416fbdcc6ecede33e2cd15 Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Tue, 6 Feb 2024 11:18:35 +0000 Subject: [PATCH 0954/1171] feat: add more ACs --- protocol/0019-MCAL-margin_calculator.md | 5 +++-- protocol/features.json | 1 + 2 files changed, 4 insertions(+), 2 deletions(-) diff --git a/protocol/0019-MCAL-margin_calculator.md b/protocol/0019-MCAL-margin_calculator.md index 94279897c..50ba8518b 100644 --- a/protocol/0019-MCAL-margin_calculator.md +++ b/protocol/0019-MCAL-margin_calculator.md @@ -183,9 +183,9 @@ There should be an additional amount `limit price x size x margin factor = 15910 - When a party holds orders and positions, decreases the order size, the orders will not uncross (0019-MCAL-167) -- When a party holds orders and positions, decreases the orders price, the order will be stopped (because if the orders is fully filled and then party will distressed) (0019-MCAL-168) +- When a party holds orders and positions, increase the order size, the order will be stopped (because their margin balance will be less than the margin maintenance level) (0019-MCAL-168) -- When a party holds orders and positions, decreases the orders price, the order will be stopped (because if the orders is partially filled and then party will distressed) (0019-MCAL-169) +- When a party holds orders and positions, decreases the orders size, the order and order margin will be update (0019-MCAL-169) - When a party holds orders and positions, decreases the orders price, the order will be fully filled (0019-MCAL-172) @@ -195,6 +195,7 @@ There should be an additional amount `limit price x size x margin factor = 15910 - When a party holds orders and positions, decreases the orders price, the order will be stopped (because if the orders is partially filled and then their margin balance will be less than the margin maintenance level) (0019-MCAL-175) +- When a party holds orders and positions, amend the orders price, the order will be partialy filled but order margin level will increase, so the rest of the order is canceled (0019-MCAL-176) **When a party is distressed:** diff --git a/protocol/features.json b/protocol/features.json index 244806f4f..f5d6e3969 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -168,6 +168,7 @@ "0019-MCAL-173", "0019-MCAL-174", "0019-MCAL-175", + "0019-MCAL-176", "0019-MCAL-200", "0019-MCAL-201", "0019-MCAL-202", From d9596e5472a5c3f1593b02c77c5bd5d5993c9077 Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Tue, 6 Feb 2024 11:49:03 +0000 Subject: [PATCH 0955/1171] chore: typo --- protocol/0019-MCAL-margin_calculator.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/protocol/0019-MCAL-margin_calculator.md b/protocol/0019-MCAL-margin_calculator.md index 50ba8518b..c7d374c70 100644 --- a/protocol/0019-MCAL-margin_calculator.md +++ b/protocol/0019-MCAL-margin_calculator.md @@ -195,7 +195,7 @@ There should be an additional amount `limit price x size x margin factor = 15910 - When a party holds orders and positions, decreases the orders price, the order will be stopped (because if the orders is partially filled and then their margin balance will be less than the margin maintenance level) (0019-MCAL-175) -- When a party holds orders and positions, amend the orders price, the order will be partialy filled but order margin level will increase, so the rest of the order is canceled (0019-MCAL-176) +- When a party holds orders and positions, amend the orders price, the order will be partially filled but order margin level will increase, so the rest of the order is cancelled (0019-MCAL-176) **When a party is distressed:** @@ -848,3 +848,4 @@ riskiest short: -1 ## SCENARIOS Scenarios found [here](https://docs.google.com/spreadsheets/d/1VXMdpgyyA9jp0hoWcIQTUFrhOdtu-fak/edit#gid=1586131462) + From e2c3afcef03f3a63a2c441af505773cb5a2fb0b2 Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Wed, 7 Feb 2024 12:19:20 +0000 Subject: [PATCH 0956/1171] feat: remove the maxQuantumAmount from reward cap --- 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 48f790d70..d72fb8ae7 100644 --- a/protocol/0057-TRAN-transfers.md +++ b/protocol/0057-TRAN-transfers.md @@ -109,7 +109,7 @@ A party should be able to configure the distribution of rewards by specifying th - `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. -- `cap_reward_fee_multiple` [optional] - if set, the actual amount of reward transferred to each public key during distribution for this transfer will be `min(calculated_reward_in_quantum, cap_reward_fee_multiple × fees_paid_this_epoch_in_quantum)`. When calculating how much of the reward each one is getting, if some is left from the applied cap, we recalculate on the remaining balance only for parties that have not reached their cap until the leftover is less than `transfer.fee.maxQuantumAmount x quantum`.If all keys are capped (i.e. the total amount of the transfer cannot be be sent to eligible keys without breaching the cap) then the remaining balance must be left in the reward pool and included in the distribution in future epochs. If this occurs, and the total transferred in a given epoch this does not affect the size of the next iteration, which proceeds as normal (including decay factors etc.) as if the full transfer has been made. +- `cap_reward_fee_multiple` [optional] - if set, the actual amount of reward transferred to each public key during distribution for this transfer will be `min(calculated_reward_in_quantum, cap_reward_fee_multiple × fees_paid_this_epoch_in_quantum)`. When calculating how much of the reward each one is getting, if some is left from the applied cap, we recalculate on the remaining balance only for parties that have not reached their cap until the leftover is less than `1 x quantum`.If all keys are capped (i.e. the total amount of the transfer cannot be be sent to eligible keys without breaching the cap) then the remaining balance must be left in the reward pool and included in the distribution in future epochs. If this occurs, and the total transferred in a given epoch this does not affect the size of the next iteration, which proceeds as normal (including decay factors etc.) as if the full transfer has been made. - `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. From 6b24770600cfe9169eff170ea18205297d639d05 Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Wed, 7 Feb 2024 12:46:03 +0000 Subject: [PATCH 0957/1171] feat: update asset unit --- 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 d72fb8ae7..cb28471b9 100644 --- a/protocol/0057-TRAN-transfers.md +++ b/protocol/0057-TRAN-transfers.md @@ -109,7 +109,7 @@ A party should be able to configure the distribution of rewards by specifying th - `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. -- `cap_reward_fee_multiple` [optional] - if set, the actual amount of reward transferred to each public key during distribution for this transfer will be `min(calculated_reward_in_quantum, cap_reward_fee_multiple × fees_paid_this_epoch_in_quantum)`. When calculating how much of the reward each one is getting, if some is left from the applied cap, we recalculate on the remaining balance only for parties that have not reached their cap until the leftover is less than `1 x quantum`.If all keys are capped (i.e. the total amount of the transfer cannot be be sent to eligible keys without breaching the cap) then the remaining balance must be left in the reward pool and included in the distribution in future epochs. If this occurs, and the total transferred in a given epoch this does not affect the size of the next iteration, which proceeds as normal (including decay factors etc.) as if the full transfer has been made. +- `cap_reward_fee_multiple` [optional] - if set, the actual amount of reward transferred to each public key during distribution for this transfer will be `min(calculated_reward_in_quantum, cap_reward_fee_multiple × fees_paid_this_epoch_in_quantum)`. When calculating how much of the reward each one is getting, if some is left from the applied cap, we recalculate on the remaining balance only for parties that have not reached their cap until the leftover is less than 1 reward asset unit and the maximum rounds of recalulation is 10. If all keys are capped (i.e. the total amount of the transfer cannot be be sent to eligible keys without breaching the cap) then the remaining balance must be left in the reward pool and included in the distribution in future epochs. If this occurs, and the total transferred in a given epoch this does not affect the size of the next iteration, which proceeds as normal (including decay factors etc.) as if the full transfer has been made. - `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. From 52a44713fc21f122fb6447d98afd5d26b4eefd78 Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Wed, 7 Feb 2024 12:49:41 +0000 Subject: [PATCH 0958/1171] chore: typo --- 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 cb28471b9..463b9204a 100644 --- a/protocol/0057-TRAN-transfers.md +++ b/protocol/0057-TRAN-transfers.md @@ -109,7 +109,7 @@ A party should be able to configure the distribution of rewards by specifying th - `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. -- `cap_reward_fee_multiple` [optional] - if set, the actual amount of reward transferred to each public key during distribution for this transfer will be `min(calculated_reward_in_quantum, cap_reward_fee_multiple × fees_paid_this_epoch_in_quantum)`. When calculating how much of the reward each one is getting, if some is left from the applied cap, we recalculate on the remaining balance only for parties that have not reached their cap until the leftover is less than 1 reward asset unit and the maximum rounds of recalulation is 10. If all keys are capped (i.e. the total amount of the transfer cannot be be sent to eligible keys without breaching the cap) then the remaining balance must be left in the reward pool and included in the distribution in future epochs. If this occurs, and the total transferred in a given epoch this does not affect the size of the next iteration, which proceeds as normal (including decay factors etc.) as if the full transfer has been made. +- `cap_reward_fee_multiple` [optional] - if set, the actual amount of reward transferred to each public key during distribution for this transfer will be `min(calculated_reward_in_quantum, cap_reward_fee_multiple × fees_paid_this_epoch_in_quantum)`. When calculating how much of the reward each one is getting, if some is left from the applied cap, we recalculate on the remaining balance only for parties that have not reached their cap until the leftover is less than 1 reward asset unit or the maximum rounds of recalculation is 10. If all keys are capped (i.e. the total amount of the transfer cannot be be sent to eligible keys without breaching the cap) then the remaining balance must be left in the reward pool and included in the distribution in future epochs. If this occurs, and the total transferred in a given epoch this does not affect the size of the next iteration, which proceeds as normal (including decay factors etc.) as if the full transfer has been made. - `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. From 0dac479f8fc8e27d44bcd0ae40bba96e274d57b2 Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Thu, 8 Feb 2024 16:14:04 +0000 Subject: [PATCH 0959/1171] feat: update margin slippage in AMM --- protocol/0019-MCAL-margin_calculator.md | 19 ++++++++++++++++--- 1 file changed, 16 insertions(+), 3 deletions(-) diff --git a/protocol/0019-MCAL-margin_calculator.md b/protocol/0019-MCAL-margin_calculator.md index 37d07545d..4e3acd3a2 100644 --- a/protocol/0019-MCAL-margin_calculator.md +++ b/protocol/0019-MCAL-margin_calculator.md @@ -606,6 +606,14 @@ maintenance_margin_long + max(open_volume, 0) * [ quantitative_model.risk_factors_long ] . [ Product.value(market_observable) ] + buy_orders * [ quantitative_model.risk_factors_long ] . [ Product.value(market_observable) ]`, ``` +For any sub-account running [AMM strategies], we would calculate it as follows: + +```formula +maintenance_margin_long + = max(product.value(market_observable * riskiest_long * market.linearSlippageFactor), 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 `slippage_volume = max( open_volume, 0 )`, @@ -644,6 +652,14 @@ maintenance_margin_short + 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) ]` ``` +For any sub-account running [AMM strategies], we would calculate it as follows: + +```formula +maintenance_margin_short + = max(mark_price * abs(riskiest short) * market.linearSlippageFactor, 0) + + abs(min( open_volume, 0 )) * [ quantitative_model.risk_factors_short ] . [ Product.value(market_observable) ] + abs +``` + where meanings of terms in Step 1 apply except for: `slippage_per_unit = max(0, Product.value(exit_price)-Product.value(market_observable))` @@ -755,11 +771,8 @@ riskiest_short = min( open_volume + sell_orders, 0 ) = min( 10 - 8, 0 ) = 0 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.linearSlippageFactor)), 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), 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 From c5767849cd1a7684f15c0757c8f267b3b49432d9 Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Thu, 8 Feb 2024 16:21:29 +0000 Subject: [PATCH 0960/1171] chore: format --- protocol/0019-MCAL-margin_calculator.md | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/protocol/0019-MCAL-margin_calculator.md b/protocol/0019-MCAL-margin_calculator.md index 4e3acd3a2..5c488a92a 100644 --- a/protocol/0019-MCAL-margin_calculator.md +++ b/protocol/0019-MCAL-margin_calculator.md @@ -610,8 +610,8 @@ For any sub-account running [AMM strategies], we would calculate it as follows: ```formula maintenance_margin_long - = max(product.value(market_observable * riskiest_long * market.linearSlippageFactor), 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(product.value(market_observable * riskiest_long * market.linearSlippageFactor), 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 @@ -656,8 +656,9 @@ For any sub-account running [AMM strategies], we would calculate it as follows: ```formula maintenance_margin_short - = max(mark_price * abs(riskiest short) * market.linearSlippageFactor, 0) - + abs(min( open_volume, 0 )) * [ quantitative_model.risk_factors_short ] . [ Product.value(market_observable) ] + abs + = max(mark_price * abs(riskiest short) * market.linearSlippageFactor, 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: From e3462059f46a9a281a997edabd696b493100758d Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Fri, 9 Feb 2024 12:14:07 +0000 Subject: [PATCH 0961/1171] feat: update margin formula --- protocol/0019-MCAL-margin_calculator.md | 89 ++++++------------------- 1 file changed, 19 insertions(+), 70 deletions(-) diff --git a/protocol/0019-MCAL-margin_calculator.md b/protocol/0019-MCAL-margin_calculator.md index 5c488a92a..b4e223f4e 100644 --- a/protocol/0019-MCAL-margin_calculator.md +++ b/protocol/0019-MCAL-margin_calculator.md @@ -602,44 +602,16 @@ with ```formula maintenance_margin_long - = max(min(riskiest_long * slippage_per_unit, product.value(market_observable) * (riskiest_long * market.linearSlippageFactor)), 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) ]`, -``` - -For any sub-account running [AMM strategies], we would calculate it as follows: - -```formula -maintenance_margin_long - = max(product.value(market_observable * riskiest_long * market.linearSlippageFactor), 0) + = max(product.value(market_observable) * riskiest_long * market.linearSlippageFactor, 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 -`slippage_volume = max( open_volume, 0 )`, - -and - -if `open_volume > 0` then - -`slippage_per_unit = max(0, Product.value(market_observable) - Product.value(exit_price))`, - -else `slippage_per_unit = 0`. - -where - `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. - -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.linearSlippageFactor)) = mark_price * (slippage_volume * market.linearSlippageFactor)` above. - ### **Step 2** If `riskiest short == 0` then `maintenance_margin_short = 0`. @@ -648,45 +620,28 @@ Else ```formula maintenance_margin_short - = max(min(abs(riskiest short) * slippage_per_unit, mark_price * (abs(riskiest short) * market.linearSlippageFactor), 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) ]` -``` - -For any sub-account running [AMM strategies], we would calculate it as follows: - -```formula -maintenance_margin_short - = max(mark_price * abs(riskiest short) * market.linearSlippageFactor, 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)]` + = max(mark_price * abs(riskiest short) * market.linearSlippageFactor, 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 = max(0, Product.value(exit_price)-Product.value(market_observable))` +where meanings of terms in Step 1 apply ### **Step 3** If `open_volume > 0`: -`maintenance_margin = max(min(open_volume * slippage_per_unit, product.value(market_observable) * (open_volume * market.maxSlippageFraction[1] + open_volume^2 * market.maxSlippageFraction[2])), 0) - + open_volume * [ quantitative_model.risk_factors_long ] . [ Product.value(market_observable) ]` -where - -`slippage_per_unit = max(0, Product.value(market_observable) - Product.value(exit_price))` +`maintenance_margin = max(product.value(market_observable) * (open_volume * market.maxSlippageFraction[1]), 0) + + open_volume * [quantitative_model.risk_factors_long] * [Product.value(market_observable) ]` If `open_volume < 0`: ```formula maintenance_margin - = max(min(abs(open_volume) * slippage_per_unit, mark_price * (abs(open_volume) * market.maxSlippageFraction[1] + abs(slippage_volume)^2 * market.maxSlippageFraction[2])), 0) - + abs(open_volume) * [ quantitative_model.risk_factors_short ] . [ Product.value(market_observable) ]` + = max(product.value(market_observable) * (abs(open_volume) * market.maxSlippageFraction[1]), 0) + + abs(open_volume) * [quantitative_model.risk_factors_short] * [Product.value(market_observable) ]` ``` -where - -`slippage_per_unit = max(0, Product.value(market_observable) - Product.value(exit_price))` - If `open_volume == 0`: `maintenance_margin = 0` @@ -709,8 +664,6 @@ Use the same calculation as above with the following re-defined: - 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 ### **Step 5** @@ -768,13 +721,9 @@ 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 = 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.linearSlippageFactor)), 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), 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 +maintenance_margin_long =max(product.value(market_observable) * (riskiest_long * market.linearSlippageFactor), 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(144*(14 * 0.25), 0) + 10 * 0.1 * 144 + 4 * 0.1 * 144 = 705.6 # Step 2 @@ -784,20 +733,20 @@ Since riskiest short == 0 then maintenance_margin_short = 0 Since open_volume == 10 -maintenance_margin = max(min(open_volume * slippage_per_unit, product.value(market_observable) * (open_volume * market.maxSlippageFraction[1] + open_volume^2 * market.maxSlippageFraction[2])), 0) +maintenance_margin = max(product.value(market_observable) * (open_volume * market.maxSlippageFraction[1] + open_volume^2 * market.maxSlippageFraction[2]), 0) + open_volume * [ 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 = max(min(476, 532.224), 0) + 10 * 0.1 * 144 = 620 + = max(144*(14 * 0.25 + 14 * 14 * 0.001), 0) + 10 * 0.1 * 144 = 676.2 # Step 4 -maintenance_margin_with_orders = max ( 677.6, 0) = 677.6 -order_margin = 677.6 - 620 = 57.6 +maintenance_margin_with_orders = max (705.6, 0) = 677.6 +order_margin = 705.6 - 676.2 = 29.4 # Step 5 -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 +collateral_release_level = 705.6 * collateral_release_scaling_factor = 705.6 * 1.1 +initial_margin = 705.6 * initial_margin_scaling_factor = 705.6 * 1.2 +search_level = 705.6 * search_level_scaling_factor = 705.6 * 1.3 ``` From 59d5596c7072da6d3362da74b0bd6a6562ae2f54 Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Fri, 9 Feb 2024 14:04:09 +0000 Subject: [PATCH 0962/1171] feat: update ACs --- protocol/0019-MCAL-margin_calculator.md | 39 ++++++++----------------- 1 file changed, 12 insertions(+), 27 deletions(-) diff --git a/protocol/0019-MCAL-margin_calculator.md b/protocol/0019-MCAL-margin_calculator.md index b4e223f4e..a8ac67f9a 100644 --- a/protocol/0019-MCAL-margin_calculator.md +++ b/protocol/0019-MCAL-margin_calculator.md @@ -8,16 +8,6 @@ - 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) @@ -34,9 +24,9 @@ sell 10 @ 100 100 ``` - then the maintenance margin for the party is `min(1 x (100000-15900), 15900 x 0.25 x 1) + 0.1 x 1 x 15900 = 5565`. (0019-MCAL-024) + then the maintenance margin for the party is `15900 x 0.25 x 1 + 0.1 x 1 x 15900 = 5565`. (0019-MCAL-210) -- In the same situation as above, if `market.linearSlippageFactor = 100`, (i.e. 10 000%) instead, then the margin for the party is `min(1 x (100000-15900), 15900 x 100 x 1) + 0.1 x 1 x 15900 = 85690`. (0019-MCAL-025) +- In the same situation as above, if `market.linearSlippageFactor = 100`, (i.e. 10 000%) instead, then the margin for the party is `15900 x 100 x 1 + 0.1 x 1 x 15900 = 85690`. (0019-MCAL-211) - If the `market.linearSlippageFactor` 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) @@ -51,7 +41,7 @@ sell 10 @ 100 100 ``` - then the dated future maintenance margin component for the party is `min(1 x (100000-15900), 15900 x 0.25 x 1) + 0.1 x 1 x 15900 = 5565`. The current accrued funding payment for the perpetual component is calculated using + then the dated future maintenance margin component for the party is `15900 x 0.25 x 1 + 0.1 x 1 x 15900 = 5565`. 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) @@ -256,11 +246,7 @@ There should be an additional amount `limit price x size x margin factor = 15910 sell 10 @ 100 100 ``` - the maintenance margin for the party is `min(1 x (100 000-159 00), 159 00 x 0.25 x 1) + 0.1 x 1 x 159 00 = 5565` - - for this market the party switches to isolated margin with `margin factor=0.9` then the party will have margin account balance of - `average entry price x current position x new margin factor = 57 500 x 1 x 0.9 = 6325` - the difference topped up from the party’s general account(0019-MCAL-233) + the maintenance margin for the party is `159 00 x 0.25 x 1 + 0.1 x 1 x 159 00 = 5565` for this market the party switches to isolated margin with `margin factor=0.9` then the party will have margin account balance of `average entry price x current position x new margin factor = 57 500 x 1 x 0.9 = 6325` the difference topped up from the party’s general account(0019-MCAL-233) - In isolated margin mode, a party `short 1@15 900`, `margin factor=0.9` and order book is @@ -274,7 +260,7 @@ There should be an additional amount `limit price x size x margin factor = 15910 the margin account will hold `average entry price x current position x new margin factor = 57 500 x 1 x 0.9 = 6325` - for this market the party switches to cross margin and the market has `market.linearSlippageFactor = 0.25`, `RF short = 0.1` then the maintenance margin for the party is `min(1 x (100 000-159 00), 159 00 x 0.25 x 1) + 0.1 x 1 x 159 00 = 5565` + for this market the party switches to cross margin and the market has `market.linearSlippageFactor = 0.25`, `RF short = 0.1` then the maintenance margin for the party is `159 00 x 0.25 x 1 + 0.1 x 1 x 159 00 = 5565` but if `5565 < collatoral release level` the maintenance margin will remain unchanged at `6325` the difference topped up from the party’s general account(0019-MCAL-232) @@ -337,7 +323,6 @@ There should be an additional amount `limit price x size x margin factor = 15910 - When the party has position -1 and order -3, and new long orders with size 3 will be offset(0019-MCAL-231) - **Check decimals:** - A feature test that checks margin in case market PDP > 0 is created and passes. (0019-MCAL-090) @@ -367,7 +352,7 @@ There should be an additional amount `limit price x size x margin factor = 15910 sell 10 @ 100 100 ``` - then the dated future maintenance margin component for the party is `min(1 x (100000-15900), 15900 x 0.25 x 1) + 0.1 x 1 x 15900 = 5565`. The current accrued funding payment for the perpetual component is calculated using + then the dated future maintenance margin component for the party is `15900 x 0.25 x 1 + 0.1 x 1 x 15900 = 5565`. 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) @@ -620,7 +605,7 @@ Else ```formula maintenance_margin_short - = max(mark_price * abs(riskiest short) * market.linearSlippageFactor, 0) + = max(product.value(market_observable) * abs(riskiest short) * market.linearSlippageFactor, 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)]` ``` @@ -631,14 +616,14 @@ where meanings of terms in Step 1 apply If `open_volume > 0`: -`maintenance_margin = max(product.value(market_observable) * (open_volume * market.maxSlippageFraction[1]), 0) +`maintenance_margin = max(product.value(market_observable) * (open_volume * market.linearSlippageFactor), 0) + open_volume * [quantitative_model.risk_factors_long] * [Product.value(market_observable) ]` If `open_volume < 0`: ```formula maintenance_margin - = max(product.value(market_observable) * (abs(open_volume) * market.maxSlippageFraction[1]), 0) + = max(product.value(market_observable) * (abs(open_volume) * market.linearSlippageFactor), 0) + abs(open_volume) * [quantitative_model.risk_factors_short] * [Product.value(market_observable) ]` ``` @@ -733,14 +718,14 @@ Since riskiest short == 0 then maintenance_margin_short = 0 Since open_volume == 10 -maintenance_margin = max(product.value(market_observable) * (open_volume * market.maxSlippageFraction[1] + open_volume^2 * market.maxSlippageFraction[2]), 0) +maintenance_margin = max(product.value(market_observable) * (open_volume * market.maxSlippageFraction[1]), 0) + open_volume * [ quantitative_model.risk_factors_long ] . [ Product.value(market_observable) ] - = max(144*(14 * 0.25 + 14 * 14 * 0.001), 0) + 10 * 0.1 * 144 = 676.2 + = max(144*(14 * 0.25), 0) + 10 * 0.1 * 144 = 648 # Step 4 maintenance_margin_with_orders = max (705.6, 0) = 677.6 -order_margin = 705.6 - 676.2 = 29.4 +order_margin = 705.6 - 648 = 47.6 # Step 5 From fce854d245c0a3f6047d3c8a81d395218cea9884 Mon Sep 17 00:00:00 2001 From: David Siska <62546419+davidsiska-vega@users.noreply.github.com> Date: Fri, 9 Feb 2024 14:18:35 +0000 Subject: [PATCH 0963/1171] feat: market update ACs for mark price and perps price (#2171) * feat: market update ACs for mark price and perps price * feat: market update ACs for mark price and perps price * feat: market update ACs for mark price and perps price * feat: market update ACs for mark price and perps price * feat: market update ACs for mark price and perps price * feat: market update ACs for mark price and perps price * chore: add ACs to feature.json file --------- Co-authored-by: gordsport --- protocol/0009-MRKP-mark_price.md | 5 +++++ protocol/0053-PERP-product_builtin_perpetual_future.md | 6 ++++++ protocol/features.json | 7 ++++++- 3 files changed, 17 insertions(+), 1 deletion(-) diff --git a/protocol/0009-MRKP-mark_price.md b/protocol/0009-MRKP-mark_price.md index dde1d7d92..ac34a06b8 100644 --- a/protocol/0009-MRKP-mark_price.md +++ b/protocol/0009-MRKP-mark_price.md @@ -132,6 +132,11 @@ Note that for calculating the median with an even number of entries we sort, pic - When `markPriceConfiguration: source weight` is provided then it must not be all `0` (0009-MRKP-059) + - Launch a cash settled futures market which uses the "Last Traded Price" mark price method. Submit a market update proposal to change this to a composite price with some chosen configuration. Observe that the new methodology is applied correctly from enactment onwards. (0009-MRKP-134). + +- Launch a perpetual futures market which uses the "Last Traded Price" mark price method. Submit a market update proposal to change this to a composite price with some chosen configuration. Observe that the new methodology is applied correctly from enactment onwards. (0009-MRKP-135). + + ### Example 1 - A typical path of a cash settled futures market from end of opening auction till expiry (use Algorithm 2 (ie median price))(0009-MRKP-040) 1. Market is in opening auction, no mark price. diff --git a/protocol/0053-PERP-product_builtin_perpetual_future.md b/protocol/0053-PERP-product_builtin_perpetual_future.md index ad26ec955..2dcfa6914 100644 --- a/protocol/0053-PERP-product_builtin_perpetual_future.md +++ b/protocol/0053-PERP-product_builtin_perpetual_future.md @@ -364,3 +364,9 @@ Assert that the scaling factor is applied before the funding cap is applied (0053-PERP-041). The upper and lower clamp values are being correctly validated as per the [parameters defined in the spec](https://github.com/vegaprotocol/specs/blob/palazzo/protocol/0053-PERP-product_builtin_perpetual_future.md#1-product-parameters). (0053-PERP-042). + +Launch a perpetual futures market which sets `internalCompositePrice` to `Nil` (mark price is used) for the "vega side price" for funding calculation. Submit a market update proposal to change this to a composite price with a configuration which uses the impact notional price from the order book. Observe that the new methodology for funding calculations is applied correctly from enactment onwards. (0053-PERP-044). + +Launch a perpetual futures market which sets `internalCompositePrice` to a configuration which uses the impact notional price from the order book. for the "vega side price" for funding calculation. Submit a market update proposal to change this `Nil` (so that mark price gets used for the vega side price). Observe that the new methodology for funding calculations is applied correctly from enactment onwards. (0053-PERP-045). + +Launch a perpetual futures market which uses the "Last Traded Price" for the "vega side price" for funding calculation. Submit a market update proposal to change this to a composite price with a configuration which uses the impact notional price from the order book. Observe that the new methodology for funding calculations is applied correctly from enactment onwards. (0053-PERP-046). diff --git a/protocol/features.json b/protocol/features.json index 8ca8154b3..4885d5f47 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -392,7 +392,12 @@ "0009-MRKP-127", "0009-MRKP-130", "0009-MRKP-131", - "0009-MRKP-132" + "0009-MRKP-132", + "0009-MRKP-134", + "0009-MRKP-135", + "0053-PERP-044", + "0053-PERP-045", + "0053-PERP-046" ] }, "Ethereum RPC and EVM based data sources": { From be504bea27ebfa2398c97a0ede234d5a5492d39a Mon Sep 17 00:00:00 2001 From: Witold Date: Fri, 2 Feb 2024 19:00:32 +0100 Subject: [PATCH 0964/1171] refactor: AC clarifications --- non-protocol-specs/0012-NP-LIPE-liquidation-price-estimate.md | 2 +- non-protocol-specs/0013-NP-POSE-position-estimate.md | 2 +- 2 files changed, 2 insertions(+), 2 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 4371262ca..2c95dbe48 100644 --- a/non-protocol-specs/0012-NP-LIPE-liquidation-price-estimate.md +++ b/non-protocol-specs/0012-NP-LIPE-liquidation-price-estimate.md @@ -57,5 +57,5 @@ When including orders we sort the orders in the order they will get filled in (d 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 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) +1. There's no difference in the estimate for an open volume (use `open_volume_only` field) and that with `0` open volume and market order of the same size (use `including_buy_orders` or `including_sell_orders` depending on the order side). (0012-NP-LIPE-006) 1. When margining mode gets successfully changed to isolated margin mode and party has non-zero general account balance afterwards than its liquidation price estimate for all cases (position only, with buy orders, with sell orders) moves closer to the current mark price (compared to cross-margin figure). (0012-NP-LIPE-007) diff --git a/non-protocol-specs/0013-NP-POSE-position-estimate.md b/non-protocol-specs/0013-NP-POSE-position-estimate.md index 49700a839..e047de528 100644 --- a/non-protocol-specs/0013-NP-POSE-position-estimate.md +++ b/non-protocol-specs/0013-NP-POSE-position-estimate.md @@ -46,7 +46,7 @@ The endpoint request contains additional optional argument `scale_liquidation_pr ## Acceptance criteria 1. In isolated margin mode the request with `0` open volume and one or more limit orders specified results in a non-zero order margin in the margin level estimate and margin mode correctly representing isolated margin mode. (0013-NP-POSE-001) -1. When account balances are set to `0` the collateral increase figure per specified theoretical position correctly approximates the actual margin and order margin account balances for a party which opens such a position. (0013-NP-POSE-002) +1. When account balances are set to `0` and market has slippage factors set to `0`, the collateral increase figure per specified theoretical position correctly approximates the actual margin and order margin account balances for a party which opens such a position. (0013-NP-POSE-002) 1. When response for a given request contains figure `x` as the collateral increase best case then resubmitting the request with margin account balance increased by `x` should result in `0` collateral increase estimate for the best case. When increasing the margin account balance in the request further the collateral increase should remain at `0`. Same should be true when the above is repeated for the worst case. (0013-NP-POSE-003) 1. In isolated margin mode increasing general account balance specified in the request has no impact on the collateral increase estimate and the liquidation price estimate. (0013-NP-POSE-004) 1. In isolated margin mode the liquidation price estimate for a position with non-zero additional margin requirement with `include_collateral_increase_in_available_collateral` argument set to `true` results in liquidation price which is closer to the current mark price than the result obtained with argument set to `false`. (0013-NP-POSE-005) From 13ecbcd2fa16edbd3f084f9caf8b72256589b8d6 Mon Sep 17 00:00:00 2001 From: Witold Date: Mon, 5 Feb 2024 14:13:51 +0100 Subject: [PATCH 0965/1171] refactor: amend 0012-NP-LIPE-005 --- non-protocol-specs/0012-NP-LIPE-liquidation-price-estimate.md | 4 ++-- 1 file changed, 2 insertions(+), 2 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 2c95dbe48..f99d097a6 100644 --- a/non-protocol-specs/0012-NP-LIPE-liquidation-price-estimate.md +++ b/non-protocol-specs/0012-NP-LIPE-liquidation-price-estimate.md @@ -55,7 +55,7 @@ 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 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. An estimate is obtained for a long position with multiple limit sell orders 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 buy orders with the absolute value of the total remaining size of the orders less than the open volume. The estimated liquidation price with buy 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 buy orders. As the price keeps moving in small increments the liquidation happens within the originally estimated range (with buy orders) (0012-NP-LIPE-005) 1. There's no difference in the estimate for an open volume (use `open_volume_only` field) and that with `0` open volume and market order of the same size (use `including_buy_orders` or `including_sell_orders` depending on the order side). (0012-NP-LIPE-006) 1. When margining mode gets successfully changed to isolated margin mode and party has non-zero general account balance afterwards than its liquidation price estimate for all cases (position only, with buy orders, with sell orders) moves closer to the current mark price (compared to cross-margin figure). (0012-NP-LIPE-007) From cc16f113c7934a4c4c70d2324c698054ef7f50c1 Mon Sep 17 00:00:00 2001 From: Witold Date: Wed, 7 Feb 2024 13:15:13 +0100 Subject: [PATCH 0966/1171] refactor: clarify and extend liquidation ACs --- .../0012-NP-LIPE-liquidation-price-estimate.md | 10 ++++++---- non-protocol-specs/0013-NP-POSE-position-estimate.md | 6 +++--- 2 files changed, 9 insertions(+), 7 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 f99d097a6..6d9760eab 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 \cdot \text{risk factor}) + V \cdot \text{constant}, +\text{collateral available} + V(S^{\text{liquidation}}-S^\text{current}) = S^{\text{liquidation}} (\abs{V} \cdot \text{linear slippage factor}+\abs{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{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} - V \cdot \text{constant}}{V \cdot \text{linear slippage factor}+V \cdot \text{risk factor}-V} +S^{\text{liquidation}} = \frac{\text{collateral available}-V \cdot S^\text{current} - V \cdot \text{constant}}{\abs{V} \cdot \text{linear slippage factor}+\abs{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). @@ -55,7 +55,9 @@ 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 orders 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 buy orders with the absolute value of the total remaining size of the orders less than the open volume. The estimated liquidation price with buy 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 buy orders. As the price keeps moving in small increments the liquidation happens within the originally estimated range (with buy orders) (0012-NP-LIPE-005) +1. An estimate for cross-margin mode with `include_collateral_increase_in_available_collateral` set to `true` is obtained for a long position with multiple limit sell orders 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 for cross-margin mode with `include_collateral_increase_in_available_collateral` set to `true` is obtained for a short position with multiple limit buy orders with the absolute value of the total remaining size of the orders less than the open volume. The estimated liquidation price with buy 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 buy orders. As the price keeps moving in small increments the liquidation happens within the originally estimated range (with buy orders) (0012-NP-LIPE-005) 1. There's no difference in the estimate for an open volume (use `open_volume_only` field) and that with `0` open volume and market order of the same size (use `including_buy_orders` or `including_sell_orders` depending on the order side). (0012-NP-LIPE-006) 1. When margining mode gets successfully changed to isolated margin mode and party has non-zero general account balance afterwards than its liquidation price estimate for all cases (position only, with buy orders, with sell orders) moves closer to the current mark price (compared to cross-margin figure). (0012-NP-LIPE-007) +1. An estimate for isolated margin mode with `include_collateral_increase_in_available_collateral` set to `true` is obtained for a short position with open sell orders. As the price keeps moving in small increments the liquidation happens within the originally estimated range (`open_volume_only` estimate). The sell orders and order margin account balance remain unchanged. (0012-NP-LIPE-008) +1. An estimate for isolated margin mode with `include_collateral_increase_in_available_collateral` set to `true` is obtained for a long position with open buy orders. As the price keeps moving in small increments the liquidation happens within the originally estimated range (`open_volume_only` estimate). The buy orders and order margin account balance remain unchanged. (0012-NP-LIPE-009) diff --git a/non-protocol-specs/0013-NP-POSE-position-estimate.md b/non-protocol-specs/0013-NP-POSE-position-estimate.md index e047de528..3ab57649a 100644 --- a/non-protocol-specs/0013-NP-POSE-position-estimate.md +++ b/non-protocol-specs/0013-NP-POSE-position-estimate.md @@ -35,11 +35,11 @@ Liquidation price estimate as specified in [0012-NP-LIPE-liquidation-price-estim Depending on the [margining mode](../protocol/0019-MCAL-margin_calculator.md#margining-modes) selected by the party for the market on which its position is being considered the $\text{collateral available}$ will differ. -Cross-margin mode: $\text{collateral available} = \text{margin account balance} + \text{general account balance}$. +Cross-margin mode: $\text{collateral available} = \text{margin account balance} + \text{general account balance} + \text{order margin account balance}$. -Isolated margin mode: $\text{collateral available} = \text{margin account balance} + \text{order margin account balance}$. +Isolated margin mode: $\text{collateral available} = \text{margin account balance}$. -The position estimate request has an additional `include_collateral_increase_in_available_collateral` argument. It's relevant for the isolated margin mode: when set to `false` the collateral available used in liquidation price estimate will be the sum of the specified margin and order margin accounts only. When set to `true` the collateral increase estimated for the specified position will also be included in the available collateral. +The position estimate request has an additional `include_collateral_increase_in_available_collateral` argument. It's relevant for the isolated margin mode: when set to `false` the collateral available used in liquidation price estimate will be the margin account balance only. When set to `true` the portion of the collateral increase estimated for the specified position only (not for the additional orders) will also be included in the available collateral. The endpoint request contains additional optional argument `scale_liquidation_price_to_market_decimals`. When set to `false` the liquidation price estimates are scaled to asset decimal places, when set to `true` these estimates are scaled to market decimal places. From 1e7bbb7020cbf8e2aa04104ae752b9abcced3cd1 Mon Sep 17 00:00:00 2001 From: Witold Date: Fri, 9 Feb 2024 15:57:26 +0100 Subject: [PATCH 0967/1171] refactor: additional clarifications --- non-protocol-specs/0012-NP-LIPE-liquidation-price-estimate.md | 4 ++-- non-protocol-specs/0013-NP-POSE-position-estimate.md | 2 +- 2 files 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 6d9760eab..6f47894f5 100644 --- a/non-protocol-specs/0012-NP-LIPE-liquidation-price-estimate.md +++ b/non-protocol-specs/0012-NP-LIPE-liquidation-price-estimate.md @@ -55,8 +55,8 @@ 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 for cross-margin mode with `include_collateral_increase_in_available_collateral` set to `true` is obtained for a long position with multiple limit sell orders 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 for cross-margin mode with `include_collateral_increase_in_available_collateral` set to `true` is obtained for a short position with multiple limit buy orders with the absolute value of the total remaining size of the orders less than the open volume. The estimated liquidation price with buy 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 buy orders. As the price keeps moving in small increments the liquidation happens within the originally estimated range (with buy orders) (0012-NP-LIPE-005) +1. An estimate for cross-margin mode with `include_collateral_increase_in_available_collateral` set to `true` is obtained for a long position with multiple limit sell orders with the absolute value of the total remaining size of the orders less than the open volume. The general account balance should be set to `0` in the query and the margin account balance should be set to the maintenance margin for the chosen position. Orders should be chosen so that the liquidation price estimate with sell orders is non-zero (otherwise the party is collateralised up to a point that it will never get liquidated if these orders fill). 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 for cross-margin mode with `include_collateral_increase_in_available_collateral` set to `true` is obtained for a short position with multiple limit buy orders with the absolute value of the total remaining size of the orders less than the open volume. The general account balance should be set to `0` in the query and the margin account balance should be set to the maintenance margin for the chosen position. The estimated liquidation price with buy 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 buy orders. As the price keeps moving in small increments the liquidation happens within the originally estimated range (with buy orders) (0012-NP-LIPE-005) 1. There's no difference in the estimate for an open volume (use `open_volume_only` field) and that with `0` open volume and market order of the same size (use `including_buy_orders` or `including_sell_orders` depending on the order side). (0012-NP-LIPE-006) 1. When margining mode gets successfully changed to isolated margin mode and party has non-zero general account balance afterwards than its liquidation price estimate for all cases (position only, with buy orders, with sell orders) moves closer to the current mark price (compared to cross-margin figure). (0012-NP-LIPE-007) 1. An estimate for isolated margin mode with `include_collateral_increase_in_available_collateral` set to `true` is obtained for a short position with open sell orders. As the price keeps moving in small increments the liquidation happens within the originally estimated range (`open_volume_only` estimate). The sell orders and order margin account balance remain unchanged. (0012-NP-LIPE-008) diff --git a/non-protocol-specs/0013-NP-POSE-position-estimate.md b/non-protocol-specs/0013-NP-POSE-position-estimate.md index 3ab57649a..f7d0ba95b 100644 --- a/non-protocol-specs/0013-NP-POSE-position-estimate.md +++ b/non-protocol-specs/0013-NP-POSE-position-estimate.md @@ -46,7 +46,7 @@ The endpoint request contains additional optional argument `scale_liquidation_pr ## Acceptance criteria 1. In isolated margin mode the request with `0` open volume and one or more limit orders specified results in a non-zero order margin in the margin level estimate and margin mode correctly representing isolated margin mode. (0013-NP-POSE-001) -1. When account balances are set to `0` and market has slippage factors set to `0`, the collateral increase figure per specified theoretical position correctly approximates the actual margin and order margin account balances for a party which opens such a position. (0013-NP-POSE-002) +1. When account balances are set to `0` and market has slippage factors set to `0`, the collateral increase figure per specified theoretical position correctly approximates (absolute relative difference of less than $10^{-6}$) the actual margin and order margin account balances for a party which opens such a position. (0013-NP-POSE-002) 1. When response for a given request contains figure `x` as the collateral increase best case then resubmitting the request with margin account balance increased by `x` should result in `0` collateral increase estimate for the best case. When increasing the margin account balance in the request further the collateral increase should remain at `0`. Same should be true when the above is repeated for the worst case. (0013-NP-POSE-003) 1. In isolated margin mode increasing general account balance specified in the request has no impact on the collateral increase estimate and the liquidation price estimate. (0013-NP-POSE-004) 1. In isolated margin mode the liquidation price estimate for a position with non-zero additional margin requirement with `include_collateral_increase_in_available_collateral` argument set to `true` results in liquidation price which is closer to the current mark price than the result obtained with argument set to `false`. (0013-NP-POSE-005) From 81936ff98091cd87ade0593f78db8b722befb9a4 Mon Sep 17 00:00:00 2001 From: Charlie <99198652+cdummett@users.noreply.github.com> Date: Wed, 14 Feb 2024 11:07:48 +0000 Subject: [PATCH 0968/1171] feat: update fees on auction exit AC (#2173) --- protocol/0080-SPOT-product_builtin_spot.md | 2 +- protocol/cosmic-features.json | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/protocol/0080-SPOT-product_builtin_spot.md b/protocol/0080-SPOT-product_builtin_spot.md index f7e30a4c9..38fd258a3 100644 --- a/protocol/0080-SPOT-product_builtin_spot.md +++ b/protocol/0080-SPOT-product_builtin_spot.md @@ -132,5 +132,5 @@ Price-monitoring auctions are still required and should be implemented following 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. If the fee rates change for any reason within an auction, when the auction exits the amount required to cover fees must be recalculated. If a party does not have enough funds to cover the increase their order should be stopped with a clear return code. (0080-SPOT-021). 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/cosmic-features.json b/protocol/cosmic-features.json index 571708e67..fa19e42d6 100644 --- a/protocol/cosmic-features.json +++ b/protocol/cosmic-features.json @@ -585,8 +585,8 @@ "0080-SPOT-016", "0080-SPOT-017", "0080-SPOT-018", - "0080-SPOT-019", "0080-SPOT-020", + "0080-SPOT-021", "0081-SUCM-004", "0044-LIME-029", "0044-LIME-043", From 2d29824d9ad946fc68aa553a6bc83827f84aa06c Mon Sep 17 00:00:00 2001 From: Gordsport <83510148+gordsport@users.noreply.github.com> Date: Wed, 14 Feb 2024 12:11:20 +0000 Subject: [PATCH 0969/1171] feat: Add extra validator ranking reward metric AC (#2174) * feat: Add extra validator ranking reward metric AC Adds an extra validator ranking reward metric AC: For reward metrics relating to trading, an individual must meet the staking requirement AND notional time-weighted average position requirement) 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 or the market creation reward metric. e.g. For a party that is a consensus or standby validator, the staking requirement and notional time-weighted average position requirement do not apply to their validator ranking metric * chore: split AC into 3 * fix: remove old AC --- protocol/0056-REWA-rewards_overview.md | 3 +++ protocol/features.json | 3 +++ 2 files changed, 6 insertions(+) diff --git a/protocol/0056-REWA-rewards_overview.md b/protocol/0056-REWA-rewards_overview.md index 169ff1743..940b939d6 100644 --- a/protocol/0056-REWA-rewards_overview.md +++ b/protocol/0056-REWA-rewards_overview.md @@ -988,6 +988,9 @@ At the end of epoch 2, 10000 VEGA rewards should be distributed to the `ETHUSDT` - 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). +- For a party that is a consensus or standby validator, the [staking requirement](https://github.com/vegaprotocol/specs/blob/palazzo/protocol/0057-TRAN-transfers.md#recurring-transfers-to-reward-accounts) and [notional time-weighted average position requirement](https://github.com/vegaprotocol/specs/blob/palazzo/protocol/0057-TRAN-transfers.md#recurring-transfers-to-reward-accounts) do not apply to their validator ranking metric. (0056-REWA-109). +- A party does not need to meet the staking requirements and notional time-weighted average position set in the recurring transfer for market creation reward metric. (0056-REWA-110). +- For reward metrics relating to trading, an individual must meet the [staking requirement](https://github.com/vegaprotocol/specs/blob/palazzo/protocol/0057-TRAN-transfers.md#recurring-transfers-to-reward-accounts) AND [notional time-weighted average position requirement](https://github.com/vegaprotocol/specs/blob/palazzo/protocol/0056-REWA-rewards_overview.md#market-creation-reward-metrics) set in the recurring transfer. (0056-REWA-111). ### Distribution Strategy diff --git a/protocol/features.json b/protocol/features.json index 4885d5f47..f06f5f99e 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -37,6 +37,9 @@ "0056-REWA-106", "0056-REWA-107", "0056-REWA-108", + "0056-REWA-109", + "0056-REWA-110", + "0056-REWA-111", "0083-RFPR-052", "0083-RFPR-059", "0083-RFPR-060", From 1dda34a0c11b826af62c6f84984ad63a1e8e03dd Mon Sep 17 00:00:00 2001 From: Witold Date: Thu, 15 Feb 2024 10:42:01 +0100 Subject: [PATCH 0970/1171] refactor: amend a few perp ACs --- protocol/0019-MCAL-margin_calculator.md | 26 ++++++++++++------------- 1 file changed, 13 insertions(+), 13 deletions(-) diff --git a/protocol/0019-MCAL-margin_calculator.md b/protocol/0019-MCAL-margin_calculator.md index c7d374c70..349fdea31 100644 --- a/protocol/0019-MCAL-margin_calculator.md +++ b/protocol/0019-MCAL-margin_calculator.md @@ -65,22 +65,22 @@ = 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 = 5565 + 0.5 * 0.16 * 1 = 5565.08` (0019-MCAL-026) + - If `s_twap = 1600`, `f_twap = 1590` `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 = 556.5 + 0.5 * 0.16 * 1 = 556.58` (0019-MCAL-026) - 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 = 5565 + 0.5 * 70 * 1 = 5600` (0019-MCAL-027) - - However is position is instead `-1`, with the same margin requirement, if `margin funding factor = 0.5`, `total margin requirement = futures margin + funding margin = 5565 + 0.5 * max(0, 70 * -1) = 5565`(0019-MCAL-030) + - Then with `s_twap = 1600`, `clamp_upper_bound = 0.05` and `f_twap = 1500`, `funding_payment = 1500 + 1600 * (0.05 - 1) = -20` + - Thus, with `margin funding factor = 0.5`, `total margin requirement = futures margin + funding margin = 525 + 0.5 * max(0, -20 * 1) = 525` (0019-MCAL-027) + - However is position is instead `-1`, with the same margin requirement, if `margin funding factor = 0.5`, `total margin requirement = futures margin + funding margin = 525 + 0.5 * max(0, -20 * -1 = 535)`(0019-MCAL-030) - 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 = 5565 + 0.5 * max(0, -90 * 1) = 5565` (0019-MCAL-028) - - However is position is instead `-1`, with the same margin requirement, if `margin funding factor = 0.5`, `total margin requirement = futures margin + funding margin = 5565 + 0.5 * max(0, -90 * -1) = 5610`(0019-MCAL-029) + - Then with `s_twap = 1600`, `clamp_lower_bound = -0.05` and `f_twap = 1700`, `funding_payment = 1700 + 1600 * (-0.05 - 1) = 20` + - Thus, with `margin funding factor = 0.5`, `total margin requirement = futures margin + funding margin = 595 + 0.5 * max(0, 20 * 1) = 605` (0019-MCAL-028) + - However is position is instead `-1`, with the same margin requirement, if `margin funding factor = 0.5`, `total margin requirement = futures margin + funding margin = 595 + 0.5 * max(0, 20 * -1) = 595`(0019-MCAL-029) ## Acceptance Criteria (Isolated-margin) @@ -411,8 +411,8 @@ There should be an additional amount `limit price x size x margin factor = 15910 = 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 = 5565 + 0.5 * 0.16 * 1 = 5565.08` (0019-MCAL-053) + - If `s_twap = 1600`, `f_twap=1590`, `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 = 556.5 + 0.5 * 0.16 * 1 = 556.58` (0019-MCAL-053) - If instead - `clamp_upper_bound*s_twap < max(clamp_lower_bound*s_twap, (1 + delta_t * interest_rate)*s_twap-f_twap)` @@ -424,9 +424,9 @@ There should be an additional amount `limit price x size x margin factor = 15910 - 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 = 5565 + 0.5 * max(0, -90 * 1) = 5565` (0019-MCAL-055) - - However is position is instead `-1`, with the same margin requirement, if `margin funding factor = 0.5`, `total margin requirement = futures margin + funding margin = 5565 + 0.5 * max(0, -90 * -1) = 5610`(0019-MCAL-056) + - Then with `s_twap = 1600`, `clamp_lower_bound = -0.05` and `f_twap = 1700`, `funding_payment = 1700 + 1600 * (-0.05 - 1) = 20` + - Thus, with `margin funding factor = 0.5`, `total margin requirement = futures margin + funding margin = 595 + 0.5 * max(0, 20 * 1) = 605` (0019-MCAL-055) + - However is position is instead `-1`, with the same margin requirement, if `margin funding factor = 0.5`, `total margin requirement = futures margin + funding margin = 595 + 0.5 * max(0, 20 * -1) = 595`(0019-MCAL-056) ## Acceptance Criteria (Protocol upgrade) From 8f1d42aa9d91207c93bf645d8e9659ccf19d236b Mon Sep 17 00:00:00 2001 From: Sohill-Patel <85170301+Sohill-Patel@users.noreply.github.com> Date: Thu, 15 Feb 2024 11:56:26 +0000 Subject: [PATCH 0971/1171] chore: remove dup ac --- protocol/0056-REWA-rewards_overview.md | 1 - protocol/features.json | 1 - 2 files changed, 2 deletions(-) diff --git a/protocol/0056-REWA-rewards_overview.md b/protocol/0056-REWA-rewards_overview.md index 940b939d6..34b74508b 100644 --- a/protocol/0056-REWA-rewards_overview.md +++ b/protocol/0056-REWA-rewards_overview.md @@ -990,7 +990,6 @@ At the end of epoch 2, 10000 VEGA rewards should be distributed to the `ETHUSDT` - If a party is not a consensus or standby validator their validator ranking reward metric should be set to `0` (0056-REWA-092). - For a party that is a consensus or standby validator, the [staking requirement](https://github.com/vegaprotocol/specs/blob/palazzo/protocol/0057-TRAN-transfers.md#recurring-transfers-to-reward-accounts) and [notional time-weighted average position requirement](https://github.com/vegaprotocol/specs/blob/palazzo/protocol/0057-TRAN-transfers.md#recurring-transfers-to-reward-accounts) do not apply to their validator ranking metric. (0056-REWA-109). - A party does not need to meet the staking requirements and notional time-weighted average position set in the recurring transfer for market creation reward metric. (0056-REWA-110). -- For reward metrics relating to trading, an individual must meet the [staking requirement](https://github.com/vegaprotocol/specs/blob/palazzo/protocol/0057-TRAN-transfers.md#recurring-transfers-to-reward-accounts) AND [notional time-weighted average position requirement](https://github.com/vegaprotocol/specs/blob/palazzo/protocol/0056-REWA-rewards_overview.md#market-creation-reward-metrics) set in the recurring transfer. (0056-REWA-111). ### Distribution Strategy diff --git a/protocol/features.json b/protocol/features.json index f06f5f99e..a8bf86786 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -39,7 +39,6 @@ "0056-REWA-108", "0056-REWA-109", "0056-REWA-110", - "0056-REWA-111", "0083-RFPR-052", "0083-RFPR-059", "0083-RFPR-060", From 04fe51a7236b8995f8f72f11a1fa64d930424e05 Mon Sep 17 00:00:00 2001 From: Witold Date: Thu, 15 Feb 2024 14:51:36 +0100 Subject: [PATCH 0972/1171] refactor: modify AC --- .../0013-NP-POSE-position-estimate.md | 13 ++++++---- protocol/features.json | 25 ++++++++++++++----- 2 files changed, 27 insertions(+), 11 deletions(-) diff --git a/non-protocol-specs/0013-NP-POSE-position-estimate.md b/non-protocol-specs/0013-NP-POSE-position-estimate.md index f7d0ba95b..b2c83f0b7 100644 --- a/non-protocol-specs/0013-NP-POSE-position-estimate.md +++ b/non-protocol-specs/0013-NP-POSE-position-estimate.md @@ -21,13 +21,16 @@ Margin level estimate contains the levels specified in [0019-MCAL-margin_calcula ### Collateral increase estimate -Collateral increase estimate provides an approximate amount of the additional funds above the specified margin and order margin account level balances required. - -In cross-margin mode it's the difference between the initial margin level estimate for the specified position and the margin account balance specified in the request. +Collateral increase estimate provides an approximate difference between the current collateral and the resulting collateral for the specified theoretical position. In isolated margin mode it's the difference between collateral required to support the specified position and orders with the margin factor provided and the balance of margin and order margin accounts specified in the request. -Collateral increase estimate is always floored at 0, it only tries to estimate the increase in the collateral request, not the potential collateral release amount. If the request is made such that the account balances specified are equal to or greater than the required margin then 0 is returned. +In cross-margin mode: + +- if the collateral required for the specified position is higher than the combined margin and order margin account balances then it's the difference between the initial margin level for the specified position and the sum of those account balances. +- if the collateral required for the specified position is lower than the combined margin and order margin account balances then: + - if the combined account balances are above the margin release level for the specified position: it's the difference between the initial margin level for the specified position and the sum of those account balances, + - otherwise it's `0`. ### Liquidation price estimate @@ -47,7 +50,7 @@ The endpoint request contains additional optional argument `scale_liquidation_pr 1. In isolated margin mode the request with `0` open volume and one or more limit orders specified results in a non-zero order margin in the margin level estimate and margin mode correctly representing isolated margin mode. (0013-NP-POSE-001) 1. When account balances are set to `0` and market has slippage factors set to `0`, the collateral increase figure per specified theoretical position correctly approximates (absolute relative difference of less than $10^{-6}$) the actual margin and order margin account balances for a party which opens such a position. (0013-NP-POSE-002) -1. When response for a given request contains figure `x` as the collateral increase best case then resubmitting the request with margin account balance increased by `x` should result in `0` collateral increase estimate for the best case. When increasing the margin account balance in the request further the collateral increase should remain at `0`. Same should be true when the above is repeated for the worst case. (0013-NP-POSE-003) +1. For a market with slippage cap factor set to `0`, when the response for a given request contains figure `x` as the collateral increase (best and worst case should be the same) then resubmitting the request with margin account balance increased by `x` should result in `0` collateral increase estimate. When increasing the margin account balance in the request further the collateral increase should get negative by the amount of the increase when in isolated margin mode. In cross margin mode it should remain at `0` until the combined margin and order balances are above the margin release level for the theoretical position. Then the collateral increase amount should be negative and equal to: `initial margin level for the specified position - margin account balance - order account balance`. (0013-NP-POSE-009) 1. In isolated margin mode increasing general account balance specified in the request has no impact on the collateral increase estimate and the liquidation price estimate. (0013-NP-POSE-004) 1. In isolated margin mode the liquidation price estimate for a position with non-zero additional margin requirement with `include_collateral_increase_in_available_collateral` argument set to `true` results in liquidation price which is closer to the current mark price than the result obtained with argument set to `false`. (0013-NP-POSE-005) 1. When market is set with different number of decimal places then its settlement asset then setting `scale_liquidation_price_to_market_decimals` to `false` results in liquidation price estimates scaled to asset decimal places, when set to `true` these estimates get scaled to market decimal places. (0013-NP-POSE-006) diff --git a/protocol/features.json b/protocol/features.json index a8bf86786..53549dac9 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -67,7 +67,12 @@ }, "Fixed size amendments": { "milestone": "palazzo", - "acs": ["0004-AMND-056", "0004-AMND-057", "0004-AMND-058", "0004-AMND-059"] + "acs": [ + "0004-AMND-056", + "0004-AMND-057", + "0004-AMND-058", + "0004-AMND-059" + ] }, "Margin isolation": { "milestone": "palazzo", @@ -286,7 +291,12 @@ }, "Transfers from vesting": { "milestone": "palazzo", - "acs": ["0057-TRAN-066", "0057-TRAN-067", "0057-TRAN-068", "0057-TRAN-069"] + "acs": [ + "0057-TRAN-066", + "0057-TRAN-067", + "0057-TRAN-068", + "0057-TRAN-069" + ] }, "Liquidity fee setting": { "milestone": "palazzo", @@ -302,7 +312,10 @@ }, "Governance market name change": { "milestone": "palazzo", - "acs": ["0028-GOVE-159", "0028-GOVE-166"] + "acs": [ + "0028-GOVE-159", + "0028-GOVE-166" + ] }, "Insurance pools redistribution": { "milestone": "palazzo", @@ -462,16 +475,16 @@ "0012-NP-LIPE-007", "0013-NP-POSE-001", "0013-NP-POSE-002", - "0013-NP-POSE-003", "0013-NP-POSE-004", "0013-NP-POSE-005", "0013-NP-POSE-006", "0013-NP-POSE-007", - "0013-NP-POSE-008" + "0013-NP-POSE-008", + "0013-NP-POSE-009" ] }, "Unknown": { "milestone": "unknown", "acs": [] } -} +} \ No newline at end of file From 303d749bcb071da43d46d6665200e15ce445965f Mon Sep 17 00:00:00 2001 From: Gordsport <83510148+gordsport@users.noreply.github.com> Date: Thu, 22 Feb 2024 11:18:20 +0000 Subject: [PATCH 0973/1171] chore: update approbation now we have completed palazzo (#2184) * chore: update approbation now we have completed palazzo This updates the paths for approbation now that we have completed palazzo. The Approbation runs will now run against colosseo * fix: milestone names --- .github/workflows/quality_check.yml | 2 +- protocol/colosseo-features.json | 35 -- protocol/features.json | 497 ++-------------------------- protocol/palazzo-features.json | 490 +++++++++++++++++++++++++++ 4 files changed, 512 insertions(+), 512 deletions(-) delete mode 100644 protocol/colosseo-features.json create mode 100644 protocol/palazzo-features.json diff --git a/.github/workflows/quality_check.yml b/.github/workflows/quality_check.yml index c7ebd4e6f..24b201724 100644 --- a/.github/workflows/quality_check.yml +++ b/.github/workflows/quality_check.yml @@ -77,4 +77,4 @@ jobs: - name: "Run Check Features" run: | - npx github:vegaprotocol/approbation check-features --specs="{./non-protocol-specs/**/*.md,./protocol/**/*.md,./protocol/**/*.ipynb}" --features="./protocol/colosseo-features.json" + npx github:vegaprotocol/approbation check-features --specs="{./non-protocol-specs/**/*.md,./protocol/**/*.md,./protocol/**/*.ipynb}" --features="./protocol/features.json" diff --git a/protocol/colosseo-features.json b/protocol/colosseo-features.json deleted file mode 100644 index d39b01838..000000000 --- a/protocol/colosseo-features.json +++ /dev/null @@ -1,35 +0,0 @@ -{ - "Markprice updates": { - "milestone": "nebula", - "acs": [ - "0009-MRKP-132", - "0053-PERP-043", - "0032-PRIM-039", - "0032-PRIM-040" - ] - }, - "Community Tags": { - "milestone": "nebula", - "acs": [ - "0028-GOVE-167", - "0028-GOVE-168", - "0028-GOVE-169", - "0028-GOVE-170", - "0028-GOVE-171", - "0028-GOVE-172", - "0028-GOVE-173", - "0028-GOVE-174", - "0028-GOVE-175", - "0028-GOVE-176", - "0028-GOVE-177" - ] - }, - "Perpetual funding rates": { - "milestone": "nebula", - "acs": ["0053-PERP-036"] - }, - "Unknown": { - "milestone": "unknown", - "acs": [] - } -} diff --git a/protocol/features.json b/protocol/features.json index 53549dac9..1ca7166c4 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -1,490 +1,35 @@ { - "Perpetuals": { - "milestone": "palazzo", - "acs": [ - "0014-ORDT-120", - "0014-ORDT-121", - "0014-ORDT-122", - "0014-ORDT-123", - "0082-ETHD-052", - "0053-PERP-024", - "0053-PERP-025", - "0053-PERP-026", - "0053-PERP-027", - "0053-PERP-029", - "0053-PERP-030", - "0053-PERP-031", - "0053-PERP-032", - "0053-PERP-040", - "0053-PERP-041", - "0053-PERP-042" - ] - }, - "Team rewards": { - "milestone": "palazzo", - "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", - "0056-REWA-109", - "0056-REWA-110", - "0083-RFPR-052", - "0083-RFPR-059", - "0083-RFPR-060", - "0083-RFPR-061", - "0083-RFPR-062", - "0083-RFPR-063", - "0083-RFPR-064", - "0083-RFPR-065", - "0083-RFPR-066", - "0083-RFPR-067", - "0088-PPRF-001", - "0088-PPRF-002", - "0088-PPRF-003", - "0088-PPRF-004", - "0088-PPRF-005", - "0062-SPAM-033", - "0062-SPAM-035", - "0062-SPAM-036", - "0062-SPAM-037", - "0062-SPAM-038", - "0062-SPAM-039", - "0062-SPAM-040", - "0062-SPAM-041", - "0062-SPAM-042" - ] - }, - "Fixed size amendments": { - "milestone": "palazzo", - "acs": [ - "0004-AMND-056", - "0004-AMND-057", - "0004-AMND-058", - "0004-AMND-059" - ] - }, - "Margin isolation": { - "milestone": "palazzo", - "acs": [ - "0019-MCAL-031", - "0019-MCAL-032", - "0019-MCAL-033", - "0019-MCAL-034", - "0019-MCAL-035", - "0019-MCAL-036", - "0019-MCAL-037", - "0019-MCAL-038", - "0019-MCAL-039", - "0019-MCAL-040", - "0019-MCAL-049", - "0019-MCAL-050", - "0019-MCAL-051", - "0019-MCAL-052", - "0019-MCAL-053", - "0019-MCAL-054", - "0019-MCAL-055", - "0019-MCAL-056", - "0019-MCAL-057", - "0019-MCAL-058", - "0019-MCAL-059", - "0019-MCAL-060", - "0019-MCAL-061", - "0019-MCAL-062", - "0019-MCAL-064", - "0019-MCAL-065", - "0019-MCAL-066", - "0019-MCAL-067", - "0019-MCAL-068", - "0019-MCAL-070", - "0019-MCAL-071", - "0019-MCAL-072", - "0019-MCAL-073", - "0019-MCAL-074", - "0019-MCAL-075", - "0019-MCAL-078", - "0019-MCAL-100", - "0019-MCAL-101", - "0019-MCAL-102", - "0019-MCAL-103", - "0019-MCAL-104", - "0019-MCAL-105", - "0019-MCAL-106", - "0019-MCAL-107", - "0019-MCAL-108", - "0019-MCAL-109", - "0019-MCAL-110", - "0019-MCAL-112", - "0019-MCAL-113", - "0019-MCAL-114", - "0019-MCAL-115", - "0019-MCAL-116", - "0019-MCAL-117", - "0019-MCAL-119", - "0019-MCAL-120", - "0019-MCAL-121", - "0019-MCAL-122", - "0019-MCAL-123", - "0019-MCAL-124", - "0019-MCAL-125", - "0019-MCAL-126", - "0019-MCAL-127", - "0019-MCAL-128", - "0019-MCAL-129", - "0019-MCAL-130", - "0019-MCAL-131", - "0019-MCAL-132", - "0019-MCAL-133", - "0019-MCAL-134", - "0019-MCAL-135", - "0019-MCAL-136", - "0019-MCAL-137", - "0019-MCAL-138", - "0019-MCAL-139", - "0019-MCAL-140", - "0019-MCAL-141", - "0019-MCAL-142", - "0019-MCAL-143", - "0019-MCAL-144", - "0019-MCAL-145", - "0019-MCAL-146", - "0019-MCAL-147", - "0019-MCAL-148", - "0019-MCAL-149", - "0019-MCAL-150", - "0019-MCAL-151", - "0019-MCAL-152", - "0019-MCAL-153", - "0019-MCAL-160", - "0019-MCAL-161", - "0019-MCAL-162", - "0019-MCAL-163", - "0019-MCAL-164", - "0019-MCAL-165", - "0019-MCAL-166", - "0019-MCAL-167", - "0019-MCAL-168", - "0019-MCAL-169", - "0019-MCAL-172", - "0019-MCAL-173", - "0019-MCAL-174", - "0019-MCAL-175", - "0019-MCAL-176", - "0019-MCAL-200", - "0019-MCAL-201", - "0019-MCAL-202", - "0019-MCAL-203", - "0019-MCAL-204", - "0019-MCAL-205", - "0019-MCAL-206", - "0019-MCAL-207", - "0019-MCAL-220", - "0019-MCAL-221", - "0019-MCAL-222", - "0019-MCAL-223", - "0019-MCAL-224", - "0019-MCAL-225", - "0019-MCAL-226", - "0019-MCAL-227", - "0019-MCAL-228", - "0019-MCAL-229", - "0019-MCAL-230", - "0019-MCAL-231", - "0019-MCAL-232", - "0019-MCAL-233", - "0074-BTCH-020", - "0074-BTCH-021" - ] - }, - "Quadratic slippage removal": { - "milestone": "palazzo", - "acs": [ - "0019-MCAL-024", - "0019-MCAL-025", - "0019-MCAL-026", - "0019-MCAL-027", - "0019-MCAL-028", - "0019-MCAL-029", - "0019-MCAL-030" - ] - }, - "Modify liquidation mechanics": { - "milestone": "palazzo", - "acs": [ - "0012-POSR-001", - "0012-POSR-005", - "0012-POSR-009", - "0012-POSR-010", - "0012-POSR-011", - "0012-POSR-012", - "0012-POSR-013", - "0012-POSR-014", - "0012-POSR-015", - "0012-POSR-016", - "0012-POSR-017", - "0012-POSR-018", - "0012-POSR-019", - "0012-POSR-020", - "0012-POSR-021", - "0012-POSR-022", - "0012-POSR-023", - "0012-POSR-024", - "0012-POSR-025", - "0012-POSR-026", - "0012-POSR-027", - "0012-POSR-028", - "0012-POSR-029", - "0003-MTMK-015", - "0003-MTMK-016", - "0003-MTMK-017", - "0053-PERP-037", - "0053-PERP-038", - "0053-PERP-039" - ] - }, - "Batch governance proposals": { - "milestone": "palazzo", - "acs": [ - "0028-GOVE-067", - "0028-GOVE-068", - "0028-GOVE-145", - "0028-GOVE-146", - "0028-GOVE-148", - "0028-GOVE-149", - "0028-GOVE-160", - "0028-GOVE-161", - "0028-GOVE-163", - "0028-GOVE-164", - "0028-GOVE-165" - ] - }, - "Transfer fee cap": { - "milestone": "palazzo", - "acs": [ - "0057-TRAN-011", - "0057-TRAN-012", - "0057-TRAN-014", - "0057-TRAN-015", - "0057-TRAN-016", - "0057-TRAN-017", - "0057-TRAN-018", - "0057-TRAN-019", - "0057-TRAN-020", - "0057-TRAN-021", - "0057-TRAN-022", - "0057-TRAN-023", - "0057-TRAN-024", - "0057-TRAN-027", - "0057-TRAN-064", - "0057-TRAN-065" - ] - }, - "Transfers from vesting": { - "milestone": "palazzo", - "acs": [ - "0057-TRAN-066", - "0057-TRAN-067", - "0057-TRAN-068", - "0057-TRAN-069" - ] - }, - "Liquidity fee setting": { - "milestone": "palazzo", - "acs": [ - "0042-LIQF-056", - "0042-LIQF-057", - "0042-LIQF-058", - "0042-LIQF-059", - "0042-LIQF-060", - "0042-LIQF-061", - "0042-LIQF-062" - ] - }, - "Governance market name change": { - "milestone": "palazzo", - "acs": [ - "0028-GOVE-159", - "0028-GOVE-166" - ] - }, - "Insurance pools redistribution": { - "milestone": "palazzo", - "acs": [ - "0002-STTL-011", - "0002-STTL-012", - "0002-STTL-013", - "0013-ACCT-033", - "0043-MKTL-010" - ] - }, - "Position Linked Stop-Orders": { - "milestone": "palazzo", - "acs": [ - "0014-ORDT-127", - "0014-ORDT-128", - "0014-ORDT-129", - "0014-ORDT-130", - "0014-ORDT-131", - "0014-ORDT-137", - "0014-ORDT-138", - "0014-ORDT-139" - ] - }, "Markprice updates": { - "milestone": "palazzo", + "milestone": "colosseo", "acs": [ - "0009-MRKP-001", - "0009-MRKP-003", - "0009-MRKP-010", - "0009-MRKP-011", - "0009-MRKP-012", - "0009-MRKP-013", - "0009-MRKP-014", - "0009-MRKP-015", - "0009-MRKP-016", - "0009-MRKP-017", - "0009-MRKP-018", - "0009-MRKP-019", - "0009-MRKP-020", - "0009-MRKP-021", - "0009-MRKP-022", - "0009-MRKP-023", - "0009-MRKP-024", - "0009-MRKP-025", - "0009-MRKP-026", - "0009-MRKP-027", - "0009-MRKP-028", - "0009-MRKP-029", - "0009-MRKP-030", - "0009-MRKP-031", - "0009-MRKP-032", - "0053-PERP-033", - "0053-PERP-034", - "0009-MRKP-040", - "0009-MRKP-041", - "0009-MRKP-050", - "0009-MRKP-051", - "0009-MRKP-052", - "0009-MRKP-053", - "0009-MRKP-054", - "0009-MRKP-055", - "0009-MRKP-056", - "0009-MRKP-057", - "0009-MRKP-058", - "0009-MRKP-059", - "0009-MRKP-060", - "0009-MRKP-061", - "0009-MRKP-062", - "0009-MRKP-063", - "0009-MRKP-064", - "0009-MRKP-110", - "0009-MRKP-111", - "0009-MRKP-112", - "0009-MRKP-113", - "0009-MRKP-114", - "0009-MRKP-115", - "0009-MRKP-116", - "0009-MRKP-117", - "0009-MRKP-118", - "0009-MRKP-119", - "0009-MRKP-120", - "0009-MRKP-121", - "0009-MRKP-122", - "0009-MRKP-123", - "0009-MRKP-124", - "0009-MRKP-125", - "0009-MRKP-126", - "0009-MRKP-127", - "0009-MRKP-130", - "0009-MRKP-131", "0009-MRKP-132", - "0009-MRKP-134", - "0009-MRKP-135", - "0053-PERP-044", - "0053-PERP-045", - "0053-PERP-046" + "0053-PERP-043", + "0032-PRIM-039", + "0032-PRIM-040" ] }, - "Ethereum RPC and EVM based data sources": { - "milestone": "palazzo", + "Community Tags": { + "milestone": "colosseo", "acs": [ - "0087-EVMD-001", - "0087-EVMD-003", - "0087-EVMD-004", - "0087-EVMD-005", - "0087-EVMD-006", - "0087-EVMD-007", - "0087-EVMD-008", - "0087-EVMD-009", - "0087-EVMD-010", - "0087-EVMD-011", - "0087-EVMD-012", - "0087-EVMD-013", - "0087-EVMD-014", - "0087-EVMD-015", - "0087-EVMD-016", - "0087-EVMD-017", - "0087-EVMD-018", - "0087-EVMD-019", - "0087-EVMD-020", - "0087-EVMD-021", - "0087-EVMD-022", - "0087-EVMD-023", - "0087-EVMD-024", - "0087-EVMD-025", - "0087-EVMD-026", - "0087-EVMD-027", - "0087-EVMD-028", - "0087-EVMD-029", - "0087-EVMD-030", - "0087-EVMD-031", - "0087-EVMD-032", - "0087-EVMD-033", - "0087-EVMD-034", - "0087-EVMD-035", - "0087-EVMD-036", - "0087-EVMD-037", - "0087-EVMD-038", - "0087-EVMD-039", - "0087-EVMD-040", - "0087-EVMD-041", - "0087-EVMD-042", - "0087-EVMD-043", - "0087-EVMD-044" + "0028-GOVE-167", + "0028-GOVE-168", + "0028-GOVE-169", + "0028-GOVE-170", + "0028-GOVE-171", + "0028-GOVE-172", + "0028-GOVE-173", + "0028-GOVE-174", + "0028-GOVE-175", + "0028-GOVE-176", + "0028-GOVE-177" ] }, - "Price estimate": { - "milestone": "palazzo", - "acs": [ - "0012-NP-LIPE-001", - "0012-NP-LIPE-002", - "0012-NP-LIPE-003", - "0012-NP-LIPE-004", - "0012-NP-LIPE-005", - "0012-NP-LIPE-006", - "0012-NP-LIPE-007", - "0013-NP-POSE-001", - "0013-NP-POSE-002", - "0013-NP-POSE-004", - "0013-NP-POSE-005", - "0013-NP-POSE-006", - "0013-NP-POSE-007", - "0013-NP-POSE-008", - "0013-NP-POSE-009" - ] + "Perpetual funding rates": { + "milestone": "colosseo", + "acs": ["0053-PERP-036"] }, "Unknown": { "milestone": "unknown", "acs": [] } -} \ No newline at end of file +} diff --git a/protocol/palazzo-features.json b/protocol/palazzo-features.json new file mode 100644 index 000000000..53549dac9 --- /dev/null +++ b/protocol/palazzo-features.json @@ -0,0 +1,490 @@ +{ + "Perpetuals": { + "milestone": "palazzo", + "acs": [ + "0014-ORDT-120", + "0014-ORDT-121", + "0014-ORDT-122", + "0014-ORDT-123", + "0082-ETHD-052", + "0053-PERP-024", + "0053-PERP-025", + "0053-PERP-026", + "0053-PERP-027", + "0053-PERP-029", + "0053-PERP-030", + "0053-PERP-031", + "0053-PERP-032", + "0053-PERP-040", + "0053-PERP-041", + "0053-PERP-042" + ] + }, + "Team rewards": { + "milestone": "palazzo", + "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", + "0056-REWA-109", + "0056-REWA-110", + "0083-RFPR-052", + "0083-RFPR-059", + "0083-RFPR-060", + "0083-RFPR-061", + "0083-RFPR-062", + "0083-RFPR-063", + "0083-RFPR-064", + "0083-RFPR-065", + "0083-RFPR-066", + "0083-RFPR-067", + "0088-PPRF-001", + "0088-PPRF-002", + "0088-PPRF-003", + "0088-PPRF-004", + "0088-PPRF-005", + "0062-SPAM-033", + "0062-SPAM-035", + "0062-SPAM-036", + "0062-SPAM-037", + "0062-SPAM-038", + "0062-SPAM-039", + "0062-SPAM-040", + "0062-SPAM-041", + "0062-SPAM-042" + ] + }, + "Fixed size amendments": { + "milestone": "palazzo", + "acs": [ + "0004-AMND-056", + "0004-AMND-057", + "0004-AMND-058", + "0004-AMND-059" + ] + }, + "Margin isolation": { + "milestone": "palazzo", + "acs": [ + "0019-MCAL-031", + "0019-MCAL-032", + "0019-MCAL-033", + "0019-MCAL-034", + "0019-MCAL-035", + "0019-MCAL-036", + "0019-MCAL-037", + "0019-MCAL-038", + "0019-MCAL-039", + "0019-MCAL-040", + "0019-MCAL-049", + "0019-MCAL-050", + "0019-MCAL-051", + "0019-MCAL-052", + "0019-MCAL-053", + "0019-MCAL-054", + "0019-MCAL-055", + "0019-MCAL-056", + "0019-MCAL-057", + "0019-MCAL-058", + "0019-MCAL-059", + "0019-MCAL-060", + "0019-MCAL-061", + "0019-MCAL-062", + "0019-MCAL-064", + "0019-MCAL-065", + "0019-MCAL-066", + "0019-MCAL-067", + "0019-MCAL-068", + "0019-MCAL-070", + "0019-MCAL-071", + "0019-MCAL-072", + "0019-MCAL-073", + "0019-MCAL-074", + "0019-MCAL-075", + "0019-MCAL-078", + "0019-MCAL-100", + "0019-MCAL-101", + "0019-MCAL-102", + "0019-MCAL-103", + "0019-MCAL-104", + "0019-MCAL-105", + "0019-MCAL-106", + "0019-MCAL-107", + "0019-MCAL-108", + "0019-MCAL-109", + "0019-MCAL-110", + "0019-MCAL-112", + "0019-MCAL-113", + "0019-MCAL-114", + "0019-MCAL-115", + "0019-MCAL-116", + "0019-MCAL-117", + "0019-MCAL-119", + "0019-MCAL-120", + "0019-MCAL-121", + "0019-MCAL-122", + "0019-MCAL-123", + "0019-MCAL-124", + "0019-MCAL-125", + "0019-MCAL-126", + "0019-MCAL-127", + "0019-MCAL-128", + "0019-MCAL-129", + "0019-MCAL-130", + "0019-MCAL-131", + "0019-MCAL-132", + "0019-MCAL-133", + "0019-MCAL-134", + "0019-MCAL-135", + "0019-MCAL-136", + "0019-MCAL-137", + "0019-MCAL-138", + "0019-MCAL-139", + "0019-MCAL-140", + "0019-MCAL-141", + "0019-MCAL-142", + "0019-MCAL-143", + "0019-MCAL-144", + "0019-MCAL-145", + "0019-MCAL-146", + "0019-MCAL-147", + "0019-MCAL-148", + "0019-MCAL-149", + "0019-MCAL-150", + "0019-MCAL-151", + "0019-MCAL-152", + "0019-MCAL-153", + "0019-MCAL-160", + "0019-MCAL-161", + "0019-MCAL-162", + "0019-MCAL-163", + "0019-MCAL-164", + "0019-MCAL-165", + "0019-MCAL-166", + "0019-MCAL-167", + "0019-MCAL-168", + "0019-MCAL-169", + "0019-MCAL-172", + "0019-MCAL-173", + "0019-MCAL-174", + "0019-MCAL-175", + "0019-MCAL-176", + "0019-MCAL-200", + "0019-MCAL-201", + "0019-MCAL-202", + "0019-MCAL-203", + "0019-MCAL-204", + "0019-MCAL-205", + "0019-MCAL-206", + "0019-MCAL-207", + "0019-MCAL-220", + "0019-MCAL-221", + "0019-MCAL-222", + "0019-MCAL-223", + "0019-MCAL-224", + "0019-MCAL-225", + "0019-MCAL-226", + "0019-MCAL-227", + "0019-MCAL-228", + "0019-MCAL-229", + "0019-MCAL-230", + "0019-MCAL-231", + "0019-MCAL-232", + "0019-MCAL-233", + "0074-BTCH-020", + "0074-BTCH-021" + ] + }, + "Quadratic slippage removal": { + "milestone": "palazzo", + "acs": [ + "0019-MCAL-024", + "0019-MCAL-025", + "0019-MCAL-026", + "0019-MCAL-027", + "0019-MCAL-028", + "0019-MCAL-029", + "0019-MCAL-030" + ] + }, + "Modify liquidation mechanics": { + "milestone": "palazzo", + "acs": [ + "0012-POSR-001", + "0012-POSR-005", + "0012-POSR-009", + "0012-POSR-010", + "0012-POSR-011", + "0012-POSR-012", + "0012-POSR-013", + "0012-POSR-014", + "0012-POSR-015", + "0012-POSR-016", + "0012-POSR-017", + "0012-POSR-018", + "0012-POSR-019", + "0012-POSR-020", + "0012-POSR-021", + "0012-POSR-022", + "0012-POSR-023", + "0012-POSR-024", + "0012-POSR-025", + "0012-POSR-026", + "0012-POSR-027", + "0012-POSR-028", + "0012-POSR-029", + "0003-MTMK-015", + "0003-MTMK-016", + "0003-MTMK-017", + "0053-PERP-037", + "0053-PERP-038", + "0053-PERP-039" + ] + }, + "Batch governance proposals": { + "milestone": "palazzo", + "acs": [ + "0028-GOVE-067", + "0028-GOVE-068", + "0028-GOVE-145", + "0028-GOVE-146", + "0028-GOVE-148", + "0028-GOVE-149", + "0028-GOVE-160", + "0028-GOVE-161", + "0028-GOVE-163", + "0028-GOVE-164", + "0028-GOVE-165" + ] + }, + "Transfer fee cap": { + "milestone": "palazzo", + "acs": [ + "0057-TRAN-011", + "0057-TRAN-012", + "0057-TRAN-014", + "0057-TRAN-015", + "0057-TRAN-016", + "0057-TRAN-017", + "0057-TRAN-018", + "0057-TRAN-019", + "0057-TRAN-020", + "0057-TRAN-021", + "0057-TRAN-022", + "0057-TRAN-023", + "0057-TRAN-024", + "0057-TRAN-027", + "0057-TRAN-064", + "0057-TRAN-065" + ] + }, + "Transfers from vesting": { + "milestone": "palazzo", + "acs": [ + "0057-TRAN-066", + "0057-TRAN-067", + "0057-TRAN-068", + "0057-TRAN-069" + ] + }, + "Liquidity fee setting": { + "milestone": "palazzo", + "acs": [ + "0042-LIQF-056", + "0042-LIQF-057", + "0042-LIQF-058", + "0042-LIQF-059", + "0042-LIQF-060", + "0042-LIQF-061", + "0042-LIQF-062" + ] + }, + "Governance market name change": { + "milestone": "palazzo", + "acs": [ + "0028-GOVE-159", + "0028-GOVE-166" + ] + }, + "Insurance pools redistribution": { + "milestone": "palazzo", + "acs": [ + "0002-STTL-011", + "0002-STTL-012", + "0002-STTL-013", + "0013-ACCT-033", + "0043-MKTL-010" + ] + }, + "Position Linked Stop-Orders": { + "milestone": "palazzo", + "acs": [ + "0014-ORDT-127", + "0014-ORDT-128", + "0014-ORDT-129", + "0014-ORDT-130", + "0014-ORDT-131", + "0014-ORDT-137", + "0014-ORDT-138", + "0014-ORDT-139" + ] + }, + "Markprice updates": { + "milestone": "palazzo", + "acs": [ + "0009-MRKP-001", + "0009-MRKP-003", + "0009-MRKP-010", + "0009-MRKP-011", + "0009-MRKP-012", + "0009-MRKP-013", + "0009-MRKP-014", + "0009-MRKP-015", + "0009-MRKP-016", + "0009-MRKP-017", + "0009-MRKP-018", + "0009-MRKP-019", + "0009-MRKP-020", + "0009-MRKP-021", + "0009-MRKP-022", + "0009-MRKP-023", + "0009-MRKP-024", + "0009-MRKP-025", + "0009-MRKP-026", + "0009-MRKP-027", + "0009-MRKP-028", + "0009-MRKP-029", + "0009-MRKP-030", + "0009-MRKP-031", + "0009-MRKP-032", + "0053-PERP-033", + "0053-PERP-034", + "0009-MRKP-040", + "0009-MRKP-041", + "0009-MRKP-050", + "0009-MRKP-051", + "0009-MRKP-052", + "0009-MRKP-053", + "0009-MRKP-054", + "0009-MRKP-055", + "0009-MRKP-056", + "0009-MRKP-057", + "0009-MRKP-058", + "0009-MRKP-059", + "0009-MRKP-060", + "0009-MRKP-061", + "0009-MRKP-062", + "0009-MRKP-063", + "0009-MRKP-064", + "0009-MRKP-110", + "0009-MRKP-111", + "0009-MRKP-112", + "0009-MRKP-113", + "0009-MRKP-114", + "0009-MRKP-115", + "0009-MRKP-116", + "0009-MRKP-117", + "0009-MRKP-118", + "0009-MRKP-119", + "0009-MRKP-120", + "0009-MRKP-121", + "0009-MRKP-122", + "0009-MRKP-123", + "0009-MRKP-124", + "0009-MRKP-125", + "0009-MRKP-126", + "0009-MRKP-127", + "0009-MRKP-130", + "0009-MRKP-131", + "0009-MRKP-132", + "0009-MRKP-134", + "0009-MRKP-135", + "0053-PERP-044", + "0053-PERP-045", + "0053-PERP-046" + ] + }, + "Ethereum RPC and EVM based data sources": { + "milestone": "palazzo", + "acs": [ + "0087-EVMD-001", + "0087-EVMD-003", + "0087-EVMD-004", + "0087-EVMD-005", + "0087-EVMD-006", + "0087-EVMD-007", + "0087-EVMD-008", + "0087-EVMD-009", + "0087-EVMD-010", + "0087-EVMD-011", + "0087-EVMD-012", + "0087-EVMD-013", + "0087-EVMD-014", + "0087-EVMD-015", + "0087-EVMD-016", + "0087-EVMD-017", + "0087-EVMD-018", + "0087-EVMD-019", + "0087-EVMD-020", + "0087-EVMD-021", + "0087-EVMD-022", + "0087-EVMD-023", + "0087-EVMD-024", + "0087-EVMD-025", + "0087-EVMD-026", + "0087-EVMD-027", + "0087-EVMD-028", + "0087-EVMD-029", + "0087-EVMD-030", + "0087-EVMD-031", + "0087-EVMD-032", + "0087-EVMD-033", + "0087-EVMD-034", + "0087-EVMD-035", + "0087-EVMD-036", + "0087-EVMD-037", + "0087-EVMD-038", + "0087-EVMD-039", + "0087-EVMD-040", + "0087-EVMD-041", + "0087-EVMD-042", + "0087-EVMD-043", + "0087-EVMD-044" + ] + }, + "Price estimate": { + "milestone": "palazzo", + "acs": [ + "0012-NP-LIPE-001", + "0012-NP-LIPE-002", + "0012-NP-LIPE-003", + "0012-NP-LIPE-004", + "0012-NP-LIPE-005", + "0012-NP-LIPE-006", + "0012-NP-LIPE-007", + "0013-NP-POSE-001", + "0013-NP-POSE-002", + "0013-NP-POSE-004", + "0013-NP-POSE-005", + "0013-NP-POSE-006", + "0013-NP-POSE-007", + "0013-NP-POSE-008", + "0013-NP-POSE-009" + ] + }, + "Unknown": { + "milestone": "unknown", + "acs": [] + } +} \ No newline at end of file From 70d97a5b1c551cb95788fcd5e1998f423711a168 Mon Sep 17 00:00:00 2001 From: Gordsport <83510148+gordsport@users.noreply.github.com> Date: Thu, 22 Feb 2024 11:34:30 +0000 Subject: [PATCH 0974/1171] Add spot ACs from cosmic (#2163) * feat(acs): add spot acs from cosmic milestone This adds All the spot ACs from the cosmic elevator milestone just before the feature was deferred. * fix: remove LNL ACs * fix: MD055 markdownlint errors * fix: remove more LNL ACs * fix: remove AC already correctly in 0037-OPEG (14 / 19) * fix: delete duplicate AC copied from another spec * fix: tidy up MKTD spot ACs * fix: tidy up BTCH ACs for spot * chore: add in an AC already covered in STs * chore: mark spot ACs as stretch * fix: linting * chore: remove untestable ACs * fix: AC coded number * fix: remove old number * chore: align features.json --- protocol/0004-AMND-amends.md | 1 - protocol/0010-MARG-margin_orchestration.md | 8 +- protocol/0019-MCAL-margin_calculator.md | 6 +- protocol/0020-APIS-core_api.md | 2 +- protocol/0026-AUCT-auctions.md | 1 - protocol/0031-ETHB-ethereum_bridge_spec.md | 2 +- protocol/0080-SPOT-product_builtin_spot.md | 3 +- protocol/features.json | 287 +++++++++++++++++++++ 8 files changed, 297 insertions(+), 13 deletions(-) diff --git a/protocol/0004-AMND-amends.md b/protocol/0004-AMND-amends.md index 4d73351ff..e43005bd3 100644 --- a/protocol/0004-AMND-amends.md +++ b/protocol/0004-AMND-amends.md @@ -22,7 +22,6 @@ - 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) diff --git a/protocol/0010-MARG-margin_orchestration.md b/protocol/0010-MARG-margin_orchestration.md index d3ed5badd..fad70db62 100644 --- a/protocol/0010-MARG-margin_orchestration.md +++ b/protocol/0010-MARG-margin_orchestration.md @@ -72,11 +72,11 @@ The [margin calculator](./0019-MCAL-margin_calculator.md) returns four margin le The protocol compares these levels to the balance in the trader's margin account for a market. -| Traders Collateral | Protocol Action | Whitepaper Description +| Traders Collateral | Protocol Action | Whitepaper Description | | ------------- |:-------------:| -----:| -| less than _collateral search level_ | Collateral search, possibly close outs | Collateral search, Close out zone -| 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 +| less than _collateral search level_ | Collateral search, possibly close outs | Collateral search, Close out zone | +| 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: diff --git a/protocol/0019-MCAL-margin_calculator.md b/protocol/0019-MCAL-margin_calculator.md index 16eca02be..23d3df561 100644 --- a/protocol/0019-MCAL-margin_calculator.md +++ b/protocol/0019-MCAL-margin_calculator.md @@ -771,9 +771,9 @@ Given the following trader positions: | Tables | Open | Buys | Sells | | ------------- |:-------------:| -----:| -----:| -| case-1 | 1 | 1 | -2 -| case-2 | -1 | 2| 0 -| case-3 | 1 | 0 | -2 +| case-1 | 1 | 1 | -2 | +| case-2 | -1 | 2| 0 | +| case-3 | 1 | 0 | -2 | #### *case-1* diff --git a/protocol/0020-APIS-core_api.md b/protocol/0020-APIS-core_api.md index c29a57d09..d129cc0b6 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/0026-AUCT-auctions.md b/protocol/0026-AUCT-auctions.md index 97ce75efb..46c1a3320 100644 --- a/protocol/0026-AUCT-auctions.md +++ b/protocol/0026-AUCT-auctions.md @@ -160,7 +160,6 @@ 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 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) diff --git a/protocol/0031-ETHB-ethereum_bridge_spec.md b/protocol/0031-ETHB-ethereum_bridge_spec.md index fb20caa84..8acda13db 100644 --- a/protocol/0031-ETHB-ethereum_bridge_spec.md +++ b/protocol/0031-ETHB-ethereum_bridge_spec.md @@ -109,7 +109,7 @@ The Ethereum Bridge uses 1 network parameter, `blockchains.ethereumConfig`, a JS | Property | Type | Example value | Description | |------------------|--------| ------------|--------------| -| `chain_id` | String | `"3"` | Ethereum [Chain ID](https://eips.ethereum.org/EIPS/eip-155) to connect to +| `chain_id` | String | `"3"` | Ethereum [Chain ID](https://eips.ethereum.org/EIPS/eip-155) to connect to | | `network_id` | String | `"3"` | Ethereum [Network ID](https://eips.ethereum.org/EIPS/eip-155) to connect to | | `collateral_bridge_contract` | {string, integer} | `{address: "0xCcB517899f714BD1B2f32931fF429aDEdDd02A93", deployment_height: 1}` | The address for a deployed instance of the bridge contract | | `staking_bridge_contract` | {string, integer} | `{address: "0xCcB517899f714BD1B2f32931fF429aDEdDd02A93", deployment_height: 1}` | The addresses to listen to for [staking events](./0059-STKG-simple_staking_and_delegating.md). | diff --git a/protocol/0080-SPOT-product_builtin_spot.md b/protocol/0080-SPOT-product_builtin_spot.md index 38fd258a3..3ef35458e 100644 --- a/protocol/0080-SPOT-product_builtin_spot.md +++ b/protocol/0080-SPOT-product_builtin_spot.md @@ -119,8 +119,6 @@ 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-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) @@ -134,3 +132,4 @@ Price-monitoring auctions are still required and should be implemented following 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, when the auction exits the amount required to cover fees must be recalculated. If a party does not have enough funds to cover the increase their order should be stopped with a clear return code. (0080-SPOT-021). 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). +1. Spot governance proposal fails with asset error, when quote_asset and base_asset has same assets. (0080-SPOT-022). diff --git a/protocol/features.json b/protocol/features.json index 1ca7166c4..3a2036aa9 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -7,6 +7,293 @@ "0032-PRIM-039", "0032-PRIM-040" ] + }, + "Spot": { + "milestone": "colosseo", + "acs": [ + "0080-SPOT-001", + "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-020", + "0080-SPOT-021", + "0080-SPOT-022", + "0044-LIME-029", + "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", + "0008-TRAD-008", + "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", + "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", + "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" + ] + }, + "Spot stretch": { + "milestone": "colosseo", + "acs": [ + "0029-FEES-015", + "0029-FEES-016", + "0029-FEES-017", + "0029-FEES-018", + "0029-FEES-019", + "0029-FEES-020", + "0029-FEES-021", + "0029-FEES-022", + "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", + "0070-MKTD-009", + "0070-MKTD-010", + "0070-MKTD-011", + "0070-MKTD-012", + "0070-MKTD-013", + "0070-MKTD-014", + "0070-MKTD-015", + "0070-MKTD-016", + "0074-BTCH-012", + "0074-BTCH-015", + "0074-BTCH-016", + "0074-BTCH-019", + "0079-TGAP-006", + "0079-TGAP-007" + ] }, "Community Tags": { "milestone": "colosseo", From 7b220e79f9fbfe9c9efacc797309949734e0532e Mon Sep 17 00:00:00 2001 From: Charlie Date: Thu, 1 Feb 2024 13:41:43 +0000 Subject: [PATCH 0975/1171] feat: market tick size --- protocol/0001-MKTF-market_framework.md | 3 ++- protocol/0004-AMND-amends.md | 3 ++- protocol/0025-OCRE-order_submission.md | 2 ++ protocol/0028-GOVE-governance.md | 4 ++++ protocol/0037-OPEG-pegged_orders.md | 3 ++- 5 files changed, 12 insertions(+), 3 deletions(-) diff --git a/protocol/0001-MKTF-market_framework.md b/protocol/0001-MKTF-market_framework.md index 5f16a0699..d4444d8f1 100644 --- a/protocol/0001-MKTF-market_framework.md +++ b/protocol/0001-MKTF-market_framework.md @@ -32,6 +32,7 @@ Data: - **Position Decimal Places**: number of decimal places for orders and positions, i.e. if this is 2 then the smallest increment that can be traded is 0.01, for example 0.01 BTC in a `BTSUSD` market. - If this is negative e.g. -3 this means that the smallest order and position is of size 1000. - Accepted values are `-6,...,-1,0,1,2,...,6`. +- **Tick size**: the minimum change in quote price for the market. Order prices and offsets for pegged orders must be given as an exact multiple of the tick size. For example if the tick size is 0.02 USD. then a price of 100.02 USD is acceptable and a price of 100.03 USD is not. The tick size of a market can be updated through governance. - **Liquidation strategy**: A field specifying the liquidation strategy for the market. Please refer to [0012-POSR-position_resolution](./0012-POSR-position_resolution.md#managing-networks-position) for supported strategies. Note: it is agreed that initially the integer representation of the full precision of both order and positions can be required to fit into an int64, so this means that the largest position/order size possible reduces by a factor of ten for every extra decimal place used. This also means that, for instance, it would not be possible to create a `BTCUSD` market that allows order/position sizes equivalent to 1 sat. @@ -222,7 +223,7 @@ 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. +It may propose new risk model and parameters, price monitoring parameters, tick size, 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. diff --git a/protocol/0004-AMND-amends.md b/protocol/0004-AMND-amends.md index e43005bd3..5241c9789 100644 --- a/protocol/0004-AMND-amends.md +++ b/protocol/0004-AMND-amends.md @@ -4,6 +4,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) +- Price change amends specifying a new price which is not an integer multiple of the markets tick size should be rejected and the original order should be left in place. - Reducing the quantity by specifying a `sizeDelta` 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 using a `sizeDelta` 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 by specifying a `sizeDelta` 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) @@ -96,7 +97,7 @@ Amending an order does not alter the `orderID` and creation time of the original The fields which can be altered are: - `Price` - - Amending the price causes the order to be removed from the book and re-inserted at the new price level. This can result in the order being filled if the price is moved to a level that would cross. + - Amending the price causes the order to be removed from the book and re-inserted at the new price level. This can result in the order being filled if the price is moved to a level that would cross. The amended price must be an integer multiple of the [markets tick size](./0001-MKTF-market_framework.md#market). - `SizeDelta` - Amending the size by specifying a `sizeDelta` will be applied to both the `Size` and `Remaining` part of the order. In the case that the remaining amount it reduced to zero or less, the order is cancelled. This must be a multiple of the smallest value allowed by the `Position Decimal Places` (PDP) specified in the [Market Framework](./0001-MKTF-market_framework.md), i.e. is PDP = 2 then `SizeDelta` must be a whole multiple of 0.01. (NB: `SizeDelta` may use an int64 where the int value 1 is the smallest multiple allowable given the configured dp). In case PDP is negative this again applies e.g. if PDP = -1 then `SizeDelta` must be a whole multiple of 10. - `Size` diff --git a/protocol/0025-OCRE-order_submission.md b/protocol/0025-OCRE-order_submission.md index f163e500f..04eb71377 100644 --- a/protocol/0025-OCRE-order_submission.md +++ b/protocol/0025-OCRE-order_submission.md @@ -7,6 +7,7 @@ To allow traders to interact with the market, they must be able to enter an orde ## Reference-level explanation - 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). +- Order submissions will only be accepted if the quoted price is an integer multiple of the markets tick size. - 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 an iceberg (transparent iceberg) order can be done without losing time priority, as the current displayed size will not be changed. @@ -38,6 +39,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) +- If an order's price is not an exact multiple of the markets tick size it should be rejected. - 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/0028-GOVE-governance.md b/protocol/0028-GOVE-governance.md index 3252fc637..14a0572b7 100644 --- a/protocol/0028-GOVE-governance.md +++ b/protocol/0028-GOVE-governance.md @@ -555,6 +555,8 @@ APIs should also exist for clients to: - 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 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) +- A market proposal with a tick size less than or equal to `0` gets rejected. +- A market proposal with a tick size which is not an exact multiple of `10^-mdp` gets rejected (where `mdp` is the market decimal places). #### Market change proposals @@ -594,6 +596,8 @@ APIs should also exist for clients to: - 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) +- A market change proposal specifying a new tick size less than or equal to `0` gets rejected. +- A market change proposal specifying a new tick size which is not an exact multiple of `10^-mdp` gets rejected (where `mdp` is the market decimal places). #### Network parameter change proposals diff --git a/protocol/0037-OPEG-pegged_orders.md b/protocol/0037-OPEG-pegged_orders.md index c3edc288f..d40aaca15 100644 --- a/protocol/0037-OPEG-pegged_orders.md +++ b/protocol/0037-OPEG-pegged_orders.md @@ -16,6 +16,7 @@ - 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 pegged order specifying an offset which is not an integer multiple of the markets tick size should be rejected. - 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) @@ -30,7 +31,7 @@ Pegged orders are limit orders where the price is specified of the form `REFEREN **Reference Price:** This is the price against which the final order priced is calculated. Possible options are best bid/ask and mid price. -**Offset:** This is a value added to the reference price. It must be non-negative or positive (see table below) and must be a multiple of the tick size. +**Offset:** This is a value added to the reference price. It must be non-negative or positive (see table below) and must be a multiple of the tick size defined by the [market framework](./0001-MKTF-market_framework.md#market). When a party submits a new pegged order, only a LIMIT order is accepted. The party also specifies the reference price to which the order will be priced along with an offset to apply to this price. The reference price is looked up from the live market and the final price is calculated and used to insert the new order. The order is placed on the book at the back of the calculated price level. From 6190929f24189af89f868eacf5966d18e93c04a4 Mon Sep 17 00:00:00 2001 From: Charlie Date: Thu, 1 Feb 2024 13:42:44 +0000 Subject: [PATCH 0976/1171] feat: remove invalid price levels on tick size change --- 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 14a0572b7..2dceacdc0 100644 --- a/protocol/0028-GOVE-governance.md +++ b/protocol/0028-GOVE-governance.md @@ -598,6 +598,8 @@ APIs should also exist for clients to: - 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) - A market change proposal specifying a new tick size less than or equal to `0` gets rejected. - A market change proposal specifying a new tick size which is not an exact multiple of `10^-mdp` gets rejected (where `mdp` is the market decimal places). +- At enactment, a market change proposal updating the tick size cancels all orders where the quoted price is not an exact multiple of `10^-mdp` (where `mdp` is the market decimal places). +- At enactment, a market change proposal updating the tick size cancels all pegged orders where the offset is not an exact multiple of `10^-mdp` (where `mdp` is the market decimal places). #### Network parameter change proposals From 2cc10791a116fb54847a8fe0b37c8ac2bbb0f9aa Mon Sep 17 00:00:00 2001 From: Charlie Date: Mon, 19 Feb 2024 13:38:06 +0000 Subject: [PATCH 0977/1171] Revert "feat: remove invalid price levels on tick size change" This reverts commit a08bb51304e42d7cd9bee6cfb9dc1b7bc78175ec. --- 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 2dceacdc0..14a0572b7 100644 --- a/protocol/0028-GOVE-governance.md +++ b/protocol/0028-GOVE-governance.md @@ -598,8 +598,6 @@ APIs should also exist for clients to: - 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) - A market change proposal specifying a new tick size less than or equal to `0` gets rejected. - A market change proposal specifying a new tick size which is not an exact multiple of `10^-mdp` gets rejected (where `mdp` is the market decimal places). -- At enactment, a market change proposal updating the tick size cancels all orders where the quoted price is not an exact multiple of `10^-mdp` (where `mdp` is the market decimal places). -- At enactment, a market change proposal updating the tick size cancels all pegged orders where the offset is not an exact multiple of `10^-mdp` (where `mdp` is the market decimal places). #### Network parameter change proposals From 931a03b2274119ac8a32294e52a69480cb50e255 Mon Sep 17 00:00:00 2001 From: Charlie Date: Wed, 21 Feb 2024 10:01:19 +0000 Subject: [PATCH 0978/1171] feat: round price of orders pegged to mid --- protocol/0037-OPEG-pegged_orders.md | 18 +++++++++++++++++- 1 file changed, 17 insertions(+), 1 deletion(-) diff --git a/protocol/0037-OPEG-pegged_orders.md b/protocol/0037-OPEG-pegged_orders.md index d40aaca15..b02b65945 100644 --- a/protocol/0037-OPEG-pegged_orders.md +++ b/protocol/0037-OPEG-pegged_orders.md @@ -20,12 +20,28 @@ - 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) +- Given a mid-price which is not an integer multiple of the market tick size, a buy order pegged to the mid price should have it's price rounded up to the nearest market tick size. + For example, given: + - `tick_size=10` + - `best_bid_price=100` + - `best_ask_price=190` + - `mid_price=145` + Then: + - A pegged buy order using the mid price as the reference and `offset=10` should be inserted at `price=140`. +- Given a mid-price which is not an integer multiple of the market tick size, a buy orders pegged to the mid price should have it's price rounded up to the nearest market tick size. + For example, given: + - `tick_size=10` + - `best_bid_price=100` + - `best_ask_price=190` + - `mid_price=145` + Then: + - A pegged buy order using the mid price as the reference and `offset=10` should be inserted at `price=150`. ## Summary Market Makers and some other market participants are interested in maintaining limit orders on the order book that are a defined distance from a reference price (i.e. best bid, mid and best offer/ask) rather than at a specific limit price. In addition to being impossible to achieve perfectly through simple Amend commands, this method also creates many additional transactions. These problems are enough of an issue for centralised exchanges that many implement pegged orders, which are automatically repriced when the reference price moves. For decentralised trading with greater constraints on throughput and potentially orders of magnitude higher latency, pegged orders are all but essential to maintain a healthy and liquid order book. -Pegged orders are limit orders where the price is specified of the form `REFERENCE / OFFSET`, therefore 'pegged' is a _price type_, and can be used for any limit order that is valid during continuous trading. A pegged order's price is calculated from the value of the reference price on entry to the order book. Pegged orders that are persistent will be repriced, losing time priority, _after processing any event_ which causes the `REFERENCE` price to change. Pegged orders are not permitted in some trading period types, most notably auctions, and pegged orders that are on the book at the start of such a period will be parked (moved to a separate off-book area) in time priority until they are cancelled or expire, or the market enters a period that allows pegs, in which case they are re-priced and added back to the order book. Pegged orders entered during a period that does not accept them will be added to the parked area. Pegged orders submitted to a market with a main trading mode that does not support pegged orders will be rejected. All pegged orders in the system are held in a sorted by entry time list so that actions like re-pricing and parking/un-parking are performed in the same order as which the orders were entered into the system. +Pegged orders are limit orders where the price is specified of the form `REFERENCE / OFFSET`, therefore 'pegged' is a _price type_, and can be used for any limit order that is valid during continuous trading. A pegged order's price is calculated from the value of the reference price on entry to the order book. Note, to ensure orders are inserted at valid price levels allowed by the market's tick size, buy orders are rounded up to the nearest valid price and sell orders are rounded down to the nearest valid price (a valid price is one which is an exact multiple of the tick size). This ensures a pegged buy and sell order both with the smallest allowed offset from the mid form the smallest possible spread (one tick). Pegged orders that are persistent will be repriced, losing time priority, _after processing any event_ which causes the `REFERENCE` price to change. Pegged orders are not permitted in some trading period types, most notably auctions, and pegged orders that are on the book at the start of such a period will be parked (moved to a separate off-book area) in time priority until they are cancelled or expire, or the market enters a period that allows pegs, in which case they are re-priced and added back to the order book. Pegged orders entered during a period that does not accept them will be added to the parked area. Pegged orders submitted to a market with a main trading mode that does not support pegged orders will be rejected. All pegged orders in the system are held in a sorted by entry time list so that actions like re-pricing and parking/un-parking are performed in the same order as which the orders were entered into the system. ## Guide-level explanation From aaf3350a0f86aae708c9949b7e5d04b10c66654a Mon Sep 17 00:00:00 2001 From: Charlie Date: Wed, 21 Feb 2024 10:11:35 +0000 Subject: [PATCH 0979/1171] chore: assign ac codes --- protocol/0004-AMND-amends.md | 2 +- protocol/0025-OCRE-order_submission.md | 2 +- protocol/0028-GOVE-governance.md | 4 ++-- protocol/0037-OPEG-pegged_orders.md | 4 ++-- 4 files changed, 6 insertions(+), 6 deletions(-) diff --git a/protocol/0004-AMND-amends.md b/protocol/0004-AMND-amends.md index 5241c9789..4e618571b 100644 --- a/protocol/0004-AMND-amends.md +++ b/protocol/0004-AMND-amends.md @@ -4,7 +4,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) -- Price change amends specifying a new price which is not an integer multiple of the markets tick size should be rejected and the original order should be left in place. +- Price change amends specifying a new price which is not an integer multiple of the markets tick size should be rejected and the original order should be left in place (0004-AMND-060). - Reducing the quantity by specifying a `sizeDelta` 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 using a `sizeDelta` 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 by specifying a `sizeDelta` 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) diff --git a/protocol/0025-OCRE-order_submission.md b/protocol/0025-OCRE-order_submission.md index 04eb71377..10a7b8c02 100644 --- a/protocol/0025-OCRE-order_submission.md +++ b/protocol/0025-OCRE-order_submission.md @@ -39,7 +39,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) -- If an order's price is not an exact multiple of the markets tick size it should be rejected. +- If an order's price is not an exact multiple of the markets tick size it should be rejected (0025-OCRE-007). - 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/0028-GOVE-governance.md b/protocol/0028-GOVE-governance.md index 14a0572b7..27c76a5b3 100644 --- a/protocol/0028-GOVE-governance.md +++ b/protocol/0028-GOVE-governance.md @@ -555,8 +555,8 @@ APIs should also exist for clients to: - 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 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) -- A market proposal with a tick size less than or equal to `0` gets rejected. -- A market proposal with a tick size which is not an exact multiple of `10^-mdp` gets rejected (where `mdp` is the market decimal places). +- A market proposal with a tick size less than or equal to `0` gets rejected (0028-GOVE-180). +- A market proposal with a tick size which is not an exact multiple of `10^-mdp` gets rejected (where `mdp` is the market decimal places) (0028-GOVE-181). #### Market change proposals diff --git a/protocol/0037-OPEG-pegged_orders.md b/protocol/0037-OPEG-pegged_orders.md index b02b65945..07d6f1729 100644 --- a/protocol/0037-OPEG-pegged_orders.md +++ b/protocol/0037-OPEG-pegged_orders.md @@ -20,7 +20,7 @@ - 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) -- Given a mid-price which is not an integer multiple of the market tick size, a buy order pegged to the mid price should have it's price rounded up to the nearest market tick size. +- Given a mid-price which is not an integer multiple of the market tick size, a buy order pegged to the mid price should have it's price rounded up to the nearest market tick size (0037-OPEG-020). For example, given: - `tick_size=10` - `best_bid_price=100` @@ -28,7 +28,7 @@ - `mid_price=145` Then: - A pegged buy order using the mid price as the reference and `offset=10` should be inserted at `price=140`. -- Given a mid-price which is not an integer multiple of the market tick size, a buy orders pegged to the mid price should have it's price rounded up to the nearest market tick size. +- Given a mid-price which is not an integer multiple of the market tick size, a buy orders pegged to the mid price should have it's price rounded up to the nearest market tick size (0037-OPEG-021). For example, given: - `tick_size=10` - `best_bid_price=100` From 807fe653a816fc577c538f716bf1bd8ae4345965 Mon Sep 17 00:00:00 2001 From: Charlie Date: Thu, 22 Feb 2024 10:08:14 +0000 Subject: [PATCH 0980/1171] feat: clarify tick size specified in market decimals --- protocol/0001-MKTF-market_framework.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0001-MKTF-market_framework.md b/protocol/0001-MKTF-market_framework.md index d4444d8f1..6579c5bcd 100644 --- a/protocol/0001-MKTF-market_framework.md +++ b/protocol/0001-MKTF-market_framework.md @@ -32,7 +32,7 @@ Data: - **Position Decimal Places**: number of decimal places for orders and positions, i.e. if this is 2 then the smallest increment that can be traded is 0.01, for example 0.01 BTC in a `BTSUSD` market. - If this is negative e.g. -3 this means that the smallest order and position is of size 1000. - Accepted values are `-6,...,-1,0,1,2,...,6`. -- **Tick size**: the minimum change in quote price for the market. Order prices and offsets for pegged orders must be given as an exact multiple of the tick size. For example if the tick size is 0.02 USD. then a price of 100.02 USD is acceptable and a price of 100.03 USD is not. The tick size of a market can be updated through governance. +- **Tick size**: the minimum change in quote price for the market. Order prices and offsets for pegged orders must be given as an exact multiple of the tick size. For example if the tick size is 0.02 USD. then a price of 100.02 USD is acceptable and a price of 100.03 USD is not. The tick size of a market can be updated through governance. Note, the tick size should be specified in terms of the market decimals, e.g. for a scaled tick size of `0.02` (USDT) in a market using `5` decimal places, the tick size would be set to `2000`. - **Liquidation strategy**: A field specifying the liquidation strategy for the market. Please refer to [0012-POSR-position_resolution](./0012-POSR-position_resolution.md#managing-networks-position) for supported strategies. Note: it is agreed that initially the integer representation of the full precision of both order and positions can be required to fit into an int64, so this means that the largest position/order size possible reduces by a factor of ten for every extra decimal place used. This also means that, for instance, it would not be possible to create a `BTCUSD` market that allows order/position sizes equivalent to 1 sat. From a9d8453490f958accc56841aba9e859678f01c55 Mon Sep 17 00:00:00 2001 From: gordsport Date: Thu, 22 Feb 2024 12:54:45 +0000 Subject: [PATCH 0981/1171] fix: features.json file after colosseo updates --- protocol/features.json | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/protocol/features.json b/protocol/features.json index 3a2036aa9..59ed344e3 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -315,6 +315,17 @@ "milestone": "colosseo", "acs": ["0053-PERP-036"] }, + "Market tick size": { + "milestone": "colosseo", + "acs": [ + "0004-AMND-060", + "0025-OCRE-006", + "0028-GOVE-180", + "0028-GOVE-181", + "0037-OPEG-020", + "0037-OPEG-021" + ] + }, "Unknown": { "milestone": "unknown", "acs": [] From 7a6958e898076ed8c14a186fe710877c58e03f0b Mon Sep 17 00:00:00 2001 From: Pete Barrow Date: Thu, 22 Feb 2024 13:11:12 +0000 Subject: [PATCH 0982/1171] fix: Wording --- protocol/0014-ORDT-order_types.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/protocol/0014-ORDT-order_types.md b/protocol/0014-ORDT-order_types.md index 4f08ab588..a35243316 100644 --- a/protocol/0014-ORDT-order_types.md +++ b/protocol/0014-ORDT-order_types.md @@ -263,8 +263,8 @@ 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) + - A 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 (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) From 948d2ee693c795f3d61018648e320afdea9586c1 Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Mon, 26 Feb 2024 09:32:04 +0000 Subject: [PATCH 0983/1171] feat: add ac for taker fee cap --- protocol/0057-TRAN-transfers.md | 18 +++++++++++++++++- 1 file changed, 17 insertions(+), 1 deletion(-) diff --git a/protocol/0057-TRAN-transfers.md b/protocol/0057-TRAN-transfers.md index 463b9204a..9044d33a7 100644 --- a/protocol/0057-TRAN-transfers.md +++ b/protocol/0057-TRAN-transfers.md @@ -109,7 +109,7 @@ A party should be able to configure the distribution of rewards by specifying th - `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. -- `cap_reward_fee_multiple` [optional] - if set, the actual amount of reward transferred to each public key during distribution for this transfer will be `min(calculated_reward_in_quantum, cap_reward_fee_multiple × fees_paid_this_epoch_in_quantum)`. When calculating how much of the reward each one is getting, if some is left from the applied cap, we recalculate on the remaining balance only for parties that have not reached their cap until the leftover is less than 1 reward asset unit or the maximum rounds of recalculation is 10. If all keys are capped (i.e. the total amount of the transfer cannot be be sent to eligible keys without breaching the cap) then the remaining balance must be left in the reward pool and included in the distribution in future epochs. If this occurs, and the total transferred in a given epoch this does not affect the size of the next iteration, which proceeds as normal (including decay factors etc.) as if the full transfer has been made. +- `cap_reward_fee_multiple` [optional] - if set, the actual amount of reward transferred to each public key during distribution for this transfer will be `min(calculated_reward_in_quantum, cap_reward_fee_multiple × fees_paid_this_epoch_in_quantum)`. When calculating how much of the reward each one is getting, if some is left from the applied cap, we recalculate on the remaining balance only for parties that have not reached their cap until the leftover is less than 1 reward asset unit or the maximum rounds of recalculation is 10. If all keys are capped (i.e. the total amount of the transfer cannot be be sent to eligible keys without breaching the cap) then the remaining balance must be left in the reward pool and included in the distribution in future epochs. If this occurs, and the total transferred in a given epoch, this does not affect the size of the next iteration, which proceeds as normal (including decay factors etc.) as if the full transfer has been made. - `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. @@ -388,3 +388,19 @@ If the network parameter `spam.protection.maxUserTransfersPerEpoch` is modified, 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) +If the network parameter `cap_reward_fee_multiple` is set, and if `calculated_reward_in_quantum < cap_reward_fee_multiple × fees_paid_this_epoch_in_quantum` then the actual amount of reward transferred to each public key during distribution for this transfer will be `calculated_reward_in_quantum`(0057-TRAN-070) + +If the network parameter `cap_reward_fee_multiple` is set, and if `calculated_reward_in_quantum > cap_reward_fee_multiple × fees_paid_this_epoch_in_quantum` then the actual amount of reward transferred to each public key during distribution for this transfer will be `cap_reward_fee_multiple × fees_paid_this_epoch_in_quantum`(0057-TRAN-071) + +If the network parameter `cap_reward_fee_multiple` is set, and if some reward is left from the applied cap, the remaining balance should be recalculated only for parties that have not reacher their cap until the leftover is less than 1 reward asset unit or the maximum rounds of recalculation is 10 +(0057-TRAN-072) + +If the network parameter `cap_reward_fee_multiple` is set, and if all keys are capped, then the remaining balance must be left in the reward pool and included in the distribution in the future epochs. (0057-TRAN-073) + +If the scenario above occurs, and the total transferred in a given epoch, this does not affect the size of the next iteration, which proceeds as normal (including decay factors etc.) as if the full transfer has been made (0057-TRAN-074) + + + + + + From 1a87816614ddb51db1e044d2bfc72f5adb5f742b Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Mon, 26 Feb 2024 09:35:09 +0000 Subject: [PATCH 0984/1171] chore: typo --- protocol/0057-TRAN-transfers.md | 10 ++-------- 1 file changed, 2 insertions(+), 8 deletions(-) diff --git a/protocol/0057-TRAN-transfers.md b/protocol/0057-TRAN-transfers.md index 9044d33a7..3ce3c0d3e 100644 --- a/protocol/0057-TRAN-transfers.md +++ b/protocol/0057-TRAN-transfers.md @@ -392,15 +392,9 @@ If the network parameter `cap_reward_fee_multiple` is set, and if `calculated_re If the network parameter `cap_reward_fee_multiple` is set, and if `calculated_reward_in_quantum > cap_reward_fee_multiple × fees_paid_this_epoch_in_quantum` then the actual amount of reward transferred to each public key during distribution for this transfer will be `cap_reward_fee_multiple × fees_paid_this_epoch_in_quantum`(0057-TRAN-071) -If the network parameter `cap_reward_fee_multiple` is set, and if some reward is left from the applied cap, the remaining balance should be recalculated only for parties that have not reacher their cap until the leftover is less than 1 reward asset unit or the maximum rounds of recalculation is 10 +If the network parameter `cap_reward_fee_multiple` is set, and if some reward is left from the applied cap, the remaining balance should be recalculated only for parties that have not reached their cap until the leftover is less than 1 reward asset unit or the maximum rounds of recalculation is 10 (0057-TRAN-072) If the network parameter `cap_reward_fee_multiple` is set, and if all keys are capped, then the remaining balance must be left in the reward pool and included in the distribution in the future epochs. (0057-TRAN-073) -If the scenario above occurs, and the total transferred in a given epoch, this does not affect the size of the next iteration, which proceeds as normal (including decay factors etc.) as if the full transfer has been made (0057-TRAN-074) - - - - - - +If the scenario above occurs, and the total transferred in a given epoch, this does not affect the size of the next iteration, which proceeds as normal (including decay factors etc.) as if the full transfer has been made (0057-TRAN-074) \ No newline at end of file From aa9bfe528de238af1afc576d2ace0d59003dbf5b Mon Sep 17 00:00:00 2001 From: Charlie Date: Mon, 26 Feb 2024 09:51:31 +0000 Subject: [PATCH 0985/1171] feat: add AC clarifying update logic --- protocol/0028-GOVE-governance.md | 1 + protocol/colosseo-features.json | 47 ++++++++++++++++++++++++++++++++ 2 files changed, 48 insertions(+) create mode 100644 protocol/colosseo-features.json diff --git a/protocol/0028-GOVE-governance.md b/protocol/0028-GOVE-governance.md index 27c76a5b3..b488b9fba 100644 --- a/protocol/0028-GOVE-governance.md +++ b/protocol/0028-GOVE-governance.md @@ -557,6 +557,7 @@ APIs should also exist for clients to: - A market proposal with position decimal places not in `{-6,...,-1,0,1,2,...,6}` gets rejected. (0028-GOVE-062) - A market proposal with a tick size less than or equal to `0` gets rejected (0028-GOVE-180). - A market proposal with a tick size which is not an exact multiple of `10^-mdp` gets rejected (where `mdp` is the market decimal places) (0028-GOVE-181). +- At enactment, a market change proposal updating the tick size leaves in place all orders where the quoted price is not an exact multiple of `10^-mdp` (where `mdp` is the market decimal places) (0028-GOVE-182). #### Market change proposals diff --git a/protocol/colosseo-features.json b/protocol/colosseo-features.json new file mode 100644 index 000000000..50938b567 --- /dev/null +++ b/protocol/colosseo-features.json @@ -0,0 +1,47 @@ +{ + "Markprice updates": { + "milestone": "nebula", + "acs": [ + "0009-MRKP-132", + "0053-PERP-043", + "0032-PRIM-039", + "0032-PRIM-040" + ] + }, + "Community Tags": { + "milestone": "nebula", + "acs": [ + "0028-GOVE-167", + "0028-GOVE-168", + "0028-GOVE-169", + "0028-GOVE-170", + "0028-GOVE-171", + "0028-GOVE-172", + "0028-GOVE-173", + "0028-GOVE-174", + "0028-GOVE-175", + "0028-GOVE-176", + "0028-GOVE-177" + ] + }, + "Perpetual funding rates": { + "milestone": "nebula", + "acs": ["0053-PERP-036"] + }, + "Market tick size": { + "milestone": "nebula", + "acs": [ + "0004-AMND-060", + "0025-OCRE-006", + "0028-GOVE-180", + "0028-GOVE-181", + "0028-GOVE-182", + "0037-OPEG-020", + "0037-OPEG-021" + ] + }, + "Unknown": { + "milestone": "unknown", + "acs": [] + } +} From 244eb4869f56de86dbc64f1d7140d2f5026f3ed6 Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Mon, 26 Feb 2024 10:03:04 +0000 Subject: [PATCH 0986/1171] chore: address comment --- 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 3ce3c0d3e..9b6bfed57 100644 --- a/protocol/0057-TRAN-transfers.md +++ b/protocol/0057-TRAN-transfers.md @@ -397,4 +397,4 @@ If the network parameter `cap_reward_fee_multiple` is set, and if some reward is If the network parameter `cap_reward_fee_multiple` is set, and if all keys are capped, then the remaining balance must be left in the reward pool and included in the distribution in the future epochs. (0057-TRAN-073) -If the scenario above occurs, and the total transferred in a given epoch, this does not affect the size of the next iteration, which proceeds as normal (including decay factors etc.) as if the full transfer has been made (0057-TRAN-074) \ No newline at end of file +If the network parameter `cap_reward_fee_multiple` is set, and the total reward transferred in a given epoch, this does not affect the size of the next iteration, which proceeds as normal (including decay factors etc.) as if the full transfer has been made (0057-TRAN-074) From ef39e90110ee0851de5c2adb0740c58530de3669 Mon Sep 17 00:00:00 2001 From: gordsport Date: Mon, 26 Feb 2024 13:48:03 +0000 Subject: [PATCH 0987/1171] chore: add features.json entry --- protocol/features.json | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/protocol/features.json b/protocol/features.json index 59ed344e3..92f038f4e 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -326,6 +326,16 @@ "0037-OPEG-021" ] }, + "Taker fee cap": { + "milestone": "colosseo", + "acs": [ + "0057-TRAN-070" + "0057-TRAN-071", + "0057-TRAN-072", + "0057-TRAN-073", + "0057-TRAN-074" + ] + }, "Unknown": { "milestone": "unknown", "acs": [] From 80676f69b20b1f0f2b57e7384e494e65382e0a6a Mon Sep 17 00:00:00 2001 From: gordsport Date: Mon, 26 Feb 2024 13:50:56 +0000 Subject: [PATCH 0988/1171] fix: syntax --- protocol/features.json | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/features.json b/protocol/features.json index 92f038f4e..25d45af6d 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -329,7 +329,7 @@ "Taker fee cap": { "milestone": "colosseo", "acs": [ - "0057-TRAN-070" + "0057-TRAN-070", "0057-TRAN-071", "0057-TRAN-072", "0057-TRAN-073", From c5bd394452e44e0d194ef1e4f827947bbb89a061 Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Mon, 26 Feb 2024 15:30:06 +0000 Subject: [PATCH 0989/1171] feat: add AC for validation --- protocol/0057-TRAN-transfers.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/protocol/0057-TRAN-transfers.md b/protocol/0057-TRAN-transfers.md index 9b6bfed57..d3623f5dc 100644 --- a/protocol/0057-TRAN-transfers.md +++ b/protocol/0057-TRAN-transfers.md @@ -398,3 +398,5 @@ If the network parameter `cap_reward_fee_multiple` is set, and if some reward is If the network parameter `cap_reward_fee_multiple` is set, and if all keys are capped, then the remaining balance must be left in the reward pool and included in the distribution in the future epochs. (0057-TRAN-073) If the network parameter `cap_reward_fee_multiple` is set, and the total reward transferred in a given epoch, this does not affect the size of the next iteration, which proceeds as normal (including decay factors etc.) as if the full transfer has been made (0057-TRAN-074) + +If the network parameter `cap_reward_fee_multiple` is set to be `<0`, then it should be rejected (0057-TRAN-075) From 259e07f2551120680b95e3a981c211c5eb459cab Mon Sep 17 00:00:00 2001 From: Gordsport <83510148+gordsport@users.noreply.github.com> Date: Mon, 26 Feb 2024 15:31:03 +0000 Subject: [PATCH 0990/1171] chore: add new AC to features file --- protocol/features.json | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/protocol/features.json b/protocol/features.json index 25d45af6d..af00b9f1a 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -333,7 +333,8 @@ "0057-TRAN-071", "0057-TRAN-072", "0057-TRAN-073", - "0057-TRAN-074" + "0057-TRAN-074", + "0057-TRAN-075" ] }, "Unknown": { From 2a2eeecee234be78a3ee13c54382ddd3756fa4db Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Mon, 26 Feb 2024 15:53:55 +0000 Subject: [PATCH 0991/1171] feat: address comment --- 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 d3623f5dc..bd2a46b86 100644 --- a/protocol/0057-TRAN-transfers.md +++ b/protocol/0057-TRAN-transfers.md @@ -399,4 +399,4 @@ If the network parameter `cap_reward_fee_multiple` is set, and if all keys are c If the network parameter `cap_reward_fee_multiple` is set, and the total reward transferred in a given epoch, this does not affect the size of the next iteration, which proceeds as normal (including decay factors etc.) as if the full transfer has been made (0057-TRAN-074) -If the network parameter `cap_reward_fee_multiple` is set to be `<0`, then it should be rejected (0057-TRAN-075) +If the network parameter `cap_reward_fee_multiple` is set to be `<=0`, then it should be rejected (0057-TRAN-075) From c35ed7ef73c42c865606da19f87c3053a6cde32c Mon Sep 17 00:00:00 2001 From: Gordsport <83510148+gordsport@users.noreply.github.com> Date: Mon, 26 Feb 2024 16:02:16 +0000 Subject: [PATCH 0992/1171] feat: Add order spam (#2180) * feat: Add order spam Copies content from: - https://github.com/vegaprotocol/specs/issues/2097 With base branch as Colosseo * fix: add ACs to features.json * Update 0062-SPAM-spam_protection.md * fix: AC code error and MD lint * Update protocol/0062-SPAM-spam_protection.md Co-authored-by: David Siska <62546419+davidsiska-vega@users.noreply.github.com> * fix: quality checks * Update 0062-SPAM-spam_protection.md * chore: Update features.json * fix: Update protocol/0062-SPAM-spam_protection.md Co-authored-by: David Siska <62546419+davidsiska-vega@users.noreply.github.com> --------- Co-authored-by: Vegaklaus <62546834+Vegaklaus@users.noreply.github.com> Co-authored-by: David Siska <62546419+davidsiska-vega@users.noreply.github.com> --- protocol/0062-SPAM-spam_protection.md | 19 ++++++++++++++++++- protocol/features.json | 4 ++++ wordlist.txt | 2 ++ 3 files changed, 24 insertions(+), 1 deletion(-) diff --git a/protocol/0062-SPAM-spam_protection.md b/protocol/0062-SPAM-spam_protection.md index fd5b559a6..c559ec279 100644 --- a/protocol/0062-SPAM-spam_protection.md +++ b/protocol/0062-SPAM-spam_protection.md @@ -83,6 +83,20 @@ Further, each party is allowed to submit up to `n` transactions per epoch where **Note** `spam.protection.max.updatePartyProfile` must be an integer greater than or equal to `0` (and default to `5`). +### Transaction Spam + +Network parameter: `spam.order.MinimalMarginQuantumMultiple` (between 0 and infinite) + +If the maintenance margin for a given transaction is smaller than the parameter `spam.order.MinimalMarginSizeQuantumMultiple`, then the transaction is pre-block rejected. +I.e. if `(rf + linear slippage param) x size x price < spam.order.MinimalMarginSizeQuantumMultiple x asset quantum amount` then the order is rejected. Here `rf` is the risk factor (and will be different for long and for short) `linear slippage param` is a market parameter and `size` and `price` are assumed to be correctly scaled by, PDPs and MDPs respectively. + +If the market does not exist and thus the maintenance margin is not defined, the transaction is rejected. + +Non-persistent orders (on both spot and futures markets) are not blocked by this mechanism as long as the market exists. + +The calculation for this should be done before the gas cost calculation as rejected transactions should not get into the calculation of the +gas cost. + ### Related topics @@ -127,6 +141,9 @@ More than 360 delegation changes in one epoch (or, respectively, the value of `s - A party holding no less than `spam.protection.referralSet.min.funds` x quantum and staking no less than `referralProgram.minStakedVegaTokens` should not have any `UpdateReferralSettransactions` pre-block rejected (0062-SPAM-041). - A party who has submitted strictly more than `spam.protection.max.updatePartyProfile` `UpdatePartyProfile` transactions in an epoch should have any future `UpdatePartyProfile` transactions in that epoch **pre-block** rejected (0062-SPAM-038). - A party who has submitted more than `spam.protection.max.updatePartyProfile` `UpdatePartyProfile` transactions in the current epoch plus in the current block, should have their `UpdatePartyProfile` transactions submitted in the current block **pre-block** rejected (0062-SPAM-039). - +- Issue a set of orders starting with the minimum price, and doubling the order price with every order. Once the first order passes the spam filter, quadruple the parameter `spam.order.MinimalMarginQuantumMultiple` and continue. Once the next order passes the filter, quadruple the quantum size for the underlying asset, and continue until an order passes the filter again. Verify that all rejected orders had a margin smaller than `spam.order.MinimalMarginQuantumMultiple`, and all accepted ones one bigger or equal. (0062-SPAM-043). +- Issue a set of orders for an existing, but not yet enacted market, starting with the minimum price, and doubling the order price with every order. Once the first order passes the spam filter, quadruple the parameter `spam.order.MinimalMarginQuantumMultiple` and continue. Once the next order passes the filter, quadruple the quantum size for the underlying asset, and continue until an order passes the filter again. Verify that all rejected orders had a margin smaller than `spam.order.MinimalMarginQuantumMultiple`, and all accepted ones one bigger or equal. (0062-SPAM-044). +- Create an order for a non-existing market, and verify that it is rejected by the spam filter. (0062-SPAM-045). +- Create a non-persistent order for an existing market with a minimum order price, and verify that it is not rejected by the spam filter. (0062-SPAM-046). > **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 59ed344e3..4e78ce0ec 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -315,6 +315,10 @@ "milestone": "colosseo", "acs": ["0053-PERP-036"] }, + "Order spam": { + "milestone": "unknown", + "acs": ["0062-SPAM-043", "0062-SPAM-044", "0062-SPAM-045", "0062-SPAM-046"] + }, "Market tick size": { "milestone": "colosseo", "acs": [ diff --git a/wordlist.txt b/wordlist.txt index 9d2a6b610..1cbcea401 100644 --- a/wordlist.txt +++ b/wordlist.txt @@ -174,6 +174,7 @@ margined margining marketID math +MDPs mempool Merkle messager @@ -200,6 +201,7 @@ orderbooks ORDT parallelisation PDP +PDPs performant permissioned permissionless From 325ef274d886a198f40d0132b13bbc273b3713c9 Mon Sep 17 00:00:00 2001 From: Charlie Date: Mon, 26 Feb 2024 17:34:01 +0000 Subject: [PATCH 0993/1171] chore: remove redundant AC --- protocol/0028-GOVE-governance.md | 1 - protocol/colosseo-features.json | 1 - 2 files changed, 2 deletions(-) diff --git a/protocol/0028-GOVE-governance.md b/protocol/0028-GOVE-governance.md index b488b9fba..06cc54a52 100644 --- a/protocol/0028-GOVE-governance.md +++ b/protocol/0028-GOVE-governance.md @@ -556,7 +556,6 @@ APIs should also exist for clients to: - 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) - A market proposal with a tick size less than or equal to `0` gets rejected (0028-GOVE-180). -- A market proposal with a tick size which is not an exact multiple of `10^-mdp` gets rejected (where `mdp` is the market decimal places) (0028-GOVE-181). - At enactment, a market change proposal updating the tick size leaves in place all orders where the quoted price is not an exact multiple of `10^-mdp` (where `mdp` is the market decimal places) (0028-GOVE-182). #### Market change proposals diff --git a/protocol/colosseo-features.json b/protocol/colosseo-features.json index 50938b567..5217d3804 100644 --- a/protocol/colosseo-features.json +++ b/protocol/colosseo-features.json @@ -34,7 +34,6 @@ "0004-AMND-060", "0025-OCRE-006", "0028-GOVE-180", - "0028-GOVE-181", "0028-GOVE-182", "0037-OPEG-020", "0037-OPEG-021" From db165ca1daf18317b4495c0c90f5dcb8d2ce6d29 Mon Sep 17 00:00:00 2001 From: Charlie Date: Mon, 26 Feb 2024 17:44:01 +0000 Subject: [PATCH 0994/1171] fix: update correct features json --- protocol/colosseo-features.json | 46 --------------------------------- protocol/features.json | 2 +- 2 files changed, 1 insertion(+), 47 deletions(-) delete mode 100644 protocol/colosseo-features.json diff --git a/protocol/colosseo-features.json b/protocol/colosseo-features.json deleted file mode 100644 index 5217d3804..000000000 --- a/protocol/colosseo-features.json +++ /dev/null @@ -1,46 +0,0 @@ -{ - "Markprice updates": { - "milestone": "nebula", - "acs": [ - "0009-MRKP-132", - "0053-PERP-043", - "0032-PRIM-039", - "0032-PRIM-040" - ] - }, - "Community Tags": { - "milestone": "nebula", - "acs": [ - "0028-GOVE-167", - "0028-GOVE-168", - "0028-GOVE-169", - "0028-GOVE-170", - "0028-GOVE-171", - "0028-GOVE-172", - "0028-GOVE-173", - "0028-GOVE-174", - "0028-GOVE-175", - "0028-GOVE-176", - "0028-GOVE-177" - ] - }, - "Perpetual funding rates": { - "milestone": "nebula", - "acs": ["0053-PERP-036"] - }, - "Market tick size": { - "milestone": "nebula", - "acs": [ - "0004-AMND-060", - "0025-OCRE-006", - "0028-GOVE-180", - "0028-GOVE-182", - "0037-OPEG-020", - "0037-OPEG-021" - ] - }, - "Unknown": { - "milestone": "unknown", - "acs": [] - } -} diff --git a/protocol/features.json b/protocol/features.json index 4e78ce0ec..3498cb7ed 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -325,7 +325,7 @@ "0004-AMND-060", "0025-OCRE-006", "0028-GOVE-180", - "0028-GOVE-181", + "0028-GOVE-182", "0037-OPEG-020", "0037-OPEG-021" ] From 066af51aab92a59355190bad1738f6b12faea954 Mon Sep 17 00:00:00 2001 From: Gordsport <83510148+gordsport@users.noreply.github.com> Date: Mon, 26 Feb 2024 18:18:15 +0000 Subject: [PATCH 0995/1171] fix: correct milestone name --- protocol/features.json | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/features.json b/protocol/features.json index 3498cb7ed..5834b5f1e 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -316,7 +316,7 @@ "acs": ["0053-PERP-036"] }, "Order spam": { - "milestone": "unknown", + "milestone": "colosseo", "acs": ["0062-SPAM-043", "0062-SPAM-044", "0062-SPAM-045", "0062-SPAM-046"] }, "Market tick size": { From eaafff47eccd2fe7213de7ba8aae39d90e407f97 Mon Sep 17 00:00:00 2001 From: Gordsport <83510148+gordsport@users.noreply.github.com> Date: Tue, 27 Feb 2024 09:31:33 +0000 Subject: [PATCH 0996/1171] fix: missed merge from palazzo into colosseo (#2190) This adds in the changes from https://github.com/vegaprotocol/specs/pull/2182 into colosseo and renumbers the new community tags ACs --- protocol/0028-GOVE-governance.md | 7 ++++--- protocol/features.json | 4 ++-- 2 files changed, 6 insertions(+), 5 deletions(-) diff --git a/protocol/0028-GOVE-governance.md b/protocol/0028-GOVE-governance.md index 06cc54a52..ed7b36a81 100644 --- a/protocol/0028-GOVE-governance.md +++ b/protocol/0028-GOVE-governance.md @@ -581,7 +581,9 @@ APIs should also exist for clients to: - 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 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) +- 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. Resuming the market will then put the market in the state it was in prior to it being suspended. + - monitoring auction (0028-GOVE-114) + - opening auction (0028-GOVE-167) - 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) @@ -762,7 +764,7 @@ The voting to approve the batch happens, the batch passes, the value of the prop ##### Community Market Tags -- A proposal to add community tags to a market can be successfully submitted. (0028-GOVE-167) +- A proposal to add community tags to a market can be successfully submitted. (0028-GOVE-178) - When that proposal is approved and enacted the community tags are immediately added to that market's community tags property. (0028-GOVE-168) - A proposal to remove community tags from a market can be successfully submitted. (0028-GOVE-169) - When that proposal is approved and enacted the community tags are immediately removed from that market's community tags property. (0028-GOVE-170) @@ -772,4 +774,3 @@ The voting to approve the batch happens, the batch passes, the value of the prop - A voter's equity-like share does not give them any additional voting weight when voting on a market community tags update proposal. (0028-GOVE-174) - A proposal to add community tags with any community tags longer than `governance.proposal.market.maxCommunityTagLength` is rejected as invalid (0028-GOVE-175) - A proposal to remove community tags with any community tags longer than `governance.proposal.market.maxCommunityTagLength` is rejected as invalid (0028-GOVE-176) - diff --git a/protocol/features.json b/protocol/features.json index dd14b9ff9..a4d0795fc 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -298,7 +298,6 @@ "Community Tags": { "milestone": "colosseo", "acs": [ - "0028-GOVE-167", "0028-GOVE-168", "0028-GOVE-169", "0028-GOVE-170", @@ -308,7 +307,8 @@ "0028-GOVE-174", "0028-GOVE-175", "0028-GOVE-176", - "0028-GOVE-177" + "0028-GOVE-177", + "0028-GOVE-178" ] }, "Perpetual funding rates": { From b0eee9e6c71b21a8ee1e90642f98a9e4af629fb8 Mon Sep 17 00:00:00 2001 From: David Siska <62546419+davidsiska-vega@users.noreply.github.com> Date: Tue, 27 Feb 2024 11:51:36 +0000 Subject: [PATCH 0997/1171] fix: closeout trades and auctions (#2189) * fix: closeout trades and auctions * fix: closeout trades and auctions * chore: Add AC to features.json * fix: closeout trades and auctions * fix: closeout trades and auctions --------- Co-authored-by: gordsport --- protocol/0012-POSR-position_resolution.md | 2 +- protocol/features.json | 4 ++++ protocol/palazzo-features.json | 1 - 3 files changed, 5 insertions(+), 2 deletions(-) diff --git a/protocol/0012-POSR-position_resolution.md b/protocol/0012-POSR-position_resolution.md index a5e050644..ab70da7c0 100644 --- a/protocol/0012-POSR-position_resolution.md +++ b/protocol/0012-POSR-position_resolution.md @@ -38,7 +38,7 @@ - The network must never dispose more than `available volume * max fraction of book side within liquidity bounds consumed` in a single order. (0012-POSR-025) - A network disposal order which generates trades must not affect the mark price. (0012-POSR-026) - A network disposal order can not cross with orders outside the liquidity price range. (0012-POSR-027) -- A network disposal order can cross with orders outside price monitoring bounds but must not trigger a price monitoring auction. (0012-POSR-028) +- A network disposal order will not cross with orders outside price monitoring bounds (internally has to behave like an IOC at one tick inside the price monitoring bound). Hence a network disposal cannot trade at a price outside the tightest price monitoring and it won't ever trigger a price monitoring auction. (0012-POSR-030) - A network disposal order which crosses multiple orders should generate multiple atomic trades. (0012-POSR-029) ### Network Profit and Loss diff --git a/protocol/features.json b/protocol/features.json index a4d0795fc..cb6290b99 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -341,6 +341,10 @@ "0057-TRAN-075" ] }, + "Closeout trades and auctions": { + "milestone": "colosseo", + "acs": ["0012-POSR-030"] + }, "Unknown": { "milestone": "unknown", "acs": [] diff --git a/protocol/palazzo-features.json b/protocol/palazzo-features.json index 53549dac9..2e4a17cd8 100644 --- a/protocol/palazzo-features.json +++ b/protocol/palazzo-features.json @@ -242,7 +242,6 @@ "0012-POSR-025", "0012-POSR-026", "0012-POSR-027", - "0012-POSR-028", "0012-POSR-029", "0003-MTMK-015", "0003-MTMK-016", From 9d6ef32d3f8fb4ea4cb3895116f62fad64464c30 Mon Sep 17 00:00:00 2001 From: Charlie Date: Wed, 28 Feb 2024 11:03:47 +0000 Subject: [PATCH 0998/1171] feat: change direction of rounding pegged orders --- protocol/0037-OPEG-pegged_orders.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/protocol/0037-OPEG-pegged_orders.md b/protocol/0037-OPEG-pegged_orders.md index 07d6f1729..35616c5db 100644 --- a/protocol/0037-OPEG-pegged_orders.md +++ b/protocol/0037-OPEG-pegged_orders.md @@ -20,28 +20,28 @@ - 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) -- Given a mid-price which is not an integer multiple of the market tick size, a buy order pegged to the mid price should have it's price rounded up to the nearest market tick size (0037-OPEG-020). +- Given a mid-price which is not an integer multiple of the market tick size, a buy order pegged to the mid price should have it's price rounded down to the nearest market tick size (0037-OPEG-020). For example, given: - `tick_size=10` - `best_bid_price=100` - `best_ask_price=190` - `mid_price=145` Then: - - A pegged buy order using the mid price as the reference and `offset=10` should be inserted at `price=140`. -- Given a mid-price which is not an integer multiple of the market tick size, a buy orders pegged to the mid price should have it's price rounded up to the nearest market tick size (0037-OPEG-021). + - A pegged buy order using the mid price as the reference and `offset=10` should be inserted at `price=130`. +- Given a mid-price which is not an integer multiple of the market tick size, a sell order pegged to the mid price should have it's price rounded up to the nearest market tick size (0037-OPEG-021). For example, given: - `tick_size=10` - `best_bid_price=100` - `best_ask_price=190` - `mid_price=145` Then: - - A pegged buy order using the mid price as the reference and `offset=10` should be inserted at `price=150`. + - A pegged buy order using the mid price as the reference and `offset=10` should be inserted at `price=160`. ## Summary Market Makers and some other market participants are interested in maintaining limit orders on the order book that are a defined distance from a reference price (i.e. best bid, mid and best offer/ask) rather than at a specific limit price. In addition to being impossible to achieve perfectly through simple Amend commands, this method also creates many additional transactions. These problems are enough of an issue for centralised exchanges that many implement pegged orders, which are automatically repriced when the reference price moves. For decentralised trading with greater constraints on throughput and potentially orders of magnitude higher latency, pegged orders are all but essential to maintain a healthy and liquid order book. -Pegged orders are limit orders where the price is specified of the form `REFERENCE / OFFSET`, therefore 'pegged' is a _price type_, and can be used for any limit order that is valid during continuous trading. A pegged order's price is calculated from the value of the reference price on entry to the order book. Note, to ensure orders are inserted at valid price levels allowed by the market's tick size, buy orders are rounded up to the nearest valid price and sell orders are rounded down to the nearest valid price (a valid price is one which is an exact multiple of the tick size). This ensures a pegged buy and sell order both with the smallest allowed offset from the mid form the smallest possible spread (one tick). Pegged orders that are persistent will be repriced, losing time priority, _after processing any event_ which causes the `REFERENCE` price to change. Pegged orders are not permitted in some trading period types, most notably auctions, and pegged orders that are on the book at the start of such a period will be parked (moved to a separate off-book area) in time priority until they are cancelled or expire, or the market enters a period that allows pegs, in which case they are re-priced and added back to the order book. Pegged orders entered during a period that does not accept them will be added to the parked area. Pegged orders submitted to a market with a main trading mode that does not support pegged orders will be rejected. All pegged orders in the system are held in a sorted by entry time list so that actions like re-pricing and parking/un-parking are performed in the same order as which the orders were entered into the system. +Pegged orders are limit orders where the price is specified of the form `REFERENCE / OFFSET`, therefore 'pegged' is a _price type_, and can be used for any limit order that is valid during continuous trading. A pegged order's price is calculated from the value of the reference price on entry to the order book. Note, to ensure orders are inserted at valid price levels allowed by the market's tick size, buy orders are rounded down to the nearest valid price and sell orders are rounded up to the nearest valid price (a valid price is one which is an exact multiple of the tick size). This ensures pegged buy and sell orders will not cross, even if the market tick size is increased through governance. Pegged orders that are persistent will be repriced, losing time priority, _after processing any event_ which causes the `REFERENCE` price to change. Pegged orders are not permitted in some trading period types, most notably auctions, and pegged orders that are on the book at the start of such a period will be parked (moved to a separate off-book area) in time priority until they are cancelled or expire, or the market enters a period that allows pegs, in which case they are re-priced and added back to the order book. Pegged orders entered during a period that does not accept them will be added to the parked area. Pegged orders submitted to a market with a main trading mode that does not support pegged orders will be rejected. All pegged orders in the system are held in a sorted by entry time list so that actions like re-pricing and parking/un-parking are performed in the same order as which the orders were entered into the system. ## Guide-level explanation From 1e3f6d3cd344ddda826ab6eaf2ed23ae9d4bc33c Mon Sep 17 00:00:00 2001 From: Charlie Date: Wed, 28 Feb 2024 17:31:56 +0000 Subject: [PATCH 0999/1171] Revert "feat: change direction of rounding pegged orders" This reverts commit 9d6ef32d3f8fb4ea4cb3895116f62fad64464c30. --- protocol/0037-OPEG-pegged_orders.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/protocol/0037-OPEG-pegged_orders.md b/protocol/0037-OPEG-pegged_orders.md index 35616c5db..07d6f1729 100644 --- a/protocol/0037-OPEG-pegged_orders.md +++ b/protocol/0037-OPEG-pegged_orders.md @@ -20,28 +20,28 @@ - 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) -- Given a mid-price which is not an integer multiple of the market tick size, a buy order pegged to the mid price should have it's price rounded down to the nearest market tick size (0037-OPEG-020). +- Given a mid-price which is not an integer multiple of the market tick size, a buy order pegged to the mid price should have it's price rounded up to the nearest market tick size (0037-OPEG-020). For example, given: - `tick_size=10` - `best_bid_price=100` - `best_ask_price=190` - `mid_price=145` Then: - - A pegged buy order using the mid price as the reference and `offset=10` should be inserted at `price=130`. -- Given a mid-price which is not an integer multiple of the market tick size, a sell order pegged to the mid price should have it's price rounded up to the nearest market tick size (0037-OPEG-021). + - A pegged buy order using the mid price as the reference and `offset=10` should be inserted at `price=140`. +- Given a mid-price which is not an integer multiple of the market tick size, a buy orders pegged to the mid price should have it's price rounded up to the nearest market tick size (0037-OPEG-021). For example, given: - `tick_size=10` - `best_bid_price=100` - `best_ask_price=190` - `mid_price=145` Then: - - A pegged buy order using the mid price as the reference and `offset=10` should be inserted at `price=160`. + - A pegged buy order using the mid price as the reference and `offset=10` should be inserted at `price=150`. ## Summary Market Makers and some other market participants are interested in maintaining limit orders on the order book that are a defined distance from a reference price (i.e. best bid, mid and best offer/ask) rather than at a specific limit price. In addition to being impossible to achieve perfectly through simple Amend commands, this method also creates many additional transactions. These problems are enough of an issue for centralised exchanges that many implement pegged orders, which are automatically repriced when the reference price moves. For decentralised trading with greater constraints on throughput and potentially orders of magnitude higher latency, pegged orders are all but essential to maintain a healthy and liquid order book. -Pegged orders are limit orders where the price is specified of the form `REFERENCE / OFFSET`, therefore 'pegged' is a _price type_, and can be used for any limit order that is valid during continuous trading. A pegged order's price is calculated from the value of the reference price on entry to the order book. Note, to ensure orders are inserted at valid price levels allowed by the market's tick size, buy orders are rounded down to the nearest valid price and sell orders are rounded up to the nearest valid price (a valid price is one which is an exact multiple of the tick size). This ensures pegged buy and sell orders will not cross, even if the market tick size is increased through governance. Pegged orders that are persistent will be repriced, losing time priority, _after processing any event_ which causes the `REFERENCE` price to change. Pegged orders are not permitted in some trading period types, most notably auctions, and pegged orders that are on the book at the start of such a period will be parked (moved to a separate off-book area) in time priority until they are cancelled or expire, or the market enters a period that allows pegs, in which case they are re-priced and added back to the order book. Pegged orders entered during a period that does not accept them will be added to the parked area. Pegged orders submitted to a market with a main trading mode that does not support pegged orders will be rejected. All pegged orders in the system are held in a sorted by entry time list so that actions like re-pricing and parking/un-parking are performed in the same order as which the orders were entered into the system. +Pegged orders are limit orders where the price is specified of the form `REFERENCE / OFFSET`, therefore 'pegged' is a _price type_, and can be used for any limit order that is valid during continuous trading. A pegged order's price is calculated from the value of the reference price on entry to the order book. Note, to ensure orders are inserted at valid price levels allowed by the market's tick size, buy orders are rounded up to the nearest valid price and sell orders are rounded down to the nearest valid price (a valid price is one which is an exact multiple of the tick size). This ensures a pegged buy and sell order both with the smallest allowed offset from the mid form the smallest possible spread (one tick). Pegged orders that are persistent will be repriced, losing time priority, _after processing any event_ which causes the `REFERENCE` price to change. Pegged orders are not permitted in some trading period types, most notably auctions, and pegged orders that are on the book at the start of such a period will be parked (moved to a separate off-book area) in time priority until they are cancelled or expire, or the market enters a period that allows pegs, in which case they are re-priced and added back to the order book. Pegged orders entered during a period that does not accept them will be added to the parked area. Pegged orders submitted to a market with a main trading mode that does not support pegged orders will be rejected. All pegged orders in the system are held in a sorted by entry time list so that actions like re-pricing and parking/un-parking are performed in the same order as which the orders were entered into the system. ## Guide-level explanation From 62f8b65461d60db3eeaab0f1f9d5aca01ad5610c Mon Sep 17 00:00:00 2001 From: Charlie Date: Wed, 28 Feb 2024 17:40:29 +0000 Subject: [PATCH 1000/1171] feat: cancel pegged orders --- protocol/0028-GOVE-governance.md | 2 +- protocol/features.json | 1 + 2 files changed, 2 insertions(+), 1 deletion(-) diff --git a/protocol/0028-GOVE-governance.md b/protocol/0028-GOVE-governance.md index ed7b36a81..a91149c21 100644 --- a/protocol/0028-GOVE-governance.md +++ b/protocol/0028-GOVE-governance.md @@ -599,7 +599,7 @@ APIs should also exist for clients to: - 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) - A market change proposal specifying a new tick size less than or equal to `0` gets rejected. -- A market change proposal specifying a new tick size which is not an exact multiple of `10^-mdp` gets rejected (where `mdp` is the market decimal places). +- At enactment, a market change proposal updating the tick size cancels all pegged orders where their offset is no longer an exact integer multiple of the tick size (0028-GOVE-183). #### Network parameter change proposals diff --git a/protocol/features.json b/protocol/features.json index cb6290b99..65c0e8405 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -326,6 +326,7 @@ "0025-OCRE-006", "0028-GOVE-180", "0028-GOVE-182", + "0028-GOVE-183", "0037-OPEG-020", "0037-OPEG-021" ] From 83030c053c07d984686c790969aad985389cc1e5 Mon Sep 17 00:00:00 2001 From: Charlie Date: Wed, 28 Feb 2024 17:41:34 +0000 Subject: [PATCH 1001/1171] chore: assign missing ac code --- protocol/0028-GOVE-governance.md | 2 +- protocol/features.json | 1 + 2 files changed, 2 insertions(+), 1 deletion(-) diff --git a/protocol/0028-GOVE-governance.md b/protocol/0028-GOVE-governance.md index a91149c21..042155cdd 100644 --- a/protocol/0028-GOVE-governance.md +++ b/protocol/0028-GOVE-governance.md @@ -598,7 +598,7 @@ APIs should also exist for clients to: - 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) -- A market change proposal specifying a new tick size less than or equal to `0` gets rejected. +- A market change proposal specifying a new tick size less than or equal to `0` gets rejected (0028-GOVE-184). - At enactment, a market change proposal updating the tick size cancels all pegged orders where their offset is no longer an exact integer multiple of the tick size (0028-GOVE-183). #### Network parameter change proposals diff --git a/protocol/features.json b/protocol/features.json index 65c0e8405..57540aed2 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -327,6 +327,7 @@ "0028-GOVE-180", "0028-GOVE-182", "0028-GOVE-183", + "0028-GOVE-184", "0037-OPEG-020", "0037-OPEG-021" ] From 04b110a270dd00e77b52dfff3d676859a928ea8a Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Thu, 29 Feb 2024 15:58:32 +0000 Subject: [PATCH 1002/1171] feat: update formatting in formula --- 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 bd2a46b86..4220a15c6 100644 --- a/protocol/0057-TRAN-transfers.md +++ b/protocol/0057-TRAN-transfers.md @@ -71,7 +71,7 @@ A recurring transfers needs to contain this specific information: The amount paid at the end of each epoch is calculated using the following formula: ```math -amount = start amount x factor ^ (current epoch - start epoch) +amount = \text{start amount} x \text{factor}^{(\text{current epoch} - \text{start epoch})} ``` If insufficient funds are present in the source account at the time a transfer is initiated by the network, the whole recurring transfer is cancelled. From a98c8920f0d294310d7fa362ac8795cd1fa13f1c Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Thu, 29 Feb 2024 16:17:30 +0000 Subject: [PATCH 1003/1171] chore: update formating --- 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 4220a15c6..60d5315be 100644 --- a/protocol/0057-TRAN-transfers.md +++ b/protocol/0057-TRAN-transfers.md @@ -71,7 +71,7 @@ A recurring transfers needs to contain this specific information: The amount paid at the end of each epoch is calculated using the following formula: ```math -amount = \text{start amount} x \text{factor}^{(\text{current epoch} - \text{start epoch})} +\text{amount} = \text{start amount} x \text{factor}^{(\text{current epoch} - \text{start epoch})} ``` If insufficient funds are present in the source account at the time a transfer is initiated by the network, the whole recurring transfer is cancelled. From 6475cd4fcf42abb1b36d4cf2e25ab777cbc95796 Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Thu, 29 Feb 2024 16:26:59 +0000 Subject: [PATCH 1004/1171] feat: update parameter of each transfer --- protocol/0057-TRAN-transfers.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/protocol/0057-TRAN-transfers.md b/protocol/0057-TRAN-transfers.md index 60d5315be..1dc1b4a5b 100644 --- a/protocol/0057-TRAN-transfers.md +++ b/protocol/0057-TRAN-transfers.md @@ -388,15 +388,15 @@ If the network parameter `spam.protection.maxUserTransfersPerEpoch` is modified, 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) -If the network parameter `cap_reward_fee_multiple` is set, and if `calculated_reward_in_quantum < cap_reward_fee_multiple × fees_paid_this_epoch_in_quantum` then the actual amount of reward transferred to each public key during distribution for this transfer will be `calculated_reward_in_quantum`(0057-TRAN-070) +If the parameter of each transfer `cap_reward_fee_multiple` is set, and if `calculated_reward_in_quantum < cap_reward_fee_multiple × fees_paid_this_epoch_in_quantum` then the actual amount of reward transferred to each public key during distribution for this transfer will be `calculated_reward_in_quantum`(0057-TRAN-070) -If the network parameter `cap_reward_fee_multiple` is set, and if `calculated_reward_in_quantum > cap_reward_fee_multiple × fees_paid_this_epoch_in_quantum` then the actual amount of reward transferred to each public key during distribution for this transfer will be `cap_reward_fee_multiple × fees_paid_this_epoch_in_quantum`(0057-TRAN-071) +If the parameter of each transfer `cap_reward_fee_multiple` is set, and if `calculated_reward_in_quantum > cap_reward_fee_multiple × fees_paid_this_epoch_in_quantum` then the actual amount of reward transferred to each public key during distribution for this transfer will be `cap_reward_fee_multiple × fees_paid_this_epoch_in_quantum`(0057-TRAN-071) -If the network parameter `cap_reward_fee_multiple` is set, and if some reward is left from the applied cap, the remaining balance should be recalculated only for parties that have not reached their cap until the leftover is less than 1 reward asset unit or the maximum rounds of recalculation is 10 +If the parameter of each transfer `cap_reward_fee_multiple` is set, and if some reward is left from the applied cap, the remaining balance should be recalculated only for parties that have not reached their cap until the leftover is less than 1 reward asset unit or the maximum rounds of recalculation is 10 (0057-TRAN-072) -If the network parameter `cap_reward_fee_multiple` is set, and if all keys are capped, then the remaining balance must be left in the reward pool and included in the distribution in the future epochs. (0057-TRAN-073) +If the parameter of each transfer `cap_reward_fee_multiple` is set, and if all keys are capped, then the remaining balance must be left in the reward pool and included in the distribution in the future epochs. (0057-TRAN-073) -If the network parameter `cap_reward_fee_multiple` is set, and the total reward transferred in a given epoch, this does not affect the size of the next iteration, which proceeds as normal (including decay factors etc.) as if the full transfer has been made (0057-TRAN-074) +If the parameter of each transfer `cap_reward_fee_multiple` is set, and the total reward transferred in a given epoch, this does not affect the size of the next iteration, which proceeds as normal (including decay factors etc.) as if the full transfer has been made (0057-TRAN-074) -If the network parameter `cap_reward_fee_multiple` is set to be `<=0`, then it should be rejected (0057-TRAN-075) +If the parameter of each transfer `cap_reward_fee_multiple` is set to be `<=0`, then it should be rejected (0057-TRAN-075) From 63b741389410a825affdd327d1ced9789484e52c Mon Sep 17 00:00:00 2001 From: David Siska <62546419+davidsiska-vega@users.noreply.github.com> Date: Fri, 1 Mar 2024 09:41:07 +0000 Subject: [PATCH 1005/1171] fix: remove for now order spam (#2196) * fix: remove for now order spam * fix: remove for now order spam --- protocol/0062-SPAM-spam_protection.md | 18 ------------------ protocol/features.json | 4 ---- 2 files changed, 22 deletions(-) diff --git a/protocol/0062-SPAM-spam_protection.md b/protocol/0062-SPAM-spam_protection.md index c559ec279..87cc36501 100644 --- a/protocol/0062-SPAM-spam_protection.md +++ b/protocol/0062-SPAM-spam_protection.md @@ -83,20 +83,6 @@ Further, each party is allowed to submit up to `n` transactions per epoch where **Note** `spam.protection.max.updatePartyProfile` must be an integer greater than or equal to `0` (and default to `5`). -### Transaction Spam - -Network parameter: `spam.order.MinimalMarginQuantumMultiple` (between 0 and infinite) - -If the maintenance margin for a given transaction is smaller than the parameter `spam.order.MinimalMarginSizeQuantumMultiple`, then the transaction is pre-block rejected. -I.e. if `(rf + linear slippage param) x size x price < spam.order.MinimalMarginSizeQuantumMultiple x asset quantum amount` then the order is rejected. Here `rf` is the risk factor (and will be different for long and for short) `linear slippage param` is a market parameter and `size` and `price` are assumed to be correctly scaled by, PDPs and MDPs respectively. - -If the market does not exist and thus the maintenance margin is not defined, the transaction is rejected. - -Non-persistent orders (on both spot and futures markets) are not blocked by this mechanism as long as the market exists. - -The calculation for this should be done before the gas cost calculation as rejected transactions should not get into the calculation of the -gas cost. - ### Related topics @@ -141,9 +127,5 @@ More than 360 delegation changes in one epoch (or, respectively, the value of `s - A party holding no less than `spam.protection.referralSet.min.funds` x quantum and staking no less than `referralProgram.minStakedVegaTokens` should not have any `UpdateReferralSettransactions` pre-block rejected (0062-SPAM-041). - A party who has submitted strictly more than `spam.protection.max.updatePartyProfile` `UpdatePartyProfile` transactions in an epoch should have any future `UpdatePartyProfile` transactions in that epoch **pre-block** rejected (0062-SPAM-038). - A party who has submitted more than `spam.protection.max.updatePartyProfile` `UpdatePartyProfile` transactions in the current epoch plus in the current block, should have their `UpdatePartyProfile` transactions submitted in the current block **pre-block** rejected (0062-SPAM-039). -- Issue a set of orders starting with the minimum price, and doubling the order price with every order. Once the first order passes the spam filter, quadruple the parameter `spam.order.MinimalMarginQuantumMultiple` and continue. Once the next order passes the filter, quadruple the quantum size for the underlying asset, and continue until an order passes the filter again. Verify that all rejected orders had a margin smaller than `spam.order.MinimalMarginQuantumMultiple`, and all accepted ones one bigger or equal. (0062-SPAM-043). -- Issue a set of orders for an existing, but not yet enacted market, starting with the minimum price, and doubling the order price with every order. Once the first order passes the spam filter, quadruple the parameter `spam.order.MinimalMarginQuantumMultiple` and continue. Once the next order passes the filter, quadruple the quantum size for the underlying asset, and continue until an order passes the filter again. Verify that all rejected orders had a margin smaller than `spam.order.MinimalMarginQuantumMultiple`, and all accepted ones one bigger or equal. (0062-SPAM-044). -- Create an order for a non-existing market, and verify that it is rejected by the spam filter. (0062-SPAM-045). -- Create a non-persistent order for an existing market with a minimum order price, and verify that it is not rejected by the spam filter. (0062-SPAM-046). > **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 cb6290b99..f5864b6e1 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -315,10 +315,6 @@ "milestone": "colosseo", "acs": ["0053-PERP-036"] }, - "Order spam": { - "milestone": "colosseo", - "acs": ["0062-SPAM-043", "0062-SPAM-044", "0062-SPAM-045", "0062-SPAM-046"] - }, "Market tick size": { "milestone": "colosseo", "acs": [ From 3096267d754336645d7dbc644fb3a406c749f8c5 Mon Sep 17 00:00:00 2001 From: David Siska <62546419+davidsiska-vega@users.noreply.github.com> Date: Fri, 1 Mar 2024 10:01:17 +0000 Subject: [PATCH 1006/1171] fix: formatting --- protocol/0057-TRAN-transfers.md | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/protocol/0057-TRAN-transfers.md b/protocol/0057-TRAN-transfers.md index 1dc1b4a5b..1d4889146 100644 --- a/protocol/0057-TRAN-transfers.md +++ b/protocol/0057-TRAN-transfers.md @@ -70,9 +70,11 @@ A recurring transfers needs to contain this specific information: The amount paid at the end of each epoch is calculated using the following formula: -```math -\text{amount} = \text{start amount} x \text{factor}^{(\text{current epoch} - \text{start epoch})} -``` +$$ +\text{amount} = \text{start amount} \cdot \text{factor}^{(\text{current epoch} - \text{start epoch})} +$$ + + If insufficient funds are present in the source account at the time a transfer is initiated by the network, the whole recurring transfer is cancelled. If the `amount` is less than `transfer.minTransferQuantumMultiple x quantum` then the recurring transfer is cancelled. From 3b847f47a7f5018565dbafe1b99d0636d26744da Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Fri, 1 Mar 2024 10:20:35 +0000 Subject: [PATCH 1007/1171] chore: markdown --- protocol/0057-TRAN-transfers.md | 2 -- 1 file changed, 2 deletions(-) diff --git a/protocol/0057-TRAN-transfers.md b/protocol/0057-TRAN-transfers.md index 1d4889146..128b71ece 100644 --- a/protocol/0057-TRAN-transfers.md +++ b/protocol/0057-TRAN-transfers.md @@ -74,8 +74,6 @@ $$ \text{amount} = \text{start amount} \cdot \text{factor}^{(\text{current epoch} - \text{start epoch})} $$ - - If insufficient funds are present in the source account at the time a transfer is initiated by the network, the whole recurring transfer is cancelled. If the `amount` is less than `transfer.minTransferQuantumMultiple x quantum` then the recurring transfer is cancelled. From 238fc7be79d7355492f4d68b7b9771f445d494ae Mon Sep 17 00:00:00 2001 From: Gordsport <83510148+gordsport@users.noreply.github.com> Date: Fri, 1 Mar 2024 14:09:27 +0000 Subject: [PATCH 1008/1171] feat: composite price methodology (#2200) * feat: composite price methodology copies change from palazzo #2197 into Colosseo * fix: markdown linting --------- Co-authored-by: David Siska <62546419+davidsiska-vega@users.noreply.github.com> --- .github/workflows/config/markdownlint.json | 3 +- protocol/0009-MRKP-mark_price.md | 3 +- ...3-PERP-product_builtin_perpetual_future.md | 2 +- protocol/0089-COMP-composing_prices.md | 128 ++++++++++++++++++ wordlist.txt | 4 + 5 files changed, 137 insertions(+), 3 deletions(-) create mode 100644 protocol/0089-COMP-composing_prices.md diff --git a/.github/workflows/config/markdownlint.json b/.github/workflows/config/markdownlint.json index 4db16e28b..bad5db322 100644 --- a/.github/workflows/config/markdownlint.json +++ b/.github/workflows/config/markdownlint.json @@ -10,5 +10,6 @@ }, "MD024": { "siblings_only": true - } + }, + "MD049": false, } diff --git a/protocol/0009-MRKP-mark_price.md b/protocol/0009-MRKP-mark_price.md index ac34a06b8..044624fbc 100644 --- a/protocol/0009-MRKP-mark_price.md +++ b/protocol/0009-MRKP-mark_price.md @@ -29,7 +29,8 @@ Now 10.1s has elapsed since the last update and there is a market buy order for ### 2. Flexible mark price methodology -The calculations are specified in [markprice methodology research note](https://github.com/vegaprotocol/research/blob/markprice-updates/papers/markprice-methodology/markprice-methodology.tex). +The calculations are specified in [composite prices spec](./0089-COMP-composing_prices.md). + Here, we only write the acceptance criteria. Note that for calculating the median with an even number of entries we sort, pick out the two values that are in the middle of the list and average those. So in particular with two values a median is the same as the average for our purposes. diff --git a/protocol/0053-PERP-product_builtin_perpetual_future.md b/protocol/0053-PERP-product_builtin_perpetual_future.md index fabd9ff07..83b11934e 100644 --- a/protocol/0053-PERP-product_builtin_perpetual_future.md +++ b/protocol/0053-PERP-product_builtin_perpetual_future.md @@ -10,7 +10,7 @@ Unlike traditional futures contracts, the perpetual futures never expire. Withou We choose to use either: - the mark price of the market to approximate $F_u$ or -- configure the "market price for funding purposes" as part of the market proposal and use this methodology 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. +- configure the "market price for funding purposes" as part of the market proposal using [composite prices method](./0089-COMP-composing_prices.md) and use this methodology 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 diff --git a/protocol/0089-COMP-composing_prices.md b/protocol/0089-COMP-composing_prices.md new file mode 100644 index 000000000..49900369d --- /dev/null +++ b/protocol/0089-COMP-composing_prices.md @@ -0,0 +1,128 @@ +# Composite prices + +## Introduction + +Prices are composed to create mark price and on perpetual futures markets a view of what the price on the vega side is for purposes of comparing to the underlying price and an eventual funding calculation. +Mark price is used by Vega protocol to calculate mark-to-market cashflows, feed the risk calculation, to provide ``unrealised'' profit-and-loss (PnL) information and drive price monitoring. + +For perpetual futures markets there should be a composite *mark price* configuration and a composite *market price for funding* configuration so that the market can, potentially use different mark price for mark-to-market and price monitoring and completely different price for calculating funding. + +Every market will have a mark price upon leaving opening auction. +This means that either (a) the proposed mark price methodology has produced a value during the opening auction or (b) if it has not, upon leaving the opening auction the first mark price is set to the auction uncrossing price regardless of the mark price methodology. +Subsequent updates will follow the set methodology. + +## Proposed composite price methodology + +We update the mark at the end of every mark price period and the funding price possibly at a different frequency (also set as network parameter specifying a period). +In the sequel both will be referred to as "mark price period". + +### Price from observed trades + +Existing network or market parameters that enter into this: + +- Length of mark price period given by $\delta = $`network.markPriceUpdateMaximumFrequency`. + +New market parameters that enter into this: + +- $\alpha \in [0,1]$ decay weight. +- $p \in \mathbb N$ a decay power and in practice we'd want to support only $p \in \{1,2,3\}$. + +Calculate $\hat P^{\text{trades}}$ which is simply trade-size-weighted average of all eligible trades over the mark price period. +Let $P_s$ to be price at time $s$ and $w_s$ the weight set as the volume traded at the price at time $s$. +Let $\delta > 0$ be the mark price period length. +Let $\alpha \geq 0$ decay weight and $p\in \mathbb N$ a decay power. +With this define +$$ +K(s,t) = 1 - \alpha\frac{(t-s)^p}{\delta^p}\,. +$$ +and +$$ +W(t-\delta, t) := \int_{(t-\delta) \vee 0}^t K(s,t) w_s\, ds +$$ +so that finally +$$ +\hat P_t := \frac{1}{W(t-\delta, t)} \int_{(t-\delta) \vee 0}^t K(s,t) w_s \,P_s \,ds\,. +$$ +As a sanity check note that if $P_s = P$ for all $s\in (t-\delta, t]$ we get +$$ +\hat P_t := \frac{P}{W(t-\delta, t)} \int_{(t-\delta) \vee 0}^t K(s,t) w_s \,ds = P\,. +$$ + +### Price observed from the order book + +Existing network or market parameters or calculation outputs that enter into this: + +- $f_\text{initial scaling}$ is the `initial\_margin` in `market.margin.scalingFactors`. +- $f_\text{slippage}$ is the linear slippage factor in market proposal. +- $f_\text{risk}$ refers to either the long or short risk factors output by the risk model. + +New market parameters that enter into this: + +- Let $C$ be some cash amount e.g. $500$ USDT would be entered as $500 00000$ respecting the $5$ asset decimals. + +Let $C$ be some cash amount e.g. $500$ USDT. +Calculate how much this can be leveraged to $N = C\frac{1}{f_{\text{risk}} + f_{\text{slippage}}} \frac{1}{f_{\text{initial scaling}}}$ i.e. you multiply $C$ by the maximum possible leverage. +For sell side calculate $V_{\text{sell}} = \frac{N}{P_{\text{best ask}}}$ where you set $f_{\text{risk}}$ to be the one for long. +For buy side calculate $V_{\text{buy}} = \frac{N}{P_{\text{best bid}}}$ where you set $f_{\text{risk}}$ to be the one for short. +Calculate $\hat P^{\text{book}}$ which is the time average ``mid'' price seen on the book: if there is at least volume $V_{\text{sell}}$ on the sell side and at least $V_{\text{buy}}$ on the buy side: +$$ +P^{\text{book}}_s := +\frac12 \left(\text{sell vwap for volume $V_{\text{sell}}$}+\text{buy vwap for volume $V_{\text{buy}}$}\right)\,, +$$ +if not, don't include it in the time average. +If $C$ (the initial cash amount to consider) is set to $0$ then it's the usual mid price. +During auctions $P^{\text{book}}_s$ is set to the indicative uncrossing price. + +### Prices observed from data sourcing framework (oracles) + +New market parameters that enter into this: + +- Entire oracle definition for each of the data sources, in particular source and update freq / schedule. + +Obtain $(P^{\text{oracle}}_i)_{i=1}^n$ if $n \in \{0\}\cup \mathbb N$ oracle sources are defined. + +### Median of observations + +Set $L^{i}=L^{i}(s)$, $i=1,\ldots,n+2$ to be the functions which reports when a given price source from the list above was last updated and $(\delta_i)_{i=1}^d$ values defining when a given price is too old. +If for all $t-L_i(t) > \delta_i$ then all sources are stale and we do not update this source. +If at least for one $i$ we have $t-L_i(t) < \delta_i$ we do +$$ +M((P_i)_{i=1}^{2+n}) = \text{median}(\{P_i : t-L_i(t) < \delta_i\}) \,. +$$ +The median is calculated as follows: sort the prices in ascending or descending order. If $n$ is an odd number then choose the value that's in the middle of the sorted list. +If you have even number add the two in the middle up and divide by $2$. +The median price source value should update whenever any of its input price sources have been updated or whenever time has passed and a previously current source has gone stale. +The median price source will have update time set to the latest time any of the input sources were updated (it will not be set to the time when it was last recalculated just because an input has gone stale). + +### Composing with weighted average + +New market parameters that enter into this: + +- $(w_i)_{i=1}^{3+n}$ weights. +- $(\delta_i)_{i=1}^d$ specifying how old a source update can be before source is considered stale. If set to $0$ we'd want an update with the same vega time. + +We allow weights: take $(w_i)_{i=1}^{3+n}$. This allows in particular picking individual sources. +We also set $L^{i}=L^{i}(s)$, $i=1,\ldots,n+3$ be the functions which reports when a given price was last updated and $(\delta_i)_{i=1}^d$ values defining when a given price is too old. +From this we update the weights as follows: +$$ +\hat w^i := \frac{w_i \mathbf{1}_{t-L^i(t)<\delta^i}}{\sum_j w_j\mathbf{1}_{t-L^j(t)<\delta^j}}\,. +$$ +I.e. we pick those that have been updated recently enough and we re-weight. +$$ +M((P_i)_{i=1}^{3+n}) = \sum_{i=1}^{n+3} \hat w^i P_i \,. +$$ + +### Composing with median + +New market parameters that enter into this: + +- $(\delta_i)_{i=1}^d$ specifying how old a source update can be before source is considered stale. If set to $0$ we'd want an update with the same vega time. + +Set $L^{i}=L^{i}(s)$, $i=1,\ldots,n+3$ to be the functions which reports when a given price was last updated and $(\delta_i)_{i=1}^d$ values defining when a given price is too old. +If for all $t-L_i(t) > \delta_i$ then all sources are stale and we do not update the mark price. +If at least for one $i$ we have $t-L_i(t) < \delta_i$ we do +$$ +M((P_i)_{i=1}^{3+n}) = \text{median}(\{P_i : t-L_i(t) < \delta_i\}) \,. +$$ + +I.e. we do a median of the non-stale prices. diff --git a/wordlist.txt b/wordlist.txt index 1cbcea401..e6c46db2b 100644 --- a/wordlist.txt +++ b/wordlist.txt @@ -331,3 +331,7 @@ wei whitepaper Yubikey joinable +mathbb +geq +vee +mathbf From d620656328a423b6e110537ec8015ea2696e6f74 Mon Sep 17 00:00:00 2001 From: Sohill-Patel <85170301+Sohill-Patel@users.noreply.github.com> Date: Fri, 1 Mar 2024 15:34:44 +0000 Subject: [PATCH 1009/1171] chore: clearer ac --- 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 128b71ece..e45bdc8f0 100644 --- a/protocol/0057-TRAN-transfers.md +++ b/protocol/0057-TRAN-transfers.md @@ -397,6 +397,6 @@ If the parameter of each transfer `cap_reward_fee_multiple` is set, and if some If the parameter of each transfer `cap_reward_fee_multiple` is set, and if all keys are capped, then the remaining balance must be left in the reward pool and included in the distribution in the future epochs. (0057-TRAN-073) -If the parameter of each transfer `cap_reward_fee_multiple` is set, and the total reward transferred in a given epoch, this does not affect the size of the next iteration, which proceeds as normal (including decay factors etc.) as if the full transfer has been made (0057-TRAN-074) +If the parameter of each transfer `cap_reward_fee_multiple` is set, and the total reward transferred in a given epoch is not spent due to the cap, this does not affect the size of the next iteration, which proceeds as normal (including decay factors etc.) as if the full transfer has been made (0057-TRAN-074) If the parameter of each transfer `cap_reward_fee_multiple` is set to be `<=0`, then it should be rejected (0057-TRAN-075) From 86ae064dab93cb2838dce81090b68f9f99ad7dba Mon Sep 17 00:00:00 2001 From: Charlie Date: Fri, 1 Mar 2024 15:39:16 +0000 Subject: [PATCH 1010/1171] chore: fix ac typo --- protocol/0037-OPEG-pegged_orders.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/protocol/0037-OPEG-pegged_orders.md b/protocol/0037-OPEG-pegged_orders.md index 07d6f1729..a52cb01a1 100644 --- a/protocol/0037-OPEG-pegged_orders.md +++ b/protocol/0037-OPEG-pegged_orders.md @@ -28,14 +28,14 @@ - `mid_price=145` Then: - A pegged buy order using the mid price as the reference and `offset=10` should be inserted at `price=140`. -- Given a mid-price which is not an integer multiple of the market tick size, a buy orders pegged to the mid price should have it's price rounded up to the nearest market tick size (0037-OPEG-021). +- Given a mid-price which is not an integer multiple of the market tick size, a sell order pegged to the mid price should have it's price rounded down to the nearest market tick size (0037-OPEG-021). For example, given: - `tick_size=10` - `best_bid_price=100` - `best_ask_price=190` - `mid_price=145` Then: - - A pegged buy order using the mid price as the reference and `offset=10` should be inserted at `price=150`. + - A pegged sell order using the mid price as the reference and `offset=10` should be inserted at `price=150`. ## Summary From ea1905c1a8faafd8c5c577f89068de3341f0c87d Mon Sep 17 00:00:00 2001 From: David Siska <62546419+davidsiska-vega@users.noreply.github.com> Date: Mon, 4 Mar 2024 11:07:11 +0000 Subject: [PATCH 1011/1171] Fix/dont update book price in auction (#2201) * fix: don't include book price during auctions * fix: don't include book price during auctions * fix: don't include book price during auctions * fix: don't include book price during auctions --- protocol/0009-MRKP-mark_price.md | 2 +- protocol/0089-COMP-composing_prices.md | 3 ++- protocol/features.json | 4 +++- 3 files changed, 6 insertions(+), 3 deletions(-) diff --git a/protocol/0009-MRKP-mark_price.md b/protocol/0009-MRKP-mark_price.md index 044624fbc..d54b94c68 100644 --- a/protocol/0009-MRKP-mark_price.md +++ b/protocol/0009-MRKP-mark_price.md @@ -90,7 +90,7 @@ Note that for calculating the median with an even number of entries we sort, pic - When market is leaving auction (including opening auction and monitoring auction), mark price should be recalculated (0009-MRKP-024) and a perps market (with the oracle source different to that used for the external price in the perps market) (0009-MRKP-025). -- When market is at monitoring auction, book price should be indicative uncrossing price, mark price should only be recalculated when the auction exits, starting from only the last period indicated by `network.markPriceUpdateMaximumFrequency` (0009-MRKP-026) and a perps market (with the oracle source different to that used for the external price in the perps market) (0009-MRKP-027). +- When a futures market is in a monitoring auction, book price is undefined with staleness increasing with time, the book price at auction uncrossing should be set to the price of the uncrossing trade, the mark price should only be recalculated when the auction exits, starting from only the last period indicated by `network.markPriceUpdateMaximumFrequency` (0009-MRKP-036) and same for a perpetual futures market (0009-MRKP-037). - It is possible to configure a cash settled futures market to use a weighted average of 1. weighted average of trades over `network.markPriceUpdateMaximumFrequency` and 2. impact of leveraged notional on the order book with the value of USDT `100` and when the book does not have enough volume, then the book price should not be included (0009-MRKP-028) and a perps market (with the oracle source different to that used for the external price in the perps market) (0009-MRKP-029). diff --git a/protocol/0089-COMP-composing_prices.md b/protocol/0089-COMP-composing_prices.md index 49900369d..27a0f2182 100644 --- a/protocol/0089-COMP-composing_prices.md +++ b/protocol/0089-COMP-composing_prices.md @@ -71,7 +71,8 @@ P^{\text{book}}_s := $$ if not, don't include it in the time average. If $C$ (the initial cash amount to consider) is set to $0$ then it's the usual mid price. -During auctions $P^{\text{book}}_s$ is set to the indicative uncrossing price. +During auctions $P^{\text{book}}_s$ is set as undefined (and as not updating for purpose of staleness). +At auction uncrossing the book price $P^{\text{book}}_s$ is set to the uncrossing price. ### Prices observed from data sourcing framework (oracles) diff --git a/protocol/features.json b/protocol/features.json index 470c92da5..58af01581 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -5,7 +5,9 @@ "0009-MRKP-132", "0053-PERP-043", "0032-PRIM-039", - "0032-PRIM-040" + "0032-PRIM-040", + "0009-MRKP-036", + "0009-MRKP-037" ] }, "Spot": { From f1b3b90022525f3f52ecac128f3fdc8037aa59b0 Mon Sep 17 00:00:00 2001 From: Witold Date: Wed, 6 Mar 2024 12:25:28 +0100 Subject: [PATCH 1012/1171] WIP: Collat decrease ACs (#2178) * refactor: split cross and isolated margin cases * refacgtor: further clarification --------- Co-authored-by: Gordsport <83510148+gordsport@users.noreply.github.com> --- non-protocol-specs/0013-NP-POSE-position-estimate.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/non-protocol-specs/0013-NP-POSE-position-estimate.md b/non-protocol-specs/0013-NP-POSE-position-estimate.md index b2c83f0b7..22bb45fe1 100644 --- a/non-protocol-specs/0013-NP-POSE-position-estimate.md +++ b/non-protocol-specs/0013-NP-POSE-position-estimate.md @@ -50,7 +50,8 @@ The endpoint request contains additional optional argument `scale_liquidation_pr 1. In isolated margin mode the request with `0` open volume and one or more limit orders specified results in a non-zero order margin in the margin level estimate and margin mode correctly representing isolated margin mode. (0013-NP-POSE-001) 1. When account balances are set to `0` and market has slippage factors set to `0`, the collateral increase figure per specified theoretical position correctly approximates (absolute relative difference of less than $10^{-6}$) the actual margin and order margin account balances for a party which opens such a position. (0013-NP-POSE-002) -1. For a market with slippage cap factor set to `0`, when the response for a given request contains figure `x` as the collateral increase (best and worst case should be the same) then resubmitting the request with margin account balance increased by `x` should result in `0` collateral increase estimate. When increasing the margin account balance in the request further the collateral increase should get negative by the amount of the increase when in isolated margin mode. In cross margin mode it should remain at `0` until the combined margin and order balances are above the margin release level for the theoretical position. Then the collateral increase amount should be negative and equal to: `initial margin level for the specified position - margin account balance - order account balance`. (0013-NP-POSE-009) +1. In cross margin-mode, for a market with slippage cap factor set to `0`, the request to `EstimatePosition` endpoint is made with margin account balance set to less than the initial margin for the specified position, when the response for a given request contains figure `x` as the collateral increase (best and worst case should be the same) then resubmitting the request with margin account balance increased by `x` should result in `0` collateral increase estimate. When increasing the margin account balance in the request further it should remain at `0` until the combined margin and order balances are above the margin release level for the theoretical position. Then the collateral increase amount should be negative and equal to: `initial margin level for the specified position - margin account balance - order account balance`. (0013-NP-POSE-009) +1. In isolated margin mode: open a position so that open volume is non-zero and there are some open orders. Query the `EstimatePosition` with the details of that position. The collateral increase estimate should be 0. No query the `EstimatePosition` with a higher margin factor. The collateral increase estimate should be positive and equal to the decrease in the general account balance after margin factor is updated for the party. Now lower the margin factor below the value the test originally started with and repeat. The collateral increase estimate should be negative and equal to the decrease in the general account balance (the balance should increase). (0013-NP-POSE-010) 1. In isolated margin mode increasing general account balance specified in the request has no impact on the collateral increase estimate and the liquidation price estimate. (0013-NP-POSE-004) 1. In isolated margin mode the liquidation price estimate for a position with non-zero additional margin requirement with `include_collateral_increase_in_available_collateral` argument set to `true` results in liquidation price which is closer to the current mark price than the result obtained with argument set to `false`. (0013-NP-POSE-005) 1. When market is set with different number of decimal places then its settlement asset then setting `scale_liquidation_price_to_market_decimals` to `false` results in liquidation price estimates scaled to asset decimal places, when set to `true` these estimates get scaled to market decimal places. (0013-NP-POSE-006) From 0c8f5373834dfa629a18675b7b42d660a78d3011 Mon Sep 17 00:00:00 2001 From: Pete Barrow <62435083+peterbarrow@users.noreply.github.com> Date: Wed, 6 Mar 2024 11:27:13 +0000 Subject: [PATCH 1013/1171] fix: Wording for iceberg testing (#2194) --- 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 a35243316..82ce90845 100644 --- a/protocol/0014-ORDT-order_types.md +++ b/protocol/0014-ORDT-order_types.md @@ -289,7 +289,7 @@ In Spot market, for an iceberg order that is submitted with total size x and dis 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 sitting on the book, when a batch containing normal orders and other iceberg orders that will trades against the existing iceberg sitting on the book is sent, the resting iceberg order refreshes between each order in the batch (0014-ORDT-015). For product spot: (0014-ORDT-095) #### Iceberg Order Submission - Negative tests From 10064b2dbd9a6b781c5e1ba22af724fef49bb631 Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Thu, 7 Mar 2024 11:57:26 +0000 Subject: [PATCH 1014/1171] feat: add validation on risk factor during isolated margin --- protocol/0019-MCAL-margin_calculator.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/protocol/0019-MCAL-margin_calculator.md b/protocol/0019-MCAL-margin_calculator.md index 23d3df561..fb0a480cd 100644 --- a/protocol/0019-MCAL-margin_calculator.md +++ b/protocol/0019-MCAL-margin_calculator.md @@ -311,6 +311,8 @@ There should be an additional amount `limit price x size x margin factor = 15910 - switch to cross margin with position and with orders successful in auction(0019-MCAL-141) +- when switch to isolated margin mode, valid value of the margin factor must be greater than 0, and also greater than `max(risk factor long, risk factor short)`(0019-MCAL-208) + **Check order margin:** - when party has no position, and place 2 short orders during auction, order margin should be updated(0019-MCAL-200) @@ -465,7 +467,7 @@ In future there can be multiple margin calculator implementations that would be ## Isolated margin mode When in isolated margin mode, the position on the market has an associated margin factor. -The margin factor must be greater than 0 and less than or equal to 1, and also greater than `max(risk factor long, risk factor short)`. +The margin factor must be greater than 0, and also greater than `max(risk factor long, risk factor short)`. Isolated margin mode can be enabled by placing an *update margin mode* transaction. The protocol will attempt to set the funds within the margin account equal to `average entry price * current position * new margin factor`. From 62730958693ac54d25cd599abb3edc4e92f59227 Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Thu, 7 Mar 2024 13:24:49 +0000 Subject: [PATCH 1015/1171] feat: add linear slippage factor --- protocol/0019-MCAL-margin_calculator.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/protocol/0019-MCAL-margin_calculator.md b/protocol/0019-MCAL-margin_calculator.md index fb0a480cd..259056833 100644 --- a/protocol/0019-MCAL-margin_calculator.md +++ b/protocol/0019-MCAL-margin_calculator.md @@ -311,7 +311,7 @@ There should be an additional amount `limit price x size x margin factor = 15910 - switch to cross margin with position and with orders successful in auction(0019-MCAL-141) -- when switch to isolated margin mode, valid value of the margin factor must be greater than 0, and also greater than `max(risk factor long, risk factor short)`(0019-MCAL-208) +- when switch to isolated margin mode, valid value of the margin factor must be greater than 0, and also greater than `max(risk factor long, risk factor short) + linear slippage factor`(0019-MCAL-208) **Check order margin:** @@ -467,7 +467,7 @@ In future there can be multiple margin calculator implementations that would be ## Isolated margin mode When in isolated margin mode, the position on the market has an associated margin factor. -The margin factor must be greater than 0, and also greater than `max(risk factor long, risk factor short)`. +The margin factor must be greater than 0, and also greater than `max(risk factor long, risk factor short) + linear slippage factor`. Isolated margin mode can be enabled by placing an *update margin mode* transaction. The protocol will attempt to set the funds within the margin account equal to `average entry price * current position * new margin factor`. From 1a8a4c465a135c6183be6fecff6afa0a4fc6132e Mon Sep 17 00:00:00 2001 From: Gordsport <83510148+gordsport@users.noreply.github.com> Date: Fri, 8 Mar 2024 11:13:14 +0000 Subject: [PATCH 1016/1171] feat: add AC code for isolated margin validation change (#2207) Adds AC code for isolated margin validation change --- protocol/features.json | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/protocol/features.json b/protocol/features.json index 58af01581..518ae2e81 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -341,6 +341,10 @@ "0057-TRAN-075" ] }, + "Isolated margin": { + "milestone": "colosseo", + "acs": ["0019-MCAL-208"] + }, "Closeout trades and auctions": { "milestone": "colosseo", "acs": ["0012-POSR-030"] From b839f9d55d21388748b2174088083f960bffb03d Mon Sep 17 00:00:00 2001 From: Sohill-Patel <85170301+Sohill-Patel@users.noreply.github.com> Date: Tue, 12 Mar 2024 15:39:19 +0000 Subject: [PATCH 1017/1171] chore: remove ac error never raised --- protocol/0024-OSTA-order_status.md | 1 - 1 file changed, 1 deletion(-) diff --git a/protocol/0024-OSTA-order_status.md b/protocol/0024-OSTA-order_status.md index f2c31d0c4..7011257be 100644 --- a/protocol/0024-OSTA-order_status.md +++ b/protocol/0024-OSTA-order_status.md @@ -117,7 +117,6 @@ Note: The last row in the table above is added for clarity. If the order was fil - 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) From d9424598d404552262b365e338c9001e12926bd0 Mon Sep 17 00:00:00 2001 From: Sohill-Patel <85170301+Sohill-Patel@users.noreply.github.com> Date: Tue, 12 Mar 2024 15:39:58 +0000 Subject: [PATCH 1018/1171] chore: remove ac from features --- protocol/features.json | 1 - 1 file changed, 1 deletion(-) diff --git a/protocol/features.json b/protocol/features.json index 518ae2e81..bd82ea3e8 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -153,7 +153,6 @@ "0024-OSTA-042", "0024-OSTA-043", "0024-OSTA-044", - "0024-OSTA-045", "0024-OSTA-046", "0024-OSTA-047", "0024-OSTA-048", From 8b694b7fa8529dd1f6a3112e6641b1c8aead8978 Mon Sep 17 00:00:00 2001 From: Gordsport <83510148+gordsport@users.noreply.github.com> Date: Wed, 13 Mar 2024 12:15:25 +0000 Subject: [PATCH 1019/1171] feat: removal of checkpoint (#2146) * feat: add ac for price via data node * feat: removal of checkpoint It has been decided that the checkpoint (LNL) feature will be removed from the core as this is no longer a viable option for restarting the network. In its place will be snapshots and any required tooling. When reviewing this PR please take a look at the following issues (specifically the QA issue): - https://github.com/vegaprotocol/system-tests/issues/3346 - https://github.com/vegaprotocol/vega/issues/10506 * fix: missing net para name --------- Co-authored-by: Jiajia-Cui Co-authored-by: David Siska <62546419+davidsiska-vega@users.noreply.github.com> --- protocol/0028-GOVE-governance.md | 9 +- protocol/0036-BRIE-event_queue.md | 2 +- protocol/0040-ASSF-asset_framework.md | 2 +- protocol/0044-LIME-lp_mechanics.md | 5 - ...3-PERP-product_builtin_perpetual_future.md | 3 +- protocol/0054-NETP-network_parameters.md | 2 +- protocol/0056-REWA-rewards_overview.md | 4 - .../0063-VALK-validator_vega_master_keys.md | 2 +- protocol/0067-KEYS-key_management.md | 5 +- .../0069-VCBS-validators_chosen_by_stake.md | 52 +- protocol/0073-LIMN-limited_network_life.md | 469 ------------------ protocol/0075-PLUP-protocol_upgrades.md | 15 +- protocol/0077-SNAP-snapshots.md | 6 +- protocol/0081-SUCM-successor_markets.md | 11 +- protocol/0082-ETHD-ethereum-data-source.md | 4 - protocol/categories.json | 4 +- 16 files changed, 20 insertions(+), 575 deletions(-) delete mode 100644 protocol/0073-LIMN-limited_network_life.md diff --git a/protocol/0028-GOVE-governance.md b/protocol/0028-GOVE-governance.md index 042155cdd..58d43519c 100644 --- a/protocol/0028-GOVE-governance.md +++ b/protocol/0028-GOVE-governance.md @@ -383,9 +383,7 @@ transfer_amount == min( 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 initiated transfers, or recurring governance initiated transfers) must be included in LNL banking checkpoint and resume after the checkpoint restore. +### Snapshots All in memory active governance initiated transfers must be included in the snapshot of the banking engine. @@ -691,9 +689,8 @@ Below `*` stands for any of `asset, market, updateMarket, updateNetParam, freeFo - 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 +##### 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) @@ -708,8 +705,6 @@ It is NOT possible to submit a governance proposal where the source account is t - 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 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) - It is possible to submit a recurring governance transfer proposal from network treasury into any reward account (including staking rewards). (0028-GOVE-142) diff --git a/protocol/0036-BRIE-event_queue.md b/protocol/0036-BRIE-event_queue.md index ca9c25670..152d414cb 100644 --- a/protocol/0036-BRIE-event_queue.md +++ b/protocol/0036-BRIE-event_queue.md @@ -29,7 +29,7 @@ Once all validators have confirmed the event happened on the external chain, the 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. +Later on in the life of the network, this information is stored in the snapshot state with last sourced block on Ethereum to avoid interpreting events twice. Finally, the amount of confirmations expected for Ethereum is specified, this is set to 50 confirmation in mainnet. diff --git a/protocol/0040-ASSF-asset_framework.md b/protocol/0040-ASSF-asset_framework.md index 0beb4bbaa..8336d6da6 100644 --- a/protocol/0040-ASSF-asset_framework.md +++ b/protocol/0040-ASSF-asset_framework.md @@ -71,7 +71,7 @@ See: - [assets proto](https://github.com/vegaprotocol/vega/blob/develop/protos/sources/vega/assets.proto) - [governance proto](https://github.com/vegaprotocol/vega/blob/develop/protos/sources/vega/governance.proto) -The `maximumLifetimeDeposit` and `withdrawalDelayThreshold` govern how [limits](../non-protocol-specs/0003-NP-LIMI-limits_aka_training_wheels.md) behave. +The `maximumLifetimeDeposit` and `withdrawalDelayThreshold` govern how [limits](../protocol/0031-ETHB-ethereum_bridge_spec.md) behave. All the asset definition fields are immutable (cannot be changed even by governance) except: diff --git a/protocol/0044-LIME-lp_mechanics.md b/protocol/0044-LIME-lp_mechanics.md index 82ccea0dd..a01257039 100644 --- a/protocol/0044-LIME-lp_mechanics.md +++ b/protocol/0044-LIME-lp_mechanics.md @@ -401,10 +401,6 @@ In the case of spot markets it will be transferred into the network treasury for - After a protocol upgrade each market's aggregate LP fee accounts and their balances are retained (0044-LIME-033) -### Checkpoint - -- 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 - 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) @@ -427,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/0053-PERP-product_builtin_perpetual_future.md b/protocol/0053-PERP-product_builtin_perpetual_future.md index 83b11934e..063494a64 100644 --- a/protocol/0053-PERP-product_builtin_perpetual_future.md +++ b/protocol/0053-PERP-product_builtin_perpetual_future.md @@ -273,7 +273,6 @@ In both cases the estimates are for a hypothetical position of size 1. 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) 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) @@ -281,7 +280,7 @@ In both cases the estimates are for a hypothetical position of size 1. 1. Assume the market has been in a long auction so that a funding period has started and ended while the market never went back into continuous trading. In that case the funding payment should be equal to 0 and no transfers should be exchanged. (0053-PERP-026) -1. It is possible to obtain a time series for the price used for “vega side price” of the funding twap from the data node from the time of the market proposal enactment onwards (subject to data node retention policies) (0053-PERP-043) +1. It is possible to obtain a time series for the price used for “vega side price” of the funding twap from the data node from the time of the market proposal enactment onwards (subject to data node retention policies). (0053-PERP-043) 1. Assume a 10 minute funding period. Assume a few funding periods have already passed for this market. diff --git a/protocol/0054-NETP-network_parameters.md b/protocol/0054-NETP-network_parameters.md index baecaf000..9b1a377a7 100644 --- a/protocol/0054-NETP-network_parameters.md +++ b/protocol/0054-NETP-network_parameters.md @@ -91,7 +91,7 @@ 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) +- All network parameter set in `genesis.json` can be queried and the values returned are the correct ones. (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) diff --git a/protocol/0056-REWA-rewards_overview.md b/protocol/0056-REWA-rewards_overview.md index 34b74508b..13ffd9db5 100644 --- a/protocol/0056-REWA-rewards_overview.md +++ b/protocol/0056-REWA-rewards_overview.md @@ -54,7 +54,6 @@ 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 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. ### Average position metric @@ -158,8 +157,6 @@ See the [transfers](./0057-TRAN-transfers.md) spec. - A flag is stored on each market for each combination of [`funder`, `market scope`, `reward asset`] that was included in the reward payout. This flag is used to prevent any given funder from funding a creation reward in the same reward asset more than once for any given *market scope*. -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 @@ -179,7 +176,6 @@ That is, a participant might receive rewards in the settlement asset of the mark 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. ## Reward distribution diff --git a/protocol/0063-VALK-validator_vega_master_keys.md b/protocol/0063-VALK-validator_vega_master_keys.md index 2082626d7..7eb979cbe 100644 --- a/protocol/0063-VALK-validator_vega_master_keys.md +++ b/protocol/0063-VALK-validator_vega_master_keys.md @@ -21,7 +21,7 @@ where `key_number` is the sequence number of the derived key to prevent replay a 1. The node operator sends a transaction to the network saying they’re changing their hot key. 1. From `target_block` onwards the other validators no longer recognise the *old* hot key as valid. -1. The node operator restarts the node and catches up by replaying the chain or using a full checkpoint (when checkpoints become available). Or the whole network is restarted but due to the transaction other validators have the new hot key. +1. The node operator restarts the node and catches up by replaying the chain or using a [snapshot](./0077-SNAP-snapshots.md) file. Or the whole network is restarted but due to the transaction other validators have the new hot key. 1. The hot key switch is complete. ## Ethereum side for staking bridge purposes diff --git a/protocol/0067-KEYS-key_management.md b/protocol/0067-KEYS-key_management.md index 25c520c06..0dca1b1ac 100644 --- a/protocol/0067-KEYS-key_management.md +++ b/protocol/0067-KEYS-key_management.md @@ -82,8 +82,7 @@ The hot key needs to be signing many transactions with low latency. Hence storin ## Future Features [Event-Forwarder] -We expect that a key change can be done through a transaction on the chain and a form of restarting a single validator once checkpoints -are fully implemented. +We expect that a key change can be done through a transaction on the chain and a form of restarting a single validator. ### Vega Key [Event-Forwarder] @@ -227,7 +226,7 @@ need to be hashed individually). 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) +3. After both a Vega and Ethereum key rotation the node still can generate snapshots and these can successfully be used for node restarts (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) diff --git a/protocol/0069-VCBS-validators_chosen_by_stake.md b/protocol/0069-VCBS-validators_chosen_by_stake.md index 09891ea03..9e7267da0 100644 --- a/protocol/0069-VCBS-validators_chosen_by_stake.md +++ b/protocol/0069-VCBS-validators_chosen_by_stake.md @@ -139,14 +139,6 @@ is a out-of-the ordinary event and should be logged. At this point, Ersatz validators are not part of the Multisig. -## Restarts from LNL checkpoint - -See [limited network life spec](./0073-LIMN-limited_network_life.md). - -1. At each checkpoint we include node IDs of validators and their scores (meaning all the ones participating in consensus and those who submitted a transaction to become a validator and thus are eligible to be a validator or ersatz validator). -1. When initiating the restart all the nodes participating have the same Tendermint weight in genesis (or whatever they set / agree). This is used until the LNL file has finished processing. -1. When loading LNL file we have to run the same algorithm that selects the "correct" validators; after this is done Tendermint weights are updated. -1. If the validators arising from LNL weight updates are missing from the chain because they haven't started nodes then the chain will stop. The restart needs better coordination so the relevant nodes are present. ## Network Parameters @@ -508,7 +500,7 @@ Setup a network with 6 nodes (3 validators, 2 ersatz validators, 1 pending valid - 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. 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). 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 @@ -520,48 +512,6 @@ Setup a network with 6 nodes (3 validators, 2 ersatz validators, 1 pending valid 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): - - 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): - - 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): - - 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): - - 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): - - 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. -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 1. Can update multisig for new validator, and expect rewards (0069-VCBS-066) diff --git a/protocol/0073-LIMN-limited_network_life.md b/protocol/0073-LIMN-limited_network_life.md deleted file mode 100644 index c65072ccd..000000000 --- a/protocol/0073-LIMN-limited_network_life.md +++ /dev/null @@ -1,469 +0,0 @@ -# Limited network life - -Vega networks will at least initially and perhaps always run for a limited time only. This spec covers the necessary features to ensure this works smoothly. - -## Background - -Networks will have a finite lifetime because: - -- It is efficient to upgrade the protocol by starting again as it avoids the need to deal with multiple versions of the code (upgrades to a running chain need to respect and be able to recalculate the pre-upgrade deterministic state for earlier blocks, so all versions of critical code must remain in the system). -This is especially important early on when rapid iteration is desirable, as the assumption that new chains can be started for new features simplifies things considerably. - -- Trading at 1000s of tx/sec generates a lot of data. Given that most instruments are non-perpetual (they expire), this gives the ability to create new markets on a new chain and naturally let the old one come to an end rather than dragging around its history forever. - -- Bugs, security breaches, or other issues during alpha could either take out the chain OR make it desirable to halt block production. It's important to consider what happens next if this occurs. - -## Overview - -There are four main features: - -1. Create checkpoints with relevant (but minimal) information at regular intervals, and on every withdrawal request. -2. Ability to specify a checkpoint hash as part of genesis. -3. A new 'Restore' transaction that contains the full checkpoint file and triggers state restoration -4. A new 'checkpoint hash' transaction is broadcast by all validators - -Point two requires that at load time, each node calculates the hash of the checkpoint file. It then sends this through consensus to make sure that all the nodes in the new network agree on the state. - -## Creating a checkpoint - -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 (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. -- [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 -- Withdrawal transaction bundles for all bridged chains. -- Hash of the previous block, block number and transaction id of the block from which the snapshot is derived -- ERC-20 collateral: - - last block height of a confirmed ERC-20 deposit on the Ethereum chain with `number_of_confirmations`. [Ethereum bridge](./0031-ETHB-ethereum_bridge_spec.md#network-parameters) - - all pending ERC-20 deposits (not confirmed before this block) [Ethereum bridge](./0031-ETHB-ethereum_bridge_spec.md#deposits) -- 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](./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: - -- if `current_time - network.checkpoint.timeElapsedBetweenCheckpoints > time_of_last_full_checkpoint` - -Information we explicitly don't try to checkpoint: - -- Positions, limit orders, pegged orders or any order book data. LP commitments. -- Market and asset proposals where the voting period hasn't ended. - -When a checkpoint is created, each validator should calculate its hash and submit this is a transaction to the chain, so that non-validating parties can trust the hash being restored represents truly the balances. - -The checkpoint file should either be human-readable OR there should be a command line tool to convert into human readable form. - -## Specifying the checkpoint hash in genesis - -## Restoring a checkpoint - -The hash of the state file to be restored must be specified in genesis. -Any validator will submit a transaction containing the checkpoint file. Nodes verify the hash / chain of hashes to verify the hash that is in genesis. - -- If the hash matches, it will be restored. -- If it does not, the hash transaction will have no effect. - -If the genesis file has a previous state hash, all transactions will be rejected until the restore transaction arrives and is processed. - -The state will be restored in this order: - -- Restore network parameters. -- Load the asset definitions. - - The network will compare the asset coming from the restore file with the genesis assets, one by one. If there is an exact match on asset id: - - either the rest of the asset definition matches exactly in which case move to next asset coming from restore file. - - or any of the part of the definition differ, in which case ignore the entire restore transaction, the node should stop with an error. - - If the asset coming from the restore file is a new asset (asset id not matching any genesis assets) then restore the asset. -- Load the accepted market proposals. If the enactment date is in the past then set the enactment date to `now + net_param_min_enact` (so that opening auction can take place) and status to pending. -- Replay events from bridged chains - - Concerning bridges used to deposit collateral for trading, replay from the last block specified in the checkpoint and reload the pending deposits from the checkpoint so the network can start again to confirm these events. - - Concerning the staking bridges, all balances will be reconciled using the staking events from the checkpoint, up to the last seen block store as part of the checkpoint, then apply again the delegations to the validators. - -There should be a tool to extract all assets from the restore file so that they can be added to genesis block manually, should the validators so desire. - -## Restoring balances - -- Participants need access to funds after network ends. This will be facilitated by using restoration of balances to allow participants to withdraw or continue to trade with funds during the next iteration of the chain. - -## Network parameters - -| Name | Type | Description | -|----------------------------------------------------------|:--------:|-------------------------------------------------------------------|:--------:| -|`network.checkpoint.timeElapsedBetweenCheckpoints` | String (duration) | sets the minimum time elapsed between checkpoints| - -If for `network.checkpoint.timeElapsedBetweenCheckpoints` the value is set to `0` or the parameter is undefined then no checkpoints are created. Otherwise any time-length value `>0` is valid e.g. `1min`, `2h30min10s`, `1month`. If the value is invalid Vega should not start e.g. if set to `3 fish`. - -## 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) - -### 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. -1. The network is restarted with the checkpoint hash from the above checkpoint in genesis. The checkpoint replay transaction is submitted and processed. -1. The check the following sub-cases: - - If the Ethereum replay says withdrawal completed. The party has general account balance of 0 USD. The party has "signed for withdrawal" 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) - -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. -1. There are two parties: one LP for the market and one party that is not an LP. -1. The LP has a long position on `LP_long_pos`. -1. The other party has a short position `other_short_pos = LP_long_pos`. -1. The other party has a limit order on the book. -1. The other party has a pegged order on the book. -1. The LP has general balance of `LP_gen_bal`, margin balance `LP_margin_bal` and bond account balance of `LP_bond_bal`, all in `USD` -1. The other party has general balance of `other_gen_bal`, margin balance `other_margin_bal` and bond account balance of `0`, all in `USD`. -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 `id_xxx` in status "pending". -1. The party LP has a `USD` general account balance equal to `LP_gen_bal + LP_margin_bal` + `LP_bond_bal`. -1. The other party has a `USD` general account balance equal to `other_gen_bal + other_margin_bal`. - -### Test case 3: Governance proposals are maintained across resets, votes are not - -#### 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. -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`, margin balance `other_margin_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_margin_bal`. - -#### 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. -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.1.2: Perpetual market is proposed, accepted, restored (0073-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`. - -#### 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. -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`. -1. `LP party` commits a stake of 1000 USD. -1. The voting period ends 1 year in the future. The enactment date is 2 years in the future. -1. Enough time passes (but less than 1 year) 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 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) - -for product spot:(0073-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. -1. A market is proposed by a party called `LP party`. -1. The voting period ends 1 minute in the future. The enactment date is 2 years in the future. -1. More than 1 minute has passed and the minimum participation threshold hasn't been met. The market proposal status is `rejected`. -1. Enough time passes after the market has been rejected 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 no market and there are no market proposals. -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) - -for product spot: (0073-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. -1. A market is proposed by a party called `LP party`. -1. Checkpoint is taken during voting period. -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 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) - -for product spot: (0073-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. -1. A market is proposed by a party called `LP party`. -1. Checkpoint is taken during voting period -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 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) - -for product spot: (0073-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. -1. The network is restarted with the checkpoint hash from the above checkpoint in genesis. The checkpoint restore transaction is submitted and processed. -1. A new market is proposed -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 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 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. -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 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-LIMN-080) - -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) - -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. -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. 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 so that a checkpoint is created and no party submitted any withdrawal transactions throughout. -1. The network is shut down. -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_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 - -#### Test case 6.1: `timeElapsedBetweenCheckpoints` not set - -#### 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) - -- More than one party deposits stake onto Vega -- The parties delegate stake to the validators -- Setup the rewards: - - A party deposits VEGA funds to their Vega general account - - The party creates a continuing recurring transfer (for e.g: 1 token) from their general account to the reward pool -- Assert that every end of epoch, the funds are distributed, over the parties delegating stake, at end of every epoch -- Wait for the next checkpoint, then stop the network -- Load the checkpoint into a new network -- Assert that at every epoch, the recurring transfers to the reward pool continues to happen, and that the funds are properly being distributed to the delegator - -### 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). 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. -1. Wait for the next checkpoint, then stop the network. -1. Load the checkpoint into a new network -1. Assert that the proposal and the asset have been reloaded into the network with the correct settings. -1. Propose a new market using this asset -1. Deposit funds to traders via the bridge and assert that funds are received. -1. Place orders on the market that will cross. -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) - -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. -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 several minutes 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. 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. -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 market is still in "pending" state. -1. The market becomes enacted when the enactment time is passed. -1. Other parties can trade on the market, and become continuous. - -### Test case 14: Market with trading terminated is not restored, collateral moved correctly - -1. Set LP fee distribution time step to non-zero value. -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) -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 insurance pool balance has been transferred into the global insurance pool using the same settlement asset. (0073-LIMN-115) -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. 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 into the global insurance pool using the same settlement asset. (0073-LIMN-116) -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 - -1. Propose, enact a market with some trading termination and settlement date setting. Trade in the market creating positions for at least 2 parties. -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. 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 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. 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 insurance pool balance has been transferred into the global insurance pool using the same settlement asset. (0073-LIMN-117) -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 - -- Propose a market -- System saves LNL checkpoint. -- Restart Vega, load LNL checkpoint. -- The market has the same: - - 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 - -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). For product spot: (0073-LIMN-100) - -### 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 d3279ccbf..65ea7a058 100644 --- a/protocol/0075-PLUP-protocol_upgrades.md +++ b/protocol/0075-PLUP-protocol_upgrades.md @@ -2,14 +2,14 @@ ## Summary -### Current state of upgrading the vega network +### Early 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](./0073-LIMN-limited_network_life.md). This functionality has the following significant issues: +At the beginning of the Vega mainnet network, upgrading the protocol was near impossible when a major changes to the step are possible without proceeding with a checkpoint file. This functionality had 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. -Limited Network Life is not the end goal. This spec outlines how the protocol evolves from LNL checkpoints to rolling software updates, controlled by a reasonable set of governance and user controls. +This spec outlines how the protocol evolved from checkpoints to rolling software updates, controlled by a reasonable set of governance and user controls. ### How other protocols proceed @@ -23,7 +23,7 @@ The idea in this spec is to draw inspiration from the design of cosmovisor and b ### Prior example of upgrading the nodes asynchronously -Back in December 2021, vega proceeded to a LNL restore. Unfortunately, a bug in the code prevented the dispatch of the network parameters after the restore. This left +Back in December 2021, vega proceeded to a checkpoint restore. Unfortunately, a bug in the code prevented the dispatch of the network parameters after the restore. This left the network in a semi invalid state where the network parameters were defined by the ones from the genesis block instead of the one from the checkpoint from the previous network. The solution employed at the time was to: @@ -158,10 +158,6 @@ For the purposes of protocol upgrade each validator that participates in consens - (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) 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 @@ -183,8 +179,7 @@ For the purposes of protocol upgrade each validator that participates in consens ### 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. +- 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. This AC is covered in a Jenkins pipeline and not a system test. ### Overwriting transactions diff --git a/protocol/0077-SNAP-snapshots.md b/protocol/0077-SNAP-snapshots.md index bb6034e3a..549bb79d0 100644 --- a/protocol/0077-SNAP-snapshots.md +++ b/protocol/0077-SNAP-snapshots.md @@ -19,7 +19,7 @@ A snapshot is generated when the current block height MOD blocks_between_snapsho ### The contents of a snapshot -A snapshot should contain the full state of the core (collateral, markets and their orderbooks, etc...), in such a way so a node can be loaded into the exact same state the node that created the snapshot was in. After loading a snapshot, any subsequent transactions that node processes _has_ to produce the exact same result as if that node had replayed the entire chain. Compared to checkpoints, for example, where collateral aggregates the balances per party, per asset, a snapshot ought to contain every account a party has, and what its balance is. +A snapshot should contain the full state of the core (collateral, markets and their orderbooks, etc...), in such a way so a node can be loaded into the exact same state the node that created the snapshot was in. After loading a snapshot, any subsequent transactions that node processes _has_ to produce the exact same result as if that node had replayed the entire chain. Compared to [checkpoints](https://github.com/vegaprotocol/specs/blob/master/protocol/0075-PLUP-protocol_upgrades.md#early-state-of-upgrading-the-vega-network), for example, where collateral aggregates the balances per party, per asset, a snapshot ought to contain every account a party has, and what its balance is. The snapshot type in tendermint itself does not contain any state data, but rather identifying information and metadata. The data is sent out in chunks. Our snapshot metadata should contain hashes for all the chunks, so that the node can verify each chunk as it receives it from another node. If a node provides a chunk with a different hash, either the snapshot data we are trying to load is corrupt (unlikely), or a malicious node is providing bad data, in which case we can, and should, reject the chunk (and fetch it again), and perhaps ban that node so as to not receive any more potentially corrupt data. @@ -29,7 +29,7 @@ The snapshot chunks will reflect the core's internal structure quite a lot. Tend snapshot{ Height: 123, Hash: "0xDEADBEEF", // hash of the entire snapshot - Chunks: 14, // this checkpoint comes in 14 chunks + Chunks: 14, // this snapshot comes in 14 chunks Metadata: { Assets: { Chunk: 0, // which chunk is expected to contain this data @@ -61,6 +61,4 @@ A bad node can swamp the network by requesting snapshots from other nodes which - 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) - diff --git a/protocol/0081-SUCM-successor_markets.md b/protocol/0081-SUCM-successor_markets.md index bd6ca2718..7af0ceac5 100644 --- a/protocol/0081-SUCM-successor_markets.md +++ b/protocol/0081-SUCM-successor_markets.md @@ -105,17 +105,8 @@ It is possible to fetch a market "parent / successor chain" containing the initi 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 / Protocol Upgrade / Network History +### Snapshots / 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) - -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. 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) After snapshot restart the successor (child) / parent market state is preserved where applicable including the LPs ELS (0081-SUCM-017) diff --git a/protocol/0082-ETHD-ethereum-data-source.md b/protocol/0082-ETHD-ethereum-data-source.md index 314f96533..2a6fac444 100644 --- a/protocol/0082-ETHD-ethereum-data-source.md +++ b/protocol/0082-ETHD-ethereum-data-source.md @@ -170,10 +170,6 @@ Select { 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 - -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 diff --git a/protocol/categories.json b/protocol/categories.json index 3491d10f7..c5aed2675 100644 --- a/protocol/categories.json +++ b/protocol/categories.json @@ -9,7 +9,7 @@ "specs": ["0002-STTL", "0003-MTMK", "0045-DSRC", "0046-DSRM", "0047-DSRF", "0048-DSRI", "0082-ETHD", "0087-EVMD"] }, "Protections": { - "specs": ["0073-LIMN", "0072-SPPW", "0062-SPAM", "0060-WEND", "0003-NP-LIMI", "0072-SPPW", "0078-NWLI", "0079-TGAP"] + "specs": ["0073-LIMN", "0072-SPPW", "0062-SPAM", "0060-WEND", "0072-SPPW", "0078-NWLI", "0079-TGAP"] }, "Liquidity": { "specs": ["0044-LIME", "0042-LIQF", "0034-PROB", "0012-NP-LIPE"] @@ -36,7 +36,7 @@ "specs": ["0076-DANO", "0020-APIS", "0007-POSN"] }, "Referral": { - "specs": ["0083-RFPR", "0084-VDPR", "0085-RVST", "0086-ASPR"] + "specs": ["0083-RFPR", "0084-VDPR", "0085-RVST", "0086-ASPR", "0088-PPRF"] }, "UI": { "specs": ["1000-ASSO", "1001-VEST", "1002-STAK", "1003-INCO", "1004-VOTE", "3002-PROP", "1006-NETW", "1007-WALL", "3000-DEPO", "3001-WITH", "5000-MARK", "6000-COLL", "6001-SORD", "6002-MORD", "6003-POSI", "6004-FILL"] From a68adcfd534a40673d120ca99c39d6c78d6b83dd Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Wed, 13 Mar 2024 14:29:55 +0000 Subject: [PATCH 1020/1171] feat: add AC 209 for margin factor being greater than 1 --- protocol/0019-MCAL-margin_calculator.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/protocol/0019-MCAL-margin_calculator.md b/protocol/0019-MCAL-margin_calculator.md index 259056833..a476d3706 100644 --- a/protocol/0019-MCAL-margin_calculator.md +++ b/protocol/0019-MCAL-margin_calculator.md @@ -313,6 +313,8 @@ There should be an additional amount `limit price x size x margin factor = 15910 - when switch to isolated margin mode, valid value of the margin factor must be greater than 0, and also greater than `max(risk factor long, risk factor short) + linear slippage factor`(0019-MCAL-208) +- when amend margin factor during isolated margin mode, margin factor greater than 1 should be not rejected (0019-MCAL-209) + **Check order margin:** - when party has no position, and place 2 short orders during auction, order margin should be updated(0019-MCAL-200) From b7b25fab2432b96fd57d2ec847243e28973741e1 Mon Sep 17 00:00:00 2001 From: Pete Barrow <62435083+peterbarrow@users.noreply.github.com> Date: Wed, 13 Mar 2024 16:01:23 +0000 Subject: [PATCH 1021/1171] fix: Update price trigger limit from 5 to 100 (#2210) --- protocol/0032-PRIM-price_monitoring.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/protocol/0032-PRIM-price_monitoring.md b/protocol/0032-PRIM-price_monitoring.md index 3ac8812d9..ac702701f 100644 --- a/protocol/0032-PRIM-price_monitoring.md +++ b/protocol/0032-PRIM-price_monitoring.md @@ -61,11 +61,11 @@ If any of the above parameters or the risk model gets modified in any way, the p #### Hard-coded -- Vega allows maximum of `5` price monitoring parameter triples in `priceMonitoringParameters` per market. +- Vega allows maximum of `100` price monitoring parameter triples in `priceMonitoringParameters` per market. There are several reasons why this maximum is enforced. -1. anything more than `5` triplets makes reasoning about what and when will trigger an auction more difficult and could lead to markets that behave in unexpected ways. +1. anything more than `100` triplets makes reasoning about what and when will trigger an auction more difficult and could lead to markets that behave in unexpected ways. 1. allowing high number of triplets could have performance impact 1. testing everything works correctly is more manageable if the number is capped. @@ -124,7 +124,7 @@ to the risk model and obtains the range of valid up/down price moves per each of (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) +- A maximum of `100` 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) From ee2a981aaa853e5f26990bca4af120c16568e8d0 Mon Sep 17 00:00:00 2001 From: Sohill-Patel <85170301+Sohill-Patel@users.noreply.github.com> Date: Thu, 14 Mar 2024 14:19:43 +0000 Subject: [PATCH 1022/1171] chore: remove 0043-MKTL-005 --- protocol/0043-MKTL-market_lifecycle.md | 2 -- protocol/features.json | 1 - 2 files changed, 3 deletions(-) diff --git a/protocol/0043-MKTL-market_lifecycle.md b/protocol/0043-MKTL-market_lifecycle.md index 04ee9d0f1..da96a093a 100644 --- a/protocol/0043-MKTL-market_lifecycle.md +++ b/protocol/0043-MKTL-market_lifecycle.md @@ -243,8 +243,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`. 1. Parties vote against the market proposal. diff --git a/protocol/features.json b/protocol/features.json index bd82ea3e8..c83a0e9e3 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -209,7 +209,6 @@ "0039-MKTD-031", "0039-MKTD-032", "0039-MKTD-033", - "0043-MKTL-005", "0043-MKTL-006", "0043-MKTL-007", "0043-MKTL-008", From 85e6d728e3f142d22e87292780da700b2a452435 Mon Sep 17 00:00:00 2001 From: Sohill-Patel <85170301+Sohill-Patel@users.noreply.github.com> Date: Thu, 14 Mar 2024 14:36:28 +0000 Subject: [PATCH 1023/1171] feat: update wording for spot ac --- protocol/0024-OSTA-order_status.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0024-OSTA-order_status.md b/protocol/0024-OSTA-order_status.md index 7011257be..c7b127b03 100644 --- a/protocol/0024-OSTA-order_status.md +++ b/protocol/0024-OSTA-order_status.md @@ -116,7 +116,7 @@ Note: The last row in the table above is added for clarity. If the order was fil - 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_MARKET_CLOSED` when trying to send an order when the market is closed (0024-OSTA-018). For product spot the transaction result will be `Invalid Market ID` instead (0024-OSTA-044) - 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) From 66c0e7f3cd499c489540e7ca8d33f0ede20e91be Mon Sep 17 00:00:00 2001 From: Sohill-Patel <85170301+Sohill-Patel@users.noreply.github.com> Date: Thu, 14 Mar 2024 14:37:10 +0000 Subject: [PATCH 1024/1171] chore: remove one word --- protocol/0024-OSTA-order_status.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0024-OSTA-order_status.md b/protocol/0024-OSTA-order_status.md index c7b127b03..f2fb085b5 100644 --- a/protocol/0024-OSTA-order_status.md +++ b/protocol/0024-OSTA-order_status.md @@ -116,7 +116,7 @@ Note: The last row in the table above is added for clarity. If the order was fil - 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 the transaction result will be `Invalid Market ID` instead (0024-OSTA-044) +- Order reason of `ORDER_ERROR_MARKET_CLOSED` when trying to send an order when the market is closed (0024-OSTA-018). For product spot the transaction result will be `Invalid Market ID` (0024-OSTA-044) - 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) From 0f2b634a8054625728bdc4ca000335fc114d5936 Mon Sep 17 00:00:00 2001 From: Sohill-Patel <85170301+Sohill-Patel@users.noreply.github.com> Date: Thu, 14 Mar 2024 14:44:19 +0000 Subject: [PATCH 1025/1171] fix: md lint --- protocol/0024-OSTA-order_status.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0024-OSTA-order_status.md b/protocol/0024-OSTA-order_status.md index f2fb085b5..0776ed854 100644 --- a/protocol/0024-OSTA-order_status.md +++ b/protocol/0024-OSTA-order_status.md @@ -116,7 +116,7 @@ Note: The last row in the table above is added for clarity. If the order was fil - 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 the transaction result will be `Invalid Market ID` (0024-OSTA-044) +- Order reason of `ORDER_ERROR_MARKET_CLOSED` when trying to send an order when the market is closed (0024-OSTA-018). For product spot the transaction result will be `Invalid Market ID` (0024-OSTA-044) - 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) From 1c03d2259ab208c885f3aabc7009e878ad7011c1 Mon Sep 17 00:00:00 2001 From: Pete Barrow Date: Thu, 14 Mar 2024 14:55:46 +0000 Subject: [PATCH 1026/1171] fix: Updating wording --- protocol/0032-PRIM-price_monitoring.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0032-PRIM-price_monitoring.md b/protocol/0032-PRIM-price_monitoring.md index ac702701f..480b05572 100644 --- a/protocol/0032-PRIM-price_monitoring.md +++ b/protocol/0032-PRIM-price_monitoring.md @@ -137,7 +137,7 @@ 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). 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) +- 2 persistent orders with prices outside both trigger price 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) - For all available mark price calculation methodologies: the price history used by the price monitoring engine is in line with market's mark price history. (0032-PRIM-039) - For all available mark-price calculation methodologies: the mark price update candidate gets rejected if it violates the price monitoring engine bounds. (0032-PRIM-040) From b94824f53bf766c0a098b3fd7d5a44e02935fa04 Mon Sep 17 00:00:00 2001 From: Gordsport <83510148+gordsport@users.noreply.github.com> Date: Thu, 14 Mar 2024 16:06:29 +0000 Subject: [PATCH 1027/1171] Add ACs for new asset bridge (#2204) * feat: add initial deposit withdraw ACs * fix: AC code numbering * fix: spelling * feat: update VCBS spec for second bridge and add an AC * feat: add an official section on issuing signatures to update the multisig contract * feat: a couple more AC's * chore: typos * chore: fix markdown * chore: add new ACs to features.json file * fix: quality checks * fix: duplicate AC number * Update protocol/0069-VCBS-validators_chosen_by_stake.md * feat: add AC's for second bridge asset proposals * feat: add AC for swapping an asset between chains through a spot market * feat: add another API AC for the multisig add/remove bundles * fix: approbation number errors * fix: more quality checks * fix: syntax * chore: add AC to doubly check we can stop both bridges * fix: clarifications * fix: small edits * fix: reword ACs to not specify a single bridge * fix: spelling * fix: wording and add ACs to features file * fix: spellling * Fix: AC code * Update protocol/0027-ASSP-asset_proposal.md Co-authored-by: David Siska <62546419+davidsiska-vega@users.noreply.github.com> * Update protocol/0027-ASSP-asset_proposal.md Co-authored-by: David Siska <62546419+davidsiska-vega@users.noreply.github.com> * Update protocol/0027-ASSP-asset_proposal.md Co-authored-by: David Siska <62546419+davidsiska-vega@users.noreply.github.com> * Apply suggestions from code review Co-authored-by: David Siska <62546419+davidsiska-vega@users.noreply.github.com> * chore: add AC codes to features file * Apply suggestions from code review Co-authored-by: David Siska <62546419+davidsiska-vega@users.noreply.github.com> * fix: MD lint * Update protocol/0069-VCBS-validators_chosen_by_stake.md Co-authored-by: David Siska <62546419+davidsiska-vega@users.noreply.github.com> * fix: MD linting * Update protocol/0069-VCBS-validators_chosen_by_stake.md Co-authored-by: wwestgarth --------- Co-authored-by: wwestgarth Co-authored-by: David Siska <62546419+davidsiska-vega@users.noreply.github.com> Co-authored-by: wwestgarth --- ...0003-NP-LIMI-limits_aka_training_wheels.md | 2 +- protocol/0027-ASSP-asset_proposal.md | 27 +++--- protocol/0031-ETHB-ethereum_bridge_spec.md | 4 +- .../0069-VCBS-validators_chosen_by_stake.md | 89 +++++++++++++++---- protocol/0080-SPOT-product_builtin_spot.md | 1 + protocol/features.json | 24 +++++ wordlist.txt | 4 + 7 files changed, 118 insertions(+), 33 deletions(-) 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 6761e86af..04a2eab50 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 @@ -134,7 +134,7 @@ This is primarily for liquidity providers and other sophisticated participants a - 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) +1. Validators can, via multisig, stop and recommence processing bridge transactions on any of the bridges (0003-NP-LIMI-007) - 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 diff --git a/protocol/0027-ASSP-asset_proposal.md b/protocol/0027-ASSP-asset_proposal.md index 26455df6e..2c5af4ebe 100644 --- a/protocol/0027-ASSP-asset_proposal.md +++ b/protocol/0027-ASSP-asset_proposal.md @@ -22,13 +22,15 @@ When exactly the nodes must have approved or not signalled approval of the asset As detailed above, the validators will check the validity of the details supplied by the asset proposer. The validation occurs before the `validationTimestamp` provided in the `ProposalTerms`. The following checks should be applied: -### ERC20 assets +### ERC20 assets on any Ethereum VM compatible chain supporting Ethereum RPC -- The contract address provided must point to an ERC20 asset on the [bridged Ethereum network](./0031-ETHB-ethereum_bridge_spec.md) -- The contract must not already have an existing asset accepted on the Vega network (note: another _proposal_ could exist for the same asset) +- The proposal must point to an id of an Ethereum VM compatible chain supporting Ethereum RPC that Vega network recognises +- The contract address provided must point to an ERC20 asset on the [bridged Ethereum VM compatible chain supporting Ethereum RPC network](./0031-ETHB-ethereum_bridge_spec.md) +- The chain id and contract pair must not already have an existing asset accepted on the Vega network (note: another _proposal_ could exist for the same asset) - The name must strictly match the name in the ERC20 contract (e.g. `Wrapped ether`) - The symbol must strictly match the symbol (e.g. `WETH`) + ## Enabling a new asset on the bridge Once the proposal is accepted, validators will produce a bundle (e.g. transaction plus signature/s) for submission to the asset's originating blockchain. Vega nodes will make this bundle available via an API. @@ -77,7 +79,8 @@ 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 - string withdrawalDelayThreshold = 3; // this is will be interpreted against the asset decimals + string withdrawalDelayThreshold = 3; // this is will be interpreted against the asset decimals + string chain_id = 4; // this is the ID of the chain the asset's contract address is from } message AssetSource { @@ -163,18 +166,21 @@ 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 submit a new proposal asset to be used in vega for any EVM-ERPC asset bridge (0027-ASSP-034) - 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) +- 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 on any asset bridge (0027-ASSP-035) - `quantum` is a required parameter (0027-ASSP-004) - If an update asset proposal passed and it changes `quantum` _only_ then this new value becomes used immediately on enactment. (0027-ASSP-025) +- As a user if I submit a new proposal asset for an ERC20 asset without specifying a chain-id, the proposal is rejected (0027-ASSP-031) +- As a user if I submit a new proposal asset for an ERC20 asset with a chain-id that does not correspond to any bridge, the proposal is rejected (0027-ASSP-032) +- As a user if, I can see the chain-id an ERC20 asset originates on via a data node API (0027-ASSP-033) ### 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 its chain, and send the result of the validation through the chain to the other nodes (first phase proposal) on any asset bridge (0027-ASSP-027) +- As a node, when a new asset from any EVM/ERPC bridge is accepted through governance, I can sign a payload to the user so they can whitelist the asset on the bridge contract on the appropriate chain (0027-ASSP-028) +- As a node, I receive events from the external blockchain queues for all the registered EVM/ERPC chains, that confirm the asset is enabled on the relevant chain bridge contract (0027-ASSP-029) +- 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 EVM/ERPC chain the asset is bridged from (0027-ASSP-030) ### Validation @@ -201,4 +207,3 @@ This must be an integer strictly greater than `0`. - 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) - diff --git a/protocol/0031-ETHB-ethereum_bridge_spec.md b/protocol/0031-ETHB-ethereum_bridge_spec.md index 8acda13db..e3795e69d 100644 --- a/protocol/0031-ETHB-ethereum_bridge_spec.md +++ b/protocol/0031-ETHB-ethereum_bridge_spec.md @@ -138,13 +138,13 @@ This example connects the network to Ropsten: ### Deposit - 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 wallet address can call the deposit function on the bridge contract on any EVM/ERPC chain on which the bridge contract is deployed and successfully deposit any token that is listed via `list_asset` on the asset bridge on the said chain (0031-ETHB-084). - 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) + - A valid multisig bundle can be passed to the withdraw function to successfully withdraw an ERC-20 asset to a wallet address on any EVM/ERPC chain asset bridge (0031-ETHB-085) - An invalid multisig bundle will be rejected from withdraw (0031-ETHB-014) ### Allowlist a token (by eth address) diff --git a/protocol/0069-VCBS-validators_chosen_by_stake.md b/protocol/0069-VCBS-validators_chosen_by_stake.md index 9e7267da0..e88693f20 100644 --- a/protocol/0069-VCBS-validators_chosen_by_stake.md +++ b/protocol/0069-VCBS-validators_chosen_by_stake.md @@ -84,30 +84,58 @@ Basic vega chain liveness criteria is covered in their [performance score](./006 ## Verifying Ethereum (and later other chain) integration -In order to be considered for promotion from ersatz validator to Tendermint validator, an ersatz validator must prove itself to be reliable. This is measured by ensuring their reliability in forwarding [Ethereum events](./0036-BRIE-event_queue.md). -A network parameter, `network.validators.minimumEthereumEventsForNewValidator`, is used to set the acceptable minimum count of times that an ersatz validator was the first to forward a subsequently accepted Ethereum event at least `network.validators.minimumEthereumEventsForNewValidator` times. +In order to be considered for promotion from ersatz validator to Tendermint validator, an ersatz validator must prove itself to be reliable. This is measured by ensuring their reliability in forwarding [Chain events](./0036-BRIE-event_queue.md). +A network parameter, `network.validators.minimumEthereumEventsForNewValidator`, is used to set the acceptable minimum count of times that an ersatz validator was the first to forward a subsequently accepted Ethereum event at least `network.validators.minimumEthereumEventsForNewValidator` times. An ersatz node will have to forward this number of events for each bridge. ## Multisig updates (and multisig weight updates if those are used) -Vega will know the initial multisig signer list (and weights) and watch for `signer added` and `signer removed` events to track which ethereum keys are present on multisig. +Vega will know the initial multisig signer list (and weights) and watch for `signer added` and `signer removed` events to track which ethereum keys are present on the multisig on every registered EVM/ERPC chain. -Once (if) the ethereum multisig contract supports validator weights the vega node will watch for Ethereum events announcing the weight changing. -Thus for each validator that is on the multisig contract it will know the validator score (weight) the ethereum multisig is using. +Once (if) the multisig contracts supports validator weights the vega node will watch for Ethereum events announcing the weight changing. +Thus for each validator that is on each multisig contract it will know the validator score (weight) the multisig is using. -We will have `network.validators.multisig.numberOfSigners` represented on the multisig (currently `13`) but this could change. +We will have `network.validators.multisig.numberOfSigners` represented on each multisig. Note that `network.validators.multisig.numberOfSigners` must always be less than or equal to `network.validators.tendermint.number`. -In the reward calculation for the top `network.validators.multisig.numberOfSigners` by `validator_score` (as seen on VEGA) use `min(validator_score, ethereum_multisig_weight)` when calculating the final reward with `0` for those who are in the top `network.validators.multisig.numberOfSigners` by score but *not* on the multisig contract. +In the reward calculation for the top `network.validators.multisig.numberOfSigners` by `validator_score` (as seen on VEGA) use `min(validator_score, chain_1_multisig_weight, ..., chain_n_multisig_weight)`, with `n` representing the number of registered EVM/ERPC chains for assets, when calculating the final reward with `0` for those who are in the top `network.validators.multisig.numberOfSigners` by score but *missing* from the multisig contract on any of the `n` registered asset chains. -Thus a validator who is not there but should be has incentive to pay gas to update the multisig. Moreover a validator who's score has gone up substantially will want to do so as well. +Thus a validator who is not there but should be has incentive to pay gas to update each multisig. Moreover a validator who's score has gone up substantially will want to do so as well. -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. +As a consequence, if a potential validator joined the Vega chain validators but has *not* updated the Multisig members (and/or weights) for each bridge, 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. +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 and the community to remove the demoted member from all Multisig contracts. They are incentivised to do so by all receiving a `validator_score` of `0` *in the reward calculation* until the excess member is removed from each bridge. 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. + +## Issuing signatures bundles to update Multisig contracts + +When a nodes is promoted or demoted from the tendermint validator set the multisig control contracts on each bridge should be updated to reflect the new set. To be able to update the signers on the multisig control contract a signature bundle authorising the addition or removal of a signer is required containing a quorum of signatures from those already on the multisig control contract. + +As rewards are withheld from all parties who have staked and delegated to the Vega network, any party is allowed to request a signature bundle to resolve the multisig contract and continue receiving rewards. This can be done by sending in a transaction to the network containing the following information: + +```json +{ + "submitter": "abc", # the Ethereum address that will submit the transaction to the multisig contract + "node_id": "xyz", # the node ID who needs to be added or removed + "type": "add/remove", # whether the node needs to be added or removed + "chain_id": "1", # the ID of the EVM chain the signature bundle is for +} +``` + +Then result from a successful submission will be the generation of a signature bundle made available via a data node. + +A transaction to issue signatures must fail if: + +- the request *does not* correspond to a validator the needs adding/removing from the contract +- the given chain-id does not belong to any bridge + +Once a validator who needs adding/removing from the contract has been added/removed (or no longer needs to be added or removed) it must not be possible to request more signature bundles for it. + +All signature bundles for a particular adding/removal event *must* use the same nonce. For example if validator `v` is promoted and needs to be added to the contract, when three different parties submit transactions to issue signatures, each of their bundles should use the same nonce. This necessary so that ones one bundle has been used, the other 2 are now defunct. + + ## Ersatz/Standby validators 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 @@ -137,7 +165,7 @@ is a out-of-the ordinary event and should be logged. ### Multisig for Ersatz validators -At this point, Ersatz validators are not part of the Multisig. +At this point, Ersatz validators are not part of any Multisig. ## Network Parameters @@ -150,6 +178,8 @@ At this point, Ersatz validators are not part of the Multisig. |`network.validators.multisig.numberOfSigners` | String (integer) | 9 | Currently set to the number of validators on the network. In future will be used to scale multisig Validator participation. | |`network.validators.ersatz.rewardFactor` | String (float) | 0.2 | Scales down [the rewards](./0069-VCBS-validators_chosen_by_stake.md#ersatz-validators) of ersatz validators relative to actual validators | |`network.validators.ersatz.multipleOfTendermintValidators` | String (integer) | 2 | Used to [calculate the number](./0069-VCBS-validators_chosen_by_stake.md#ersatz-validators) of ersatz Validators that will earn rewards | +|`spam.protection.minMultisigUpdates` | String (integer) | 5 | Minimum number of staked tokens a party must have to be able to submit a transaction to issue signatures | +|`spam.protection.max.MultisigUpdates` | String (integer) | 5 | Maximum number of times per epoch a party can submit a transaction to issue signatures | ## Acceptance criteria @@ -191,9 +221,9 @@ At this point, Ersatz validators are not part of the Multisig. 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. + - 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 all the multisig contracts. - 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. + - Verify that at the end of the epoch all of the Tendermint validators should have a multisig score = 0 since Bob is still on all contracts. 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**. @@ -221,8 +251,21 @@ At this point, Ersatz validators are not part of the Multisig. - 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): - 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. + - Ensure its ethereum key is **NOT** put on any of the multisig contract. - Verify the validator has 0 for their multisig score and receives no staking reward. +1. All multisig contracts must be updated for non-zero multisig scores (0069-VCBS-092) + - 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. + - Assert that since the demoted validator is still on the multisigs, all tendermint validators should have a multisig score of `0` + - Remove the demoted validator from only one multisig contracts + - Assert that all tendermint validators have a multisig score of `0` + - Remove the demoted validator the remaining multisig contracts + - Assert that all tendermint validators *except the promoted validator* should have a multisig score of `1` + - Add the promoted validator to only one of the multisig contracts + - Assert that the promoted validator still has a multisig score of `0` + - Add the promoted validator to all of the multisig contracts + - Assert that the promoted validator now has a multisig score of `1` #### Validator Score @@ -518,18 +561,17 @@ Setup a network with 6 nodes (3 validators, 2 ersatz validators, 1 pending valid - 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. + - Update the multisig contract on all bridges 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) - 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. + - Update all multisig contracts 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 multisig signers to be the keys of the current consensus (tendermint) validators up to `network.validators.multisig.numberOfSigners`. This request can only be submitted `spam.protection.max.MultisigUpdates` times per epoch per vega key per registered EVM/ERPC asset chain (alternatively the request will provide the update bundles for all the chains). Once multisig uses weights it will also include the correct weights for all multisig contracts. (0069-VCBS-094) +1. Replace a validator with a new node via promotion/demotion. Ensure that rewards are paid out at the end of the epoch if all multisigs are updated to match the new validator. (0069-VCBS-091) ### Re-Issuing Signature Bundles by non Validators @@ -553,3 +595,12 @@ 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) + +1. After a node has been promoted, issue a request for a signature to add it to the multisig control contract but provide a chain-id that does not correspond to any bridge. It should fail. +(0069-VCBS-089) + +1. After a node has been demoted, issue a request for a signature to remove it to the multisig control contract but provide a chain-id that does not correspond to any bridge. It should fail. +(0069-VCBS-090) + +1. After a successful transaction to issue signatures, the data node API containing the signature bundles also includes the chain-id for the multisig contract it corresponds to. +(0069-VCBS-093) diff --git a/protocol/0080-SPOT-product_builtin_spot.md b/protocol/0080-SPOT-product_builtin_spot.md index 3ef35458e..a5e396362 100644 --- a/protocol/0080-SPOT-product_builtin_spot.md +++ b/protocol/0080-SPOT-product_builtin_spot.md @@ -133,3 +133,4 @@ Price-monitoring auctions are still required and should be implemented following 1. If the fee rates change for any reason within an auction, when the auction exits the amount required to cover fees must be recalculated. If a party does not have enough funds to cover the increase their order should be stopped with a clear return code. (0080-SPOT-021). 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). 1. Spot governance proposal fails with asset error, when quote_asset and base_asset has same assets. (0080-SPOT-022). +1. A `Spot` market can be created for a `quote_asset` / `base_asset` where each asset exists on a different originating chain i.e one asset is on one asset bridge and another asset is from another asset bridge. As a user I can then deposit one asset through one bridge, swap it, and withdraw the other asset through any other bridge (0080-SPOT-023) diff --git a/protocol/features.json b/protocol/features.json index c83a0e9e3..28c27f6f2 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -347,6 +347,30 @@ "milestone": "colosseo", "acs": ["0012-POSR-030"] }, + "New asset bridge": { + "milestone": "colosseo", + "acs": [ + "0027-ASSP-027", + "0027-ASSP-028", + "0027-ASSP-029", + "0027-ASSP-030", + "0027-ASSP-031", + "0027-ASSP-032", + "0027-ASSP-033", + "0027-ASSP-034", + "0027-ASSP-035", + "0031-ETHB-084", + "0031-ETHB-085", + "0069-VCBS-089", + "0069-VCBS-090", + "0069-VCBS-091", + "0069-VCBS-092", + "0069-VCBS-093", + "0069-VCBS-094", + "0080-SPOT-023", + "0003-NP-LIMI-007" + ] + }, "Unknown": { "milestone": "unknown", "acs": [] diff --git a/wordlist.txt b/wordlist.txt index e6c46db2b..8001e5979 100644 --- a/wordlist.txt +++ b/wordlist.txt @@ -9,6 +9,7 @@ allowlisted antiwhaling API APIs +Arbitrum AST asynchrony atomicity @@ -92,6 +93,7 @@ ERC ERC-1155 ERC-20 ERC-721 +ERPC ETH ETH's ETHB @@ -185,6 +187,7 @@ misconfiguration MTM mu multisig +multisigs MultisigControl multisignature NFTs @@ -322,6 +325,7 @@ vegawallet verifiably verifier visor +VM VW VWAP walkthrough From 7530f5c81e4eebd9709d988dceec8331aff12d16 Mon Sep 17 00:00:00 2001 From: Pete Barrow Date: Wed, 20 Mar 2024 11:32:47 +0000 Subject: [PATCH 1028/1171] fix: Updating wording for self trading states --- protocol/0068-MATC-matching_engine.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0068-MATC-matching_engine.md b/protocol/0068-MATC-matching_engine.md index a1b61a174..a2e215042 100644 --- a/protocol/0068-MATC-matching_engine.md +++ b/protocol/0068-MATC-matching_engine.md @@ -54,7 +54,7 @@ For [Good 'Til Time (GTT) / Good 'Till Cancelled (GTC) / Good For Normal (GFN)]( - 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) +- All attempts to [self trade](./0024-OSTA-order_status.md#wash-trading) are prevented and the aggressive side is STOPPED if completely unfilled or PARTIALLY_FILLED if some matching occurred before the self trade. 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): From 00939dcd3211faaf5d8fad256619e06538ec55b7 Mon Sep 17 00:00:00 2001 From: Jiajia-Cui <92106936+Jiajia-Cui@users.noreply.github.com> Date: Wed, 20 Mar 2024 16:37:45 +0000 Subject: [PATCH 1029/1171] chore: correct a typo in spec 0068 (#2216) --- protocol/0068-MATC-matching_engine.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0068-MATC-matching_engine.md b/protocol/0068-MATC-matching_engine.md index a2e215042..2529434c6 100644 --- a/protocol/0068-MATC-matching_engine.md +++ b/protocol/0068-MATC-matching_engine.md @@ -94,7 +94,7 @@ The matching engine is responsible for updating and maintaining the state of the ## Guide-level explanation -The machine engine consists of an order book and the logic to handle new orders arriving into the engine. The matching engine can be in one of two possible states, continuous trading or auction trading. In continuous trading the incoming orders are processed immediately. In auction mode incoming orders are placed on the order book and are not processed for matching until we attempt to uncross. +The matching engine consists of an order book and the logic to handle new orders arriving into the engine. The matching engine can be in one of two possible states, continuous trading or auction trading. In continuous trading the incoming orders are processed immediately. In auction mode incoming orders are placed on the order book and are not processed for matching until we attempt to uncross. ### Continuous Mode From b3d2e02c005b30cc5ff64709b7ce20f114dd6dcb Mon Sep 17 00:00:00 2001 From: Gordsport <83510148+gordsport@users.noreply.github.com> Date: Thu, 21 Mar 2024 09:46:26 +0000 Subject: [PATCH 1030/1171] fix: remove 0044-LIME-074 as its not for spot (#2217) Removes 0044-LIME-074 as its not for spot --- protocol/0044-LIME-lp_mechanics.md | 2 +- protocol/features.json | 1 - 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/protocol/0044-LIME-lp_mechanics.md b/protocol/0044-LIME-lp_mechanics.md index a01257039..9fcb3dcbf 100644 --- a/protocol/0044-LIME-lp_mechanics.md +++ b/protocol/0044-LIME-lp_mechanics.md @@ -382,7 +382,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). - 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) diff --git a/protocol/features.json b/protocol/features.json index 28c27f6f2..51fb990e4 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -43,7 +43,6 @@ "0044-LIME-068", "0044-LIME-070", "0044-LIME-072", - "0044-LIME-074", "0044-LIME-076", "0044-LIME-078", "0044-LIME-080", From fa68d3d9beb9ca21a07af6b13f27c83750763637 Mon Sep 17 00:00:00 2001 From: Gordsport <83510148+gordsport@users.noreply.github.com> Date: Fri, 22 Mar 2024 13:31:50 +0000 Subject: [PATCH 1031/1171] fix: add missing AC regarding the rewards.team.minEpochsInTeam netparam (#2220) Adds an AC to ensure that the `rewards.team.minEpochsInTeam` is adhered to when team members become eligible for rewards --- protocol/0083-RFPR-on_chain_referral_program.md | 1 + protocol/features.json | 4 ++++ 2 files changed, 5 insertions(+) diff --git a/protocol/0083-RFPR-on_chain_referral_program.md b/protocol/0083-RFPR-on_chain_referral_program.md index f959f00fe..39846dbe4 100644 --- a/protocol/0083-RFPR-on_chain_referral_program.md +++ b/protocol/0083-RFPR-on_chain_referral_program.md @@ -505,6 +505,7 @@ The Estimate Fees API should now calculate the following additional information: 1. If a party submits a `JoinTeam` transaction and the team is not `closed` then the party **should** be added to the team. (0083-RFPR-064). 1. If a party submits a `JoinTeam` transaction and the team is `closed` then the party **will** be added to the team if **they are** specified in the `allow_list`. (0083-RFPR-065). 1. If a party submits a `JoinTeam` transaction and the team is `closed` then the party **will not** be added to the team if **they are not** specified in the `allow_list`. (0083-RFPR-066). +1. Assert that a user joining a team is not eligible for rewards until the number of epochs since joining the team as specified in the `rewards.team.minEpochsInTeam` network parameter has passed. (0083-RFPR-068). #### Epoch and running volumes diff --git a/protocol/features.json b/protocol/features.json index 51fb990e4..345b29abc 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -370,6 +370,10 @@ "0003-NP-LIMI-007" ] }, + "Teams": { + "milestone": "colosseo", + "acs": ["0083-RFPR-068"] + }, "Unknown": { "milestone": "unknown", "acs": [] From ded1d2a2b8513096ef865ebf461d36dfd1b1dd05 Mon Sep 17 00:00:00 2001 From: Gordsport <83510148+gordsport@users.noreply.github.com> Date: Fri, 22 Mar 2024 16:46:58 +0000 Subject: [PATCH 1032/1171] chore: Add AC for vega issue #10973 (#2221) * chore: Add AC for vega issue #10973 Adds and AC for the vegaprotocol/vega#10973 issue seen on testnet * fix: add to features.json * fix: json syntax --- protocol/0043-MKTL-market_lifecycle.md | 5 +++++ protocol/features.json | 4 ++++ 2 files changed, 9 insertions(+) diff --git a/protocol/0043-MKTL-market_lifecycle.md b/protocol/0043-MKTL-market_lifecycle.md index da96a093a..a41bb2f30 100644 --- a/protocol/0043-MKTL-market_lifecycle.md +++ b/protocol/0043-MKTL-market_lifecycle.md @@ -365,3 +365,8 @@ After `market.liquidity.successorLaunchWindowLength` has passed since market set 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. + +### Market gets suspended and resumed before it has been enacted (0043-MKTL-011) + +1. A market is proposed and then suspended before it is enacted. +1. The market is resumed and should now be able to leave opening auction. diff --git a/protocol/features.json b/protocol/features.json index 345b29abc..5f4ed956d 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -374,6 +374,10 @@ "milestone": "colosseo", "acs": ["0083-RFPR-068"] }, + "Market suspended/resumed before enactment": { + "milestone": "colosseo", + "acs": ["0043-MKTL-011"] + }, "Unknown": { "milestone": "unknown", "acs": [] From 7e6b39da05cd9a047506f08121e689d877abb238 Mon Sep 17 00:00:00 2001 From: Sohill-Patel <85170301+Sohill-Patel@users.noreply.github.com> Date: Fri, 22 Mar 2024 22:28:18 +0000 Subject: [PATCH 1033/1171] fix: update ac description (#2222) --- protocol/0043-MKTL-market_lifecycle.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/protocol/0043-MKTL-market_lifecycle.md b/protocol/0043-MKTL-market_lifecycle.md index a41bb2f30..5bec4de59 100644 --- a/protocol/0043-MKTL-market_lifecycle.md +++ b/protocol/0043-MKTL-market_lifecycle.md @@ -368,5 +368,4 @@ After `market.liquidity.successorLaunchWindowLength` has passed since market set ### Market gets suspended and resumed before it has been enacted (0043-MKTL-011) -1. A market is proposed and then suspended before it is enacted. -1. The market is resumed and should now be able to leave opening auction. +1. A market cannot be suspended if the proposal to enact the market is open From d2fd548a01c6bc8ae917c82e978bb12be481740e Mon Sep 17 00:00:00 2001 From: Charlie Date: Fri, 22 Mar 2024 15:43:20 +0000 Subject: [PATCH 1034/1171] feat: update 0041-TSTK --- protocol/0041-TSTK-target_stake.md | 11 +++++++++-- 1 file changed, 9 insertions(+), 2 deletions(-) diff --git a/protocol/0041-TSTK-target_stake.md b/protocol/0041-TSTK-target_stake.md index bc7af1ea1..3229ec4b7 100644 --- a/protocol/0041-TSTK-target_stake.md +++ b/protocol/0041-TSTK-target_stake.md @@ -66,7 +66,7 @@ Example 3: if `market.stake.target.scalingFactor = 10`, `rf = 0.004` and `max_oi ## Target stake for spot markets -See [spot market spec](0080-SPOT-product_builtin_spot.md).3600s +See [spot market spec](0080-SPOT-product_builtin_spot.md). 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`. @@ -93,4 +93,11 @@ The above design ensures the `target_stake` of a market is unable to fluctuate d ### Acceptance criteria -Too be decided. +- For a spot market, given a `scaling_factor=1` and zero asset decimals. The target stake should be set to the maximum total supplied stake over the previous `time_window`. (0041-TSTK-XXX) +- For a spot market, given a `scaling_factor=1` and non-zero asset decimals. The target stake should be set to the maximum total supplied stake over the previous `time_window`. (0041-TSTK-XXX) +- For a spot market, given a `scaling_factor<1` The target stake should be set to the product of the `scaling_factor` and the maximum total supplied stake over the previous `time_window`. (0041-TSTK-XXX) +- For a spot market, given a LP increases their commitment, the target stake should increase to reflect that change. (0041-TSTK-XXX) +- For a spot market, given a LP decreases their commitment, the target stake will not decrease to reflect that change un till end of the epoch when the reduction is processed and the rolling time window no longer includes the total stake prior to the commitment change.(0041-TSTK-XXX) +- For a spot market, change of `market.stake.target.scalingFactor` will immediately change the target stake. (0041-TSTK-XXX) +- For a spot market, an increase of `time_window` will immediately change the length of time window over which total stake is measured however new records will not be added hence the target stake will not immediately change (0041-TSTK-XXX) +- For a spot market, a decrease of `time_window` will immediately change the length of time window over which the total stake is measured and old records will be dropped hence the target stake will immediately change (0041-TSTK-XXX) From 475cccd9b8877ec49dc268c206a6f436d497d966 Mon Sep 17 00:00:00 2001 From: Charlie Date: Fri, 22 Mar 2024 15:43:38 +0000 Subject: [PATCH 1035/1171] feat: update 0042-LIQF --- ...042-LIQF-setting_fees_and_rewarding_lps.md | 61 +++++++++++-------- 1 file changed, 35 insertions(+), 26 deletions(-) diff --git a/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md b/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md index 083a82c18..39a4324d3 100644 --- a/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md +++ b/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md @@ -345,20 +345,20 @@ Each LP further gets a performance bonus: $b_i \times B$ with a transfer type th ### CALCULATING LIQUIDITY FEE FACTOR TESTS - The examples provided result in the given outcomes (0042-LIQF-001) -- The resulting liquidity-fee-factor is always equal to one of the liquidity provider's individually nominated fee factors (0042-LIQF-002) +- The resulting liquidity-fee-factor is always equal to one of the liquidity provider's individually nominated fee factors (0042-LIQF-002) For product spot: (0042-LIQF-XXX). - The resulting liquidity-fee-factor is never less than zero (0042-LIQF-003) - Liquidity fee factors are recalculated every time a liquidity provider nominates a new fee factor (using the commit liquidity network transaction). (0042-LIQF-004) -- Liquidity fee factors are recalculated every time the liquidity demand estimate changes. (0042-LIQF-005) +- Liquidity fee factors are recalculated every time the liquidity demand estimate changes. (0042-LIQF-005). For product spot: (0042-LIQF-XXX). - 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) +- If passage of time causes the liquidity demand estimate to change, the fee factor is correctly recalculated. (0042-LIQF-007). For product spot: (0042-LIQF-XXX). - A market can be proposed with a choice of liquidity fee settings. These settings can be updated by a subsequent market update proposal. Moreover, the correct fee value and liquidity fee setting method can be read from the data node APIs. Upon proposal enactment the new liquidity method is applied to recalculate the liquidity fee. The tests should be carried out with the following methods: - - Weighted average (0042-LIQF-056) - - Constant fee (0042-LIQF-061) - - Marginal cost (0042-LIQF-062) -- The above example for the liquidity fee when the method is weighted-average results in a fee-factor of 1.5% (0042-LIQF-057) -- The above example for the liquidity fee when the method is constant-fee results in a fee-factor of 0.8% (0042-LIQF-058) -- The above example for the liquidity fee when the method is marginal cost results in a fee-factor of `3.75%` (0042-LIQF-059) -- For the constant-fee method validate that the fee factor can only be between 0 and 1 inclusive (0042-LIQF-060) + - Weighted average (0042-LIQF-056). For product spot: (0042-LIQF-XXX). + - Constant fee (0042-LIQF-061). For product spot: (0042-LIQF-XXX). + - Marginal cost (0042-LIQF-062). For product spot: (0042-LIQF-XXX). +- The above example for the liquidity fee when the method is weighted-average results in a fee-factor of 1.5% (0042-LIQF-057). For product spot: (0042-LIQF-XXX). +- The above example for the liquidity fee when the method is constant-fee results in a fee-factor of 0.8% (0042-LIQF-058). For product spot: (0042-LIQF-XXX). +- The above example for the liquidity fee when the method is marginal cost results in a fee-factor of `3.75%` (0042-LIQF-059). For product spot: (0042-LIQF-XXX). +- For the constant-fee method validate that the fee factor can only be between 0 and 1 inclusive (0042-LIQF-060). For product spot: (0042-LIQF-XXX). ### CHANGE OF NETWORK PARAMETERS TESTS @@ -380,14 +380,23 @@ Each LP further gets a performance bonus: $b_i \times B$ with a transfer type th ### 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) +- Given the fee setting method is marginal cost. An LP joining a spot market that is below the target stake with a higher fee bid than the current fee: their fee is used when the fee is next recalculated (0042-LIQF-XXX) - 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) +- Given the fee setting method is marginal cost. An LP joining a spot market that is below the target stake with a higher fee bid than the current fee: their fee is used when the fee is next recalculated (0042-LIQF-XXX) - 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) +- Given the fee setting method is marginal cost. An LP joining a spot 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 when the fee is next recalculated (0042-LIQF-XXX) - 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) +- Given the fee setting method is marginal cost. An LP joining a spot 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 when the fee is next recalculated (0042-LIQF-XXX) - 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) +- Given the fee setting method is marginal cost. An LP joining a spot 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 when the fee is next recalculated (0042-LIQF-XXX) - 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) +- Given the fee setting method is marginal cost. An LP joining a spot 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 when the fee is next recalculated (0042-LIQF-XXX) - 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) +- Given the fee setting method is marginal cost. 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 when the fee is next recalculated (0042-LIQF-XXX) - 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) +- Given the fee setting method is marginal cost. 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 when the fee is next recalculated (0042-LIQF-XXX) - 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) +- Given the fee setting method is marginal cost. 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 when the fee is next recalculated (0042-LIQF-XXX) - 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 @@ -412,36 +421,36 @@ 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, `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) + - Their liquidity is all provided at the start of the epoch and then none is provided for the second half (0042-LIQF-037). For spot (0042-LIQF-0XX) + - Their liquidity is provided scattered throughout the epoch (0042-LIQF-038). For spot (0042-LIQF-0XX) -- 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 = 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). For spot (0042-LIQF-0XX) +- 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). For spot (0042-LIQF-0XX) - 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) - - 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) + - 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). For spot (0042-LIQF-0XX) + - 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). For spot (0042-LIQF-0XX) + - 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). For spot (0042-LIQF-0XX) - 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) - - 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 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) + - 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). For spot (0042-LIQF-0XX) + - 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). For spot (0042-LIQF-0XX) + - 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). For spot (0042-LIQF-0XX) + - 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). For spot (0042-LIQF-0XX) ### SLA Performance bonus transfers -- 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) +- 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). For spot (0042-LIQF-0XX) +- 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). For spot (0042-LIQF-0XX) +- 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). For spot (0042-LIQF-0XX) +- 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). For spot (0042-LIQF-0XX) ### 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): +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). For spot (0042-LIQF-0XX): | LP | penalty fraction | LP-per-market fee accounts balance | 1st transfer amt | 2nd (bonus) transfer amt | | --- | -------------- | -------------- | -------------- | -------------- | | LP1 | 0 | 1000 | 1000 | 24673.94095 | From 9edc9431873b0aed9088e5d177d5fca9b342bc06 Mon Sep 17 00:00:00 2001 From: Charlie Date: Fri, 22 Mar 2024 15:43:49 +0000 Subject: [PATCH 1036/1171] feat: update 0044-LIME --- protocol/0044-LIME-lp_mechanics.md | 39 +++++++++++++++--------------- 1 file changed, 19 insertions(+), 20 deletions(-) diff --git a/protocol/0044-LIME-lp_mechanics.md b/protocol/0044-LIME-lp_mechanics.md index 9fcb3dcbf..85528674d 100644 --- a/protocol/0044-LIME-lp_mechanics.md +++ b/protocol/0044-LIME-lp_mechanics.md @@ -308,30 +308,29 @@ Note: - 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) -- 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` >= `market.liquidity.commitmentMinTimeFraction`, no penalty will be taken from their bond account (0044-LIME-013). For product spot (0044-LIME-0XX) - 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.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). For product spot (0044-LIME-0XX) +- 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). For product spot (0044-LIME-0XX) - 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) -- 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 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 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). For product spot (0044-LIME-0XX) +- 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). For product spot (0044-LIME-0XX) +- 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). For product spot (0044-LIME-0XX) +- 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). For product spot (0044-LIME-0XX) +- 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). For product spot (0044-LIME-0XX) - 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-049) + - 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). For product spot (0044-LIME-0XX) + - 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). For product spot (0044-LIME-0XX) -- 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) +- 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 product spot (0044-LIME-0XX) - 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 + 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) @@ -363,19 +362,19 @@ 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) -- 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) +- 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). For product spot (0044-LIME-0XX) -- 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) +- 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 product spot (0044-LIME-0XX) -- 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) +- 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 product spot (0044-LIME-0XX) -- 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) +- 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 product spot (0044-LIME-0XX) -- 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) +- 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 product spot (0044-LIME-0XX) -- 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) +- 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 product spot (0044-LIME-0XX) -- 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) +- 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). For product spot (0044-LIME-0XX) - 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 fcdd5545be339c924f5100862155f9f00efe008b Mon Sep 17 00:00:00 2001 From: Charlie Date: Fri, 22 Mar 2024 15:43:59 +0000 Subject: [PATCH 1037/1171] feat: update 0014-ORDT --- protocol/0014-ORDT-order_types.md | 89 +++++++++++++++++-------------- 1 file changed, 49 insertions(+), 40 deletions(-) diff --git a/protocol/0014-ORDT-order_types.md b/protocol/0014-ORDT-order_types.md index 82ce90845..6906a7665 100644 --- a/protocol/0014-ORDT-order_types.md +++ b/protocol/0014-ORDT-order_types.md @@ -75,7 +75,7 @@ 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. -- A stop order submission may have an optional `Size Override`: +- Providing the stop order is not being submitted to a Spot market, a stop order submission may have an optional `Size Override`: - If unset, the size within the contained normal order submission will be used - If set to `Position`, triggering should override the contained order's size with the trader's entire current position on the market. - The `Position` override configuration should also include the option `position_fraction` which determines what proportion of the position is closed when the stop order is triggered. At time of triggering the size of the order will be determined by $fraction \cdot position$. @@ -100,11 +100,13 @@ Therefore the trigger level of a stop order moves with the market allowing the t - Spam prevention: - - Stop orders will only be accepted from keys with either a non-zero open position or at least one active order. + - In markets which allow leverage. 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. + - In markets which allow leverage. If the trader's position size moves to zero exactly, and they have no open orders, all stop orders will be cancelled. + + - In spot markets, as their is no concept of a position, the trader will need to lock the funds required to execute the wrapped order in the holding account even before the stop order is triggered. Refer to section [spot trading](./0080-SPOT-product_builtin_spot.md#7-trading) for the calculation of the required funds. ### Iceberg / transparent iceberg orders @@ -338,66 +340,67 @@ In Spot market, for multiple iceberg orders submitted as a batch of orders with ### Stop orders -- Once triggered, a stop order is removed from the book and cannot be triggered again. (0014-ORDT-041) +- Once triggered, a stop order is removed from the book and cannot be triggered again. (0014-ORDT-041). For spot products (0014-ORDT-XXX) - 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) +- In a spot market, a stop order placed by a key with no position or open orders will be accepted. (0014-ORDT-XXX) +- 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). For spot products (0014-ORDT-XXX) -- 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) +- 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). For spot products (0014-ORDT-XXX) +- 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). For spot products (0014-ORDT-XXX) -- 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 `Rises Above` setting at 75 will be triggered by any trade at price 75 or higher. (0014-ORDT-047). For spot products (0014-ORDT-XXX) +- 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). For spot products (0014-ORDT-XXX) +- 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). For spot products (0014-ORDT-XXX) +- 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). For spot products (0014-ORDT-XXX) - 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) - - An OCO stop order with expiration time `T` with one side set to execute at that time will execute at time `T` if reached without being triggered, with the specified side triggering and the other side cancelling. This must be tested both sides (fall below and rise above). (0014-ORDT-131) - - An OCO stop order with expiration time `T` with both sides set to execute at that time will be rejected on submission (0014-ORDT-130) +- 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). For spot products (0014-ORDT-XXX) +- 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). For spot products (0014-ORDT-XXX) + - 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). For spot products (0014-ORDT-XXX) + - An OCO stop order with expiration time `T` with one side set to execute at that time will execute at time `T` if reached without being triggered, with the specified side triggering and the other side cancelling. This must be tested both sides (fall below and rise above). (0014-ORDT-131). For spot products (0014-ORDT-XXX) + - An OCO stop order with expiration time `T` with both sides set to execute at that time will be rejected on submission (0014-ORDT-130). For spot products (0014-ORDT-XXX) -- 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) +- 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). For spot products (0014-ORDT-XXX) +- If a pair of stop orders are specified as OCO, one being triggered also removes the other from the book. (0014-ORDT-056). For spot products (0014-ORDT-XXX) +- 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). For spot products (0014-ORDT-XXX) - 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) + - Be triggered by a fall to `57`. (0014-ORDT-059). For spot products (0014-ORDT-XXX) + - Not be triggered by a fall to `58`. (0014-ORDT-060). For spot products (0014-ORDT-XXX) - 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) + - Be triggered by a rise to `42`. (0014-ORDT-061). For spot products (0014-ORDT-XXX) + - Not be triggered by a rise to `41`. (0014-ORDT-062). For spot products (0014-ORDT-XXX) - 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) + - Be triggered by a fall to `45`. (0014-ORDT-063). For spot products (0014-ORDT-XXX) + - Not be triggered by a fall to `46`. (0014-ORDT-064). For spot products (0014-ORDT-XXX) -- A stop order placed during an auction will not execute during an auction, nor will it participate in the uncrossing. (0014-ORDT-065) -- A stop order placed during an auction, where the uncrossing price is within the triggering range, will immediately execute following uncrossing. (0014-ORDT-066) +- A stop order placed during an auction will not execute during an auction, nor will it participate in the uncrossing. (0014-ORDT-065). For spot products (0014-ORDT-XXX) +- A stop order placed during an auction, where the uncrossing price is within the triggering range, will immediately execute following uncrossing. (0014-ORDT-066). For spot products (0014-ORDT-XXX) -- A stop order placed prior to an auction will not execute during an auction, nor will it participate in the uncrossing. (0014-ORDT-134) -- A stop order placed prior to an auction, where the uncrossing price is within the triggering range, will immediately execute following uncrossing. (0014-ORDT-135) -- An order with a stop is placed during continuous trading. The market goes into auction. The market exits auction, the condition for triggering the stop is not met. The stop order is still present. (0014-ORDT-136) +- A stop order placed prior to an auction will not execute during an auction, nor will it participate in the uncrossing. (0014-ORDT-134). For spot products (0014-ORDT-XXX) +- A stop order placed prior to an auction, where the uncrossing price is within the triggering range, will immediately execute following uncrossing. (0014-ORDT-135). For spot products (0014-ORDT-XXX) +- An order with a stop is placed during continuous trading. The market goes into auction. The market exits auction, the condition for triggering the stop is not met. The stop order is still present. (0014-ORDT-136). For spot products (0014-ORDT-XXX) -- A party places a stop order on a market in continuous trading, the market moves to an auction and the party cancels the stop order. When the market exits the auction the party no longer has a stop order. (0014-ORDT-132) -- A stop order placed during the opening auction, will be rejected. (0014-ORDT-133) +- A party places a stop order on a market in continuous trading, the market moves to an auction and the party cancels the stop order. When the market exits the auction the party no longer has a stop order. (0014-ORDT-132). For spot products (0014-ORDT-XXX) +- A stop order placed during the opening auction, will be rejected. (0014-ORDT-133). For spot products (0014-ORDT-XXX) - 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) +- A Stop order that hasn't been triggered can be cancelled. (0014-ORDT-071). For spot products (0014-ORDT-XXX) +- All stop orders for a specific party can be cancelled by a single stop order cancellation. (0014-ORDT-072). For spot products (0014-ORDT-XXX) +- All stop orders for a specific party for a specific market can be cancelled by a single stop order cancellation. (0014-ORDT-073). For spot products (0014-ORDT-XXX) - If a stop order is placed with a position_fraction equal to 0.5 and the position size is 5 then the rounding should be equal to 3 (0014-ORDT-138) ## 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, 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 submitted with post_only=True are rejected. (0014-ORDT-074). For spot products (0014-ORDT-XXX) +- Stop orders submitted with invalid values for trigger price (0, negative values) and trailing percentage (0, negative values) are rejected. (0014-ORDT-075). For spot products (0014-ORDT-XXX) +- Stop orders submitted with expiry in the past are rejected. (0014-ORDT-076). For spot products (0014-ORDT-XXX) +- GFA Stop orders submitted are rejected. (0014-ORDT-077). For spot products (0014-ORDT-XXX) +- Stop orders once triggered can not be cancelled. (0014-ORDT-078). For spot products (0014-ORDT-XXX) - If a stop order is placed with a position_fraction equal to 0 the order should be rejected. (0014-ORDT-139) - A party with a long position cannot enter a buy stop order, and a party with a short position cannot enter a sell stop order (0014-ORDT-137) @@ -414,6 +417,7 @@ In Spot market, for multiple iceberg orders submitted as a batch of orders with - A stop order with a size override linked to the position of the trader will use the current position as an override of the triggered order size. (0014-ORDT-127) - All stop orders with a position size override should be cancelled if the trader's position flips sides (long->short or short->long). (0014-ORDT-128) - A stop order with a position size override with a position_fraction set to 0.75, for a trader with long position 20, should create a stop order for selling size 15 when triggered (0014-ORDT-129) +- Given a spot market, a stop order with a position size override will be rejected (0014-ORDT-XXX) ## Perpetuals @@ -423,6 +427,11 @@ In Spot market, for multiple iceberg orders submitted as a batch of orders with - Icebergs (0014-ORDT-122) - All stop order types (0014-ORDT-123) +## Spot + +- A trader submitting a stop order wrapping a buy limit order will have the funds required to execute that order locked in the relevant holding account for the quote asset. (0014-ORDT-XXX) +- A trader submitting a stop order wrapping a sell limit order will have the funds required to execute that order locked in the relevant holding account for the base asset (0014-ORDT-XXX) + ### See also - [0068-MATC-Matching engine](./0068-MATC-matching_engine.md) From a7f4bc991b67f40a1c8367b1277e42786783b49b Mon Sep 17 00:00:00 2001 From: Charlie Date: Fri, 22 Mar 2024 15:45:05 +0000 Subject: [PATCH 1038/1171] feat: update 0080-SPOT --- protocol/0080-SPOT-product_builtin_spot.md | 3 --- 1 file changed, 3 deletions(-) diff --git a/protocol/0080-SPOT-product_builtin_spot.md b/protocol/0080-SPOT-product_builtin_spot.md index a5e396362..b872f6892 100644 --- a/protocol/0080-SPOT-product_builtin_spot.md +++ b/protocol/0080-SPOT-product_builtin_spot.md @@ -76,9 +76,6 @@ See spec [0041-TSTK](./0041-TSTK-target_stake.md). 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`. From 05a9e6dfc4bdf1185c478f0152c55cebad7a4227 Mon Sep 17 00:00:00 2001 From: Charlie <99198652+cdummett@users.noreply.github.com> Date: Mon, 25 Mar 2024 15:01:30 +0000 Subject: [PATCH 1039/1171] feat: apply feedback from review Co-authored-by: Jiajia-Cui <92106936+Jiajia-Cui@users.noreply.github.com> --- protocol/0041-TSTK-target_stake.md | 2 +- protocol/0044-LIME-lp_mechanics.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 3229ec4b7..ed75b74c3 100644 --- a/protocol/0041-TSTK-target_stake.md +++ b/protocol/0041-TSTK-target_stake.md @@ -97,7 +97,7 @@ The above design ensures the `target_stake` of a market is unable to fluctuate d - For a spot market, given a `scaling_factor=1` and non-zero asset decimals. The target stake should be set to the maximum total supplied stake over the previous `time_window`. (0041-TSTK-XXX) - For a spot market, given a `scaling_factor<1` The target stake should be set to the product of the `scaling_factor` and the maximum total supplied stake over the previous `time_window`. (0041-TSTK-XXX) - For a spot market, given a LP increases their commitment, the target stake should increase to reflect that change. (0041-TSTK-XXX) -- For a spot market, given a LP decreases their commitment, the target stake will not decrease to reflect that change un till end of the epoch when the reduction is processed and the rolling time window no longer includes the total stake prior to the commitment change.(0041-TSTK-XXX) +- For a spot market, given a LP decreases their commitment, the target stake will not decrease to reflect that change until end of the epoch when the reduction is processed and the rolling time window no longer includes the total stake prior to the commitment change.(0041-TSTK-XXX) - For a spot market, change of `market.stake.target.scalingFactor` will immediately change the target stake. (0041-TSTK-XXX) - For a spot market, an increase of `time_window` will immediately change the length of time window over which total stake is measured however new records will not be added hence the target stake will not immediately change (0041-TSTK-XXX) - For a spot market, a decrease of `time_window` will immediately change the length of time window over which the total stake is measured and old records will be dropped hence the target stake will immediately change (0041-TSTK-XXX) diff --git a/protocol/0044-LIME-lp_mechanics.md b/protocol/0044-LIME-lp_mechanics.md index 85528674d..42bbf8657 100644 --- a/protocol/0044-LIME-lp_mechanics.md +++ b/protocol/0044-LIME-lp_mechanics.md @@ -322,7 +322,7 @@ and in the case of spot markets into the network treasury for the asset (0044-LIME-019). For product spot (0044-LIME-0XX) - 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). For product spot (0044-LIME-0XX) - 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). For product spot (0044-LIME-0XX) -- 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). For product spot (0044-LIME-0XX) +- 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). For product spot (0044-LIME-0XX) - 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). For product spot (0044-LIME-0XX) - 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). For product spot (0044-LIME-0XX) From a54eef3fa24480582a6ff544f50872e20efeaeb1 Mon Sep 17 00:00:00 2001 From: David Siska <62546419+davidsiska-vega@users.noreply.github.com> Date: Mon, 25 Mar 2024 16:23:24 +0000 Subject: [PATCH 1040/1171] Feat/liq strat range (#2218) * feat: liquidation explicit range * feat: liquidation explicit range * feat: liquidation explicit range * feat: liquidation explicit range * feat: liquidation explicit range * feat: liquidation explicit range * fix: witold's correction Co-authored-by: Witold * fix: include price mon into disc --------- Co-authored-by: Witold --- protocol/0012-POSR-position_resolution.md | 15 +++++++++++---- protocol/features.json | 8 ++++++++ protocol/palazzo-features.json | 2 -- wordlist.txt | 2 ++ 4 files changed, 21 insertions(+), 6 deletions(-) diff --git a/protocol/0012-POSR-position_resolution.md b/protocol/0012-POSR-position_resolution.md index ab70da7c0..009e1699d 100644 --- a/protocol/0012-POSR-position_resolution.md +++ b/protocol/0012-POSR-position_resolution.md @@ -31,15 +31,16 @@ - When calculating the available volume, the full remaining size of iceberg orders should be considered. (0012-POSR-019) - When calculating the available volume, volume outside price monitoring bounds should be considered. (0012-POSR-020) -- When calculating the available volume, volume outside the liquidity price range should not be considered. (0012-POSR-021) +- When calculating the available volume, volume outside the disposal price range should not be considered. (0012-POSR-033) - Given a highly liquid market, if the network’s position is greater than `full disposal size`. The network must attempt to dispose `position * disposal fraction` at the next disposal step. (0012-POSR-022) - Given a highly liquid market, if the network’s position is less than or equal to `full disposal size`. The network must attempt to dispose of its full position at the next disposal step. (0012-POSR-023) - Given a highly liquid market, if the network’s `disposal fraction<1` and `full disposal size`=0, the network must still eventually dispose of its full position. (0012-POSR-024) - The network must never dispose more than `available volume * max fraction of book side within liquidity bounds consumed` in a single order. (0012-POSR-025) - A network disposal order which generates trades must not affect the mark price. (0012-POSR-026) -- A network disposal order can not cross with orders outside the liquidity price range. (0012-POSR-027) +- A network disposal order can not cross with orders outside the disposal price range. (0012-POSR-031) - A network disposal order will not cross with orders outside price monitoring bounds (internally has to behave like an IOC at one tick inside the price monitoring bound). Hence a network disposal cannot trade at a price outside the tightest price monitoring and it won't ever trigger a price monitoring auction. (0012-POSR-030) - A network disposal order which crosses multiple orders should generate multiple atomic trades. (0012-POSR-029) +- A network disposal order which crosses with volume implied by an vAMM should trade with the vAMM volume. (0012-POSR-032) ### Network Profit and Loss @@ -110,15 +111,21 @@ Currently only one liquidation strategy is supported and its defined by the foll - `disposal time step` (min: `1s`, max: `1h`): network attempts to unload its position in a given market every time it goes out of auction and then every `disposal time step` seconds as long as market is not in auction mode and while the network's position is not equal to `0`, - `disposal fraction` (min: `0.01`, max: `1`): fraction of network's current open volume that it will try to reduce in a single disposal attempt, - `full disposal size` (min: `0`, max: `max int`): once net absolute value of network's open volume is at or below that value, the network will attempt to dispose the remaining amount in one go, -- `max fraction of book side within liquidity bounds consumed` (min: `0`, max: `1`): once the network chooses the size of its order (`s_candidate`) the effective size will be calculated as `s_effective=min(m*N, s_candidate)`, where `N` is the sum of volume (on the side of the book with which the network's order will be matching) that falls within the range implied by the `market.liquidity.priceRange` [parameter](./0044-LIME-lp_mechanics.md#market-parameters) and `m` is the `max fraction of book side within liquidity bounds consumed`. +- `disposal slippage range` (decimal `>0` with default of `0.1` which is interpreted as `10%`, existing markets to default to their current SLA range). Just like [SLA range](./0044-LIME-lp_mechanics.md) these are taken from `mid_price` during continuous trading or indicative uncrossing price during auctions so the lower bound becomes `max(0,price x (1-range)` and upper bound `price x (1+range)`. +- `max fraction of book side within bounds consumed` (min: `0`, max: `1`): once the network chooses the size of its order (`s_candidate`) the effective size will be calculated as `s_effective=min(m*N, s_candidate)`, where `N` is the sum of volume (on the side of the book with which the network's order will be matching) that falls within the range implied by the `disposal slippage range` and `m` is the `max fraction of book side within liquidity bounds consumed`. +When vAMMs are implemented and provide liquidity then volume implied by vAMMs that lies within the relevant range must be included in the calculation. + +Assume the price range implied by the `disposal slippage range` is `[a, b]`. +Assume the the tightest price monitoring bound has lower bound plus one tick of `c` and upper bound minus one tick of `d`. +Once the network has worked out a size of its immediate or cancel limit order it sets its price to `max(a,c)` if it's a sell order or `min(b,d)` if it's a buy order, and it submits the order. -Assume the price range implied by the `market.liquidity.priceRange` is `[a, b]`. Once the network has worked out a size of its immediate or cancel limit order it sets it's price to `a` if it's a sell order or `b` if it's a buy order, and it submits the order. Note that setting: - `disposal time step` = `0s`, - `disposal fraction` = `1`, - `full disposal size` = `max int`, +- `disposal slippage range` = `10`, - `max fraction of book side within liquidity bounds consumed` = `1` is closest to reproducing the legacy setup where party would get liquidated immediately (with a difference that closeout now happens immediately even if there's not enough volume on the book to fully absorb it) hence the above values should be used when migrating existing markets to a new version. For all new markets these values should be specified explicitly. diff --git a/protocol/features.json b/protocol/features.json index 5f4ed956d..dbbb2a62c 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -370,6 +370,14 @@ "0003-NP-LIMI-007" ] }, + "Explicit liquidation range": { + "milestone": "colosseo", + "acs": [ + "0012-POSR-031", + "0012-POSR-032", + "0012-POSR-033" + ] + }, "Teams": { "milestone": "colosseo", "acs": ["0083-RFPR-068"] diff --git a/protocol/palazzo-features.json b/protocol/palazzo-features.json index 2e4a17cd8..0f704e3cd 100644 --- a/protocol/palazzo-features.json +++ b/protocol/palazzo-features.json @@ -235,13 +235,11 @@ "0012-POSR-018", "0012-POSR-019", "0012-POSR-020", - "0012-POSR-021", "0012-POSR-022", "0012-POSR-023", "0012-POSR-024", "0012-POSR-025", "0012-POSR-026", - "0012-POSR-027", "0012-POSR-029", "0003-MTMK-015", "0003-MTMK-016", diff --git a/wordlist.txt b/wordlist.txt index 8001e5979..81a3aab42 100644 --- a/wordlist.txt +++ b/wordlist.txt @@ -317,6 +317,8 @@ UTC validator validator's validators +vAMM +vAMMs vega vegaprotocol vegatools From cde80691d92aeb9aafcf5c33e12c12ccc41fb751 Mon Sep 17 00:00:00 2001 From: gordsport Date: Mon, 25 Mar 2024 17:06:01 +0000 Subject: [PATCH 1041/1171] chore: add AC codes --- protocol/0014-ORDT-order_types.md | 82 +++++----- protocol/0041-TSTK-target_stake.md | 16 +- ...042-LIQF-setting_fees_and_rewarding_lps.md | 70 ++++---- protocol/0044-LIME-lp_mechanics.md | 36 ++--- protocol/features.json | 152 +++++++++++++++++- 5 files changed, 253 insertions(+), 103 deletions(-) diff --git a/protocol/0014-ORDT-order_types.md b/protocol/0014-ORDT-order_types.md index 6906a7665..5d62b07f6 100644 --- a/protocol/0014-ORDT-order_types.md +++ b/protocol/0014-ORDT-order_types.md @@ -340,67 +340,67 @@ In Spot market, for multiple iceberg orders submitted as a batch of orders with ### Stop orders -- Once triggered, a stop order is removed from the book and cannot be triggered again. (0014-ORDT-041). For spot products (0014-ORDT-XXX) +- Once triggered, a stop order is removed from the book and cannot be triggered again. (0014-ORDT-041). For spot products (0014-ORDT-124) - 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) -- In a spot market, a stop order placed by a key with no position or open orders will be accepted. (0014-ORDT-XXX) -- 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). For spot products (0014-ORDT-XXX) +- In a spot market, a stop order placed by a key with no position or open orders will be accepted. (0014-ORDT-125) +- 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). For spot products (0014-ORDT-126) -- 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). For spot products (0014-ORDT-XXX) -- 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). For spot products (0014-ORDT-XXX) +- 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). For spot products (0014-ORDT-127) +- 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). For spot products (0014-ORDT-128) -- 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). For spot products (0014-ORDT-XXX) -- 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). For spot products (0014-ORDT-XXX) -- 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). For spot products (0014-ORDT-XXX) -- 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). For spot products (0014-ORDT-XXX) +- 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). For spot products (0014-ORDT-129) +- 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). For spot products (0014-ORDT-130) +- 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). For spot products (0014-ORDT-131) +- 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). For spot products (0014-ORDT-132) - 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). For spot products (0014-ORDT-XXX) -- 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). For spot products (0014-ORDT-XXX) - - 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). For spot products (0014-ORDT-XXX) - - An OCO stop order with expiration time `T` with one side set to execute at that time will execute at time `T` if reached without being triggered, with the specified side triggering and the other side cancelling. This must be tested both sides (fall below and rise above). (0014-ORDT-131). For spot products (0014-ORDT-XXX) - - An OCO stop order with expiration time `T` with both sides set to execute at that time will be rejected on submission (0014-ORDT-130). For spot products (0014-ORDT-XXX) +- 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). For spot products (0014-ORDT-133) +- 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). For spot products (0014-ORDT-134) + - 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). For spot products (0014-ORDT-135) + - An OCO stop order with expiration time `T` with one side set to execute at that time will execute at time `T` if reached without being triggered, with the specified side triggering and the other side cancelling. This must be tested both sides (fall below and rise above). (0014-ORDT-131). For spot products (0014-ORDT-136) + - An OCO stop order with expiration time `T` with both sides set to execute at that time will be rejected on submission (0014-ORDT-130). For spot products (0014-ORDT-137) -- 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). For spot products (0014-ORDT-XXX) -- If a pair of stop orders are specified as OCO, one being triggered also removes the other from the book. (0014-ORDT-056). For spot products (0014-ORDT-XXX) -- 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). For spot products (0014-ORDT-XXX) +- 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). For spot products (0014-ORDT-138) +- If a pair of stop orders are specified as OCO, one being triggered also removes the other from the book. (0014-ORDT-056). For spot products (0014-ORDT-139) +- 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). For spot products (0014-ORDT-140) - 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). For spot products (0014-ORDT-XXX) - - Not be triggered by a fall to `58`. (0014-ORDT-060). For spot products (0014-ORDT-XXX) + - Be triggered by a fall to `57`. (0014-ORDT-059). For spot products (0014-ORDT-141) + - Not be triggered by a fall to `58`. (0014-ORDT-060). For spot products (0014-ORDT-142) - 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). For spot products (0014-ORDT-XXX) - - Not be triggered by a rise to `41`. (0014-ORDT-062). For spot products (0014-ORDT-XXX) + - Be triggered by a rise to `42`. (0014-ORDT-061). For spot products (0014-ORDT-143) + - Not be triggered by a rise to `41`. (0014-ORDT-062). For spot products (0014-ORDT-144) - 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). For spot products (0014-ORDT-XXX) - - Not be triggered by a fall to `46`. (0014-ORDT-064). For spot products (0014-ORDT-XXX) + - Be triggered by a fall to `45`. (0014-ORDT-063). For spot products (0014-ORDT-145) + - Not be triggered by a fall to `46`. (0014-ORDT-064). For spot products (0014-ORDT-146) -- A stop order placed during an auction will not execute during an auction, nor will it participate in the uncrossing. (0014-ORDT-065). For spot products (0014-ORDT-XXX) -- A stop order placed during an auction, where the uncrossing price is within the triggering range, will immediately execute following uncrossing. (0014-ORDT-066). For spot products (0014-ORDT-XXX) +- A stop order placed during an auction will not execute during an auction, nor will it participate in the uncrossing. (0014-ORDT-065). For spot products (0014-ORDT-147) +- A stop order placed during an auction, where the uncrossing price is within the triggering range, will immediately execute following uncrossing. (0014-ORDT-066). For spot products (0014-ORDT-148) -- A stop order placed prior to an auction will not execute during an auction, nor will it participate in the uncrossing. (0014-ORDT-134). For spot products (0014-ORDT-XXX) -- A stop order placed prior to an auction, where the uncrossing price is within the triggering range, will immediately execute following uncrossing. (0014-ORDT-135). For spot products (0014-ORDT-XXX) -- An order with a stop is placed during continuous trading. The market goes into auction. The market exits auction, the condition for triggering the stop is not met. The stop order is still present. (0014-ORDT-136). For spot products (0014-ORDT-XXX) +- A stop order placed prior to an auction will not execute during an auction, nor will it participate in the uncrossing. (0014-ORDT-134). For spot products (0014-ORDT-149) +- A stop order placed prior to an auction, where the uncrossing price is within the triggering range, will immediately execute following uncrossing. (0014-ORDT-135). For spot products (0014-ORDT-150) +- An order with a stop is placed during continuous trading. The market goes into auction. The market exits auction, the condition for triggering the stop is not met. The stop order is still present. (0014-ORDT-136). For spot products (0014-ORDT-151) -- A party places a stop order on a market in continuous trading, the market moves to an auction and the party cancels the stop order. When the market exits the auction the party no longer has a stop order. (0014-ORDT-132). For spot products (0014-ORDT-XXX) -- A stop order placed during the opening auction, will be rejected. (0014-ORDT-133). For spot products (0014-ORDT-XXX) +- A party places a stop order on a market in continuous trading, the market moves to an auction and the party cancels the stop order. When the market exits the auction the party no longer has a stop order. (0014-ORDT-132). For spot products (0014-ORDT-152) +- A stop order placed during the opening auction, will be rejected. (0014-ORDT-133). For spot products (0014-ORDT-153) - 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). For spot products (0014-ORDT-XXX) -- All stop orders for a specific party can be cancelled by a single stop order cancellation. (0014-ORDT-072). For spot products (0014-ORDT-XXX) -- All stop orders for a specific party for a specific market can be cancelled by a single stop order cancellation. (0014-ORDT-073). For spot products (0014-ORDT-XXX) +- A Stop order that hasn't been triggered can be cancelled. (0014-ORDT-071). For spot products (0014-ORDT-154) +- All stop orders for a specific party can be cancelled by a single stop order cancellation. (0014-ORDT-072). For spot products (0014-ORDT-155) +- All stop orders for a specific party for a specific market can be cancelled by a single stop order cancellation. (0014-ORDT-073). For spot products (0014-ORDT-156) - If a stop order is placed with a position_fraction equal to 0.5 and the position size is 5 then the rounding should be equal to 3 (0014-ORDT-138) ## Stop Orders - Negative Cases -- Stop orders submitted with post_only=True are rejected. (0014-ORDT-074). For spot products (0014-ORDT-XXX) -- Stop orders submitted with invalid values for trigger price (0, negative values) and trailing percentage (0, negative values) are rejected. (0014-ORDT-075). For spot products (0014-ORDT-XXX) -- Stop orders submitted with expiry in the past are rejected. (0014-ORDT-076). For spot products (0014-ORDT-XXX) -- GFA Stop orders submitted are rejected. (0014-ORDT-077). For spot products (0014-ORDT-XXX) -- Stop orders once triggered can not be cancelled. (0014-ORDT-078). For spot products (0014-ORDT-XXX) +- Stop orders submitted with post_only=True are rejected. (0014-ORDT-074). For spot products (0014-ORDT-157) +- Stop orders submitted with invalid values for trigger price (0, negative values) and trailing percentage (0, negative values) are rejected. (0014-ORDT-075). For spot products (0014-ORDT-158) +- Stop orders submitted with expiry in the past are rejected. (0014-ORDT-076). For spot products (0014-ORDT-159) +- GFA Stop orders submitted are rejected. (0014-ORDT-077). For spot products (0014-ORDT-160) +- Stop orders once triggered can not be cancelled. (0014-ORDT-078). For spot products (0014-ORDT-161) - If a stop order is placed with a position_fraction equal to 0 the order should be rejected. (0014-ORDT-139) - A party with a long position cannot enter a buy stop order, and a party with a short position cannot enter a sell stop order (0014-ORDT-137) @@ -417,7 +417,7 @@ In Spot market, for multiple iceberg orders submitted as a batch of orders with - A stop order with a size override linked to the position of the trader will use the current position as an override of the triggered order size. (0014-ORDT-127) - All stop orders with a position size override should be cancelled if the trader's position flips sides (long->short or short->long). (0014-ORDT-128) - A stop order with a position size override with a position_fraction set to 0.75, for a trader with long position 20, should create a stop order for selling size 15 when triggered (0014-ORDT-129) -- Given a spot market, a stop order with a position size override will be rejected (0014-ORDT-XXX) +- Given a spot market, a stop order with a position size override will be rejected (0014-ORDT-162) ## Perpetuals @@ -429,8 +429,8 @@ In Spot market, for multiple iceberg orders submitted as a batch of orders with ## Spot -- A trader submitting a stop order wrapping a buy limit order will have the funds required to execute that order locked in the relevant holding account for the quote asset. (0014-ORDT-XXX) -- A trader submitting a stop order wrapping a sell limit order will have the funds required to execute that order locked in the relevant holding account for the base asset (0014-ORDT-XXX) +- A trader submitting a stop order wrapping a buy limit order will have the funds required to execute that order locked in the relevant holding account for the quote asset. (0014-ORDT-163) +- A trader submitting a stop order wrapping a sell limit order will have the funds required to execute that order locked in the relevant holding account for the base asset (0014-ORDT-164) ### See also diff --git a/protocol/0041-TSTK-target_stake.md b/protocol/0041-TSTK-target_stake.md index ed75b74c3..c7a5e6c1f 100644 --- a/protocol/0041-TSTK-target_stake.md +++ b/protocol/0041-TSTK-target_stake.md @@ -93,11 +93,11 @@ The above design ensures the `target_stake` of a market is unable to fluctuate d ### Acceptance criteria -- For a spot market, given a `scaling_factor=1` and zero asset decimals. The target stake should be set to the maximum total supplied stake over the previous `time_window`. (0041-TSTK-XXX) -- For a spot market, given a `scaling_factor=1` and non-zero asset decimals. The target stake should be set to the maximum total supplied stake over the previous `time_window`. (0041-TSTK-XXX) -- For a spot market, given a `scaling_factor<1` The target stake should be set to the product of the `scaling_factor` and the maximum total supplied stake over the previous `time_window`. (0041-TSTK-XXX) -- For a spot market, given a LP increases their commitment, the target stake should increase to reflect that change. (0041-TSTK-XXX) -- For a spot market, given a LP decreases their commitment, the target stake will not decrease to reflect that change until end of the epoch when the reduction is processed and the rolling time window no longer includes the total stake prior to the commitment change.(0041-TSTK-XXX) -- For a spot market, change of `market.stake.target.scalingFactor` will immediately change the target stake. (0041-TSTK-XXX) -- For a spot market, an increase of `time_window` will immediately change the length of time window over which total stake is measured however new records will not be added hence the target stake will not immediately change (0041-TSTK-XXX) -- For a spot market, a decrease of `time_window` will immediately change the length of time window over which the total stake is measured and old records will be dropped hence the target stake will immediately change (0041-TSTK-XXX) +- For a spot market, given a `scaling_factor=1` and zero asset decimals. The target stake should be set to the maximum total supplied stake over the previous `time_window`. (0041-TSTK-106) +- For a spot market, given a `scaling_factor=1` and non-zero asset decimals. The target stake should be set to the maximum total supplied stake over the previous `time_window`. (0041-TSTK-107) +- For a spot market, given a `scaling_factor<1` The target stake should be set to the product of the `scaling_factor` and the maximum total supplied stake over the previous `time_window`. (0041-TSTK-108) +- For a spot market, given a LP increases their commitment, the target stake should increase to reflect that change. (0041-TSTK-109) +- For a spot market, given a LP decreases their commitment, the target stake will not decrease to reflect that change until end of the epoch when the reduction is processed and the rolling time window no longer includes the total stake prior to the commitment change.(0041-TSTK-110) +- For a spot market, change of `market.stake.target.scalingFactor` will immediately change the target stake. (0041-TSTK-111) +- For a spot market, an increase of `time_window` will immediately change the length of time window over which total stake is measured however new records will not be added hence the target stake will not immediately change (0041-TSTK-112) +- For a spot market, a decrease of `time_window` will immediately change the length of time window over which the total stake is measured and old records will be dropped hence the target stake will immediately change (0041-TSTK-113) diff --git a/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md b/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md index 39a4324d3..2eeb281b9 100644 --- a/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md +++ b/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md @@ -345,20 +345,20 @@ Each LP further gets a performance bonus: $b_i \times B$ with a transfer type th ### CALCULATING LIQUIDITY FEE FACTOR TESTS - The examples provided result in the given outcomes (0042-LIQF-001) -- The resulting liquidity-fee-factor is always equal to one of the liquidity provider's individually nominated fee factors (0042-LIQF-002) For product spot: (0042-LIQF-XXX). +- The resulting liquidity-fee-factor is always equal to one of the liquidity provider's individually nominated fee factors (0042-LIQF-002) For product spot: (0042-LIQF-063). - The resulting liquidity-fee-factor is never less than zero (0042-LIQF-003) - Liquidity fee factors are recalculated every time a liquidity provider nominates a new fee factor (using the commit liquidity network transaction). (0042-LIQF-004) -- Liquidity fee factors are recalculated every time the liquidity demand estimate changes. (0042-LIQF-005). For product spot: (0042-LIQF-XXX). +- Liquidity fee factors are recalculated every time the liquidity demand estimate changes. (0042-LIQF-005). For product spot: (0042-LIQF-064). - 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). For product spot: (0042-LIQF-XXX). +- If passage of time causes the liquidity demand estimate to change, the fee factor is correctly recalculated. (0042-LIQF-007). For product spot: (0042-LIQF-065). - A market can be proposed with a choice of liquidity fee settings. These settings can be updated by a subsequent market update proposal. Moreover, the correct fee value and liquidity fee setting method can be read from the data node APIs. Upon proposal enactment the new liquidity method is applied to recalculate the liquidity fee. The tests should be carried out with the following methods: - - Weighted average (0042-LIQF-056). For product spot: (0042-LIQF-XXX). - - Constant fee (0042-LIQF-061). For product spot: (0042-LIQF-XXX). - - Marginal cost (0042-LIQF-062). For product spot: (0042-LIQF-XXX). -- The above example for the liquidity fee when the method is weighted-average results in a fee-factor of 1.5% (0042-LIQF-057). For product spot: (0042-LIQF-XXX). -- The above example for the liquidity fee when the method is constant-fee results in a fee-factor of 0.8% (0042-LIQF-058). For product spot: (0042-LIQF-XXX). -- The above example for the liquidity fee when the method is marginal cost results in a fee-factor of `3.75%` (0042-LIQF-059). For product spot: (0042-LIQF-XXX). -- For the constant-fee method validate that the fee factor can only be between 0 and 1 inclusive (0042-LIQF-060). For product spot: (0042-LIQF-XXX). + - Weighted average (0042-LIQF-056). For product spot: (0042-LIQF-066). + - Constant fee (0042-LIQF-061). For product spot: (0042-LIQF-067). + - Marginal cost (0042-LIQF-062). For product spot: (0042-LIQF-068). +- The above example for the liquidity fee when the method is weighted-average results in a fee-factor of 1.5% (0042-LIQF-057). For product spot: (0042-LIQF-069). +- The above example for the liquidity fee when the method is constant-fee results in a fee-factor of 0.8% (0042-LIQF-058). For product spot: (0042-LIQF-070). +- The above example for the liquidity fee when the method is marginal cost results in a fee-factor of `3.75%` (0042-LIQF-059). For product spot: (0042-LIQF-071). +- For the constant-fee method validate that the fee factor can only be between 0 and 1 inclusive (0042-LIQF-060). For product spot: (0042-LIQF-072). ### CHANGE OF NETWORK PARAMETERS TESTS @@ -380,23 +380,23 @@ Each LP further gets a performance bonus: $b_i \times B$ with a transfer type th ### 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) -- Given the fee setting method is marginal cost. An LP joining a spot market that is below the target stake with a higher fee bid than the current fee: their fee is used when the fee is next recalculated (0042-LIQF-XXX) +- Given the fee setting method is marginal cost. An LP joining a spot market that is below the target stake with a higher fee bid than the current fee: their fee is used when the fee is next recalculated (0042-LIQF-073) - 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) -- Given the fee setting method is marginal cost. An LP joining a spot market that is below the target stake with a higher fee bid than the current fee: their fee is used when the fee is next recalculated (0042-LIQF-XXX) +- Given the fee setting method is marginal cost. An LP joining a spot market that is below the target stake with a higher fee bid than the current fee: their fee is used when the fee is next recalculated (0042-LIQF-074) - 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) -- Given the fee setting method is marginal cost. An LP joining a spot 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 when the fee is next recalculated (0042-LIQF-XXX) +- Given the fee setting method is marginal cost. An LP joining a spot 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 when the fee is next recalculated (0042-LIQF-075) - 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) -- Given the fee setting method is marginal cost. An LP joining a spot 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 when the fee is next recalculated (0042-LIQF-XXX) +- Given the fee setting method is marginal cost. An LP joining a spot 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 when the fee is next recalculated (0042-LIQF-076) - 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) -- Given the fee setting method is marginal cost. An LP joining a spot 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 when the fee is next recalculated (0042-LIQF-XXX) +- Given the fee setting method is marginal cost. An LP joining a spot 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 when the fee is next recalculated (0042-LIQF-077) - 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) -- Given the fee setting method is marginal cost. An LP joining a spot 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 when the fee is next recalculated (0042-LIQF-XXX) +- Given the fee setting method is marginal cost. An LP joining a spot 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 when the fee is next recalculated (0042-LIQF-078) - 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) -- Given the fee setting method is marginal cost. 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 when the fee is next recalculated (0042-LIQF-XXX) +- Given the fee setting method is marginal cost. 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 when the fee is next recalculated (0042-LIQF-079) - 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) -- Given the fee setting method is marginal cost. 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 when the fee is next recalculated (0042-LIQF-XXX) +- Given the fee setting method is marginal cost. 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 when the fee is next recalculated (0042-LIQF-080) - 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) -- Given the fee setting method is marginal cost. 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 when the fee is next recalculated (0042-LIQF-XXX) +- Given the fee setting method is marginal cost. 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 when the fee is next recalculated (0042-LIQF-081) - 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 @@ -421,36 +421,36 @@ 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, `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). For spot (0042-LIQF-0XX) - - Their liquidity is provided scattered throughout the epoch (0042-LIQF-038). For spot (0042-LIQF-0XX) + - Their liquidity is all provided at the start of the epoch and then none is provided for the second half (0042-LIQF-037). For spot (0042-LIQF-082) + - Their liquidity is provided scattered throughout the epoch (0042-LIQF-038). For spot (0042-LIQF-083) -- 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). For spot (0042-LIQF-0XX) -- 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). For spot (0042-LIQF-0XX) +- 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). For spot (0042-LIQF-084) +- 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). For spot (0042-LIQF-085) - 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). For spot (0042-LIQF-0XX) - - 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). For spot (0042-LIQF-0XX) - - 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). For spot (0042-LIQF-0XX) + - 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). For spot (0042-LIQF-086) + - 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). For spot (0042-LIQF-087) + - 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). For spot (0042-LIQF-088) - 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). For spot (0042-LIQF-0XX) - - 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). For spot (0042-LIQF-0XX) - - 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). For spot (0042-LIQF-0XX) - - 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). For spot (0042-LIQF-0XX) + - 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). For spot (0042-LIQF-089) + - 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). For spot (0042-LIQF-090) + - 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). For spot (0042-LIQF-090) + - 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). For spot (0042-LIQF-100) ### SLA Performance bonus transfers -- 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). For spot (0042-LIQF-0XX) -- 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). For spot (0042-LIQF-0XX) -- 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). For spot (0042-LIQF-0XX) -- 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). For spot (0042-LIQF-0XX) +- 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). For spot (0042-LIQF-101) +- 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). For spot (0042-LIQF-102) +- 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). For spot (0042-LIQF-103) +- 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). For spot (0042-LIQF-104) ### 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). For spot (0042-LIQF-0XX): +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). For spot (0042-LIQF-105): | LP | penalty fraction | LP-per-market fee accounts balance | 1st transfer amt | 2nd (bonus) transfer amt | | --- | -------------- | -------------- | -------------- | -------------- | | LP1 | 0 | 1000 | 1000 | 24673.94095 | diff --git a/protocol/0044-LIME-lp_mechanics.md b/protocol/0044-LIME-lp_mechanics.md index 42bbf8657..c15e37753 100644 --- a/protocol/0044-LIME-lp_mechanics.md +++ b/protocol/0044-LIME-lp_mechanics.md @@ -308,26 +308,26 @@ Note: - 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) -- 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). For product spot (0044-LIME-0XX) +- 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). For product spot (0044-LIME-102) - 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). For product spot (0044-LIME-0XX) -- 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). For product spot (0044-LIME-0XX) +- 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). For product spot (0044-LIME-103) +- 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). For product spot (0044-LIME-104) - 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). For product spot (0044-LIME-0XX) -- 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). For product spot (0044-LIME-0XX) -- 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). For product spot (0044-LIME-0XX) -- 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). For product spot (0044-LIME-0XX) -- 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). For product spot (0044-LIME-0XX) +- 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). For product spot (0044-LIME-105) +- 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). For product spot (0044-LIME-106) +- 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). For product spot (0044-LIME-107) +- 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). For product spot (0044-LIME-108) +- 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). For product spot (0044-LIME-109) - 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). For product spot (0044-LIME-0XX) - - 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). For product spot (0044-LIME-0XX) + - 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). For product spot (0044-LIME-110) + - 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). For product spot (0044-LIME-111) -- 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 product spot (0044-LIME-0XX) +- 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 product spot (0044-LIME-112) - 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) @@ -362,19 +362,19 @@ 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) -- 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). For product spot (0044-LIME-0XX) +- 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). For product spot (0044-LIME-113) -- 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 product spot (0044-LIME-0XX) +- 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 product spot (0044-LIME-114) -- 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 product spot (0044-LIME-0XX) +- 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 product spot (0044-LIME-115) -- 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 product spot (0044-LIME-0XX) +- 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 product spot (0044-LIME-116) -- 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 product spot (0044-LIME-0XX) +- 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 product spot (0044-LIME-117) -- 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 product spot (0044-LIME-0XX) +- 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 product spot (0044-LIME-118) -- 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). For product spot (0044-LIME-0XX) +- 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). For product spot (0044-LIME-119) - 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) diff --git a/protocol/features.json b/protocol/features.json index 5f4ed956d..3245fd0bd 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -243,7 +243,76 @@ "0068-MATC-089", "0068-MATC-090", "0068-MATC-091", - "0068-MATC-092" + "0068-MATC-092", + "0041-TSTK-106", + "0041-TSTK-107", + "0041-TSTK-108", + "0041-TSTK-109", + "0041-TSTK-110", + "0041-TSTK-111", + "0041-TSTK-112", + "0041-TSTK-113", + "0042-LIQF-063", + "0042-LIQF-064", + "0042-LIQF-065", + "0042-LIQF-066", + "0042-LIQF-067", + "0042-LIQF-068", + "0042-LIQF-069", + "0042-LIQF-070", + "0042-LIQF-071", + "0042-LIQF-072", + "0042-LIQF-073", + "0042-LIQF-074", + "0042-LIQF-075", + "0042-LIQF-076", + "0042-LIQF-077", + "0042-LIQF-078", + "0042-LIQF-079", + "0042-LIQF-080", + "0042-LIQF-081", + "0042-LIQF-082", + "0042-LIQF-083", + "0042-LIQF-084", + "0042-LIQF-085", + "0042-LIQF-086", + "0042-LIQF-087", + "0042-LIQF-088", + "0042-LIQF-089", + "0042-LIQF-090", + "0042-LIQF-091", + "0042-LIQF-092", + "0042-LIQF-093", + "0042-LIQF-094", + "0042-LIQF-095", + "0042-LIQF-096", + "0042-LIQF-097", + "0042-LIQF-098", + "0042-LIQF-099", + "0042-LIQF-100", + "0042-LIQF-101", + "0042-LIQF-102", + "0042-LIQF-103", + "0042-LIQF-104", + "0042-LIQF-105", + "0044-LIME-102", + "0044-LIME-103", + "0044-LIME-104", + "0044-LIME-105", + "0044-LIME-106", + "0044-LIME-107", + "0044-LIME-108", + "0044-LIME-109", + "0044-LIME-110", + "0044-LIME-111", + "0044-LIME-112", + "0044-LIME-113", + "0044-LIME-114", + "0044-LIME-115", + "0044-LIME-116", + "0044-LIME-117", + "0044-LIME-118", + "0044-LIME-119" ] }, "Spot stretch": { @@ -378,6 +447,87 @@ "milestone": "colosseo", "acs": ["0043-MKTL-011"] }, + "Spot stop orders": { + "milestone": "colosseo", + "acs": [ + "0014-ORDT-124", + "0014-ORDT-125", + "0014-ORDT-126", + "0014-ORDT-127", + "0014-ORDT-128", + "0014-ORDT-129", + "0014-ORDT-130", + "0014-ORDT-131", + "0014-ORDT-132", + "0014-ORDT-133", + "0014-ORDT-134", + "0014-ORDT-135", + "0014-ORDT-136", + "0014-ORDT-137", + "0014-ORDT-138", + "0014-ORDT-139", + "0014-ORDT-140", + "0014-ORDT-141", + "0014-ORDT-142", + "0014-ORDT-143", + "0014-ORDT-144", + "0014-ORDT-145", + "0014-ORDT-146", + "0014-ORDT-147", + "0014-ORDT-148", + "0014-ORDT-149", + "0014-ORDT-150", + "0014-ORDT-151", + "0014-ORDT-152", + "0014-ORDT-153", + "0014-ORDT-154", + "0014-ORDT-155", + "0014-ORDT-156", + "0014-ORDT-157", + "0014-ORDT-158", + "0014-ORDT-159", + "0014-ORDT-160", + "0014-ORDT-161", + "0014-ORDT-162", + "0014-ORDT-163", + "0014-ORDT-164", + ] + }, + "spot ammend": { + "milestone": "colosseo", + "acs": [ + "0037-OPEG-019", + "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" + ] + } +}, "Unknown": { "milestone": "unknown", "acs": [] From 876cab40dc2e14cdb6972965a3e94ca45b17aca2 Mon Sep 17 00:00:00 2001 From: gordsport Date: Mon, 25 Mar 2024 17:10:38 +0000 Subject: [PATCH 1042/1171] fix: duplicate numbers --- protocol/0014-ORDT-order_types.md | 4 ++-- protocol/features.json | 4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/protocol/0014-ORDT-order_types.md b/protocol/0014-ORDT-order_types.md index 5d62b07f6..179290cc8 100644 --- a/protocol/0014-ORDT-order_types.md +++ b/protocol/0014-ORDT-order_types.md @@ -359,10 +359,10 @@ In Spot market, for multiple iceberg orders submitted as a batch of orders with - 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). For spot products (0014-ORDT-134) - 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). For spot products (0014-ORDT-135) - An OCO stop order with expiration time `T` with one side set to execute at that time will execute at time `T` if reached without being triggered, with the specified side triggering and the other side cancelling. This must be tested both sides (fall below and rise above). (0014-ORDT-131). For spot products (0014-ORDT-136) - - An OCO stop order with expiration time `T` with both sides set to execute at that time will be rejected on submission (0014-ORDT-130). For spot products (0014-ORDT-137) + - An OCO stop order with expiration time `T` with both sides set to execute at that time will be rejected on submission (0014-ORDT-130). For spot products (0014-ORDT-165) - 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). For spot products (0014-ORDT-138) -- If a pair of stop orders are specified as OCO, one being triggered also removes the other from the book. (0014-ORDT-056). For spot products (0014-ORDT-139) +- If a pair of stop orders are specified as OCO, one being triggered also removes the other from the book. (0014-ORDT-056). For spot products (0014-ORDT-166) - 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). For spot products (0014-ORDT-140) - A trailing stop order for a 5% drop placed when the price is `50`, followed by a price rise to `60` will: diff --git a/protocol/features.json b/protocol/features.json index 3245fd0bd..cb74a2632 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -463,9 +463,7 @@ "0014-ORDT-134", "0014-ORDT-135", "0014-ORDT-136", - "0014-ORDT-137", "0014-ORDT-138", - "0014-ORDT-139", "0014-ORDT-140", "0014-ORDT-141", "0014-ORDT-142", @@ -491,6 +489,8 @@ "0014-ORDT-162", "0014-ORDT-163", "0014-ORDT-164", + "0014-ORDT-165", + "0014-ORDT-166" ] }, "spot ammend": { From 33af44b3fd555d7bd2ac7a61a5ed65800d434924 Mon Sep 17 00:00:00 2001 From: gordsport Date: Mon, 25 Mar 2024 17:15:15 +0000 Subject: [PATCH 1043/1171] fix: AC numbering --- protocol/0042-LIQF-setting_fees_and_rewarding_lps.md | 4 ++-- protocol/features.json | 8 -------- 2 files changed, 2 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 2eeb281b9..8625329a4 100644 --- a/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md +++ b/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md @@ -390,7 +390,7 @@ Each LP further gets a performance bonus: $b_i \times B$ with a transfer type th - 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) - Given the fee setting method is marginal cost. An LP joining a spot 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 when the fee is next recalculated (0042-LIQF-077) - 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) -- Given the fee setting method is marginal cost. An LP joining a spot 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 when the fee is next recalculated (0042-LIQF-078) +- Given the fee setting method is marginal cost. An LP joining a spot 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 when the fee is next recalculated (0042-LIQF-078) - 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) - Given the fee setting method is marginal cost. 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 when the fee is next recalculated (0042-LIQF-079) - 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) @@ -437,7 +437,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, 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). For spot (0042-LIQF-089) - 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). For spot (0042-LIQF-090) - - 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). For spot (0042-LIQF-090) + - 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). For spot (0042-LIQF-091) - 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). For spot (0042-LIQF-100) diff --git a/protocol/features.json b/protocol/features.json index cb74a2632..ebd30c8e4 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -281,14 +281,6 @@ "0042-LIQF-089", "0042-LIQF-090", "0042-LIQF-091", - "0042-LIQF-092", - "0042-LIQF-093", - "0042-LIQF-094", - "0042-LIQF-095", - "0042-LIQF-096", - "0042-LIQF-097", - "0042-LIQF-098", - "0042-LIQF-099", "0042-LIQF-100", "0042-LIQF-101", "0042-LIQF-102", From 0c3d3f1f4e04ea36cc7d302fe58971d220fc6b69 Mon Sep 17 00:00:00 2001 From: gordsport Date: Mon, 25 Mar 2024 17:26:04 +0000 Subject: [PATCH 1044/1171] fix: AC number dupes --- protocol/0014-ORDT-order_types.md | 22 +++++++++++----------- protocol/features.json | 24 ++++++++++++------------ 2 files changed, 23 insertions(+), 23 deletions(-) diff --git a/protocol/0014-ORDT-order_types.md b/protocol/0014-ORDT-order_types.md index 179290cc8..c36ebfe24 100644 --- a/protocol/0014-ORDT-order_types.md +++ b/protocol/0014-ORDT-order_types.md @@ -346,22 +346,22 @@ In Spot market, for multiple iceberg orders submitted as a batch of orders with - In a spot market, a stop order placed by a key with no position or open orders will be accepted. (0014-ORDT-125) - 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). For spot products (0014-ORDT-126) -- 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). For spot products (0014-ORDT-127) -- 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). For spot products (0014-ORDT-128) +- 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). For spot products (0014-ORDT-167) +- 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). For spot products (0014-ORDT-168) -- 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). For spot products (0014-ORDT-129) -- 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). For spot products (0014-ORDT-130) -- 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). For spot products (0014-ORDT-131) -- 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). For spot products (0014-ORDT-132) +- 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). For spot products (0014-ORDT-169) +- 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). For spot products (0014-ORDT-170) +- 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). For spot products (0014-ORDT-171) +- 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). For spot products (0014-ORDT-172) - 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). For spot products (0014-ORDT-133) -- 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). For spot products (0014-ORDT-134) - - 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). For spot products (0014-ORDT-135) - - An OCO stop order with expiration time `T` with one side set to execute at that time will execute at time `T` if reached without being triggered, with the specified side triggering and the other side cancelling. This must be tested both sides (fall below and rise above). (0014-ORDT-131). For spot products (0014-ORDT-136) +- 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). For spot products (0014-ORDT-173) +- 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). For spot products (0014-ORDT-174) + - 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). For spot products (0014-ORDT-175) + - An OCO stop order with expiration time `T` with one side set to execute at that time will execute at time `T` if reached without being triggered, with the specified side triggering and the other side cancelling. This must be tested both sides (fall below and rise above). (0014-ORDT-131). For spot products (0014-ORDT-176) - An OCO stop order with expiration time `T` with both sides set to execute at that time will be rejected on submission (0014-ORDT-130). For spot products (0014-ORDT-165) -- 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). For spot products (0014-ORDT-138) +- 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). For spot products (0014-ORDT-177) - If a pair of stop orders are specified as OCO, one being triggered also removes the other from the book. (0014-ORDT-056). For spot products (0014-ORDT-166) - 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). For spot products (0014-ORDT-140) diff --git a/protocol/features.json b/protocol/features.json index 7a8f0350d..3dadb66f3 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -453,17 +453,6 @@ "0014-ORDT-124", "0014-ORDT-125", "0014-ORDT-126", - "0014-ORDT-127", - "0014-ORDT-128", - "0014-ORDT-129", - "0014-ORDT-130", - "0014-ORDT-131", - "0014-ORDT-132", - "0014-ORDT-133", - "0014-ORDT-134", - "0014-ORDT-135", - "0014-ORDT-136", - "0014-ORDT-138", "0014-ORDT-140", "0014-ORDT-141", "0014-ORDT-142", @@ -490,7 +479,18 @@ "0014-ORDT-163", "0014-ORDT-164", "0014-ORDT-165", - "0014-ORDT-166" + "0014-ORDT-166", + "0014-ORDT-167", + "0014-ORDT-168", + "0014-ORDT-169", + "0014-ORDT-170", + "0014-ORDT-171", + "0014-ORDT-172", + "0014-ORDT-173", + "0014-ORDT-174", + "0014-ORDT-175", + "0014-ORDT-176", + "0014-ORDT-177" ] }, "spot ammend": { From f409bc15816148e92ac62adbd105c0d24923b25f Mon Sep 17 00:00:00 2001 From: gordsport Date: Mon, 25 Mar 2024 17:29:31 +0000 Subject: [PATCH 1045/1171] fix: json syntax --- protocol/features.json | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/protocol/features.json b/protocol/features.json index 3dadb66f3..5796ff7c2 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -526,9 +526,8 @@ "0011-MARA-018", "0011-MARA-019" ] - } -}, - "Unknown": { + }, + "Unknown": { "milestone": "unknown", "acs": [] } From bace2dfbd55254f3cb47b03fecd225445c0e37f0 Mon Sep 17 00:00:00 2001 From: Gordsport <83510148+gordsport@users.noreply.github.com> Date: Tue, 26 Mar 2024 08:58:07 +0000 Subject: [PATCH 1046/1171] chore(refactor): reorder features.json file (#2224) Reorders the features.json file for better reporting --- protocol/features.json | 204 ++++++++++++++++++++--------------------- 1 file changed, 102 insertions(+), 102 deletions(-) diff --git a/protocol/features.json b/protocol/features.json index 5796ff7c2..679579ae7 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -1,16 +1,45 @@ { - "Markprice updates": { + "Market tick size": { "milestone": "colosseo", "acs": [ - "0009-MRKP-132", - "0053-PERP-043", - "0032-PRIM-039", - "0032-PRIM-040", - "0009-MRKP-036", - "0009-MRKP-037" + "0004-AMND-060", + "0025-OCRE-006", + "0028-GOVE-180", + "0028-GOVE-182", + "0028-GOVE-183", + "0028-GOVE-184", + "0037-OPEG-020", + "0037-OPEG-021" + ] + }, + "Taker fee cap": { + "milestone": "colosseo", + "acs": [ + "0057-TRAN-070", + "0057-TRAN-071", + "0057-TRAN-072", + "0057-TRAN-073", + "0057-TRAN-074", + "0057-TRAN-075" ] }, - "Spot": { + "Isolated margin": { + "milestone": "colosseo", + "acs": ["0019-MCAL-208"] + }, + "Closeout trades and auctions": { + "milestone": "colosseo", + "acs": ["0012-POSR-030"] + }, + "Market suspended/resumed before enactment": { + "milestone": "colosseo", + "acs": ["0043-MKTL-011"] + }, + "Teams": { + "milestone": "colosseo", + "acs": ["0083-RFPR-068"] + }, + "Spot": { "milestone": "colosseo", "acs": [ "0080-SPOT-001", @@ -355,98 +384,6 @@ "0079-TGAP-007" ] }, - "Community Tags": { - "milestone": "colosseo", - "acs": [ - "0028-GOVE-168", - "0028-GOVE-169", - "0028-GOVE-170", - "0028-GOVE-171", - "0028-GOVE-172", - "0028-GOVE-173", - "0028-GOVE-174", - "0028-GOVE-175", - "0028-GOVE-176", - "0028-GOVE-177", - "0028-GOVE-178" - ] - }, - "Perpetual funding rates": { - "milestone": "colosseo", - "acs": ["0053-PERP-036"] - }, - "Market tick size": { - "milestone": "colosseo", - "acs": [ - "0004-AMND-060", - "0025-OCRE-006", - "0028-GOVE-180", - "0028-GOVE-182", - "0028-GOVE-183", - "0028-GOVE-184", - "0037-OPEG-020", - "0037-OPEG-021" - ] - }, - "Taker fee cap": { - "milestone": "colosseo", - "acs": [ - "0057-TRAN-070", - "0057-TRAN-071", - "0057-TRAN-072", - "0057-TRAN-073", - "0057-TRAN-074", - "0057-TRAN-075" - ] - }, - "Isolated margin": { - "milestone": "colosseo", - "acs": ["0019-MCAL-208"] - }, - "Closeout trades and auctions": { - "milestone": "colosseo", - "acs": ["0012-POSR-030"] - }, - "New asset bridge": { - "milestone": "colosseo", - "acs": [ - "0027-ASSP-027", - "0027-ASSP-028", - "0027-ASSP-029", - "0027-ASSP-030", - "0027-ASSP-031", - "0027-ASSP-032", - "0027-ASSP-033", - "0027-ASSP-034", - "0027-ASSP-035", - "0031-ETHB-084", - "0031-ETHB-085", - "0069-VCBS-089", - "0069-VCBS-090", - "0069-VCBS-091", - "0069-VCBS-092", - "0069-VCBS-093", - "0069-VCBS-094", - "0080-SPOT-023", - "0003-NP-LIMI-007" - ] - }, - "Explicit liquidation range": { - "milestone": "colosseo", - "acs": [ - "0012-POSR-031", - "0012-POSR-032", - "0012-POSR-033" - ] - }, - "Teams": { - "milestone": "colosseo", - "acs": ["0083-RFPR-068"] - }, - "Market suspended/resumed before enactment": { - "milestone": "colosseo", - "acs": ["0043-MKTL-011"] - }, "Spot stop orders": { "milestone": "colosseo", "acs": [ @@ -493,7 +430,7 @@ "0014-ORDT-177" ] }, - "spot ammend": { + "Spot ammend": { "milestone": "colosseo", "acs": [ "0037-OPEG-019", @@ -527,7 +464,70 @@ "0011-MARA-019" ] }, - "Unknown": { + "New asset bridge": { + "milestone": "colosseo", + "acs": [ + "0027-ASSP-027", + "0027-ASSP-028", + "0027-ASSP-029", + "0027-ASSP-030", + "0027-ASSP-031", + "0027-ASSP-032", + "0027-ASSP-033", + "0027-ASSP-034", + "0027-ASSP-035", + "0031-ETHB-084", + "0031-ETHB-085", + "0069-VCBS-089", + "0069-VCBS-090", + "0069-VCBS-091", + "0069-VCBS-092", + "0069-VCBS-093", + "0069-VCBS-094", + "0080-SPOT-023", + "0003-NP-LIMI-007" + ] + }, + "Markprice updates": { + "milestone": "colosseo", + "acs": [ + "0009-MRKP-132", + "0053-PERP-043", + "0032-PRIM-039", + "0032-PRIM-040", + "0009-MRKP-036", + "0009-MRKP-037" + ] + }, + "Perpetual funding rates": { + "milestone": "colosseo", + "acs": ["0053-PERP-036"] + }, + "Explicit liquidation range": { + "milestone": "colosseo", + "acs": [ + "0012-POSR-031", + "0012-POSR-032", + "0012-POSR-033" + ] + }, + "Community Tags": { + "milestone": "colosseo", + "acs": [ + "0028-GOVE-168", + "0028-GOVE-169", + "0028-GOVE-170", + "0028-GOVE-171", + "0028-GOVE-172", + "0028-GOVE-173", + "0028-GOVE-174", + "0028-GOVE-175", + "0028-GOVE-176", + "0028-GOVE-177", + "0028-GOVE-178" + ] + }, + "Unknown": { "milestone": "unknown", "acs": [] } From f799eaf829c2cb090598b53f3c5db1128c457dd1 Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Tue, 26 Mar 2024 12:50:50 +0000 Subject: [PATCH 1047/1171] feat: update validation on market and position decimals --- protocol/0070-MKTD-market-decimal-places.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/protocol/0070-MKTD-market-decimal-places.md b/protocol/0070-MKTD-market-decimal-places.md index 4e1c9e5f6..e39f918ca 100644 --- a/protocol/0070-MKTD-market-decimal-places.md +++ b/protocol/0070-MKTD-market-decimal-places.md @@ -70,8 +70,8 @@ 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 precision - position precision (0070-MKTD-021). For product spot: (0070-MKTD-022) + - This proposal is NOT valid if the precision is greater than the settlement asset precision - position precision (0070-MKTD-023). For product spot: (0070-MKTD-024) - 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) From 23f61771e724bc40e95205dad6e7d3b599da20f4 Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Tue, 26 Mar 2024 16:37:23 +0000 Subject: [PATCH 1048/1171] feat: address comment on spot --- protocol/0070-MKTD-market-decimal-places.md | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/protocol/0070-MKTD-market-decimal-places.md b/protocol/0070-MKTD-market-decimal-places.md index e39f918ca..3ba1ce915 100644 --- a/protocol/0070-MKTD-market-decimal-places.md +++ b/protocol/0070-MKTD-market-decimal-places.md @@ -70,8 +70,10 @@ 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 precision - position precision (0070-MKTD-021). For product spot: (0070-MKTD-022) - - This proposal is NOT valid if the precision is greater than the settlement asset precision - position precision (0070-MKTD-023). For product spot: (0070-MKTD-024) + - This proposal is valid if the precision is NOT greater than the settlement asset precision - position precision (0070-MKTD-021). For product spot, the market precision should be NOT greater than the quote asset precision - position precision (0070-MKTD-022) + - This proposal is NOT valid if the precision is greater than the settlement asset precision - position precision (0070-MKTD-023). For product spot this proposal is NOT valid if the market precision is greater than the quote asset precision - position precision (0070-MKTD-024). + - For product spot, position precision should be NOT greater than base asset precision (0070-MKTD-025) + - For product spot, the market prososal is NOT valid if the position precision is greater than base asset precision (0070-MKTD-026) - 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) From 703cc6794baabcca703f6c33f46634d86d043451 Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Tue, 26 Mar 2024 16:44:04 +0000 Subject: [PATCH 1049/1171] feat: add paragraph for validation --- protocol/0070-MKTD-market-decimal-places.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/protocol/0070-MKTD-market-decimal-places.md b/protocol/0070-MKTD-market-decimal-places.md index 3ba1ce915..48ca75eee 100644 --- a/protocol/0070-MKTD-market-decimal-places.md +++ b/protocol/0070-MKTD-market-decimal-places.md @@ -12,6 +12,8 @@ This document aims to outline how we are to handle the decimal places of a given It is possible to configure a market where orders can only be priced in increments of a specific size. This is done by specifying a different (smaller) number of decimal places than its settlement asset supports. Simply put: a market that settles in GBP can be configured to have 0 decimal places, in which case the price levels on the orderbook will be at least separated by £1, rather than the default penny. +In order to ensure that the smallest mark-to-market cashflow caused by the smallest price change on the smallest position is addressed, we need to make sure the asset precision is not less than the sum of market precision and position precision. + This effectively means that prices of submitted orders should be treated as a value that is an order of magnitude greater than what the user will submit. This is trivial to calculate, and is done when the market is created by passing in the asset details (which specify how many decimal places any given asset supports): ```go From 7bb4799b8598a51610f09ece8dadd18b4e08e2e3 Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Wed, 27 Mar 2024 10:36:50 +0000 Subject: [PATCH 1050/1171] feat: address comments --- protocol/0070-MKTD-market-decimal-places.md | 15 ++++++++++----- 1 file changed, 10 insertions(+), 5 deletions(-) diff --git a/protocol/0070-MKTD-market-decimal-places.md b/protocol/0070-MKTD-market-decimal-places.md index 48ca75eee..1107ee01b 100644 --- a/protocol/0070-MKTD-market-decimal-places.md +++ b/protocol/0070-MKTD-market-decimal-places.md @@ -12,7 +12,12 @@ This document aims to outline how we are to handle the decimal places of a given It is possible to configure a market where orders can only be priced in increments of a specific size. This is done by specifying a different (smaller) number of decimal places than its settlement asset supports. Simply put: a market that settles in GBP can be configured to have 0 decimal places, in which case the price levels on the orderbook will be at least separated by £1, rather than the default penny. -In order to ensure that the smallest mark-to-market cashflow caused by the smallest price change on the smallest position is addressed, we need to make sure the asset precision is not less than the sum of market precision and position precision. +In order to ensure we are able to represent the smallest trade at the smallest price in quote asset decimals. We want + +```go +market decimal places + position decimal places <= quote asset decimal places +position decimal palces <= base asset decimal places +``` This effectively means that prices of submitted orders should be treated as a value that is an order of magnitude greater than what the user will submit. This is trivial to calculate, and is done when the market is created by passing in the asset details (which specify how many decimal places any given asset supports): @@ -72,10 +77,10 @@ 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 precision - position precision (0070-MKTD-021). For product spot, the market precision should be NOT greater than the quote asset precision - position precision (0070-MKTD-022) - - This proposal is NOT valid if the precision is greater than the settlement asset precision - position precision (0070-MKTD-023). For product spot this proposal is NOT valid if the market precision is greater than the quote asset precision - position precision (0070-MKTD-024). - - For product spot, position precision should be NOT greater than base asset precision (0070-MKTD-025) - - For product spot, the market prososal is NOT valid if the position precision is greater than base asset precision (0070-MKTD-026) + - This proposal is valid if the precision is NOT greater than the settlement asset precision - position precision (0070-MKTD-021). For product spot, the market decimal should be NOT greater than the quote asset decimal - position decimal (0070-MKTD-022) + - This proposal is NOT valid if the precision is greater than the settlement asset precision - position precision (0070-MKTD-023). For product spot this proposal is NOT valid if the market decimal is greater than the quote asset decimal - position decimal (0070-MKTD-024). + - For product spot, position decimal should be NOT greater than base asset decimal (0070-MKTD-025) + - For product spot, the market prososal is NOT valid if the position decimal is greater than base asset decimal (0070-MKTD-026) - 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) From d04bbcbcbbc934966c8b54d1d4dffe731c7cde59 Mon Sep 17 00:00:00 2001 From: wwestgarth Date: Wed, 27 Mar 2024 10:37:37 +0000 Subject: [PATCH 1051/1171] chore: update 0069-VCBS-094, validator key treated like any other for spam on the multisig thing (#2223) --- protocol/0069-VCBS-validators_chosen_by_stake.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0069-VCBS-validators_chosen_by_stake.md b/protocol/0069-VCBS-validators_chosen_by_stake.md index e88693f20..100bbae90 100644 --- a/protocol/0069-VCBS-validators_chosen_by_stake.md +++ b/protocol/0069-VCBS-validators_chosen_by_stake.md @@ -570,7 +570,7 @@ Setup a network with 6 nodes (3 validators, 2 ersatz validators, 1 pending valid - Verify that no rewards are paid out on the first epoch. - Update all multisig contracts 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 multisig signers to be the keys of the current consensus (tendermint) validators up to `network.validators.multisig.numberOfSigners`. This request can only be submitted `spam.protection.max.MultisigUpdates` times per epoch per vega key per registered EVM/ERPC asset chain (alternatively the request will provide the update bundles for all the chains). Once multisig uses weights it will also include the correct weights for all multisig contracts. (0069-VCBS-094) +1. Any vega key with number of governance tokens more than or equal to `spam.protection.minMultisigUpdates` can submit a request to the vega network to obtain the signature bundle that would update the multisig signers to be the keys of the current consensus (tendermint) validators up to `network.validators.multisig.numberOfSigners`. This request can only be submitted `spam.protection.max.MultisigUpdates` times per epoch per vega key per registered EVM/ERPC asset chain (alternatively the request will provide the update bundles for all the chains). Once multisig uses weights it will also include the correct weights for all multisig contracts. (0069-VCBS-094) 1. Replace a validator with a new node via promotion/demotion. Ensure that rewards are paid out at the end of the epoch if all multisigs are updated to match the new validator. (0069-VCBS-091) ### Re-Issuing Signature Bundles by non Validators From 97ba60005d9cf5cd7b8490a474f8b8b2b921474b Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Wed, 27 Mar 2024 10:57:02 +0000 Subject: [PATCH 1052/1171] chore: markdown --- protocol/0070-MKTD-market-decimal-places.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/protocol/0070-MKTD-market-decimal-places.md b/protocol/0070-MKTD-market-decimal-places.md index 1107ee01b..019ef2e81 100644 --- a/protocol/0070-MKTD-market-decimal-places.md +++ b/protocol/0070-MKTD-market-decimal-places.md @@ -78,9 +78,9 @@ 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 precision - position precision (0070-MKTD-021). For product spot, the market decimal should be NOT greater than the quote asset decimal - position decimal (0070-MKTD-022) - - This proposal is NOT valid if the precision is greater than the settlement asset precision - position precision (0070-MKTD-023). For product spot this proposal is NOT valid if the market decimal is greater than the quote asset decimal - position decimal (0070-MKTD-024). + - This proposal is NOT valid if the precision is greater than the settlement asset precision - position precision (0070-MKTD-023). For product spot this proposal is NOT valid if the market decimal is greater than the quote asset decimal - position decimal (0070-MKTD-024). - For product spot, position decimal should be NOT greater than base asset decimal (0070-MKTD-025) - - For product spot, the market prososal is NOT valid if the position decimal is greater than base asset decimal (0070-MKTD-026) + - For product spot, the market proposal is NOT valid if the position decimal is greater than base asset decimal (0070-MKTD-026) - 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) @@ -92,3 +92,4 @@ Trades of course result in transfers. The amounts transferred (for the trade as - 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 82fa3346fcc9436435ef02aadaadef8b4f48b913 Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Wed, 27 Mar 2024 11:07:28 +0000 Subject: [PATCH 1053/1171] feat: update AC in json --- protocol/features.json | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/protocol/features.json b/protocol/features.json index 679579ae7..222e95d63 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -368,14 +368,16 @@ "0065-FTCO-006", "0065-FTCO-007", "0065-FTCO-008", - "0070-MKTD-009", "0070-MKTD-010", "0070-MKTD-011", "0070-MKTD-012", "0070-MKTD-013", "0070-MKTD-014", "0070-MKTD-015", - "0070-MKTD-016", + "0070-MKTD-022", + "0070-MKTD-024", + "0070-MKTD-025", + "0070-MKTD-026", "0074-BTCH-012", "0074-BTCH-015", "0074-BTCH-016", From 6a9a2b3c8e3c1e5d4f3d03cae5ff0e4fa14469e4 Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Wed, 27 Mar 2024 11:38:17 +0000 Subject: [PATCH 1054/1171] feat: remove prevision from ACs --- protocol/0070-MKTD-market-decimal-places.md | 55 ++++++++++++--------- 1 file changed, 31 insertions(+), 24 deletions(-) diff --git a/protocol/0070-MKTD-market-decimal-places.md b/protocol/0070-MKTD-market-decimal-places.md index 019ef2e81..a18036ed9 100644 --- a/protocol/0070-MKTD-market-decimal-places.md +++ b/protocol/0070-MKTD-market-decimal-places.md @@ -5,34 +5,41 @@ This document aims to outline how we are to handle the decimal places of a given ## Terminology - Settlement asset: the asset in which transactions for a given market are made (margin balances, fees, settlements, etc...). -- Market precision: the number of decimal places a market uses (as mentioned previously, a market where the smallest unit of ETH is a Gwei has a 9 decimal places, so the market precision is 9). Synonymous with _market tick_. -- Asset precision: the number of decimal places for a given asset. Again, a market with precision 9 that settles in ETH will have a market precision of 9, whereas the asset precision is 18. +- Market decimal palces: the number of decimal places a market uses (as mentioned previously, a market where the smallest unit of ETH is a Gwei has a 9 decimal places, so the market decimal is 9). Synonymous with _market tick_. +- Asset decimal places: the number of decimal places for a given asset. Again, a market with decimal 9 that settles in ETH will have a market decimal of 9, whereas the asset decimal is 18. ## Mechanics It is possible to configure a market where orders can only be priced in increments of a specific size. This is done by specifying a different (smaller) number of decimal places than its settlement asset supports. Simply put: a market that settles in GBP can be configured to have 0 decimal places, in which case the price levels on the orderbook will be at least separated by £1, rather than the default penny. -In order to ensure we are able to represent the smallest trade at the smallest price in quote asset decimals. We want +In cash settled futures market and perpetual market, in order to ensure that the smallest mark-to-market cashflow caused by the smallest price change on the smallest position is addressed, we need: ```go -market decimal places + position decimal places <= quote asset decimal places +market decimal places + position decimal places <= asset decimal places +position decimal palces <= asset decimal places +``` + +In spot market, in order to ensure we are able to represent the smallest trade at the smallest price in quote asset decimals, we need + +```go +market decimal places + position decimal places <= quote asset decimal places position decimal palces <= base asset decimal places ``` This effectively means that prices of submitted orders should be treated as a value that is an order of magnitude greater than what the user will submit. This is trivial to calculate, and is done when the market is created by passing in the asset details (which specify how many decimal places any given asset supports): ```go -priceExponent = 10**(asset_precision - market_precision) +priceExponent = 10**(asset_decimal - market_decimal) // for GBP markets with 0 decimal places this is: priceExponent = 10 ** (2 - 0) == 100 // for ETH markets with 9 decimal places, this is: priceExponent = 10 ** (18 -9) == 1,000,000,000 ``` -When an order is submitted, amended, or otherwise updated, the core emits an event for the data-node (and any other interested parties). The price in this order event should still be represented as a value in market precision. Updating the price on the order internally, for reasons we shall elaborate on later, should not effect the market data on the event bus. To clarify: +When an order is submitted, amended, or otherwise updated, the core emits an event for the data-node (and any other interested parties). The price in this order event should still be represented as a value in market decimal places. Updating the price on the order internally, for reasons we shall elaborate on later, should not effect the market data on the event bus. To clarify: ```go -// given market decimal places == 0, settlement precision == 2 +// given market decimal places == 0, settlement decimal == 2 SubmitOrder(Order{ Size: 10, Price: 1, @@ -47,7 +54,7 @@ In short, market related events should specify prices in the _"unit"_ the market ### Benefits -By allowing markets to specify their own precision, the price levels can be more closely controlled, and any changes in the mark price could be made as _"significant"_ as we want. By converting the prices internally to asset precision, we are able to accurately calculate fees and margin levels based on the asset precision. By operating a market with a lower precision than the asset itself, fees and margin requirements can be calculated with a higher level of precision. +By allowing markets to specify their own decimal places, the price levels can be more closely controlled, and any changes in the mark price could be made as _"significant"_ as we want. By converting the prices internally to asset decimal places, we are able to accurately calculate fees and margin levels based on the asset decimal. By operating a market with a lower decimal than the asset itself, fees and margin requirements can be calculated with a higher level of decimal. ## Changes required @@ -55,7 +62,7 @@ This change has an impact throughout the system, but it can broadly be broken do ### Orders -Order submissions and amendments are received, the submitted price (aka market or original price) is copied to a private field, so the events can be constructed in an accurate way. Before submitting the order to the book, or amending it, the price we received from the chain is multiplied by the price exponent. From that point on, the core will operate on the value that has the asset precision. Calculating fees and margin requirements, updating/creating the price levels, etc... all happens in asset precision. Any order events the core sends out will look exactly the same as before. +Order submissions and amendments are received, the submitted price (aka market or original price) is copied to a private field, so the events can be constructed in an accurate way. Before submitting the order to the book, or amending it, the price we received from the chain is multiplied by the price exponent. From that point on, the core will operate on the value that has the asset decimal. Calculating fees and margin requirements, updating/creating the price levels, etc... all happens in asset decimal places. Any order events the core sends out will look exactly the same as before. ### Pegged orders @@ -64,7 +71,7 @@ When (re-)pricing pegged orders, the offset values are multiplied by the same pr ### Liquidity provisions Orders created for an LP work pretty much exactly the same as pegged orders. The offsets will, again, be multiplied by the price exponent when the price is calculated, but the LP shape object is not updated. -When repricing LP orders, we ensure the price of the orders fall inside the upper and lower price bounds. These values are going to be calculated based on the prices used internally (in asset precision). So as to not create orders at a price point that is more precise than the market is configured to support, we floor the max price bound, and ceil the minimum price, as those values will effectively be the max and min prices that are allowed without trades resulting in an auction being triggered. +When repricing LP orders, we ensure the price of the orders fall inside the upper and lower price bounds. These values are going to be calculated based on the prices used internally (in asset decimal). So as to not create orders at a price point that is more precise than the market is configured to support, we floor the max price bound, and ceil the minimum price, as those values will effectively be the max and min prices that are allowed without trades resulting in an auction being triggered. ### Market data @@ -72,24 +79,24 @@ The market data returns the same min/max prices mentioned above. As the name imp ### Trades -Trades of course result in transfers. The amounts transferred (for the trade as well as the MTM) happen at asset precision. The trade events the core sends out, however, are once again market related data. The prices on these trade events will be represented as a value in market precision. +Trades of course result in transfers. The amounts transferred (for the trade as well as the MTM) happen at asset decimal. The trade events the core sends out, however, are once again market related data. The prices on these trade events will be represented as a value in market decimal. ## 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 precision - position precision (0070-MKTD-021). For product spot, the market decimal should be NOT greater than the quote asset decimal - position decimal (0070-MKTD-022) - - This proposal is NOT valid if the precision is greater than the settlement asset precision - position precision (0070-MKTD-023). For product spot this proposal is NOT valid if the market decimal is greater than the quote asset decimal - position decimal (0070-MKTD-024). +- As a user, I can propose a market with a different decimal places than its settlement asset + - This proposal is valid if the market decimal is NOT greater than the settlement asset decimal - position decimal (0070-MKTD-021). For product spot, the market decimal should be NOT greater than the quote asset decimal - position decimal (0070-MKTD-022) + - This proposal is NOT valid if the market decimal is greater than the settlement asset decimal - position decimal (0070-MKTD-023). For product spot this proposal is NOT valid if the market decimal is greater than the quote asset decimal - position decimal (0070-MKTD-024). - For product spot, position decimal should be NOT greater than base asset decimal (0070-MKTD-025) - For product spot, the market proposal is NOT valid if the position decimal is greater than base asset decimal (0070-MKTD-026) - 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) -- Settlement data received during trading on a perpetuals market is correctly handled according to the specified precision (0070-MKTD-017) + - settlement data decimal is > than the settlement asset decimal (i.e. settlement data has more decimal places than the settlement asset and precision will be lost) (0070-MKTD-018) + - settlement data decimal is < than the settlement asset deciaml (i.e. settlement data has less decimal places than the settlement asset and no precision will be lost) (0070-MKTD-019) + - settlement data decimal is equal to the settlement asset decimaln (i.e. settlement data has less 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 decimal places (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 decimal places (0070-MKTD-004). For product spot: (0070-MKTD-011) +- As a user I should see the market data prices using market decimal places. (0070-MKTD-005). For product spot: (0070-MKTD-012) +- Price bounds are calculated in asset decimal places, but enforced rounded to the closest value in market decimal places 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 decimal places (0070-MKTD-007). For product spot: (0070-MKTD-014) +- Trades prices, like orders, are shown in market decimal places. The transfers and margin requirements are in asset decimal places. ( 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 decimal places (0070-MKTD-017) From 0b8ae522746af9d86ff6ce377cc06ffdb77d33d1 Mon Sep 17 00:00:00 2001 From: Jiajia-Cui <92106936+Jiajia-Cui@users.noreply.github.com> Date: Wed, 27 Mar 2024 11:49:44 +0000 Subject: [PATCH 1055/1171] feat: address comment Co-authored-by: David Siska <62546419+davidsiska-vega@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 a18036ed9..2e5cb5263 100644 --- a/protocol/0070-MKTD-market-decimal-places.md +++ b/protocol/0070-MKTD-market-decimal-places.md @@ -5,7 +5,7 @@ This document aims to outline how we are to handle the decimal places of a given ## Terminology - Settlement asset: the asset in which transactions for a given market are made (margin balances, fees, settlements, etc...). -- Market decimal palces: the number of decimal places a market uses (as mentioned previously, a market where the smallest unit of ETH is a Gwei has a 9 decimal places, so the market decimal is 9). Synonymous with _market tick_. +- Market decimal palces: the number of decimal places a market uses (as mentioned previously, a market where the smallest unit of ETH is a Gwei has a 9 decimal places, so the market decimal is 9). - Asset decimal places: the number of decimal places for a given asset. Again, a market with decimal 9 that settles in ETH will have a market decimal of 9, whereas the asset decimal is 18. ## Mechanics From 8763965811c4f312dacc9b849f9544dbcb4e9d65 Mon Sep 17 00:00:00 2001 From: Jiajia-Cui <92106936+Jiajia-Cui@users.noreply.github.com> Date: Wed, 27 Mar 2024 11:50:12 +0000 Subject: [PATCH 1056/1171] feat: address comment on AC 022 Co-authored-by: David Siska <62546419+davidsiska-vega@users.noreply.github.com> --- protocol/0070-MKTD-market-decimal-places.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/protocol/0070-MKTD-market-decimal-places.md b/protocol/0070-MKTD-market-decimal-places.md index 2e5cb5263..36397394b 100644 --- a/protocol/0070-MKTD-market-decimal-places.md +++ b/protocol/0070-MKTD-market-decimal-places.md @@ -84,7 +84,8 @@ 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 decimal places than its settlement asset - - This proposal is valid if the market decimal is NOT greater than the settlement asset decimal - position decimal (0070-MKTD-021). For product spot, the market decimal should be NOT greater than the quote asset decimal - position decimal (0070-MKTD-022) + - This proposal is valid if the market decimal + position decimal is less than or equal to the settlement asset decimal (0070-MKTD-021). +- For product spot the proposal is valid if the market decimal + position decimal is less than or equal to the quote asset decimal (0070-MKTD-022). - This proposal is NOT valid if the market decimal is greater than the settlement asset decimal - position decimal (0070-MKTD-023). For product spot this proposal is NOT valid if the market decimal is greater than the quote asset decimal - position decimal (0070-MKTD-024). - For product spot, position decimal should be NOT greater than base asset decimal (0070-MKTD-025) - For product spot, the market proposal is NOT valid if the position decimal is greater than base asset decimal (0070-MKTD-026) From bf58364febb1defb2d7cb1be3364fc2e3aff99dc Mon Sep 17 00:00:00 2001 From: Jiajia-Cui <92106936+Jiajia-Cui@users.noreply.github.com> Date: Wed, 27 Mar 2024 11:50:31 +0000 Subject: [PATCH 1057/1171] feat: address comment on AC 023 Co-authored-by: David Siska <62546419+davidsiska-vega@users.noreply.github.com> --- protocol/0070-MKTD-market-decimal-places.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/protocol/0070-MKTD-market-decimal-places.md b/protocol/0070-MKTD-market-decimal-places.md index 36397394b..f3836aa76 100644 --- a/protocol/0070-MKTD-market-decimal-places.md +++ b/protocol/0070-MKTD-market-decimal-places.md @@ -86,7 +86,8 @@ Trades of course result in transfers. The amounts transferred (for the trade as - As a user, I can propose a market with a different decimal places than its settlement asset - This proposal is valid if the market decimal + position decimal is less than or equal to the settlement asset decimal (0070-MKTD-021). - For product spot the proposal is valid if the market decimal + position decimal is less than or equal to the quote asset decimal (0070-MKTD-022). - - This proposal is NOT valid if the market decimal is greater than the settlement asset decimal - position decimal (0070-MKTD-023). For product spot this proposal is NOT valid if the market decimal is greater than the quote asset decimal - position decimal (0070-MKTD-024). + - This proposal is NOT valid if the market decimal + position decimal is greater than the settlement asset decimal (0070-MKTD-023). + - For product spot this proposal is NOT valid if the market decimal + position decimal is greater than the quote asset decimal (0070-MKTD-024). - For product spot, position decimal should be NOT greater than base asset decimal (0070-MKTD-025) - For product spot, the market proposal is NOT valid if the position decimal is greater than base asset decimal (0070-MKTD-026) - Assert that the settlement calculation can be correctly calculated when: From 66dc1800bca1a8d397dedf8faf78a7695239acdc Mon Sep 17 00:00:00 2001 From: Jiajia-Cui <92106936+Jiajia-Cui@users.noreply.github.com> Date: Wed, 27 Mar 2024 11:50:52 +0000 Subject: [PATCH 1058/1171] feat: address comment on AC 025 Co-authored-by: David Siska <62546419+davidsiska-vega@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 f3836aa76..eef6248db 100644 --- a/protocol/0070-MKTD-market-decimal-places.md +++ b/protocol/0070-MKTD-market-decimal-places.md @@ -88,7 +88,7 @@ Trades of course result in transfers. The amounts transferred (for the trade as - For product spot the proposal is valid if the market decimal + position decimal is less than or equal to the quote asset decimal (0070-MKTD-022). - This proposal is NOT valid if the market decimal + position decimal is greater than the settlement asset decimal (0070-MKTD-023). - For product spot this proposal is NOT valid if the market decimal + position decimal is greater than the quote asset decimal (0070-MKTD-024). - - For product spot, position decimal should be NOT greater than base asset decimal (0070-MKTD-025) + - For product spot, the proposal is valid if position decimals are less than or equal than base asset decimals (0070-MKTD-025). - For product spot, the market proposal is NOT valid if the position decimal is greater than base asset decimal (0070-MKTD-026) - Assert that the settlement calculation can be correctly calculated when: - settlement data decimal is > than the settlement asset decimal (i.e. settlement data has more decimal places than the settlement asset and precision will be lost) (0070-MKTD-018) From ee34259739e5999106759ce97eeec44c93fe5294 Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Wed, 27 Mar 2024 11:54:21 +0000 Subject: [PATCH 1059/1171] chore: markdown --- protocol/0070-MKTD-market-decimal-places.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/protocol/0070-MKTD-market-decimal-places.md b/protocol/0070-MKTD-market-decimal-places.md index eef6248db..ef40414d3 100644 --- a/protocol/0070-MKTD-market-decimal-places.md +++ b/protocol/0070-MKTD-market-decimal-places.md @@ -5,7 +5,7 @@ This document aims to outline how we are to handle the decimal places of a given ## Terminology - Settlement asset: the asset in which transactions for a given market are made (margin balances, fees, settlements, etc...). -- Market decimal palces: the number of decimal places a market uses (as mentioned previously, a market where the smallest unit of ETH is a Gwei has a 9 decimal places, so the market decimal is 9). +- Market decimal palces: the number of decimal places a market uses (as mentioned previously, a market where the smallest unit of ETH is a Gwei has a 9 decimal places, so the market decimal is 9). - Asset decimal places: the number of decimal places for a given asset. Again, a market with decimal 9 that settles in ETH will have a market decimal of 9, whereas the asset decimal is 18. ## Mechanics @@ -101,4 +101,3 @@ Trades of course result in transfers. The amounts transferred (for the trade as - 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 decimal places (0070-MKTD-007). For product spot: (0070-MKTD-014) - Trades prices, like orders, are shown in market decimal places. The transfers and margin requirements are in asset decimal places. ( 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 decimal places (0070-MKTD-017) - From b011641ff67bfa73823a6997a922da5970a38541 Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Wed, 27 Mar 2024 12:00:57 +0000 Subject: [PATCH 1060/1171] chore: typo --- protocol/0070-MKTD-market-decimal-places.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/protocol/0070-MKTD-market-decimal-places.md b/protocol/0070-MKTD-market-decimal-places.md index ef40414d3..4e83c256d 100644 --- a/protocol/0070-MKTD-market-decimal-places.md +++ b/protocol/0070-MKTD-market-decimal-places.md @@ -5,7 +5,7 @@ This document aims to outline how we are to handle the decimal places of a given ## Terminology - Settlement asset: the asset in which transactions for a given market are made (margin balances, fees, settlements, etc...). -- Market decimal palces: the number of decimal places a market uses (as mentioned previously, a market where the smallest unit of ETH is a Gwei has a 9 decimal places, so the market decimal is 9). +- Market decimal places: the number of decimal places a market uses (as mentioned previously, a market where the smallest unit of ETH is a Gwei has a 9 decimal places, so the market decimal is 9). - Asset decimal places: the number of decimal places for a given asset. Again, a market with decimal 9 that settles in ETH will have a market decimal of 9, whereas the asset decimal is 18. ## Mechanics @@ -16,14 +16,14 @@ In cash settled futures market and perpetual market, in order to ensure that the ```go market decimal places + position decimal places <= asset decimal places -position decimal palces <= asset decimal places +position decimal places <= asset decimal places ``` In spot market, in order to ensure we are able to represent the smallest trade at the smallest price in quote asset decimals, we need ```go market decimal places + position decimal places <= quote asset decimal places -position decimal palces <= base asset decimal places +position decimal places <= base asset decimal places ``` This effectively means that prices of submitted orders should be treated as a value that is an order of magnitude greater than what the user will submit. This is trivial to calculate, and is done when the market is created by passing in the asset details (which specify how many decimal places any given asset supports): @@ -92,8 +92,8 @@ Trades of course result in transfers. The amounts transferred (for the trade as - For product spot, the market proposal is NOT valid if the position decimal is greater than base asset decimal (0070-MKTD-026) - Assert that the settlement calculation can be correctly calculated when: - settlement data decimal is > than the settlement asset decimal (i.e. settlement data has more decimal places than the settlement asset and precision will be lost) (0070-MKTD-018) - - settlement data decimal is < than the settlement asset deciaml (i.e. settlement data has less decimal places than the settlement asset and no precision will be lost) (0070-MKTD-019) - - settlement data decimal is equal to the settlement asset decimaln (i.e. settlement data has less decimal places than the settlement asset and no precision will be lost) (0070-MKTD-020) + - settlement data decimal is < than the settlement asset decimal (i.e. settlement data has less decimal places than the settlement asset and no precision will be lost) (0070-MKTD-019) + - settlement data decimal is equal to the settlement asset decimal (i.e. settlement data has less 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 decimal places (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 decimal places (0070-MKTD-004). For product spot: (0070-MKTD-011) - As a user I should see the market data prices using market decimal places. (0070-MKTD-005). For product spot: (0070-MKTD-012) From ffb5bc4d6a2e5c1c49eeeee8194eb159a80ee64d Mon Sep 17 00:00:00 2001 From: Witold Date: Thu, 28 Mar 2024 11:57:54 +0100 Subject: [PATCH 1061/1171] refactor: modify auction margin in cross-margin mode --- protocol/0019-MCAL-margin_calculator.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/protocol/0019-MCAL-margin_calculator.md b/protocol/0019-MCAL-margin_calculator.md index a476d3706..3ef857909 100644 --- a/protocol/0019-MCAL-margin_calculator.md +++ b/protocol/0019-MCAL-margin_calculator.md @@ -72,6 +72,8 @@ - Thus, with `margin funding factor = 0.5`, `total margin requirement = futures margin + funding margin = 595 + 0.5 * max(0, 20 * 1) = 605` (0019-MCAL-028) - However is position is instead `-1`, with the same margin requirement, if `margin funding factor = 0.5`, `total margin requirement = futures margin + funding margin = 595 + 0.5 * max(0, 20 * -1) = 595`(0019-MCAL-029) + - When placing an order to buy `10` at a price of `3` on a market in an opening auction with an indicative uncrossing price of `100` and a long risk factor of `0.1`, the resulting margin is `100` (0019-MCAL-234) + ## Acceptance Criteria (Isolated-margin) **When party has a newly created short position:** @@ -681,7 +683,7 @@ We are assuming that: Use the same calculation as above with the following re-defined: -- For the orders part of the margin: use `market_observable` = volume weighted average price of the party's long / short orders. +- For the orders part of the margin: use `market_observable` = max(volume weighted average price of the party's long / short orders, sum of volumes of party's long / short orders * auction price), where `auction price` = max(mark price, indicative uncrossing price). If any of the values is unavailable at the time of calculation assume it's equal to `0` ## Scaling other margin levels From 76bc12086de6aa9b4213597b39691ba69657c18e Mon Sep 17 00:00:00 2001 From: David Siska <62546419+davidsiska-vega@users.noreply.github.com> Date: Wed, 3 Apr 2024 11:00:32 +0100 Subject: [PATCH 1062/1171] Fix/lps vote without staked vega (#2228) * fix: LPs can vote on their market without gov token * fix: LPs can vote on their market without gov token * fix: LPs can vote on their market without gov token --- protocol/0028-GOVE-governance.md | 3 +++ protocol/features.json | 4 ++++ 2 files changed, 7 insertions(+) diff --git a/protocol/0028-GOVE-governance.md b/protocol/0028-GOVE-governance.md index 58d43519c..841dd4fb5 100644 --- a/protocol/0028-GOVE-governance.md +++ b/protocol/0028-GOVE-governance.md @@ -91,6 +91,7 @@ In a future iteration of the governance system we may restrict proposal submissi ### 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. +Moreover, market LPs can vote on market change proposals even if they don't have `governance.proposal.updateMarket.minVoterBalance` governance tokens. 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 @@ -598,6 +599,8 @@ APIs should also exist for clients to: - 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) - A market change proposal specifying a new tick size less than or equal to `0` gets rejected (0028-GOVE-184). - At enactment, a market change proposal updating the tick size cancels all pegged orders where their offset is no longer an exact integer multiple of the tick size (0028-GOVE-183). +- A market LP with ELS > 0 can vote on a market change proposal even if the key doesn't meet the `governance.proposal.updateMarket.minVoterBalance` for governance token. (0028-GOVE-185). + #### Network parameter change proposals diff --git a/protocol/features.json b/protocol/features.json index 222e95d63..5bd7b9210 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -529,6 +529,10 @@ "0028-GOVE-178" ] }, + "LPs voting without gov token": { + "milestone": "colosseo", + "acs": ["0028-GOVE-185"] + }, "Unknown": { "milestone": "unknown", "acs": [] From de4af9d78672575c917965f256e18975b0f3f24e Mon Sep 17 00:00:00 2001 From: Charlie Date: Mon, 15 Apr 2024 13:05:46 +0100 Subject: [PATCH 1063/1171] feat: allow negative relative pnl to receive rewards --- protocol/0056-REWA-rewards_overview.md | 9 +++++---- protocol/features.json | 9 +++++++++ 2 files changed, 14 insertions(+), 4 deletions(-) diff --git a/protocol/0056-REWA-rewards_overview.md b/protocol/0056-REWA-rewards_overview.md index 13ffd9db5..d9d2b4740 100644 --- a/protocol/0056-REWA-rewards_overview.md +++ b/protocol/0056-REWA-rewards_overview.md @@ -104,7 +104,7 @@ Let: - $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} = \max(\frac{\sum_{i}^{n}{r_{i}}}{N}, 0)$$ +$$m_{rr} = \frac{\sum_{i}^{n}{r_{i}}}{N}$$ ### Returns volatility metric @@ -969,10 +969,11 @@ At the end of epoch 2, 10000 VEGA rewards should be distributed to the `ETHUSDT` ### 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 zero net returns, their relative returns reward metric should be zero (0056-REWA-111). +- If an eligible party has non-zero 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-112). - 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). +- If a `window_length>1` is specified in the recurring transfer, if an eligible party has zero net returns in all epochs, their relative return metric should be zero (0056-REWA-113). +- 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. Note epochs with zero returns should be included. (0056-REWA-114). ### Returns volatility diff --git a/protocol/features.json b/protocol/features.json index 5bd7b9210..f5cc52256 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -533,6 +533,15 @@ "milestone": "colosseo", "acs": ["0028-GOVE-185"] }, + "Reward Improvements": { + "milestone": "colosseo", + "acs": [ + "0056-REWA-111", + "0056-REWA-112", + "0056-REWA-113", + "0056-REWA-114" + ] + }, "Unknown": { "milestone": "unknown", "acs": [] From f7984018f7691ad77e4210724086ec8a54b67fad Mon Sep 17 00:00:00 2001 From: Charlie Date: Mon, 15 Apr 2024 13:41:05 +0100 Subject: [PATCH 1064/1171] feat: add clarification for offseting negative scores --- protocol/0056-REWA-rewards_overview.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/protocol/0056-REWA-rewards_overview.md b/protocol/0056-REWA-rewards_overview.md index d9d2b4740..723615ca5 100644 --- a/protocol/0056-REWA-rewards_overview.md +++ b/protocol/0056-REWA-rewards_overview.md @@ -205,6 +205,8 @@ Let: - $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$ +NOTE: As reward metrics can be negative (e.g. a party has negative relative returns, all reward metrics must be offset by the lowest reward metric to ensure all metrics are positive before calculating each parties share of the rewards ) + $$d_{i}=r_{i} M_{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). From c6a9927b0be557d9090abba0087038ab2ff4baf2 Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Mon, 15 Apr 2024 16:05:15 +0100 Subject: [PATCH 1065/1171] feat: update AC FTCO-001 and 005 --- protocol/0065-FTCO-floating_point_consensus.md | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/protocol/0065-FTCO-floating_point_consensus.md b/protocol/0065-FTCO-floating_point_consensus.md index c197998d7..45524f065 100644 --- a/protocol/0065-FTCO-floating_point_consensus.md +++ b/protocol/0065-FTCO-floating_point_consensus.md @@ -94,10 +94,11 @@ This section outlines floating-point quantities `vega` currently relies on: - Up: 10%, - Down: 10%. - 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 and probability of trading get calculated (their values change from defaults). - - When the opening auction ends (choose uncrossing price that's different from first indicative uncrossing price) price monitoring bounds and probability of trading get recalculated. - - When the market goes into price 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. - - When the time-based trigger elapses price monitoring bounds and probability of trading get recalculated. + - 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 (their values change from defaults). + - When the opening auction ends (choose uncrossing price that's different from first indicative uncrossing price) price monitoring bounds get recalculated. + - When the market goes into price 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 get recalculated again and the time-based trigger countdown gets reset. + - When the time-based trigger elapses price monitoring bounds get recalculated. + - When mark price is updated, probability of trading get recalculated. 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. From ce1f085a81d3c4c3c6698e5c5b9402f54747b970 Mon Sep 17 00:00:00 2001 From: Charlie Date: Mon, 15 Apr 2024 16:56:17 +0100 Subject: [PATCH 1066/1171] feat: add specific AC for negative pnl case --- protocol/0056-REWA-rewards_overview.md | 7 ++++--- protocol/features.json | 3 ++- 2 files changed, 6 insertions(+), 4 deletions(-) diff --git a/protocol/0056-REWA-rewards_overview.md b/protocol/0056-REWA-rewards_overview.md index 723615ca5..bcd929e66 100644 --- a/protocol/0056-REWA-rewards_overview.md +++ b/protocol/0056-REWA-rewards_overview.md @@ -972,10 +972,11 @@ At the end of epoch 2, 10000 VEGA rewards should be distributed to the `ETHUSDT` ### Relative returns - If an eligible party has zero net returns, their relative returns reward metric should be zero (0056-REWA-111). -- If an eligible party has non-zero 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-112). +- If an eligible party has negative 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-112). +- 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-113). - 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, if an eligible party has zero net returns in all epochs, their relative return metric should be zero (0056-REWA-113). -- 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. Note epochs with zero returns should be included. (0056-REWA-114). +- If a `window_length>1` is specified in the recurring transfer, if an eligible party has zero net returns in all epochs, their relative return metric should be zero (0056-REWA-114). +- 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. Note epochs with zero returns should be included. (0056-REWA-115). ### Returns volatility diff --git a/protocol/features.json b/protocol/features.json index f5cc52256..f80070aa6 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -539,7 +539,8 @@ "0056-REWA-111", "0056-REWA-112", "0056-REWA-113", - "0056-REWA-114" + "0056-REWA-114", + "0056-REWA-115" ] }, "Unknown": { From d4cf9d23cd1b430d61979111d271f146e257ada7 Mon Sep 17 00:00:00 2001 From: David Siska <62546419+davidsiska-vega@users.noreply.github.com> Date: Wed, 17 Apr 2024 12:25:46 +0100 Subject: [PATCH 1067/1171] fix: clarify total fees (#2237) --- protocol/0057-TRAN-transfers.md | 1 + 1 file changed, 1 insertion(+) diff --git a/protocol/0057-TRAN-transfers.md b/protocol/0057-TRAN-transfers.md index e45bdc8f0..f85b602b4 100644 --- a/protocol/0057-TRAN-transfers.md +++ b/protocol/0057-TRAN-transfers.md @@ -110,6 +110,7 @@ A party should be able to configure the distribution of rewards by specifying th - `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. - `cap_reward_fee_multiple` [optional] - if set, the actual amount of reward transferred to each public key during distribution for this transfer will be `min(calculated_reward_in_quantum, cap_reward_fee_multiple × fees_paid_this_epoch_in_quantum)`. When calculating how much of the reward each one is getting, if some is left from the applied cap, we recalculate on the remaining balance only for parties that have not reached their cap until the leftover is less than 1 reward asset unit or the maximum rounds of recalculation is 10. If all keys are capped (i.e. the total amount of the transfer cannot be be sent to eligible keys without breaching the cap) then the remaining balance must be left in the reward pool and included in the distribution in future epochs. If this occurs, and the total transferred in a given epoch, this does not affect the size of the next iteration, which proceeds as normal (including decay factors etc.) as if the full transfer has been made. +Here, `fees_paid_this_epoch_in_quantum` are the total trading fees paid by a party (arising from `infrastructure_fee` paid, `maker_fee` paid plus `liquidity_fee` paid, over the epoch and expressed in quantum units). - `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. From 90ed3ce8567373afa414cb1065da0351693dac68 Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Wed, 17 Apr 2024 14:13:26 +0100 Subject: [PATCH 1068/1171] feat: address comment --- protocol/0065-FTCO-floating_point_consensus.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0065-FTCO-floating_point_consensus.md b/protocol/0065-FTCO-floating_point_consensus.md index 45524f065..805988b2b 100644 --- a/protocol/0065-FTCO-floating_point_consensus.md +++ b/protocol/0065-FTCO-floating_point_consensus.md @@ -98,7 +98,7 @@ This section outlines floating-point quantities `vega` currently relies on: - When the opening auction ends (choose uncrossing price that's different from first indicative uncrossing price) price monitoring bounds get recalculated. - When the market goes into price 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 get recalculated again and the time-based trigger countdown gets reset. - When the time-based trigger elapses price monitoring bounds get recalculated. - - When mark price is updated, probability of trading get recalculated. + - When mark price is updated, probability of trading get recalculated with a possible delay of a few blocks because it has to go via consensus. 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. From 98b6a816d4519c349c9e0e6320071a22fb025026 Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Wed, 17 Apr 2024 14:37:31 +0100 Subject: [PATCH 1069/1171] feat: tidy up --- protocol/0065-FTCO-floating_point_consensus.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/protocol/0065-FTCO-floating_point_consensus.md b/protocol/0065-FTCO-floating_point_consensus.md index 805988b2b..1496a0798 100644 --- a/protocol/0065-FTCO-floating_point_consensus.md +++ b/protocol/0065-FTCO-floating_point_consensus.md @@ -98,7 +98,8 @@ This section outlines floating-point quantities `vega` currently relies on: - When the opening auction ends (choose uncrossing price that's different from first indicative uncrossing price) price monitoring bounds get recalculated. - When the market goes into price 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 get recalculated again and the time-based trigger countdown gets reset. - When the time-based trigger elapses price monitoring bounds get recalculated. - - When mark price is updated, probability of trading get recalculated with a possible delay of a few blocks because it has to go via consensus. + - When mark price is updated, probability of trading get recalculated. + - All of the recalculations on price monitoring bounds and probability of trading will happen with a possible delay of a few blocks because they have to go via consensus. 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. From 9aef4ff5c7284e9ba1b406325c1b974ac4d63337 Mon Sep 17 00:00:00 2001 From: Charlie Date: Wed, 17 Apr 2024 15:29:04 +0100 Subject: [PATCH 1070/1171] feat: tidy marginal cost ACs --- protocol/0042-LIQF-setting_fees_and_rewarding_lps.md | 7 ++++--- protocol/features.json | 1 + 2 files changed, 5 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 8625329a4..c368c472f 100644 --- a/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md +++ b/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md @@ -382,13 +382,13 @@ Each LP further gets a performance bonus: $b_i \times B$ with a transfer type th - 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) - Given the fee setting method is marginal cost. An LP joining a spot market that is below the target stake with a higher fee bid than the current fee: their fee is used when the fee is next recalculated (0042-LIQF-073) - 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) -- Given the fee setting method is marginal cost. An LP joining a spot market that is below the target stake with a higher fee bid than the current fee: their fee is used when the fee is next recalculated (0042-LIQF-074) +- Given the fee setting method is marginal cost. 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-074) - 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) - Given the fee setting method is marginal cost. An LP joining a spot 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 when the fee is next recalculated (0042-LIQF-075) - 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) - Given the fee setting method is marginal cost. An LP joining a spot 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 when the fee is next recalculated (0042-LIQF-076) - 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) -- Given the fee setting method is marginal cost. An LP joining a spot 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 when the fee is next recalculated (0042-LIQF-077) +- Given the fee setting method is marginal cost. An LP joining a spot 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 when the fee is next recalculated (0042-LIQF-077) - 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) - Given the fee setting method is marginal cost. An LP joining a spot 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 when the fee is next recalculated (0042-LIQF-078) - 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) @@ -396,8 +396,9 @@ Each LP further gets a performance bonus: $b_i \times B$ with a transfer type th - 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) - Given the fee setting method is marginal cost. 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 when the fee is next recalculated (0042-LIQF-080) - 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) -- Given the fee setting method is marginal cost. 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 when the fee is next recalculated (0042-LIQF-081) +- Given the fee setting method is marginal cost. An LP leaves a spot 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 when the fee is next recalculated (0042-LIQF-081) - 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) +- Given the fee setting method is marginal cost. An LP leaves a spot market that is above target stake when their fee bid is higher than the one currently being used: fee doesn't change (0042-LIQF-106) ### API diff --git a/protocol/features.json b/protocol/features.json index 5bd7b9210..2f9e665c5 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -300,6 +300,7 @@ "0042-LIQF-079", "0042-LIQF-080", "0042-LIQF-081", + "0042-LIQF-106", "0042-LIQF-082", "0042-LIQF-083", "0042-LIQF-084", From 26f9d1ff5fb90c983ae810c58d6cd30ee5f587f7 Mon Sep 17 00:00:00 2001 From: Sohill-Patel <85170301+Sohill-Patel@users.noreply.github.com> Date: Fri, 19 Apr 2024 09:34:42 +0100 Subject: [PATCH 1071/1171] feat: couple nice to have acs --- protocol/0074-BTCH-batch-market-instructions.md | 4 ++-- protocol/features.json | 4 +++- 2 files changed, 5 insertions(+), 3 deletions(-) diff --git a/protocol/0074-BTCH-batch-market-instructions.md b/protocol/0074-BTCH-batch-market-instructions.md index 286d58f29..a0c74eb03 100644 --- a/protocol/0074-BTCH-batch-market-instructions.md +++ b/protocol/0074-BTCH-batch-market-instructions.md @@ -61,5 +61,5 @@ After entering or exiting an auction mid-batch, the full batch must be processed - 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) -- If the margin mode update transaction fails all transactions in the batch referring to the same market are Stopped. (0074-BTCH-020) -- If the margin mode update transaction fails all transactions in the batch referring to a different market are attempted as usual. (0074-BTCH-021) +- If the margin mode update transaction fails all transactions in the batch referring to the same market are Stopped. (0074-BTCH-020). For product spot (0074-BTCH-022) +- If the margin mode update transaction fails all transactions in the batch referring to a different market are attempted as usual. (0074-BTCH-021). For product spot (0074-BTCH-023) diff --git a/protocol/features.json b/protocol/features.json index 2f9e665c5..1d6201d60 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -334,7 +334,9 @@ "0044-LIME-116", "0044-LIME-117", "0044-LIME-118", - "0044-LIME-119" + "0044-LIME-119", + "0074-BTCH-022", + "0074-BTCH-023" ] }, "Spot stretch": { From cb6721c1ac950c33a0c4df7bd64be45296cd7d24 Mon Sep 17 00:00:00 2001 From: Charlie Date: Mon, 22 Apr 2024 13:18:28 +0100 Subject: [PATCH 1072/1171] chore: clarify offset logic --- protocol/0056-REWA-rewards_overview.md | 4 +++- protocol/features.json | 4 +++- 2 files changed, 6 insertions(+), 2 deletions(-) diff --git a/protocol/0056-REWA-rewards_overview.md b/protocol/0056-REWA-rewards_overview.md index bcd929e66..ad42789d4 100644 --- a/protocol/0056-REWA-rewards_overview.md +++ b/protocol/0056-REWA-rewards_overview.md @@ -205,7 +205,7 @@ Let: - $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$ -NOTE: As reward metrics can be negative (e.g. a party has negative relative returns, all reward metrics must be offset by the lowest reward metric to ensure all metrics are positive before calculating each parties share of the rewards ) +NOTE: As reward metrics can be negative (e.g. a party has negative relative returns, all reward metrics must be offset by the lowest **negative** reward metric to ensure all metrics are positive before calculating each parties share of the rewards) $$d_{i}=r_{i} M_{i}$$ @@ -977,6 +977,8 @@ At the end of epoch 2, 10000 VEGA rewards should be distributed to the `ETHUSDT` - 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, if an eligible party has zero net returns in all epochs, their relative return metric should be zero (0056-REWA-114). - 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. Note epochs with zero returns should be included. (0056-REWA-115). +- Given a recurring transfer is setup such that all eligible parties have a positive reward score, each parties metric is not offset and parties receive the correct rewards. (0056-REWA-116). +- Give a recurring transfer is setup such that all eligible parties have a negative reward score, each parties metric is offset by the lowest negative score and parties receive the correct rewards. (0056-REWA-117). ### Returns volatility diff --git a/protocol/features.json b/protocol/features.json index f80070aa6..78964c7e1 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -540,7 +540,9 @@ "0056-REWA-112", "0056-REWA-113", "0056-REWA-114", - "0056-REWA-115" + "0056-REWA-115", + "0056-REWA-116", + "0056-REWA-117" ] }, "Unknown": { From 97056b4c3a3c0b6c4cc1323cc7c712f0eb1e2c96 Mon Sep 17 00:00:00 2001 From: Charlie Date: Wed, 17 Apr 2024 09:58:17 +0100 Subject: [PATCH 1073/1171] feat: add realised returns metric --- .github/workflows/config/markdownlint.json | 2 +- protocol/0056-REWA-rewards_overview.md | 36 ++++++++++++++++++++++ protocol/features.json | 4 +-- 3 files changed, 38 insertions(+), 4 deletions(-) diff --git a/.github/workflows/config/markdownlint.json b/.github/workflows/config/markdownlint.json index bad5db322..eb2dc58bb 100644 --- a/.github/workflows/config/markdownlint.json +++ b/.github/workflows/config/markdownlint.json @@ -11,5 +11,5 @@ "MD024": { "siblings_only": true }, - "MD049": false, + "MD049": false } diff --git a/protocol/0056-REWA-rewards_overview.md b/protocol/0056-REWA-rewards_overview.md index ad42789d4..5e65dc451 100644 --- a/protocol/0056-REWA-rewards_overview.md +++ b/protocol/0056-REWA-rewards_overview.md @@ -130,6 +130,32 @@ If a party **is not** a consensus or standby validator, their reward metric is s $$m_v = 0$$ +### Realised Returns metric + +The realised returns metric, , $m_{rz}$, measures the returns a party has realised across a number of epochs. + +Let $rz_i$ be a parties realised returns in an epoch. At the start of each epoch, the network will set $rz_i$ to `0`. + +During the epoch, each parties realised returns will be incremented as follows: + +- a party pays or receives a funding payment + +$$rz_i = rz_i + fundingPayment$$ + +- a party **reduces** their position + +$$rz_i = rz_i + (tradePrice - averageEntryPrice) * positionDelta$$ + +At the end of the epoch, the average realised return metric over the last $N$ epochs is calculated as follows. + +Let: + +- $m_{rz}$ be the parties relative return reward metric +- $rz_i$ be the parties realised returns in the i th epoch +- $N$ be the window length specified in the recurring transfer. + +$$m_{rz} = \frac{\sum_{i}^{n}{rz_{i}}}{N}$$ + ### Market creation reward metrics There will be a single market creation reward metric and reward type. @@ -986,6 +1012,16 @@ At the end of epoch 2, 10000 VEGA rewards should be distributed to the `ETHUSDT` - 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 return volatility reward metric should be the variance of their relative returns in each market (0056-REWA-090). +### Realised returns + +- If an eligible party has a non-profitable position which has not been closed, they will not have a realised returns score and should receive no rewards (0056-REWA-109). +- If an eligible party has a non-profitable position which has been partly closed, they will have a negative realised returns score and should receive rewards (0056-REWA-110). +- If an eligible party had a non-profitable position which was fully closed, they will have a negative realised returns score and should receive rewards (0056-REWA-111). +- If a party open and closed a position such that there realised returns are `0`, the will have a realised returns score and should receive rewards (0056-REWA-112). +- If an eligible party has a profitable position which has not been closed, they will not have a realised returns score and should receive no rewards (0056-REWA-113). +- If an eligible party has a profitable position which has been partly closed, they will have a positive realised returns score and should receive rewards (0056-REWA-114). +- If an eligible party had a profitable position which was fully closed, they will have a positive realised returns score and should receive rewards (0056-REWA-115). + ### 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). diff --git a/protocol/features.json b/protocol/features.json index c8024dbf3..562a02072 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -543,9 +543,7 @@ "0056-REWA-112", "0056-REWA-113", "0056-REWA-114", - "0056-REWA-115", - "0056-REWA-116", - "0056-REWA-117" + "0056-REWA-115" ] }, "Unknown": { From a9a970e689984dc428dde06fa26f45ee48d58252 Mon Sep 17 00:00:00 2001 From: Charlie Date: Mon, 22 Apr 2024 13:47:47 +0100 Subject: [PATCH 1074/1171] chore: fix realised 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 5e65dc451..7963047aa 100644 --- a/protocol/0056-REWA-rewards_overview.md +++ b/protocol/0056-REWA-rewards_overview.md @@ -150,7 +150,7 @@ At the end of the epoch, the average realised return metric over the last $N$ ep Let: -- $m_{rz}$ be the parties relative return reward metric +- $m_{rz}$ be the parties realised return reward metric - $rz_i$ be the parties realised returns in the i th epoch - $N$ be the window length specified in the recurring transfer. From fa86ee1991f69d6085ef7095c07a047531cfe193 Mon Sep 17 00:00:00 2001 From: Charlie Date: Mon, 22 Apr 2024 17:28:31 +0100 Subject: [PATCH 1075/1171] chore: fix checks --- protocol/0056-REWA-rewards_overview.md | 24 ++++++++++++------------ protocol/features.json | 11 ++++++++++- wordlist.txt | 1 + 3 files changed, 23 insertions(+), 13 deletions(-) diff --git a/protocol/0056-REWA-rewards_overview.md b/protocol/0056-REWA-rewards_overview.md index 7963047aa..c7e050178 100644 --- a/protocol/0056-REWA-rewards_overview.md +++ b/protocol/0056-REWA-rewards_overview.md @@ -132,26 +132,26 @@ $$m_v = 0$$ ### Realised Returns metric -The realised returns metric, , $m_{rz}$, measures the returns a party has realised across a number of epochs. +The realised returns metric, $m_{rz}$, measures the returns a party has realised across a number of epochs. -Let $rz_i$ be a parties realised returns in an epoch. At the start of each epoch, the network will set $rz_i$ to `0`. +Let $rz_i$ be a parties realised returns in an epoch. At the start of each epoch, the network will set ${rz_i}$ to `0`. During the epoch, each parties realised returns will be incremented as follows: - a party pays or receives a funding payment -$$rz_i = rz_i + fundingPayment$$ +$${rz_i} = {rz_i} + funding payment$$ - a party **reduces** their position -$$rz_i = rz_i + (tradePrice - averageEntryPrice) * positionDelta$$ +$${rz_i} = {rz_i} + (trade price - average entry price) * position delta$$ At the end of the epoch, the average realised return metric over the last $N$ epochs is calculated as follows. Let: - $m_{rz}$ be the parties realised return reward metric -- $rz_i$ be the parties realised returns in the i th epoch +- ${rz_i}$ be the parties realised returns in the i th epoch - $N$ be the window length specified in the recurring transfer. $$m_{rz} = \frac{\sum_{i}^{n}{rz_{i}}}{N}$$ @@ -1014,13 +1014,13 @@ At the end of epoch 2, 10000 VEGA rewards should be distributed to the `ETHUSDT` ### Realised returns -- If an eligible party has a non-profitable position which has not been closed, they will not have a realised returns score and should receive no rewards (0056-REWA-109). -- If an eligible party has a non-profitable position which has been partly closed, they will have a negative realised returns score and should receive rewards (0056-REWA-110). -- If an eligible party had a non-profitable position which was fully closed, they will have a negative realised returns score and should receive rewards (0056-REWA-111). -- If a party open and closed a position such that there realised returns are `0`, the will have a realised returns score and should receive rewards (0056-REWA-112). -- If an eligible party has a profitable position which has not been closed, they will not have a realised returns score and should receive no rewards (0056-REWA-113). -- If an eligible party has a profitable position which has been partly closed, they will have a positive realised returns score and should receive rewards (0056-REWA-114). -- If an eligible party had a profitable position which was fully closed, they will have a positive realised returns score and should receive rewards (0056-REWA-115). +- If an eligible party has a non-profitable position which has not been closed, they will not have a realised returns score and should receive no rewards (0056-REWA-118). +- If an eligible party has a non-profitable position which has been partly closed, they will have a negative realised returns score and should receive rewards (0056-REWA-119). +- If an eligible party had a non-profitable position which was fully closed, they will have a negative realised returns score and should receive rewards (0056-REWA-120). +- If a party open and closed a position such that there realised returns are `0`, the will have a realised returns score and should receive rewards (0056-REWA-121). +- If an eligible party has a profitable position which has not been closed, they will not have a realised returns score and should receive no rewards (0056-REWA-122). +- If an eligible party has a profitable position which has been partly closed, they will have a positive realised returns score and should receive rewards (0056-REWA-123). +- If an eligible party had a profitable position which was fully closed, they will have a positive realised returns score and should receive rewards (0056-REWA-124). ### Validator ranking metric diff --git a/protocol/features.json b/protocol/features.json index 562a02072..30a2bee33 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -543,7 +543,16 @@ "0056-REWA-112", "0056-REWA-113", "0056-REWA-114", - "0056-REWA-115" + "0056-REWA-115", + "0056-REWA-116", + "0056-REWA-117", + "0056-REWA-118", + "0056-REWA-119", + "0056-REWA-120", + "0056-REWA-121", + "0056-REWA-122", + "0056-REWA-123", + "0056-REWA-124" ] }, "Unknown": { diff --git a/wordlist.txt b/wordlist.txt index 81a3aab42..e9fa28623 100644 --- a/wordlist.txt +++ b/wordlist.txt @@ -341,3 +341,4 @@ mathbb geq vee mathbf +rz \ No newline at end of file From 5ee68848bb460a8bb18ce8038b7d39091a1a66be Mon Sep 17 00:00:00 2001 From: Charlie Date: Tue, 23 Apr 2024 10:11:14 +0100 Subject: [PATCH 1076/1171] feat: add clarification for short positions --- protocol/0056-REWA-rewards_overview.md | 28 ++++++++++++++++++-------- protocol/features.json | 9 ++++++++- 2 files changed, 28 insertions(+), 9 deletions(-) diff --git a/protocol/0056-REWA-rewards_overview.md b/protocol/0056-REWA-rewards_overview.md index c7e050178..f7745b610 100644 --- a/protocol/0056-REWA-rewards_overview.md +++ b/protocol/0056-REWA-rewards_overview.md @@ -142,10 +142,14 @@ During the epoch, each parties realised returns will be incremented as follows: $${rz_i} = {rz_i} + funding payment$$ -- a party **reduces** their position +- a party **reduces** their **LONG** position $${rz_i} = {rz_i} + (trade price - average entry price) * position delta$$ +- a party **reduces** their **SHORT** position + +$${rz_i} = {rz_i} + (average entry price - trade price) * position delta$$ + At the end of the epoch, the average realised return metric over the last $N$ epochs is calculated as follows. Let: @@ -1014,13 +1018,21 @@ At the end of epoch 2, 10000 VEGA rewards should be distributed to the `ETHUSDT` ### Realised returns -- If an eligible party has a non-profitable position which has not been closed, they will not have a realised returns score and should receive no rewards (0056-REWA-118). -- If an eligible party has a non-profitable position which has been partly closed, they will have a negative realised returns score and should receive rewards (0056-REWA-119). -- If an eligible party had a non-profitable position which was fully closed, they will have a negative realised returns score and should receive rewards (0056-REWA-120). -- If a party open and closed a position such that there realised returns are `0`, the will have a realised returns score and should receive rewards (0056-REWA-121). -- If an eligible party has a profitable position which has not been closed, they will not have a realised returns score and should receive no rewards (0056-REWA-122). -- If an eligible party has a profitable position which has been partly closed, they will have a positive realised returns score and should receive rewards (0056-REWA-123). -- If an eligible party had a profitable position which was fully closed, they will have a positive realised returns score and should receive rewards (0056-REWA-124). +- If an eligible party has a non-profitable long position which has not been closed, they will not have a realised returns score and should receive no rewards (0056-REWA-118). +- If an eligible party has a non-profitable long position which has been partly closed, they will have a negative realised returns score and should receive rewards (0056-REWA-119). +- If an eligible party had a non-profitable long position which was fully closed, they will have a negative realised returns score and should receive rewards (0056-REWA-120). +- If a party open and closed a long position such that there realised returns are `0`, the will have a realised returns score and should receive rewards (0056-REWA-121). +- If an eligible party has a profitable long position which has not been closed, they will not have a realised returns score and should receive no rewards (0056-REWA-122). +- If an eligible party has a profitable long position which has been partly closed, they will have a positive realised returns score and should receive rewards (0056-REWA-123). +- If an eligible party had a profitable long position which was fully closed, they will have a positive realised returns score and should receive rewards (0056-REWA-124). + +- If an eligible party has a non-profitable short position which has not been closed, they will not have a realised returns score and should receive no rewards (0056-REWA-125). +- If an eligible party has a non-profitable short position which has been partly closed, they will have a negative realised returns score and should receive rewards (0056-REWA-126). +- If an eligible party had a non-profitable short position which was fully closed, they will have a negative realised returns score and should receive rewards (0056-REWA-127). +- If a party open and closed a short position such that there realised returns are `0`, the will have a realised returns score and should receive rewards (0056-REWA-128). +- If an eligible party has a profitable short position which has not been closed, they will not have a realised returns score and should receive no rewards (0056-REWA-129). +- If an eligible party has a profitable short position which has been partly closed, they will have a positive realised returns score and should receive rewards (0056-REWA-130). +- If an eligible party had a profitable short position which was fully closed, they will have a positive realised returns score and should receive rewards (0056-REWA-131). ### Validator ranking metric diff --git a/protocol/features.json b/protocol/features.json index 30a2bee33..b47f05881 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -552,7 +552,14 @@ "0056-REWA-121", "0056-REWA-122", "0056-REWA-123", - "0056-REWA-124" + "0056-REWA-124", + "0056-REWA-125", + "0056-REWA-126", + "0056-REWA-127", + "0056-REWA-128", + "0056-REWA-129", + "0056-REWA-130", + "0056-REWA-131" ] }, "Unknown": { From b67b12e14598ac95539b06ad556a126332fddb83 Mon Sep 17 00:00:00 2001 From: Charlie Date: Thu, 18 Apr 2024 10:02:31 +0100 Subject: [PATCH 1077/1171] chore: remove invalid stop AC --- protocol/0014-ORDT-order_types.md | 2 +- protocol/features.json | 1 - 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/protocol/0014-ORDT-order_types.md b/protocol/0014-ORDT-order_types.md index c36ebfe24..4f814320a 100644 --- a/protocol/0014-ORDT-order_types.md +++ b/protocol/0014-ORDT-order_types.md @@ -363,7 +363,7 @@ In Spot market, for multiple iceberg orders submitted as a batch of orders with - 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). For spot products (0014-ORDT-177) - If a pair of stop orders are specified as OCO, one being triggered also removes the other from the book. (0014-ORDT-056). For spot products (0014-ORDT-166) -- 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). For spot products (0014-ORDT-140) +- 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). For spot products (0014-ORDT-141) diff --git a/protocol/features.json b/protocol/features.json index b47f05881..6d2f79c46 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -395,7 +395,6 @@ "0014-ORDT-124", "0014-ORDT-125", "0014-ORDT-126", - "0014-ORDT-140", "0014-ORDT-141", "0014-ORDT-142", "0014-ORDT-143", From 0412272498577ab158b0a7a114e8d7718e3e9d88 Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Tue, 23 Apr 2024 15:15:44 +0100 Subject: [PATCH 1078/1171] feat: add AC for position decimal in spot market --- 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 841dd4fb5..cb8726865 100644 --- a/protocol/0028-GOVE-governance.md +++ b/protocol/0028-GOVE-governance.md @@ -553,7 +553,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 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) +- A market proposal with position decimal places not in `{-6,...,-1,0,1,2,...,6}` gets rejected. (0028-GOVE-062) For product spot: (0028-GOVE-075) - A market proposal with a tick size less than or equal to `0` gets rejected (0028-GOVE-180). - At enactment, a market change proposal updating the tick size leaves in place all orders where the quoted price is not an exact multiple of `10^-mdp` (where `mdp` is the market decimal places) (0028-GOVE-182). From 9f849e593ce01f246d850d79e81e6aad493c1bcf Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Tue, 23 Apr 2024 15:18:00 +0100 Subject: [PATCH 1079/1171] feat: update json file --- protocol/features.json | 1 + 1 file changed, 1 insertion(+) diff --git a/protocol/features.json b/protocol/features.json index 6d2f79c46..95ab5cf39 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -196,6 +196,7 @@ "0026-AUCT-029", "0026-AUCT-031", "0026-AUCT-032", + "0028-GOVE-075", "0032-PRIM-022", "0032-PRIM-023", "0032-PRIM-024", From 22f19bc789dc6652daa0117e0466a6925b1031b0 Mon Sep 17 00:00:00 2001 From: Charlie Date: Tue, 23 Apr 2024 16:23:33 +0100 Subject: [PATCH 1080/1171] chore: add more acceptance criteria --- protocol/0056-REWA-rewards_overview.md | 4 ++++ protocol/features.json | 6 +++++- 2 files changed, 9 insertions(+), 1 deletion(-) diff --git a/protocol/0056-REWA-rewards_overview.md b/protocol/0056-REWA-rewards_overview.md index f7745b610..585949695 100644 --- a/protocol/0056-REWA-rewards_overview.md +++ b/protocol/0056-REWA-rewards_overview.md @@ -1021,18 +1021,22 @@ At the end of epoch 2, 10000 VEGA rewards should be distributed to the `ETHUSDT` - If an eligible party has a non-profitable long position which has not been closed, they will not have a realised returns score and should receive no rewards (0056-REWA-118). - If an eligible party has a non-profitable long position which has been partly closed, they will have a negative realised returns score and should receive rewards (0056-REWA-119). - If an eligible party had a non-profitable long position which was fully closed, they will have a negative realised returns score and should receive rewards (0056-REWA-120). +- If an eligible party had a non-profitable long position which was fully closed with an order changing the side of the position, only the closed volume will contribute to the parties realised returns, and they will have a positive realised returns score and therefore receive rewards (0056-REWA-132). - If a party open and closed a long position such that there realised returns are `0`, the will have a realised returns score and should receive rewards (0056-REWA-121). - If an eligible party has a profitable long position which has not been closed, they will not have a realised returns score and should receive no rewards (0056-REWA-122). - If an eligible party has a profitable long position which has been partly closed, they will have a positive realised returns score and should receive rewards (0056-REWA-123). - If an eligible party had a profitable long position which was fully closed, they will have a positive realised returns score and should receive rewards (0056-REWA-124). +- If an eligible party had a profitable long position which was fully closed with an order changing the side of the position, only the closed volume will contribute to the parties realised returns, and they will have a positive realised returns score and therefore receive rewards (0056-REWA-133). - If an eligible party has a non-profitable short position which has not been closed, they will not have a realised returns score and should receive no rewards (0056-REWA-125). - If an eligible party has a non-profitable short position which has been partly closed, they will have a negative realised returns score and should receive rewards (0056-REWA-126). - If an eligible party had a non-profitable short position which was fully closed, they will have a negative realised returns score and should receive rewards (0056-REWA-127). +- If an eligible party had a non-profitable short position which was fully closed with an order changing the side of the position, only the closed volume will contribute to the parties realised returns, and they will have a positive realised returns score and therefore receive rewards (0056-REWA-134). - If a party open and closed a short position such that there realised returns are `0`, the will have a realised returns score and should receive rewards (0056-REWA-128). - If an eligible party has a profitable short position which has not been closed, they will not have a realised returns score and should receive no rewards (0056-REWA-129). - If an eligible party has a profitable short position which has been partly closed, they will have a positive realised returns score and should receive rewards (0056-REWA-130). - If an eligible party had a profitable short position which was fully closed, they will have a positive realised returns score and should receive rewards (0056-REWA-131). +- If an eligible party had a profitable short position which was fully closed with an order changing the side of the position, only the closed volume will contribute to the parties realised returns, and they will have a positive realised returns score and therefore receive rewards (0056-REWA-135). ### Validator ranking metric diff --git a/protocol/features.json b/protocol/features.json index 95ab5cf39..3f3197adc 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -559,7 +559,11 @@ "0056-REWA-128", "0056-REWA-129", "0056-REWA-130", - "0056-REWA-131" + "0056-REWA-131", + "0056-REWA-132", + "0056-REWA-133", + "0056-REWA-134", + "0056-REWA-135" ] }, "Unknown": { From 6951cd090ccdaaed5db8d614fb8ad89b53a24dd7 Mon Sep 17 00:00:00 2001 From: Charlie Date: Tue, 16 Apr 2024 12:07:14 +0100 Subject: [PATCH 1081/1171] feat: publish interim reward data --- protocol/0056-REWA-rewards_overview.md | 48 +++++++++++++++++++++++++- 1 file changed, 47 insertions(+), 1 deletion(-) diff --git a/protocol/0056-REWA-rewards_overview.md b/protocol/0056-REWA-rewards_overview.md index 585949695..ecb237528 100644 --- a/protocol/0056-REWA-rewards_overview.md +++ b/protocol/0056-REWA-rewards_overview.md @@ -32,7 +32,6 @@ At the end of the epoch: 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 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. @@ -42,6 +41,32 @@ For reward metrics relating to trading, an individual must meet the [staking req 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`. +## Publishing Interim Reward Information + +Although rewards are distributed at the end of an epoch, to give users of the protocol an understanding of what rewards they are likely to receive at the next distribution event, the protocol must publish interim data during the epoch to populate data nodes. + +For each game, each entities (individual or team) **current reward metric** and rank in the game is to be published at the specified frequency. Note, the actual reward metric should be published rather than the underlying data in the current epoch, this is important for games where the window length is greater than `1`. + +| Reward Type | Update Frequency | +| ------------------------------------------------------- | --------------------------------- | +| [Maker Fees Paid](#fee-based-reward-metrics) | every mark-to-market (MTM) period | +| [Maker Fees Received](#fee-based-reward-metrics) | every mark-to-market (MTM) period | +| [Liquidity Fees Received](#fee-based-reward-metrics) | every epoch | +| [Market Creation](#market-creation-reward-metrics) | every epoch | +| [Average Position](#average-position-metric) | every mark-to-market (MTM) period | +| [Relative Return](#relative-return-metric) | every mark-to-market (MTM) period | +| [Returns Volatility Metric](#returns-volatility-metric) | every mark-to-market (MTM) period | +| [Validator Ranking](#validator-ranking-metric) | every epoch | + + +For each game, the following data for each party should be published every MTM period so dAPPs are able to relay information to users about their eligibility and expected rewards. + +| Game Information | Update Frequency | +| ------------------------------------------------------ | --------------------------------- | +| Notional Time Weighted Average Position | every mark-to-market (MTM) period | +| Total Fees Paid | every mark-to-market (MTM) period | + + ### Fee-based reward metrics There will be three reward metrics calculated based on fees. @@ -1072,3 +1097,24 @@ At the end of epoch 2, 10000 VEGA rewards should be distributed to the `ETHUSDT` - 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). + + +## Interim Reward Information + +- Given a recurring transfer where the entity scope is individuals and the dispatch metric is maker fees paid, a parties reward metric should be updated and published every mark-to-market period. (0056-REWA-116). +- Given a recurring transfer where the entity scope is individuals and the dispatch metric is maker fees received, a parties reward metric should be updated and published every mark-to-market period. (0056-REWA-117). +- Given a recurring transfer where the entity scope is individuals and the dispatch metric is liquidity fees received, a parties reward metric should be updated and published at the end of every epoch. (0056-REWA-118). +- Given a recurring transfer where the entity scope is individuals and the dispatch metric is market creation, a parties reward metric should be updated and published at the end of every epoch. (0056-REWA-119). +- Given a recurring transfer where the entity scope is individuals and the dispatch metric is average position, a parties reward metric should be updated and published every mark-to-market period. (0056-REWA-120). +- Given a recurring transfer where the entity scope is individuals and the dispatch metric is relative returns, a parties reward metric should be updated and published every mark-to-market period. (0056-REWA-121). +- Given a recurring transfer where the entity scope is individuals and the dispatch metric is returns volatility, a parties reward metric should be updated and published every mark-to-market period. (0056-REWA-122). +- Given a recurring transfer where the entity scope is individuals and the dispatch metric is validator ranking, a parties reward metric should be updated and published at the end of every epoch. (0056-REWA-123). + +- Given a recurring transfer where the entity scope is teams and the dispatch metric is maker fees paid, a teams reward metric should be updated and published every mark-to-market period. (0056-REWA-124). +- Given a recurring transfer where the entity scope is teams and the dispatch metric is maker fees received, a teams reward metric should be updated and published every mark-to-market period. (0056-REWA-125). +- Given a recurring transfer where the entity scope is teams and the dispatch metric is liquidity fees received, a teams reward metric should be updated and published at the end of every epoch. (0056-REWA-126). +- Given a recurring transfer where the entity scope is teams and the dispatch metric is market creation, a teams reward metric should be updated and published at the end of every epoch. (0056-REWA-127). +- Given a recurring transfer where the entity scope is teams and the dispatch metric is average position, a teams reward metric should be updated and published every mark-to-market period. (0056-REWA-128). +- Given a recurring transfer where the entity scope is teams and the dispatch metric is relative returns, a teams reward metric should be updated and published every mark-to-market period. (0056-REWA-129). +- Given a recurring transfer where the entity scope is teams and the dispatch metric is returns volatility, a teams reward metric should be updated and published every mark-to-market period. (0056-REWA-130). +- Given a recurring transfer where the entity scope is teams and the dispatch metric is validator ranking, a teams reward metric should be updated and published at the end of every epoch. (0056-REWA-131). \ No newline at end of file From dbb614b45e8176c505b37938fceb6dab9e828213 Mon Sep 17 00:00:00 2001 From: Charlie Date: Tue, 16 Apr 2024 12:20:28 +0100 Subject: [PATCH 1082/1171] fix: updates for checks --- 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 ecb237528..0f39cf8f9 100644 --- a/protocol/0056-REWA-rewards_overview.md +++ b/protocol/0056-REWA-rewards_overview.md @@ -59,7 +59,7 @@ For each game, each entities (individual or team) **current reward metric** and | [Validator Ranking](#validator-ranking-metric) | every epoch | -For each game, the following data for each party should be published every MTM period so dAPPs are able to relay information to users about their eligibility and expected rewards. +For each game, the following data for each party should be published every MTM period so APIs able to relay information to users about their eligibility and expected rewards. | Game Information | Update Frequency | | ------------------------------------------------------ | --------------------------------- | @@ -1117,4 +1117,4 @@ At the end of epoch 2, 10000 VEGA rewards should be distributed to the `ETHUSDT` - Given a recurring transfer where the entity scope is teams and the dispatch metric is average position, a teams reward metric should be updated and published every mark-to-market period. (0056-REWA-128). - Given a recurring transfer where the entity scope is teams and the dispatch metric is relative returns, a teams reward metric should be updated and published every mark-to-market period. (0056-REWA-129). - Given a recurring transfer where the entity scope is teams and the dispatch metric is returns volatility, a teams reward metric should be updated and published every mark-to-market period. (0056-REWA-130). -- Given a recurring transfer where the entity scope is teams and the dispatch metric is validator ranking, a teams reward metric should be updated and published at the end of every epoch. (0056-REWA-131). \ No newline at end of file +- Given a recurring transfer where the entity scope is teams and the dispatch metric is validator ranking, a teams reward metric should be updated and published at the end of every epoch. (0056-REWA-131). From 070d611bcc7dc6f9ecf369bf56b1d3d42a7b883a Mon Sep 17 00:00:00 2001 From: Charlie Date: Mon, 22 Apr 2024 12:13:06 +0100 Subject: [PATCH 1083/1171] chore: restrict update frequency by network parameter --- protocol/0056-REWA-rewards_overview.md | 48 +++++++++++--------------- 1 file changed, 20 insertions(+), 28 deletions(-) diff --git a/protocol/0056-REWA-rewards_overview.md b/protocol/0056-REWA-rewards_overview.md index 0f39cf8f9..ed7b3ea29 100644 --- a/protocol/0056-REWA-rewards_overview.md +++ b/protocol/0056-REWA-rewards_overview.md @@ -15,6 +15,10 @@ The parameter `rewards.marketCreationQuantumMultiple` will be used together with It is reasonable to assume that `quantum` will be set to a value around `1 USD` (though there will likely be quite significant variation from this for assets that are not well correlated with USD). Therefore, for example, to reward futures markets when they reach a lifetime traded notional over 1 mil USD, then this parameter should be set to around `1000000`. Any decimal value strictly greater than `0` is valid. +## New network parameter for updating interim scores + +The parameter `rewards.updateFrequency` which is a duration string (e.g. `1m`) defines how frequency [interim scores](#publishing-interim-reward-information) are calculated and exposes for competitions. + ## Reward process high level At a high level, rewards work as follows: @@ -43,28 +47,16 @@ For reward transfers where the [scope](./0057-TRAN-transfers.md#recurring-transf ## Publishing Interim Reward Information -Although rewards are distributed at the end of an epoch, to give users of the protocol an understanding of what rewards they are likely to receive at the next distribution event, the protocol must publish interim data during the epoch to populate data nodes. - -For each game, each entities (individual or team) **current reward metric** and rank in the game is to be published at the specified frequency. Note, the actual reward metric should be published rather than the underlying data in the current epoch, this is important for games where the window length is greater than `1`. +Although rewards are distributed at the end of an epoch, to give users of the protocol an understanding of what rewards they are likely to receive at the next distribution event, APIs must make interim data available throughout an epoch. -| Reward Type | Update Frequency | -| ------------------------------------------------------- | --------------------------------- | -| [Maker Fees Paid](#fee-based-reward-metrics) | every mark-to-market (MTM) period | -| [Maker Fees Received](#fee-based-reward-metrics) | every mark-to-market (MTM) period | -| [Liquidity Fees Received](#fee-based-reward-metrics) | every epoch | -| [Market Creation](#market-creation-reward-metrics) | every epoch | -| [Average Position](#average-position-metric) | every mark-to-market (MTM) period | -| [Relative Return](#relative-return-metric) | every mark-to-market (MTM) period | -| [Returns Volatility Metric](#returns-volatility-metric) | every mark-to-market (MTM) period | -| [Validator Ranking](#validator-ranking-metric) | every epoch | +For each game, each entities (individual or team) **current reward metric** and rank in the game is to be updated every `rewards.updateFrequency` seconds. Note, the actual reward metric should be updated and exposed rather than the underlying data in the current epoch, this is important for games where the window length is greater than `1`. +For reward metrics which can only be calculated at the end of the epoch, e.g. [market creation](#market-creation-reward-metrics), [liquidity fees received](#fee-based-reward-metrics), and [validator ranking](#validator-ranking-metric); scores are only required to be updated and exposed at the end of the epoch. -For each game, the following data for each party should be published every MTM period so APIs able to relay information to users about their eligibility and expected rewards. +For each game, the following data for each party should also be published every update period so APIs are able to relay information to users about their eligibility and expected rewards. -| Game Information | Update Frequency | -| ------------------------------------------------------ | --------------------------------- | -| Notional Time Weighted Average Position | every mark-to-market (MTM) period | -| Total Fees Paid | every mark-to-market (MTM) period | +- Notional Time Weighted Average Position +- Total Fees Paid ### Fee-based reward metrics @@ -1101,20 +1093,20 @@ At the end of epoch 2, 10000 VEGA rewards should be distributed to the `ETHUSDT` ## Interim Reward Information -- Given a recurring transfer where the entity scope is individuals and the dispatch metric is maker fees paid, a parties reward metric should be updated and published every mark-to-market period. (0056-REWA-116). -- Given a recurring transfer where the entity scope is individuals and the dispatch metric is maker fees received, a parties reward metric should be updated and published every mark-to-market period. (0056-REWA-117). +- Given a recurring transfer where the entity scope is individuals and the dispatch metric is maker fees paid, a parties reward metric should be updated and published every `rewards.updateFrequency` seconds. (0056-REWA-116). +- Given a recurring transfer where the entity scope is individuals and the dispatch metric is maker fees received, a parties reward metric should be updated and published every `rewards.updateFrequency` seconds. (0056-REWA-117). - Given a recurring transfer where the entity scope is individuals and the dispatch metric is liquidity fees received, a parties reward metric should be updated and published at the end of every epoch. (0056-REWA-118). - Given a recurring transfer where the entity scope is individuals and the dispatch metric is market creation, a parties reward metric should be updated and published at the end of every epoch. (0056-REWA-119). -- Given a recurring transfer where the entity scope is individuals and the dispatch metric is average position, a parties reward metric should be updated and published every mark-to-market period. (0056-REWA-120). -- Given a recurring transfer where the entity scope is individuals and the dispatch metric is relative returns, a parties reward metric should be updated and published every mark-to-market period. (0056-REWA-121). -- Given a recurring transfer where the entity scope is individuals and the dispatch metric is returns volatility, a parties reward metric should be updated and published every mark-to-market period. (0056-REWA-122). +- Given a recurring transfer where the entity scope is individuals and the dispatch metric is average position, a parties reward metric should be updated and published every `rewards.updateFrequency` seconds. (0056-REWA-120). +- Given a recurring transfer where the entity scope is individuals and the dispatch metric is relative returns, a parties reward metric should be updated and published every `rewards.updateFrequency` seconds. (0056-REWA-121). +- Given a recurring transfer where the entity scope is individuals and the dispatch metric is returns volatility, a parties reward metric should be updated and published every `rewards.updateFrequency` seconds. (0056-REWA-122). - Given a recurring transfer where the entity scope is individuals and the dispatch metric is validator ranking, a parties reward metric should be updated and published at the end of every epoch. (0056-REWA-123). -- Given a recurring transfer where the entity scope is teams and the dispatch metric is maker fees paid, a teams reward metric should be updated and published every mark-to-market period. (0056-REWA-124). -- Given a recurring transfer where the entity scope is teams and the dispatch metric is maker fees received, a teams reward metric should be updated and published every mark-to-market period. (0056-REWA-125). +- Given a recurring transfer where the entity scope is teams and the dispatch metric is maker fees paid, a teams reward metric should be updated and published every `rewards.updateFrequency` seconds. (0056-REWA-124). +- Given a recurring transfer where the entity scope is teams and the dispatch metric is maker fees received, a teams reward metric should be updated and published every `rewards.updateFrequency` seconds. (0056-REWA-125). - Given a recurring transfer where the entity scope is teams and the dispatch metric is liquidity fees received, a teams reward metric should be updated and published at the end of every epoch. (0056-REWA-126). - Given a recurring transfer where the entity scope is teams and the dispatch metric is market creation, a teams reward metric should be updated and published at the end of every epoch. (0056-REWA-127). -- Given a recurring transfer where the entity scope is teams and the dispatch metric is average position, a teams reward metric should be updated and published every mark-to-market period. (0056-REWA-128). -- Given a recurring transfer where the entity scope is teams and the dispatch metric is relative returns, a teams reward metric should be updated and published every mark-to-market period. (0056-REWA-129). -- Given a recurring transfer where the entity scope is teams and the dispatch metric is returns volatility, a teams reward metric should be updated and published every mark-to-market period. (0056-REWA-130). +- Given a recurring transfer where the entity scope is teams and the dispatch metric is average position, a teams reward metric should be updated and published every `rewards.updateFrequency` seconds. (0056-REWA-128). +- Given a recurring transfer where the entity scope is teams and the dispatch metric is relative returns, a teams reward metric should be updated and published every `rewards.updateFrequency` seconds. (0056-REWA-129). +- Given a recurring transfer where the entity scope is teams and the dispatch metric is returns volatility, a teams reward metric should be updated and published every `rewards.updateFrequency` seconds. (0056-REWA-130). - Given a recurring transfer where the entity scope is teams and the dispatch metric is validator ranking, a teams reward metric should be updated and published at the end of every epoch. (0056-REWA-131). From 9b8777b537dc2883ef480d8714e76578b3f2e104 Mon Sep 17 00:00:00 2001 From: Charlie Date: Tue, 23 Apr 2024 16:27:13 +0100 Subject: [PATCH 1084/1171] chore: renumber AC codes --- protocol/0056-REWA-rewards_overview.md | 34 +++++++++++++------------- protocol/features.json | 18 +++++++++++++- 2 files changed, 34 insertions(+), 18 deletions(-) diff --git a/protocol/0056-REWA-rewards_overview.md b/protocol/0056-REWA-rewards_overview.md index ed7b3ea29..1be21b140 100644 --- a/protocol/0056-REWA-rewards_overview.md +++ b/protocol/0056-REWA-rewards_overview.md @@ -1093,20 +1093,20 @@ At the end of epoch 2, 10000 VEGA rewards should be distributed to the `ETHUSDT` ## Interim Reward Information -- Given a recurring transfer where the entity scope is individuals and the dispatch metric is maker fees paid, a parties reward metric should be updated and published every `rewards.updateFrequency` seconds. (0056-REWA-116). -- Given a recurring transfer where the entity scope is individuals and the dispatch metric is maker fees received, a parties reward metric should be updated and published every `rewards.updateFrequency` seconds. (0056-REWA-117). -- Given a recurring transfer where the entity scope is individuals and the dispatch metric is liquidity fees received, a parties reward metric should be updated and published at the end of every epoch. (0056-REWA-118). -- Given a recurring transfer where the entity scope is individuals and the dispatch metric is market creation, a parties reward metric should be updated and published at the end of every epoch. (0056-REWA-119). -- Given a recurring transfer where the entity scope is individuals and the dispatch metric is average position, a parties reward metric should be updated and published every `rewards.updateFrequency` seconds. (0056-REWA-120). -- Given a recurring transfer where the entity scope is individuals and the dispatch metric is relative returns, a parties reward metric should be updated and published every `rewards.updateFrequency` seconds. (0056-REWA-121). -- Given a recurring transfer where the entity scope is individuals and the dispatch metric is returns volatility, a parties reward metric should be updated and published every `rewards.updateFrequency` seconds. (0056-REWA-122). -- Given a recurring transfer where the entity scope is individuals and the dispatch metric is validator ranking, a parties reward metric should be updated and published at the end of every epoch. (0056-REWA-123). - -- Given a recurring transfer where the entity scope is teams and the dispatch metric is maker fees paid, a teams reward metric should be updated and published every `rewards.updateFrequency` seconds. (0056-REWA-124). -- Given a recurring transfer where the entity scope is teams and the dispatch metric is maker fees received, a teams reward metric should be updated and published every `rewards.updateFrequency` seconds. (0056-REWA-125). -- Given a recurring transfer where the entity scope is teams and the dispatch metric is liquidity fees received, a teams reward metric should be updated and published at the end of every epoch. (0056-REWA-126). -- Given a recurring transfer where the entity scope is teams and the dispatch metric is market creation, a teams reward metric should be updated and published at the end of every epoch. (0056-REWA-127). -- Given a recurring transfer where the entity scope is teams and the dispatch metric is average position, a teams reward metric should be updated and published every `rewards.updateFrequency` seconds. (0056-REWA-128). -- Given a recurring transfer where the entity scope is teams and the dispatch metric is relative returns, a teams reward metric should be updated and published every `rewards.updateFrequency` seconds. (0056-REWA-129). -- Given a recurring transfer where the entity scope is teams and the dispatch metric is returns volatility, a teams reward metric should be updated and published every `rewards.updateFrequency` seconds. (0056-REWA-130). -- Given a recurring transfer where the entity scope is teams and the dispatch metric is validator ranking, a teams reward metric should be updated and published at the end of every epoch. (0056-REWA-131). +- Given a recurring transfer where the entity scope is individuals and the dispatch metric is maker fees paid, a parties reward metric should be updated and published every `rewards.updateFrequency` seconds. (0056-REWA-136). +- Given a recurring transfer where the entity scope is individuals and the dispatch metric is maker fees received, a parties reward metric should be updated and published every `rewards.updateFrequency` seconds. (0056-REWA-137). +- Given a recurring transfer where the entity scope is individuals and the dispatch metric is liquidity fees received, a parties reward metric should be updated and published at the end of every epoch. (0056-REWA-138). +- Given a recurring transfer where the entity scope is individuals and the dispatch metric is market creation, a parties reward metric should be updated and published at the end of every epoch. (0056-REWA-139). +- Given a recurring transfer where the entity scope is individuals and the dispatch metric is average position, a parties reward metric should be updated and published every `rewards.updateFrequency` seconds. (0056-REWA-140). +- Given a recurring transfer where the entity scope is individuals and the dispatch metric is relative returns, a parties reward metric should be updated and published every `rewards.updateFrequency` seconds. (0056-REWA-141). +- Given a recurring transfer where the entity scope is individuals and the dispatch metric is returns volatility, a parties reward metric should be updated and published every `rewards.updateFrequency` seconds. (0056-REWA-142). +- Given a recurring transfer where the entity scope is individuals and the dispatch metric is validator ranking, a parties reward metric should be updated and published at the end of every epoch. (0056-REWA-143). + +- Given a recurring transfer where the entity scope is teams and the dispatch metric is maker fees paid, a teams reward metric should be updated and published every `rewards.updateFrequency` seconds. (0056-REWA-144). +- Given a recurring transfer where the entity scope is teams and the dispatch metric is maker fees received, a teams reward metric should be updated and published every `rewards.updateFrequency` seconds. (0056-REWA-145). +- Given a recurring transfer where the entity scope is teams and the dispatch metric is liquidity fees received, a teams reward metric should be updated and published at the end of every epoch. (0056-REWA-146). +- Given a recurring transfer where the entity scope is teams and the dispatch metric is market creation, a teams reward metric should be updated and published at the end of every epoch. (0056-REWA-147). +- Given a recurring transfer where the entity scope is teams and the dispatch metric is average position, a teams reward metric should be updated and published every `rewards.updateFrequency` seconds. (0056-REWA-148). +- Given a recurring transfer where the entity scope is teams and the dispatch metric is relative returns, a teams reward metric should be updated and published every `rewards.updateFrequency` seconds. (0056-REWA-149). +- Given a recurring transfer where the entity scope is teams and the dispatch metric is returns volatility, a teams reward metric should be updated and published every `rewards.updateFrequency` seconds. (0056-REWA-150). +- Given a recurring transfer where the entity scope is teams and the dispatch metric is validator ranking, a teams reward metric should be updated and published at the end of every epoch. (0056-REWA-151). diff --git a/protocol/features.json b/protocol/features.json index 3f3197adc..6f08d4c32 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -563,7 +563,23 @@ "0056-REWA-132", "0056-REWA-133", "0056-REWA-134", - "0056-REWA-135" + "0056-REWA-135", + "0056-REWA-136", + "0056-REWA-137", + "0056-REWA-138", + "0056-REWA-139", + "0056-REWA-140", + "0056-REWA-141", + "0056-REWA-142", + "0056-REWA-143", + "0056-REWA-144", + "0056-REWA-145", + "0056-REWA-146", + "0056-REWA-147", + "0056-REWA-148", + "0056-REWA-149", + "0056-REWA-150", + "0056-REWA-151" ] }, "Unknown": { From 3ef50ec3c93e8a2115e8776bfdf55f039725d95a Mon Sep 17 00:00:00 2001 From: Sohill-Patel <85170301+Sohill-Patel@users.noreply.github.com> Date: Tue, 23 Apr 2024 17:07:47 +0100 Subject: [PATCH 1085/1171] feat: couple more spot acs --- protocol/0028-GOVE-governance.md | 4 ++-- protocol/features.json | 4 +++- 2 files changed, 5 insertions(+), 3 deletions(-) diff --git a/protocol/0028-GOVE-governance.md b/protocol/0028-GOVE-governance.md index cb8726865..c4caeafa8 100644 --- a/protocol/0028-GOVE-governance.md +++ b/protocol/0028-GOVE-governance.md @@ -575,8 +575,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 market change proposal that aims to modify the market name in any state (apart from closed/terminated) will modify the market name at the time of vote enactment. (0028-GOVE-159) -- A market change proposal that aims to modify the market code in any state (apart from closed/terminated) will modify the market code at the time of vote enactment. (0028-GOVE-166) +- A market change proposal that aims to modify the market name in any state (apart from closed/terminated) will modify the market name at the time of vote enactment. (0028-GOVE-159). For product spot (0028-GOVE-186). +- A market change proposal that aims to modify the market code in any state (apart from closed/terminated) will modify the market code at the time of vote enactment. (0028-GOVE-166). For product spot (0028-GOVE-187). - 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 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) diff --git a/protocol/features.json b/protocol/features.json index 3f3197adc..82da5e226 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -387,7 +387,9 @@ "0074-BTCH-016", "0074-BTCH-019", "0079-TGAP-006", - "0079-TGAP-007" + "0079-TGAP-007", + "0028-GOVE-186", + "0028-GOVE-187" ] }, "Spot stop orders": { From d6f85ccbe0148032693650ed5d9252e093888366 Mon Sep 17 00:00:00 2001 From: Charlie Date: Wed, 23 Aug 2023 17:32:50 +0100 Subject: [PATCH 1086/1171] feat: add transfer interval field --- protocol/0056-REWA-rewards_overview.md | 2 ++ protocol/0057-TRAN-transfers.md | 1 + 2 files changed, 3 insertions(+) diff --git a/protocol/0056-REWA-rewards_overview.md b/protocol/0056-REWA-rewards_overview.md index 585949695..7dc944d9b 100644 --- a/protocol/0056-REWA-rewards_overview.md +++ b/protocol/0056-REWA-rewards_overview.md @@ -27,6 +27,8 @@ At the end of the epoch: 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). +Note, reward metrics should be calculated and exposed through an API even if the the reward pool is not to be funded this epoch (i.e. when the `transfer_interval` set in the [recurring transfer](./0057-TRAN-transfers.md#recurring-transfers-to-reward-accounts) is strictly greater than `1`). + ## Individual 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). diff --git a/protocol/0057-TRAN-transfers.md b/protocol/0057-TRAN-transfers.md index f85b602b4..7215aa853 100644 --- a/protocol/0057-TRAN-transfers.md +++ b/protocol/0057-TRAN-transfers.md @@ -67,6 +67,7 @@ A recurring transfers needs to contain this specific information: - 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). +- transfer interval: number of epochs between transfers, i.e. when 4, funds will be transferred every 4 epochs with the first transfer occurring 4 epochs after the transfer is processed. Must be an integer strictly greater than `0`. The amount paid at the end of each epoch is calculated using the following formula: From c9715a79ca5a36e662ec1e951d7ca8e9d22af476 Mon Sep 17 00:00:00 2001 From: Charlie Date: Thu, 24 Aug 2023 08:44:06 +0100 Subject: [PATCH 1087/1171] feat: lock funds for scheduled transfer --- protocol/0057-TRAN-transfers.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/protocol/0057-TRAN-transfers.md b/protocol/0057-TRAN-transfers.md index 7215aa853..bbb3eddb4 100644 --- a/protocol/0057-TRAN-transfers.md +++ b/protocol/0057-TRAN-transfers.md @@ -69,6 +69,8 @@ A recurring transfers needs to contain this specific information: - factor, decimal > 0.0 (a factor used with the amount specified for the transfer). - transfer interval: number of epochs between transfers, i.e. when 4, funds will be transferred every 4 epochs with the first transfer occurring 4 epochs after the transfer is processed. Must be an integer strictly greater than `0`. +Note, to avoid parties creating [reward pools](#recurring-transfers-to-reward-accounts) which are never funded, if a transfer interval strictly greater than `1` is specified. The funds for the next scheduled transfer should be taken straight away from the origin account, locked by the network, and distributed to the destination account at the end of the correct epoch. This way, if a user cancels a recurring transfer or withdraws all their funds, the next scheduled transfer will still take place. + The amount paid at the end of each epoch is calculated using the following formula: $$ From 6a8714a7d24682cee15515e5702bc80baef13597 Mon Sep 17 00:00:00 2001 From: Charlie Date: Thu, 24 Aug 2023 13:29:18 +0100 Subject: [PATCH 1088/1171] feat: make locking behaviour consistent --- 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 bbb3eddb4..4869f4f24 100644 --- a/protocol/0057-TRAN-transfers.md +++ b/protocol/0057-TRAN-transfers.md @@ -69,7 +69,7 @@ A recurring transfers needs to contain this specific information: - factor, decimal > 0.0 (a factor used with the amount specified for the transfer). - transfer interval: number of epochs between transfers, i.e. when 4, funds will be transferred every 4 epochs with the first transfer occurring 4 epochs after the transfer is processed. Must be an integer strictly greater than `0`. -Note, to avoid parties creating [reward pools](#recurring-transfers-to-reward-accounts) which are never funded, if a transfer interval strictly greater than `1` is specified. The funds for the next scheduled transfer should be taken straight away from the origin account, locked by the network, and distributed to the destination account at the end of the correct epoch. This way, if a user cancels a recurring transfer or withdraws all their funds, the next scheduled transfer will still take place. +Note, to avoid parties intentionally creating transfers which never occur, either between parties or to fund a [reward pool](#recurring-transfers-to-reward-accounts). The funds for the next scheduled transfer should be taken straight away from the origin account, locked by the network, and distributed to the destination account at the end of the correct epoch. This way, if a user cancels a recurring transfer or withdraws all their funds, the next scheduled transfer will still take place. The amount paid at the end of each epoch is calculated using the following formula: From b9417477efb5dd1ff7981eb7b38edd5def74402e Mon Sep 17 00:00:00 2001 From: Charlie Date: Tue, 16 Apr 2024 18:12:06 +0100 Subject: [PATCH 1089/1171] feat: add clarification for reward caps and ACs --- protocol/0057-TRAN-transfers.md | 25 ++++++++++++++++--------- protocol/features.json | 6 +++++- 2 files changed, 21 insertions(+), 10 deletions(-) diff --git a/protocol/0057-TRAN-transfers.md b/protocol/0057-TRAN-transfers.md index 4869f4f24..ce26a54f7 100644 --- a/protocol/0057-TRAN-transfers.md +++ b/protocol/0057-TRAN-transfers.md @@ -67,7 +67,7 @@ A recurring transfers needs to contain this specific information: - 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). -- transfer interval: number of epochs between transfers, i.e. when 4, funds will be transferred every 4 epochs with the first transfer occurring 4 epochs after the transfer is processed. Must be an integer strictly greater than `0`. +- transfer interval: number of epochs between transfers, i.e. when 4, funds will be transferred every 4 epochs with the first transfer occurring 4 epochs after the transaction is processed. Must be an integer strictly greater than `0` and less than `100` (this ceiling is for performance reasons and matches the limit on the `window_length` field). Note, to avoid parties intentionally creating transfers which never occur, either between parties or to fund a [reward pool](#recurring-transfers-to-reward-accounts). The funds for the next scheduled transfer should be taken straight away from the origin account, locked by the network, and distributed to the destination account at the end of the correct epoch. This way, if a user cancels a recurring transfer or withdraws all their funds, the next scheduled transfer will still take place. @@ -112,8 +112,7 @@ A party should be able to configure the distribution of rewards by specifying th - `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. -- `cap_reward_fee_multiple` [optional] - if set, the actual amount of reward transferred to each public key during distribution for this transfer will be `min(calculated_reward_in_quantum, cap_reward_fee_multiple × fees_paid_this_epoch_in_quantum)`. When calculating how much of the reward each one is getting, if some is left from the applied cap, we recalculate on the remaining balance only for parties that have not reached their cap until the leftover is less than 1 reward asset unit or the maximum rounds of recalculation is 10. If all keys are capped (i.e. the total amount of the transfer cannot be be sent to eligible keys without breaching the cap) then the remaining balance must be left in the reward pool and included in the distribution in future epochs. If this occurs, and the total transferred in a given epoch, this does not affect the size of the next iteration, which proceeds as normal (including decay factors etc.) as if the full transfer has been made. -Here, `fees_paid_this_epoch_in_quantum` are the total trading fees paid by a party (arising from `infrastructure_fee` paid, `maker_fee` paid plus `liquidity_fee` paid, over the epoch and expressed in quantum units). +- `cap_reward_fee_multiple` [optional] - if set, the actual amount of reward transferred to each public key during distribution for this transfer will be `min(calculated_reward_in_quantum, cap_reward_fee_multiple × feed_paid_since_last_payout)` (fees paid since last payout is akin to checking the total fees paid over the last `transfer_interval` epochs). When calculating how much of the reward each one is getting, if some is left from the applied cap, we recalculate on the remaining balance only for parties that have not reached their cap until the leftover is less than 1 reward asset unit or the maximum rounds of recalculation is 10. If all keys are capped (i.e. the total amount of the transfer cannot be be sent to eligible keys without breaching the cap) then the remaining balance must be left in the reward pool and included in the distribution in future epochs. If this occurs, and the total transferred in a given epoch, this does not affect the size of the next iteration, which proceeds as normal (including decay factors etc.) as if the full transfer has been made. - `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. @@ -392,15 +391,23 @@ If the network parameter `spam.protection.maxUserTransfersPerEpoch` is modified, 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) -If the parameter of each transfer `cap_reward_fee_multiple` is set, and if `calculated_reward_in_quantum < cap_reward_fee_multiple × fees_paid_this_epoch_in_quantum` then the actual amount of reward transferred to each public key during distribution for this transfer will be `calculated_reward_in_quantum`(0057-TRAN-070) +Given a recurring transfer which is distributed every epoch (i.e. `transfer_interval=1`), if the parameter of each transfer `cap_reward_fee_multiple` is set, and if `calculated_reward_in_quantum < cap_reward_fee_multiple × fees_paid_this_epoch_in_quantum` then the actual amount of reward transferred to each public key during distribution for this transfer will be `calculated_reward_in_quantum`(0057-TRAN-070) -If the parameter of each transfer `cap_reward_fee_multiple` is set, and if `calculated_reward_in_quantum > cap_reward_fee_multiple × fees_paid_this_epoch_in_quantum` then the actual amount of reward transferred to each public key during distribution for this transfer will be `cap_reward_fee_multiple × fees_paid_this_epoch_in_quantum`(0057-TRAN-071) +Given a recurring transfer which is distributed every epoch (i.e. `transfer_interval=1`), if the parameter of each transfer `cap_reward_fee_multiple` is set, and if `calculated_reward_in_quantum > cap_reward_fee_multiple × fees_paid_this_epoch_in_quantum` then the actual amount of reward transferred to each public key during distribution for this transfer will be `cap_reward_fee_multiple × fees_paid_this_epoch_in_quantum`(0057-TRAN-071) -If the parameter of each transfer `cap_reward_fee_multiple` is set, and if some reward is left from the applied cap, the remaining balance should be recalculated only for parties that have not reached their cap until the leftover is less than 1 reward asset unit or the maximum rounds of recalculation is 10 +Given a recurring transfer which is distributed every epoch (i.e. `transfer_interval=1`), if the parameter of each transfer `cap_reward_fee_multiple` is set, and if some reward is left from the applied cap, the remaining balance should be recalculated only for parties that have not reached their cap until the leftover is less than 1 reward asset unit or the maximum rounds of recalculation is 10 (0057-TRAN-072) -If the parameter of each transfer `cap_reward_fee_multiple` is set, and if all keys are capped, then the remaining balance must be left in the reward pool and included in the distribution in the future epochs. (0057-TRAN-073) +Given a recurring transfer which is distributed every epoch (i.e. `transfer_interval=1`), if the parameter of each transfer `cap_reward_fee_multiple` is set, and if all keys are capped, then the remaining balance must be left in the reward pool and included in the distribution in the future epochs. (0057-TRAN-073) -If the parameter of each transfer `cap_reward_fee_multiple` is set, and the total reward transferred in a given epoch is not spent due to the cap, this does not affect the size of the next iteration, which proceeds as normal (including decay factors etc.) as if the full transfer has been made (0057-TRAN-074) +Given a recurring transfer which is distributed every epoch (i.e. `transfer_interval=1`), if the parameter of each transfer `cap_reward_fee_multiple` is set, and the total reward transferred in a given epoch is not spent due to the cap, this does not affect the size of the next iteration, which proceeds as normal (including decay factors etc.) as if the full transfer has been made (0057-TRAN-074) -If the parameter of each transfer `cap_reward_fee_multiple` is set to be `<=0`, then it should be rejected (0057-TRAN-075) +Given a recurring transfer which is distributed every epoch (i.e. `transfer_interval=1`), if the parameter of each transfer `cap_reward_fee_multiple` is set to be `<=0`, then it should be rejected. (0057-TRAN-075) + +If a party sets up a recurring transfer with a `transfer_interval` field strictly greater than `1`, if they do not have enough funds to cover the next payout, the transaction will be rejected. (0057-TRAN-076) + +If a party sets up a recurring transfer with a `transfer_interval` field strictly greater than `1`, if they have enough funds to cover the next payout, the network will lock these funds and they will be unavailable for other purposes. (0057-TRAN-077) + +If a party sets up a recurring transfer with a `transfer_interval` field strictly greater than `1`, if they cancel the recurring transfer the locked funds will not be released and the next payout event will happen regardless. (0057-TRAN-078) + +If a party sets up a recurring transfer with a transfer interval strictly greater than `1` and specifies a `cap_reward_fee_multiple`. If `calculated_reward_in_quantum > cap_reward_fee_multiple × fees_paid_since_last_payout_in_quantum` then the actual amount of reward transferred to each public key during distribution for this transfer will be `cap_reward_fee_multiple × fees_paid_since_last_payout_in_quantum`(0057-TRAN-079) \ No newline at end of file diff --git a/protocol/features.json b/protocol/features.json index 82da5e226..dc89d1c01 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -565,7 +565,11 @@ "0056-REWA-132", "0056-REWA-133", "0056-REWA-134", - "0056-REWA-135" + "0056-REWA-135", + "0057-TRAN-076", + "0057-TRAN-077", + "0057-TRAN-078", + "0057-TRAN-079" ] }, "Unknown": { From 4e7360f6dffb75d08e9d8306c396927b973fe1a0 Mon Sep 17 00:00:00 2001 From: Charlie Date: Mon, 22 Apr 2024 13:50:20 +0100 Subject: [PATCH 1090/1171] chore: remove locked funds requirement --- protocol/0057-TRAN-transfers.md | 2 -- 1 file changed, 2 deletions(-) diff --git a/protocol/0057-TRAN-transfers.md b/protocol/0057-TRAN-transfers.md index ce26a54f7..9f38cc35a 100644 --- a/protocol/0057-TRAN-transfers.md +++ b/protocol/0057-TRAN-transfers.md @@ -69,8 +69,6 @@ A recurring transfers needs to contain this specific information: - factor, decimal > 0.0 (a factor used with the amount specified for the transfer). - transfer interval: number of epochs between transfers, i.e. when 4, funds will be transferred every 4 epochs with the first transfer occurring 4 epochs after the transaction is processed. Must be an integer strictly greater than `0` and less than `100` (this ceiling is for performance reasons and matches the limit on the `window_length` field). -Note, to avoid parties intentionally creating transfers which never occur, either between parties or to fund a [reward pool](#recurring-transfers-to-reward-accounts). The funds for the next scheduled transfer should be taken straight away from the origin account, locked by the network, and distributed to the destination account at the end of the correct epoch. This way, if a user cancels a recurring transfer or withdraws all their funds, the next scheduled transfer will still take place. - The amount paid at the end of each epoch is calculated using the following formula: $$ From 9408a527564c8a0b1542db80dc75bb8fd5714445 Mon Sep 17 00:00:00 2001 From: Charlie Date: Mon, 22 Apr 2024 13:51:06 +0100 Subject: [PATCH 1091/1171] chore: move transfer interval to dispatch strategy --- 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 9f38cc35a..5302bc3d0 100644 --- a/protocol/0057-TRAN-transfers.md +++ b/protocol/0057-TRAN-transfers.md @@ -67,7 +67,6 @@ A recurring transfers needs to contain this specific information: - 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). -- transfer interval: number of epochs between transfers, i.e. when 4, funds will be transferred every 4 epochs with the first transfer occurring 4 epochs after the transaction is processed. Must be an integer strictly greater than `0` and less than `100` (this ceiling is for performance reasons and matches the limit on the `window_length` field). The amount paid at the end of each epoch is calculated using the following formula: @@ -109,6 +108,7 @@ 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. The value should be limited to 100 epochs. +- `transfer_interval` - number of epochs between transfers, i.e. when 4, funds will be transferred every 4 epochs with the first transfer occurring 4 epochs after the transaction is processed. Must be an integer strictly greater than `0` and less than `100` (this ceiling is for performance reasons and matches the limit on the `window_length` field). - `lock_period` - the number of epochs after distribution to delay [vesting of rewards](./0085-RVST-rewards_vesting.md#vesting-mechanics) by. - `cap_reward_fee_multiple` [optional] - if set, the actual amount of reward transferred to each public key during distribution for this transfer will be `min(calculated_reward_in_quantum, cap_reward_fee_multiple × feed_paid_since_last_payout)` (fees paid since last payout is akin to checking the total fees paid over the last `transfer_interval` epochs). When calculating how much of the reward each one is getting, if some is left from the applied cap, we recalculate on the remaining balance only for parties that have not reached their cap until the leftover is less than 1 reward asset unit or the maximum rounds of recalculation is 10. If all keys are capped (i.e. the total amount of the transfer cannot be be sent to eligible keys without breaching the cap) then the remaining balance must be left in the reward pool and included in the distribution in future epochs. If this occurs, and the total transferred in a given epoch, this does not affect the size of the next iteration, which proceeds as normal (including decay factors etc.) as if the full transfer has been made. - `distribution_strategy` - enum defining which [distribution strategy](./0056-REWA-rewards_overview.md#distributing-rewards-between-entities) to use. From 64ad97fbfcb1f082266e13702063a7dd27e4f653 Mon Sep 17 00:00:00 2001 From: Charlie Date: Mon, 22 Apr 2024 13:52:37 +0100 Subject: [PATCH 1092/1171] chore: remove reference to interim data --- protocol/0056-REWA-rewards_overview.md | 2 -- 1 file changed, 2 deletions(-) diff --git a/protocol/0056-REWA-rewards_overview.md b/protocol/0056-REWA-rewards_overview.md index 7dc944d9b..585949695 100644 --- a/protocol/0056-REWA-rewards_overview.md +++ b/protocol/0056-REWA-rewards_overview.md @@ -27,8 +27,6 @@ At the end of the epoch: 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). -Note, reward metrics should be calculated and exposed through an API even if the the reward pool is not to be funded this epoch (i.e. when the `transfer_interval` set in the [recurring transfer](./0057-TRAN-transfers.md#recurring-transfers-to-reward-accounts) is strictly greater than `1`). - ## Individual 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). From 8e5602cf90e4f98a7a2bf7f43ed915d6f0175c0f Mon Sep 17 00:00:00 2001 From: Charlie Date: Mon, 22 Apr 2024 17:14:19 +0100 Subject: [PATCH 1093/1171] chore: revert removal of clarification --- protocol/0057-TRAN-transfers.md | 1 + 1 file changed, 1 insertion(+) diff --git a/protocol/0057-TRAN-transfers.md b/protocol/0057-TRAN-transfers.md index 5302bc3d0..8a9c04031 100644 --- a/protocol/0057-TRAN-transfers.md +++ b/protocol/0057-TRAN-transfers.md @@ -111,6 +111,7 @@ A party should be able to configure the distribution of rewards by specifying th - `transfer_interval` - number of epochs between transfers, i.e. when 4, funds will be transferred every 4 epochs with the first transfer occurring 4 epochs after the transaction is processed. Must be an integer strictly greater than `0` and less than `100` (this ceiling is for performance reasons and matches the limit on the `window_length` field). - `lock_period` - the number of epochs after distribution to delay [vesting of rewards](./0085-RVST-rewards_vesting.md#vesting-mechanics) by. - `cap_reward_fee_multiple` [optional] - if set, the actual amount of reward transferred to each public key during distribution for this transfer will be `min(calculated_reward_in_quantum, cap_reward_fee_multiple × feed_paid_since_last_payout)` (fees paid since last payout is akin to checking the total fees paid over the last `transfer_interval` epochs). When calculating how much of the reward each one is getting, if some is left from the applied cap, we recalculate on the remaining balance only for parties that have not reached their cap until the leftover is less than 1 reward asset unit or the maximum rounds of recalculation is 10. If all keys are capped (i.e. the total amount of the transfer cannot be be sent to eligible keys without breaching the cap) then the remaining balance must be left in the reward pool and included in the distribution in future epochs. If this occurs, and the total transferred in a given epoch, this does not affect the size of the next iteration, which proceeds as normal (including decay factors etc.) as if the full transfer has been made. +Here, `feed_paid_since_last_payout` are the total trading fees paid by a party (arising from `infrastructure_fee` paid, `maker_fee` paid plus `liquidity_fee` paid, since the last payout and expressed in quantum units). - `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. From 8e6f45fe25bb8187ce893b2ff40f8f8203d9046f Mon Sep 17 00:00:00 2001 From: Charlie Date: Mon, 22 Apr 2024 17:17:48 +0100 Subject: [PATCH 1094/1171] chore: fix markdownlint --- 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 8a9c04031..65f07cfdf 100644 --- a/protocol/0057-TRAN-transfers.md +++ b/protocol/0057-TRAN-transfers.md @@ -408,5 +408,5 @@ If a party sets up a recurring transfer with a `transfer_interval` field strictl If a party sets up a recurring transfer with a `transfer_interval` field strictly greater than `1`, if they have enough funds to cover the next payout, the network will lock these funds and they will be unavailable for other purposes. (0057-TRAN-077) If a party sets up a recurring transfer with a `transfer_interval` field strictly greater than `1`, if they cancel the recurring transfer the locked funds will not be released and the next payout event will happen regardless. (0057-TRAN-078) - -If a party sets up a recurring transfer with a transfer interval strictly greater than `1` and specifies a `cap_reward_fee_multiple`. If `calculated_reward_in_quantum > cap_reward_fee_multiple × fees_paid_since_last_payout_in_quantum` then the actual amount of reward transferred to each public key during distribution for this transfer will be `cap_reward_fee_multiple × fees_paid_since_last_payout_in_quantum`(0057-TRAN-079) \ No newline at end of file + +If a party sets up a recurring transfer with a transfer interval strictly greater than `1` and specifies a `cap_reward_fee_multiple`. If `calculated_reward_in_quantum > cap_reward_fee_multiple × fees_paid_since_last_payout_in_quantum` then the actual amount of reward transferred to each public key during distribution for this transfer will be `cap_reward_fee_multiple × fees_paid_since_last_payout_in_quantum`(0057-TRAN-079) From 166db7ed19f40d184d3926361b80cb825adeae70 Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Fri, 26 Apr 2024 10:50:58 +0100 Subject: [PATCH 1095/1171] feat: add ACs to cover market order collateral check for spot market --- protocol/0080-SPOT-product_builtin_spot.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/protocol/0080-SPOT-product_builtin_spot.md b/protocol/0080-SPOT-product_builtin_spot.md index b872f6892..755ec98f2 100644 --- a/protocol/0080-SPOT-product_builtin_spot.md +++ b/protocol/0080-SPOT-product_builtin_spot.md @@ -121,6 +121,8 @@ 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. For a "buy" market 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-024) +1. For a "sell" market order to be considered valid during continuous trading, the party must have a sufficient amount of the `base_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-025) 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) From 5a189a82d49ed7006d823d27c0de459bb0cf7b5e Mon Sep 17 00:00:00 2001 From: Charlie Date: Fri, 26 Apr 2024 11:55:33 +0100 Subject: [PATCH 1096/1171] chore: add acs for testing rewards from spot markets --- protocol/0056-REWA-rewards_overview.md | 28 +++++++++++++++++++++++++- protocol/features.json | 18 ++++++++++++++++- 2 files changed, 44 insertions(+), 2 deletions(-) diff --git a/protocol/0056-REWA-rewards_overview.md b/protocol/0056-REWA-rewards_overview.md index 1be21b140..fefec793c 100644 --- a/protocol/0056-REWA-rewards_overview.md +++ b/protocol/0056-REWA-rewards_overview.md @@ -71,6 +71,7 @@ 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 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). +Note, trading fees paid or received on Spot markets will contribute to fee-based reward metrics. ### Average position metric @@ -123,6 +124,8 @@ Let: $$m_{rr} = \frac{\sum_{i}^{n}{r_{i}}}{N}$$ +Note, as a position can not be created on a Spot market. Trading activity on a Spot market will not contribute to this reward metric. + ### Returns volatility metric The return volatility metric, $m_{rv}$, measures the volatility of a parties returns across a number of epochs. @@ -135,6 +138,8 @@ $$R = \{r_i \mid i = 1, 2, \ldots, N\}$$ The reward metric $m_{rv}$ is the variance of the set $R$. +Note, as a position can not be created on a Spot market. Trading activity on a Spot market will not contribute to this reward metric. + ### Validator ranking metric The validator ranking metric, $m_v$, measures the ranking score of consensus and standby validators. @@ -177,6 +182,8 @@ Let: $$m_{rz} = \frac{\sum_{i}^{n}{rz_{i}}}{N}$$ +Note, as a position can not be created on a Spot market. Trading activity on a Spot market will not contribute to this reward metric. + ### Market creation reward metrics There will be a single market creation reward metric and reward type. @@ -1091,7 +1098,7 @@ At the end of epoch 2, 10000 VEGA rewards should be distributed to the `ETHUSDT` - If a team member has a zero reward metric, they should receive no share of the rewards allocated to the team (0056-REWA-108). -## Interim Reward Information +### Interim Reward Information - Given a recurring transfer where the entity scope is individuals and the dispatch metric is maker fees paid, a parties reward metric should be updated and published every `rewards.updateFrequency` seconds. (0056-REWA-136). - Given a recurring transfer where the entity scope is individuals and the dispatch metric is maker fees received, a parties reward metric should be updated and published every `rewards.updateFrequency` seconds. (0056-REWA-137). @@ -1110,3 +1117,22 @@ At the end of epoch 2, 10000 VEGA rewards should be distributed to the `ETHUSDT` - Given a recurring transfer where the entity scope is teams and the dispatch metric is relative returns, a teams reward metric should be updated and published every `rewards.updateFrequency` seconds. (0056-REWA-149). - Given a recurring transfer where the entity scope is teams and the dispatch metric is returns volatility, a teams reward metric should be updated and published every `rewards.updateFrequency` seconds. (0056-REWA-150). - Given a recurring transfer where the entity scope is teams and the dispatch metric is validator ranking, a teams reward metric should be updated and published at the end of every epoch. (0056-REWA-151). + +### Spot markets + +- In a spot market, trades in which a party is the buyer and the aggressor will contribute to the parties’ maker fees paid reward metric for the quote asset. (0056-REWA-152). +- In a spot market, trades in which a party is the seller and the aggressor will contribute to the parties’ maker fees paid reward metric for the quote asset. (0056-REWA-153). +- In a spot market, trades in which a party is the buyer and is not the aggressor will contribute to the parties' maker fees received reward metric for the quote asset. (0056-REWA-154). +- In a spot market, trades in which a party is the seller and is not the aggressor will contribute to the parties' maker fees received reward metric for the quote asset. (0056-REWA-155). +- In a spot market, if a party receives liquidity fees at the end of the epoch, these contribute to the parties' liquidity fees received reward metric for the quote asset. (0056-REWA-156). +- In a spot market, trades in which a party is the buyer and the aggressor will not contribute to the parties’ maker fees paid reward metric for the base asset. (0056-REWA-157). +- In a spot market, trades in which a party is the seller and the aggressor will not contribute to the parties’ maker fees paid reward metric for the base asset. (0056-REWA-158). +- In a spot market, trades in which a party is the buyer and is not the aggressor will not contribute to the parties' maker fees received reward metric for the base asset. (0056-REWA-159). +- In a spot market, trades in which a party is the seller and is not the aggressor will not contribute to the parties’ maker fees received reward metric for the base asset. (0056-REWA-160). +- In a spot market, if a party receives liquidity fees at the end of the epoch, these will not contribute to the parties' liquidity fees received reward metric for the base asset. (0056-REWA-161). +- In a spot market, trading activity will not contribute to a parties average position reward metric for either the base or quote asset. (0056-REWA-162). +- In a spot market, trading activity will not contribute to a parties relative return reward metric for either the base or quote asset. (0056-REWA-163). +- In a spot market, trading activity will not contribute to a parties realised return reward metric for either the base or quote asset. (0056-REWA-164). +- Given a reward metric scoping both spot and leveraged markets, a parties trades in the spot market will correctly contribute to their maker fees paid reward metric. (0056-REWA-165). +- Given a reward metric scoping both spot and leveraged markets, a parties trades in the spot market will correctly contribute to their maker fees received reward metric. (0056-REWA-166). +- Given a reward metric scoping both spot and leveraged markets, a parties received liquidity fees from the spot market will correctly contribute to their liquidity fees received reward metric. (0056-REWA-167). diff --git a/protocol/features.json b/protocol/features.json index b045a289d..dc0260712 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -337,7 +337,23 @@ "0044-LIME-118", "0044-LIME-119", "0074-BTCH-022", - "0074-BTCH-023" + "0074-BTCH-023", + "0056-REWA-152", + "0056-REWA-153", + "0056-REWA-154", + "0056-REWA-155", + "0056-REWA-156", + "0056-REWA-157", + "0056-REWA-158", + "0056-REWA-159", + "0056-REWA-160", + "0056-REWA-161", + "0056-REWA-162", + "0056-REWA-163", + "0056-REWA-164", + "0056-REWA-165", + "0056-REWA-166", + "0056-REWA-167" ] }, "Spot stretch": { From 61e518d5f51ddb0c76e60b4cd1d0e02613cb19e4 Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Fri, 26 Apr 2024 12:09:08 +0100 Subject: [PATCH 1097/1171] feat: add AC 026027028 --- protocol/0080-SPOT-product_builtin_spot.md | 3 +++ 1 file changed, 3 insertions(+) diff --git a/protocol/0080-SPOT-product_builtin_spot.md b/protocol/0080-SPOT-product_builtin_spot.md index 755ec98f2..616167b3c 100644 --- a/protocol/0080-SPOT-product_builtin_spot.md +++ b/protocol/0080-SPOT-product_builtin_spot.md @@ -123,6 +123,9 @@ Price-monitoring auctions are still required and should be implemented following 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. For a "buy" market 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-024) 1. For a "sell" market order to be considered valid during continuous trading, the party must have a sufficient amount of the `base_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-025) +1. amending order should be rejected when an order is amended such that would trade immediately and the party can't afford none/some of the trades(0080-SPOT-026) +1. order should be rejected when submit a limit order, partly matched, party can't afford the trades.(0080-SPOT-027) +1. order should be rejected when submit a limit order, no match, added to the book, party can't cover the amount that needs to be transfered to the holding account.(0080-SPOT-028) 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) From 6e9f42b4a86f2f0a90686bd5d2e79cd051ed5e8c Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Fri, 26 Apr 2024 13:57:36 +0100 Subject: [PATCH 1098/1171] feat: add ACs to json file --- protocol/features.json | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/protocol/features.json b/protocol/features.json index dc0260712..b261e6d84 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -405,7 +405,12 @@ "0079-TGAP-006", "0079-TGAP-007", "0028-GOVE-186", - "0028-GOVE-187" + "0028-GOVE-187", + "0080-SPOT-024", + "0080-SPOT-025", + "0080-SPOT-026", + "0080-SPOT-027", + "0080-SPOT-028" ] }, "Spot stop orders": { From 321541722b137a3071d1aa2ba8556c1d2efc1568 Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Fri, 26 Apr 2024 15:26:05 +0100 Subject: [PATCH 1099/1171] 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 616167b3c..fd3614e64 100644 --- a/protocol/0080-SPOT-product_builtin_spot.md +++ b/protocol/0080-SPOT-product_builtin_spot.md @@ -125,7 +125,7 @@ Price-monitoring auctions are still required and should be implemented following 1. For a "sell" market order to be considered valid during continuous trading, the party must have a sufficient amount of the `base_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-025) 1. amending order should be rejected when an order is amended such that would trade immediately and the party can't afford none/some of the trades(0080-SPOT-026) 1. order should be rejected when submit a limit order, partly matched, party can't afford the trades.(0080-SPOT-027) -1. order should be rejected when submit a limit order, no match, added to the book, party can't cover the amount that needs to be transfered to the holding account.(0080-SPOT-028) +1. order should be rejected when submit a limit order, no match, added to the book, party can't cover the amount that needs to be transferred to the holding account.(0080-SPOT-028) 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) From 6b9523ae1dd6c57751196e647032d9dc65c244df Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Fri, 26 Apr 2024 16:54:12 +0100 Subject: [PATCH 1100/1171] feat: address comment from Charlie --- protocol/0080-SPOT-product_builtin_spot.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/protocol/0080-SPOT-product_builtin_spot.md b/protocol/0080-SPOT-product_builtin_spot.md index fd3614e64..6906f3764 100644 --- a/protocol/0080-SPOT-product_builtin_spot.md +++ b/protocol/0080-SPOT-product_builtin_spot.md @@ -122,10 +122,11 @@ 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. For a "buy" market 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-024) -1. For a "sell" market order to be considered valid during continuous trading, the party must have a sufficient amount of the `base_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-025) +1. For a "sell" market order to be considered valid during continuous trading, the party must have a sufficient amount of the `base_asset` in the `general_account` to cover the value of the trade. (0080-SPOT-025) 1. amending order should be rejected when an order is amended such that would trade immediately and the party can't afford none/some of the trades(0080-SPOT-026) 1. order should be rejected when submit a limit order, partly matched, party can't afford the trades.(0080-SPOT-027) 1. order should be rejected when submit a limit order, no match, added to the book, party can't cover the amount that needs to be transferred to the holding account.(0080-SPOT-028) +1. order should be rejected when submit a limit order, partly matched, party can afford partial trade but not what needs to be transferred to the holding account after to cover the remaining size.(0080-SPOT-029) 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) From 3251629ba5ed3a95de96ae3cbb12def4eff8aef9 Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Mon, 29 Apr 2024 10:08:48 +0100 Subject: [PATCH 1101/1171] feat: update AC code --- protocol/features.json | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/protocol/features.json b/protocol/features.json index b261e6d84..46ae72e3c 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -410,7 +410,8 @@ "0080-SPOT-025", "0080-SPOT-026", "0080-SPOT-027", - "0080-SPOT-028" + "0080-SPOT-028", + "0080-SPOT-029" ] }, "Spot stop orders": { From 97a33127a6e1b6c44fd7da9f5131e02805c47322 Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Mon, 29 Apr 2024 13:13:55 +0100 Subject: [PATCH 1102/1171] feat: add spec for when market is stuck in opening auction --- protocol/0043-MKTL-market_lifecycle.md | 22 +++++++++++++++++++++- 1 file changed, 21 insertions(+), 1 deletion(-) diff --git a/protocol/0043-MKTL-market_lifecycle.md b/protocol/0043-MKTL-market_lifecycle.md index 5bec4de59..c3df291b1 100644 --- a/protocol/0043-MKTL-market_lifecycle.md +++ b/protocol/0043-MKTL-market_lifecycle.md @@ -13,7 +13,8 @@ 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](./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. +If the proposal is successful the market will go into opening auction at least until the proposed `enactment` date. If the enactment date is passed by more than the maximum opening auction extension duration Network Parameter (`market.auction.maximumDuration`), the market should be cancelled. + ## Market lifecycle statuses @@ -334,6 +335,25 @@ After `market.liquidity.successorLaunchWindowLength` has passed since market set 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 never leaves opening auction, trading terminated triggered, market cancelled (0043-MKTL-012) + +1. A market is proposed, approved by governance process and enters the opening auction (Pending state). +1. Market stays in opening auction till time passes `market.auction.maximumDuration`, the market should be cancelled. +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 transferred into the global insurance pool 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. + +### Market (Spot) never leaves opening auction, market cancelled by governance proposal(0043-MKTL-013) + +1. A market is proposed, approved by governance process and enters the opening auction (Pending state). +1. Market stays in opening auction till time passes `market.auction.maximumDuration`, the market should be cancelled. +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. From a15679ce0750c732855716b9c56b790ba35ec6fc Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Mon, 29 Apr 2024 15:56:03 +0100 Subject: [PATCH 1103/1171] chore: tidy up --- protocol/0043-MKTL-market_lifecycle.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/protocol/0043-MKTL-market_lifecycle.md b/protocol/0043-MKTL-market_lifecycle.md index c3df291b1..1330ceefa 100644 --- a/protocol/0043-MKTL-market_lifecycle.md +++ b/protocol/0043-MKTL-market_lifecycle.md @@ -348,8 +348,7 @@ After `market.liquidity.successorLaunchWindowLength` has passed since market set ### Market (Spot) never leaves opening auction, market cancelled by governance proposal(0043-MKTL-013) 1. A market is proposed, approved by governance process and enters the opening auction (Pending state). -1. Market stays in opening auction till time passes `market.auction.maximumDuration`, the market should be cancelled. -1. Market cancelled before the market leaves the opening auction (so market never left Pending state so far). +1. Market stays in opening auction till time passes `market.auction.maximumDuration`, then the market should be cancelled. 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. From 6b7701cbc12fa593ea805f437fb5f237aac57be1 Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Mon, 29 Apr 2024 15:58:50 +0100 Subject: [PATCH 1104/1171] chore: update json file --- protocol/features.json | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/protocol/features.json b/protocol/features.json index 46ae72e3c..95523eba0 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -33,7 +33,10 @@ }, "Market suspended/resumed before enactment": { "milestone": "colosseo", - "acs": ["0043-MKTL-011"] + "acs": [ + "0043-MKTL-011", + "0043-MKTL-012", + "0043-MKTL-013"] }, "Teams": { "milestone": "colosseo", From d82b1c74e3bed2866a5fdb27b7fc3b32f66f3a34 Mon Sep 17 00:00:00 2001 From: Jiajia-Cui <92106936+Jiajia-Cui@users.noreply.github.com> Date: Mon, 29 Apr 2024 16:25:12 +0100 Subject: [PATCH 1105/1171] feat: address comment Co-authored-by: David Siska <62546419+davidsiska-vega@users.noreply.github.com> --- protocol/0043-MKTL-market_lifecycle.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0043-MKTL-market_lifecycle.md b/protocol/0043-MKTL-market_lifecycle.md index 1330ceefa..92adc76c1 100644 --- a/protocol/0043-MKTL-market_lifecycle.md +++ b/protocol/0043-MKTL-market_lifecycle.md @@ -13,7 +13,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](./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. If the enactment date is passed by more than the maximum opening auction extension duration Network Parameter (`market.auction.maximumDuration`), the market should be cancelled. +If the proposal is successful the market will go into opening auction at least until the proposed `enactment` date. If the enactment date is passed by more than the maximum opening auction extension duration Network Parameter (`market.auction.maximumDuration`) and the opening auction hasn't uncrossed, then the market is automatically cancelled. ## Market lifecycle statuses From 1ff080f320ad5637fe3cd9000212f6f76a7999c2 Mon Sep 17 00:00:00 2001 From: Tom Date: Thu, 25 Apr 2024 12:42:40 +0100 Subject: [PATCH 1106/1171] feat: automated market maker (#2019) * feat: AMM draft --------- Co-authored-by: gordsport --- .../0014-NP-VAMM-bounds-estimations.md | 124 +++ protocol/0026-AUCT-auctions.md | 8 + protocol/0028-GOVE-governance.md | 2 + ...042-LIQF-setting_fees_and_rewarding_lps.md | 11 +- protocol/0056-REWA-rewards_overview.md | 7 + protocol/0057-TRAN-transfers.md | 3 + protocol/0068-MATC-matching_engine.md | 16 + .../0090-VAMM-automated_market_maker.ipynb | 787 ++++++++++++++++++ protocol/0090-VAMM-automated_market_maker.md | 333 ++++++++ protocol/features.json | 57 +- wordlist.txt | 31 +- 11 files changed, 1365 insertions(+), 14 deletions(-) create mode 100644 non-protocol-specs/0014-NP-VAMM-bounds-estimations.md create mode 100644 protocol/0090-VAMM-automated_market_maker.ipynb create mode 100644 protocol/0090-VAMM-automated_market_maker.md diff --git a/non-protocol-specs/0014-NP-VAMM-bounds-estimations.md b/non-protocol-specs/0014-NP-VAMM-bounds-estimations.md new file mode 100644 index 000000000..8f58158ee --- /dev/null +++ b/non-protocol-specs/0014-NP-VAMM-bounds-estimations.md @@ -0,0 +1,124 @@ + +# vAMM Bounds Estimation Calculator + + +## Summary + +The protocol contains the ability for users to create vAMMs which will automatically trade and manage a position on a given market with no further interaction from the user. These are configured through a few different parameters, which uniquely specify the behaviour and volume profile of the vAMM as the price of the market moves, however are not always immediately obvious and intuitive for a user given the set of inputs. As such, it is necessary to provide an API giving canonical conversions between these values. + +The API should take a pool's specification parameters and output various metrics useful for a user deciding on vAMM configuration. Concretely, the API should take the parameters: + + 1. Base Price + 1. Upper Price + 1. Lower Price + 1. Leverage At Upper Price + 1. Leverage At Lower Price + 1. Commitment Amount + 1. Optional: Party Key + +And then return the metrics: + + 1. Loss on Commitment at Upper Bound + 1. Loss on Commitment at Lower Bound + 1. Position Size at Upper Bound + 1. Position Size at Lower Bound + 1. Liquidation Price at Upper Bound + 1. Liquidation Price at Lower Bound + 1. If `party key` is specified: + 1. Approximate trade size on amendment (immediate) + 1. Approximate crystallised loss from position rebalancing (immediate) + 1. Change in Size at Upper Bound vs current specification + 1. Change in Size at Lower Bound vs current specification + 1. Change in Loss at Upper Bound vs current specification + 1. Change in Loss at Lower Bound vs current specification + + +## Calculations + +There are a few values which are generally useful to calculate many of the above required outputs, so these will be calculated first. + +Starting with the average entry price, this value for a given range is equal no matter the absolute volume committed, so can be calculated without reference to the bond or leverage at bounds values. This is taken from the unit liquidity, $L_u$ + +$$ +L_u = \frac{\sqrt{p_u} \sqrt{p_l}}{\sqrt{p_u} - \sqrt{p_l}} , +$$ + +where $p_u$ is the price at the upper end of the range (`upper price` for the upper range and `base price` for the lower range) and $p_l$ is the corresponding lower price for the range. With this, the average entry price can be found to be + +$$ +p_a = L_u p_u (1 - \frac{L_u}{L_u + p_u}) , +$$ + +where $p_a$ is the average execution price across the range and other values are as defined above. Finally, the risk factor which will be used for calculating leverage at bounds + +$$ +r_f = \min(l_b, \frac{1}{ (f_s + f_l) \cdotp f_i}) , +$$ + +where $l_b$ is the sided value `leverage_at_bounds` (`upper ratio` if the upper band is being considered and `lower ratio` if the lower band is), $f_s$ is the market's sided risk factor (different for long and short positions), $f_l$ is the market's linear slippage component and $f_i$ is the market's initial margin factor. + + +### Position at Bounds + +With this, the volumes required to trade to the bounds of the ranges are: + +$$ +P_{v_l} = \frac{r_f b}{p_l (1 - r_f) + r_f p_a} , +$$ +$$ +P_{v_u} = \frac{r_f b}{p_u (1 + r_f) - r_f p_a} , +$$ + +where $r_f$ is the `short` factor for the upper range and the `long` factor for the lower range, `b` is the current total balance of the vAMM across all accounts, $P_{v_l}$ is the theoretical volume and the bottom of the lower bound and $P_{v_u}$ is the (absolute value of the) theoretical volume at the top of the upper bound. + + +### Loss on Commitment at Bound + +For the loss on commitment at bound, one needs to use the average entry price, bound price and the position at the bounds + +$$ +l_c = |p_a - p_b| \cdot P_b , +$$ + +where $P_b$ is the position at bounds (Either $P_{v_l}$ or $P_{v_u}$), $p_a$ is the average entry price and $p_b$ is the price at the corresponding outer bound. Note that this is an absolute value of loss, so outstanding balance at bounds would be `initial balance - $L_c$`. + + +### Liquidation Prices + +Using a similar methodology to the standard estimations for liquidation price and the above calculated values, an estimate for liquidation prices above and below the range can be obtained with + +$$ +p_{liq} = \frac{b - l_c - P_b \cdot p_b}{\abs{P_b} \cdot m_r - P_b} , +$$ + +where $p_{liq}$ is the liquidation price (above or below the specified ranges), $b$ is the original commitment balance, $l_c$ is the loss on commitment at the relevant bound, $P_b$ is the position at the relevant bound, $p_b$ is the price at the bound and $m_r$ is the market's long or short risk factor (short for the upper price bound as the position will be negative and long for the lower). + + +## Specified Key + +When a key is specified, the existence of any current vAMM should be checked and, if one exists, the above values also calculated for it and populated in the requisite areas of the response to allow easy comparison. + + +## Acceptance criteria + +- For a request specifying (base, upper, lower, leverage_upper, leverage_lower, commitment) as (1000, 1100, 900, 2, 2, 100) the response is (0014-NP-VAMM-001): + + 1. Loss on Commitment at Upper Bound: 8.515 + 1. Loss on Commitment at Lower Bound: 9.762 + 1. Position Size at Upper Bound: -0.166 + 1. Position Size at Lower Bound: 0.201 + 1. Liquidation Price at Upper Bound: 1633.663 + 1. Liquidation Price at Lower Bound: 454.545 + + +- For a request specifying (base, upper, lower, leverage_upper, leverage_lower, commitment) as (1000, 1300, 900, 1, 5, 100) the response is (0014-NP-VAMM-001): + + 1. Loss on Commitment at Upper Bound: 10.948 + 1. Loss on Commitment at Lower Bound: 21.289 + 1. Position Size at Upper Bound: -0.069 + 1. Position Size at Lower Bound: 0.437 + 1. Liquidation Price at Upper Bound: 2574.257 + 1. Liquidation Price at Lower Bound: 727.273 + +- A request with an empty upper *or* lower bound price is valid and will return the metrics for the bound which *was* specified with the metrics for the unspecified bound empty. (0014-NP-VAMM-002) +- A request with an empty upper *and* lower bound is invalid and receives an error code back. (0014-NP-VAMM-003) diff --git a/protocol/0026-AUCT-auctions.md b/protocol/0026-AUCT-auctions.md index 46c1a3320..e0eeb76cc 100644 --- a/protocol/0026-AUCT-auctions.md +++ b/protocol/0026-AUCT-auctions.md @@ -51,6 +51,8 @@ We can also imagine that an auction period could come to an end once a give numb Once the auction period finishes, vega needs to figure out the best price for the order range in the book which can be uncrossed. The first stage in this is to calculate the Volume Maximising Price Range - the range of prices (which will be a contiguous range in an unconstrained order book) at which the highest total quantity of trades can occur. +For including [AMM](./0090-VAMM-automated_market_maker.md) configurations in the auction uncrossing process and volume maximising price range, create two lists of independent copies of all currently active vAMMs, including those which are currently in `single-sided` mode due to being unsynchronised. Ensure that the price range under consideration (lowest ask - highest bid) is expanded to cover the current best bid/ask prices of all vAMMs. For vAMMs which are currently unsynchronised, take their best bid/ask to be their current fair price. When iterating through the price ranges the vAMMs should be updated after each price level checked as if they have traded that volume before checking the next level. Unsynchronised vAMMs may quote on both sides of the book (as there is no current price towards which they should be trading) but will not necessarily be marked synchronised as a result of the price auction uncrossing. + Initially we will use the mid price within this range. For example, if the volume maximising range is 98-102, we would price all trades in the uncrossing at 100 ((minimum price of range+maximum price of range)/2). In future there will be other options, which will be selectable via a network parameter specified at market creation, and changeable through governance. These other options are not yet specified. ## APIs related to auctions @@ -178,3 +180,9 @@ message Market { - 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) + +- Leaving an auction on a market with one active vAMM and some volume of crossing limit orders (bids where the vAMM would sell or sells where the vAMM would buy) results in these orders trading with the vAMM and an un-crossed order book afterwards. (0026-AUCT-033) +- Leaving an auction on a market with three active vAMMs with differing implied fair prices results in the vAMMs trading with each other and an un-crossed order book afterwards (all vAMMs either have the same fair price or are at one extreme of their range). (0026-AUCT-034) +- Leaving an auction with three active vAMMs whose ranges do not overlap at all results in the vAMMs trading with each other and at least two of them hitting their position limits. (0026-AUCT-035) +- Leaving an auction with two active vAMMs with differing implied fair prices but with overlapping ranges, and a buy order at a price within both of their upper ranges (such that they would both be short) with a volume greater than the combined short position of the vAMMs at that price, results in an uncrossed market with the remaining buy order's price as the best bid after trading with the vAMMs to move their fair prices to this price. (0026-AUCT-036) +- Leaving an auction with two active vAMMs with differing implied fair prices but with overlapping ranges, and a sell order at a price within both of their lower ranges (such that they would both be long) with a volume greater than the combined long position of the vAMMs at that price, results in an uncrossed market with the remaining sell order's price as the best ask after trading with the vAMMs to move their fair prices to this price. (0026-AUCT-037) diff --git a/protocol/0028-GOVE-governance.md b/protocol/0028-GOVE-governance.md index c4caeafa8..62e9f7923 100644 --- a/protocol/0028-GOVE-governance.md +++ b/protocol/0028-GOVE-governance.md @@ -94,6 +94,8 @@ Market change proposals can also be submitted by any party which has at least th Moreover, market LPs can vote on market change proposals even if they don't have `governance.proposal.updateMarket.minVoterBalance` governance tokens. 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. +If a party has any sub-account running [AMM strategies](./0090-VAMM-automated_market_maker.md) then the `equity-like share` of the party's votes on that market should be the sum of the `equity-like share` for the key itself and any assigned to the sub-account. + ### Duration of the proposal A new proposal will have a close date specified as a timestamp. After the proposal is created in the system and before the close date, the proposal is open for votes. e.g: A proposal is created and people have 3 weeks from the day it is sent to the network in order to submit votes for it. diff --git a/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md b/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md index c368c472f..917f51886 100644 --- a/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md +++ b/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md @@ -247,7 +247,7 @@ The account is under control of the network and funds from this account will be 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. +The liquidity fees are transferred from the market's aggregate LP fee account into the LP-per-market fee account from two different configurable size buckets, defined by the network parameter `market.liquidity.equityLikeShareFeeFraction`. The first bucket, a proportion equal to `market.liquidity.equityLikeShareFeeFraction` of the fee, is divided 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 other bucket, `1 - market.liquidity.equityLikeShareFeeFraction`, is divided purely by each LP's in-epoch liquidity score `LP i liquidity score`, scaled again across the value of all LPs at that 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. @@ -314,7 +314,7 @@ i.e. your penalty is the bigger of current epoch and average over the hysteresis ### 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 commitment 100% of the time and `1` indicating that LP was below `market.liquidity.commitmentMinTimeFraction` 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. All vAMM LPs should also receive a $p_i^n$ value, however this will always be `0`, as they are defined as always meeting their commitment. 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. @@ -458,3 +458,10 @@ Example 1, generated with [supplementary worksheet](https://docs.google.com/spre | LP2 | 0.05 | 100 | 95 | 2344.02439 | | LP3 | 0.6 | 7000 | 2800 | 69087.03466 | | LP4 | 1 | 91900 | 0 | 0 | + + +### vAMM behaviour + +- All vAMMs active on a market at the end of an epoch receive SLA bonus rebalancing payments with `0` penalty fraction. (0042-LIQF-063) +- A vAMM active on a market during an epoch, which was cancelled prior to the end of an epoch, receives SLA bonus rebalancing payments with `0` penalty fraction. (0042-LIQF-064) +- A vAMMs cancelled in a previous epoch does not receive anything and is not considered during SLA rebalancing at the end of an epoch(0042-LIQF-065) diff --git a/protocol/0056-REWA-rewards_overview.md b/protocol/0056-REWA-rewards_overview.md index fefec793c..79740b52e 100644 --- a/protocol/0056-REWA-rewards_overview.md +++ b/protocol/0056-REWA-rewards_overview.md @@ -239,6 +239,8 @@ The entire reward account balance is paid out every epoch unless the total value 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). +Any rewards which would be distributed to an AMM sub-key should instead be sent to the parent key's corresponding account. These transfers should be labelled with a field `from_key` which specifies the sub-key as the original recipient. This field should be blank for rewards earned by a standard key. + ### Distributing rewards amongst entities Rewards are distributed amongst entities based on the distribution method defined in the recurring transfer. @@ -1136,3 +1138,8 @@ At the end of epoch 2, 10000 VEGA rewards should be distributed to the `ETHUSDT` - Given a reward metric scoping both spot and leveraged markets, a parties trades in the spot market will correctly contribute to their maker fees paid reward metric. (0056-REWA-165). - Given a reward metric scoping both spot and leveraged markets, a parties trades in the spot market will correctly contribute to their maker fees received reward metric. (0056-REWA-166). - Given a reward metric scoping both spot and leveraged markets, a parties received liquidity fees from the spot market will correctly contribute to their liquidity fees received reward metric. (0056-REWA-167). + +## vAMMs + +- If an AMM sub-key earns rewards which would be transferred to it's vesting account, these rewards are instead transferred to the parent key's vesting account with a `from_key` field specifying the sub-key (0056-REWA-152). +- If an AMM sub-key earns rewards which would be transferred to it's locked account, these rewards are instead transferred to the parent key's locked account with a `from_key` field specifying the sub-key (0056-REWA-153). diff --git a/protocol/0057-TRAN-transfers.md b/protocol/0057-TRAN-transfers.md index 65f07cfdf..73c42b703 100644 --- a/protocol/0057-TRAN-transfers.md +++ b/protocol/0057-TRAN-transfers.md @@ -101,6 +101,7 @@ To support entity scoping, the transaction include the following fields: - `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_AMM` - all keys representing AMM parties (i.e. excluding those directly controlled by parties) 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 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`. @@ -410,3 +411,5 @@ If a party sets up a recurring transfer with a `transfer_interval` field strictl If a party sets up a recurring transfer with a `transfer_interval` field strictly greater than `1`, if they cancel the recurring transfer the locked funds will not be released and the next payout event will happen regardless. (0057-TRAN-078) If a party sets up a recurring transfer with a transfer interval strictly greater than `1` and specifies a `cap_reward_fee_multiple`. If `calculated_reward_in_quantum > cap_reward_fee_multiple × fees_paid_since_last_payout_in_quantum` then the actual amount of reward transferred to each public key during distribution for this transfer will be `cap_reward_fee_multiple × fees_paid_since_last_payout_in_quantum`(0057-TRAN-079) + +A recurring transfer to a reward account with entity scope set to individuals and individual scope set to `INDIVIDUAL_SCOPE_AMM` will only be divided amongst AMM parties based on their score in the relevant metric (0057-TRAN-080) diff --git a/protocol/0068-MATC-matching_engine.md b/protocol/0068-MATC-matching_engine.md index 2529434c6..b9fd4870f 100644 --- a/protocol/0068-MATC-matching_engine.md +++ b/protocol/0068-MATC-matching_engine.md @@ -118,6 +118,22 @@ Given an order book that looks like this in the market display: | | 90 | 10 | | | 80 | 15 | + +### Matching Process + +For all incoming active orders, the matching process will coordinate between the on- and off-book sources of liquidity. When an order comes in which may immediately trade (there are not already resting orders of the same type for the best applicable price) the following steps should be followed. If at any point the order's full volume has traded the process is immediately halted: + + 1. For the first applicable price level (the first valid price with no orders on the same side, implying an order could theoretically immediately trade there, one tick above best bid for an incoming buy and one tick below best ask for an incoming sell), all on-book orders should be checked. Any volume at this price level which can be met through on-book orders will then trade. + 1. For any `remaining volume`, the AMMs will be checked. This requires an algorithm to ensure the protocol does not have to check every price level individually: + 1. Call the current price level `current price` + 1. Check the price level which has the next resting on-book order, set this to be the `outer price` for the check. + 1. Check all active AMMs, querying their quote price API with the smallest trade unit on the market in the direction of trading (if the incoming order is a `buy`, query the AMM's `ask`, or vice versa). Retain those where this price < `outer price` + 1. Within these, select either the minimum `upper price` (if the incoming order is a buy) or the maximum `lower price` (if the incoming order is a sell), call this `amm bound price`. This is the range where all of these AMMs are active. Finally, select either the minimum (for a buy) or maximum (for a sell) between `amm bound price` and `outer price`. From this form an interval `current price, outer price`. + 1. Now, for each AMM within this range, calculate the volume of trading required to move each from the `current price` to the `outer price`. Call the sum of this volume `total volume`. + 1. If `remaining volume <= total volume` split trades between the AMMs according to their proportional contribution to `total volume` (e.g. larger liquidity receives a higher proportion of the trade). This ensures their mid prices will move equally. Each of these trades should count as a single aggressive trade with the given AMM and pay fees accordingly. + 1. If `remaining volume > total volume` execute all trades to move the respective AMMs to their boundary at `outer price`. Now, return to step `1` with `current price = outer price`, checking first for on-book liquidity at the new level then following this process again until all order volume is traded or liquidity exhausted. + 1. For all trades generated in the previous two steps, an execution price should be calculated using the AMM's API to return a price for a given volume. These prices should be rounded to the nearest valid market tick in the AMM's favour (i.e. round upwards when the AMM is selling and downwards when the AMM is buying). This process can be optimised as when splitting trades between AMMs according to their respective commitment sizes they will each end up at the same executed price, so only one AMM's price need be calculated. + ## See also - [0008-TRAD-Trading Workflow](./0008-TRAD-trading_workflow.md) diff --git a/protocol/0090-VAMM-automated_market_maker.ipynb b/protocol/0090-VAMM-automated_market_maker.ipynb new file mode 100644 index 000000000..8af8b49b3 --- /dev/null +++ b/protocol/0090-VAMM-automated_market_maker.ipynb @@ -0,0 +1,787 @@ +{ + "cells": [ + { + "cell_type": "code", + "execution_count": null, + "id": "94be4268-65d7-49b6-8c37-40628437dc58", + "metadata": {}, + "outputs": [], + "source": [ + "import numpy\n", + "from typing import Optional, Tuple, List\n", + "from collections import namedtuple\n", + "import matplotlib.pyplot as plt" + ] + }, + { + "cell_type": "code", + "execution_count": null, + "id": "955087ab", + "metadata": {}, + "outputs": [], + "source": [ + "\n", + "MMOrder = namedtuple(\"MMOrder\", [\"size\", \"price\"])" + ] + }, + { + "cell_type": "code", + "execution_count": null, + "id": "d91a510a-3fc5-46f7-a77e-971a4c1e3394", + "metadata": {}, + "outputs": [], + "source": [ + "class CFMMarketMaker:\n", + " def __init__(\n", + " self,\n", + " initial_price: float = 100,\n", + " price_width_below: float = 0.05,\n", + " price_width_above: float = 0.05,\n", + " margin_multiple_at_upper: float = 2,\n", + " margin_multiple_at_lower: float = 2,\n", + " volume_per_side: float = 10,\n", + " num_levels: int = 25,\n", + " tick_spacing: float = 1,\n", + " ):\n", + " self.base_price = initial_price\n", + " self.upper_price = (1 + price_width_above) * initial_price\n", + " self.lower_price = (1 - price_width_below) * initial_price\n", + "\n", + " self.base_price_sqrt = initial_price**0.5\n", + " self.upper_price_sqrt = self.upper_price**0.5\n", + " self.lower_price_sqrt = self.lower_price**0.5\n", + "\n", + " self.lower_liq_factor = 1 / (self.base_price_sqrt - self.lower_price_sqrt)\n", + " self.upper_liq_factor = 1 / (self.upper_price_sqrt - self.base_price_sqrt)\n", + "\n", + " self.margin_multiple_at_upper = margin_multiple_at_upper\n", + " self.margin_multiple_at_lower = margin_multiple_at_lower\n", + "\n", + " self.tick_spacing = tick_spacing\n", + " self.num_levels = num_levels\n", + " self.volume_per_side = volume_per_side\n", + "\n", + " def initialise(\n", + " self,\n", + " vega,\n", + " ):\n", + " risk_factors = vega.get_risk_factors(self.market_id)\n", + " self.short_factor, self.long_factor = risk_factors.short, risk_factors.long\n", + "\n", + " def _quantity_for_move(\n", + " self,\n", + " start_price_sqrt,\n", + " end_price_sqrt,\n", + " range_upper_price_sqrt,\n", + " liquidity_factor,\n", + " ) -> Optional[float]:\n", + " if liquidity_factor == 0:\n", + " return None\n", + " start_fut_pos = (\n", + " liquidity_factor\n", + " * (range_upper_price_sqrt - start_price_sqrt)\n", + " / (start_price_sqrt * range_upper_price_sqrt)\n", + " )\n", + " end_fut_pos = (\n", + " liquidity_factor\n", + " * (range_upper_price_sqrt - end_price_sqrt)\n", + " / (end_price_sqrt * range_upper_price_sqrt)\n", + " )\n", + "\n", + " return abs(start_fut_pos - end_fut_pos)\n", + "\n", + " def _generate_shape(\n", + " self, bid_price_depth: float, ask_price_depth: float\n", + " ) -> Tuple[List[MMOrder], List[MMOrder]]:\n", + " return self._generate_shape_calcs(\n", + " balance=sum(\n", + " a.balance\n", + " for a in self.vega.get_accounts_from_stream(\n", + " key_name=self.key_name,\n", + " wallet_name=self.wallet_name,\n", + " market_id=self.market_id,\n", + " )\n", + " ),\n", + " position=self.current_position,\n", + " )\n", + "\n", + " def _quote_price(self,\n", + " balance: float,\n", + " position: float,\n", + " volume: float = 0\n", + " ):\n", + " \n", + " # volume_at_lower = (\n", + " # balance * self.max_perc_loss_at_lower / (aep_lower - self.lower_price)\n", + " # )\n", + " # abs_volume_at_upper = (\n", + " # balance * self.max_perc_loss_at_upper / (self.upper_price - aep_upper)\n", + " # )\n", + "\n", + " # loss = volume_at_lower * (aep_lower - self.lower_price)\n", + " # margin = (volume_at_lower * self.lower_price) / (balance - loss)\n", + "\n", + " # volume_at_lower = balance * loss_at_lower_perc / (aep_lower - self.lower_price)\n", + " # margin = (volume_at_lower * self.lower_price) / (balance - loss)\n", + "\n", + " # volume_at_lower = margin * (balance - loss) / self.lower_price\n", + " # volume_at_lower = margin * (balance - volume_at_lower * (aep_lower - self.lower_price)) / self.lower_price\n", + " # volume_at_lower = - volume_at_lower * margin * ( aep_lower - self.lower_price) / self.lower_price + margin * balance / self.lower_price\n", + " # volume_at_lower (1 + margin * (aep_lower - self.lower_price) / self.lower_price) = margin * balance / self.lower_price\n", + " # volume_at_lower (self.lower_price (1 - margin) + margin * aep_lower) / self.lower_price = margin * balance / self.lower_price\n", + " # volume_at_lower = margin * balance / (self.lower_price (1 - margin) + margin * aep_lower)\n", + "\n", + "\n", + " # loss = abs_volume_at_upper * (self.upper_price - aep_upper)\n", + " # margin = (abs_volume_at_upper * self.upper_price) / (balance - loss)\n", + "\n", + " # abs_volume_at_upper = margin * (balance - loss) / self.upper_price\n", + " # abs_volume_at_upper = margin * (balance - abs_volume_at_upper * (self.upper_price - aep_upper)) / self.upper_price\n", + "\n", + " # abs_volume_at_upper = - abs_volume_at_upper * margin * (self.upper_price - aep_upper) / self.upper_price + margin * balance / self.upper_price\n", + "\n", + " # abs_volume_at_upper (1 + margin * (self.upper_price - aep_upper) / self.upper_price) = margin * balance / self.upper_price\n", + "\n", + " # abs_volume_at_upper (self.upper_price (1 + margin) - margin * aep_upper) / self.upper_price = margin * balance / self.upper_price\n", + " \n", + " # abs_volume_at_upper = margin * balance / (self.upper_price (1 + margin) - margin * aep_upper)\n", + "\n", + " unit_upper_L = (\n", + " self.upper_price_sqrt\n", + " * self.base_price_sqrt\n", + " / (self.upper_price_sqrt - self.base_price_sqrt)\n", + " )\n", + "\n", + " unit_lower_L = (\n", + " self.lower_price_sqrt\n", + " * self.base_price_sqrt\n", + " / (self.base_price_sqrt - self.lower_price_sqrt)\n", + " )\n", + " aep_lower = -1 * unit_lower_L * self.base_price_sqrt * ((unit_lower_L / (unit_lower_L + self.base_price_sqrt)) - 1)\n", + " aep_upper = -1 * unit_upper_L * self.upper_price_sqrt * ((unit_upper_L / (unit_upper_L + self.upper_price_sqrt)) - 1)\n", + "\n", + " volume_at_lower = self.margin_multiple_at_lower * balance / (self.lower_price * (1 - self.margin_multiple_at_lower) + self.margin_multiple_at_lower * aep_lower)\n", + " volume_at_upper = self.margin_multiple_at_upper * balance / (self.upper_price * (1 + self.margin_multiple_at_upper) - self.margin_multiple_at_upper * aep_upper)\n", + " \n", + " upper_L = (\n", + " volume_at_upper\n", + " * self.upper_price_sqrt\n", + " * self.base_price_sqrt\n", + " / (self.upper_price_sqrt - self.base_price_sqrt)\n", + " )\n", + "\n", + " lower_L = (\n", + " volume_at_lower\n", + " * self.lower_price_sqrt\n", + " * self.base_price_sqrt\n", + " / (self.base_price_sqrt - self.lower_price_sqrt)\n", + " )\n", + "\n", + " if position > 0 or (position == 0 and volume > 0):\n", + " L = lower_L\n", + " upper_bound = self.base_price_sqrt\n", + " virt_x = position + L / upper_bound\n", + "\n", + " rt_ref_price = upper_bound / (position * upper_bound / L + 1)\n", + " virt_y = L * rt_ref_price\n", + "\n", + " else:\n", + " L = upper_L\n", + " upper_bound = self.upper_price_sqrt\n", + " virt_x = (volume_at_upper + position) + L / upper_bound\n", + " \n", + " rt_ref_price = upper_bound / ((volume_at_upper + position) * upper_bound / L + 1)\n", + " virt_y = L * rt_ref_price\n", + "\n", + " if volume == 0:\n", + " return rt_ref_price ** 2\n", + " else:\n", + " out = (virt_y * virt_x) / (virt_x - volume) - virt_y\n", + " return out / volume\n", + "\n", + " def _generate_shape_calcs(\n", + " self,\n", + " balance: float,\n", + " position: float,\n", + " ) -> Tuple[List[MMOrder], List[MMOrder]]:\n", + " unit_upper_L = (\n", + " self.upper_price_sqrt\n", + " * self.base_price_sqrt\n", + " / (self.upper_price_sqrt - self.base_price_sqrt)\n", + " )\n", + "\n", + " unit_lower_L = (\n", + " self.lower_price_sqrt\n", + " * self.base_price_sqrt\n", + " / (self.base_price_sqrt - self.lower_price_sqrt)\n", + " )\n", + " aep_lower = -1 * unit_lower_L * self.base_price_sqrt * ((unit_lower_L / (unit_lower_L + self.base_price_sqrt)) - 1)\n", + " aep_upper = -1 * unit_upper_L * self.upper_price_sqrt * ((unit_upper_L / (unit_upper_L + self.upper_price_sqrt)) - 1)\n", + " \n", + " volume_at_lower = self.margin_multiple_at_lower * balance / (self.lower_price * (1 - self.margin_multiple_at_lower) + self.margin_multiple_at_lower * aep_lower)\n", + " volume_at_upper = self.margin_multiple_at_upper * balance / (self.upper_price * (1 + self.margin_multiple_at_upper) - self.margin_multiple_at_upper * aep_upper)\n", + " \n", + " upper_L = (\n", + " volume_at_upper\n", + " * self.upper_price_sqrt\n", + " * self.base_price_sqrt\n", + " / (self.upper_price_sqrt - self.base_price_sqrt)\n", + " )\n", + "\n", + " lower_L = (\n", + " volume_at_lower\n", + " * self.lower_price_sqrt\n", + " * self.base_price_sqrt\n", + " / (self.base_price_sqrt - self.lower_price_sqrt)\n", + " )\n", + "\n", + " if position > 0:\n", + " L = lower_L\n", + " upper_bound = self.base_price_sqrt\n", + " rt_ref_price = upper_bound / (position * upper_bound / L + 1)\n", + " else:\n", + " L = upper_L\n", + " upper_bound = self.upper_price_sqrt\n", + " rt_ref_price = upper_bound / ((volume_at_upper + position) * upper_bound / L + 1)\n", + "\n", + "\n", + " return self._calculate_price_levels(\n", + " ref_price=rt_ref_price ** 2,\n", + " balance=balance,\n", + " upper_L=upper_L,\n", + " lower_L=lower_L,\n", + " position=position,\n", + " )\n", + "\n", + " def _calculate_liq_val(\n", + " self, margin_frac: float, balance: float, risk_factor: float, liq_factor: float\n", + " ) -> float:\n", + " return margin_frac * (balance / risk_factor) * liq_factor\n", + "\n", + " def _calculate_price_levels(\n", + " self,\n", + " ref_price: float,\n", + " balance: float,\n", + " upper_L: float,\n", + " lower_L: float,\n", + " position: float,\n", + " ) -> Tuple[List[MMOrder], List[MMOrder]]:\n", + " if ref_price == 0:\n", + " ref_price = self.curr_price\n", + "\n", + " agg_bids = []\n", + " agg_asks = []\n", + "\n", + " pos = position\n", + "\n", + " for i in range(1, self.num_levels):\n", + " pre_price_sqrt = (ref_price + (i - 1) * self.tick_spacing) ** 0.5\n", + " price = ref_price + i * self.tick_spacing\n", + "\n", + " if price > self.upper_price or price < self.lower_price:\n", + " continue\n", + "\n", + " volume = self._quantity_for_move(\n", + " pre_price_sqrt,\n", + " price**0.5,\n", + " self.upper_price_sqrt if pos < 0 else self.base_price_sqrt,\n", + " upper_L if pos < 0 else lower_L,\n", + " )\n", + " if volume is not None:\n", + " if pos > 0 and pos - volume < 0:\n", + " volume = pos\n", + " agg_asks.append(MMOrder(volume, price))\n", + " pos -= volume\n", + "\n", + " pos = position\n", + " for i in range(1, self.num_levels):\n", + " pre_price_sqrt = (ref_price - (i - 1) * self.tick_spacing) ** 0.5\n", + " price = ref_price - i * self.tick_spacing\n", + "\n", + " if price > self.upper_price or price < self.lower_price:\n", + " continue\n", + "\n", + " volume = self._quantity_for_move(\n", + " pre_price_sqrt,\n", + " price**0.5,\n", + " self.upper_price_sqrt if pos < 0 else self.base_price_sqrt,\n", + " upper_L if pos < 0 else lower_L,\n", + " )\n", + " if volume is not None:\n", + " if pos < 0 and pos + volume > 0:\n", + " volume = pos\n", + " agg_bids.append(MMOrder(volume, price))\n", + " pos += volume\n", + "\n", + " return agg_bids, agg_asks" + ] + }, + { + "cell_type": "code", + "execution_count": null, + "id": "60c5c97e", + "metadata": {}, + "outputs": [], + "source": [] + }, + { + "cell_type": "code", + "execution_count": null, + "id": "c2cc483a", + "metadata": { + "scrolled": true + }, + "outputs": [], + "source": [ + "\n", + "mm = CFMMarketMaker(\n", + " initial_price=2000,\n", + " price_width_above=5,\n", + " price_width_below=0.99,\n", + " margin_multiple_at_lower=5,\n", + " margin_multiple_at_upper=5,\n", + " num_levels=8000,\n", + " tick_spacing=1,\n", + ")\n", + "\n", + "balance = 100_000\n", + "\n", + "mm.short_factor = 0.02\n", + "mm.long_factor = 0.02\n", + "\n", + "lower_L_unit = (\n", + " mm.base_price_sqrt\n", + " * mm.lower_price_sqrt\n", + " / (mm.base_price_sqrt - mm.lower_price_sqrt)\n", + ")\n", + "upper_L_unit = (\n", + " mm.base_price_sqrt\n", + " * mm.upper_price_sqrt\n", + " / (mm.upper_price_sqrt - mm.base_price_sqrt)\n", + ")\n", + "\n", + "aep_lower = -1 * lower_L_unit * mm.base_price_sqrt * ((lower_L_unit / (lower_L_unit + mm.base_price_sqrt)) - 1)\n", + "volume_at_lower = mm.margin_multiple_at_lower * balance / (mm.lower_price * (1 - mm.margin_multiple_at_lower) + mm.margin_multiple_at_lower * aep_lower)\n", + "\n", + "aep_upper = -1 * upper_L_unit * mm.upper_price_sqrt * ((upper_L_unit / (upper_L_unit + mm.upper_price_sqrt)) - 1)\n", + "volume_at_upper = mm.margin_multiple_at_upper * balance / (mm.upper_price * (1 - mm.margin_multiple_at_upper) - mm.margin_multiple_at_upper * aep_upper)\n", + "\n", + "upper_L = (\n", + " volume_at_upper\n", + " * mm.upper_price_sqrt\n", + " * mm.base_price_sqrt\n", + " / (mm.upper_price_sqrt - mm.base_price_sqrt)\n", + ")\n", + "\n", + "lower_L = (\n", + " volume_at_lower\n", + " * mm.base_price_sqrt\n", + " * mm.lower_price_sqrt\n", + " / (mm.base_price_sqrt - mm.lower_price_sqrt)\n", + ")\n", + "\n", + "to_price = 3000\n", + "pos = mm._quantity_for_move(\n", + " mm.base_price_sqrt,\n", + " to_price**0.5,\n", + " mm.base_price_sqrt if to_price < mm.base_price else mm.upper_price_sqrt,\n", + " lower_L if to_price < mm.base_price else upper_L,\n", + ")\n", + "\n", + "print(\"Price is {}\".format(mm._quote_price(\n", + " balance=balance, position=0\n", + " ))\n", + ")\n", + "\n", + "print(\"Position is {}\".format(pos))\n", + "bids, asks = mm._generate_shape_calcs(\n", + " balance=balance, position=(-1 if to_price > mm.base_price else 1) * pos\n", + ")\n", + "\n", + "# x = []\n", + "# y = []\n", + "\n", + "# cumsum = 0\n", + "# for bid in bids:\n", + "# x.append(bid.price)\n", + "# cumsum += bid.size\n", + "# y.append(cumsum)\n", + "\n", + "# plt.plot(x, y, color=\"blue\")\n", + "x = []\n", + "y = []\n", + "\n", + "# cumsum = 0\n", + "# for ask in asks:\n", + "# x.append(ask.price)\n", + "# cumsum += ask.size\n", + "# y.append(cumsum)\n", + "# plt.plot(x, y, color=\"red\")\n", + "# plt.show()\n", + "\n", + "cumsum = 0\n", + "for bid in bids:\n", + " x.append(bid.price)\n", + " cumsum += bid.size\n", + " y.append(bid.size)\n", + "\n", + "plt.bar(x, y, color=\"blue\")\n", + "x = []\n", + "y = []\n", + "\n", + "cumsum = 0\n", + "for ask in asks:\n", + " x.append(ask.price)\n", + " cumsum += ask.size\n", + " y.append(ask.size)\n", + "plt.ylim((0, 0.5))\n", + "plt.bar(x, y, color=\"red\")\n", + "\n", + "print(f\"Mid is {(bids[0].price + asks[0].price) / 2 }\")\n", + "plt.show()\n", + "\n" + ] + }, + { + "cell_type": "code", + "execution_count": null, + "id": "d319c5bc", + "metadata": {}, + "outputs": [], + "source": [ + "mm = CFMMarketMaker(\n", + " initial_price=2000,\n", + " price_width_above=5,\n", + " price_width_below=0.99,\n", + " margin_multiple_at_upper=0.8,\n", + " margin_multiple_at_lower=0.8,\n", + " num_levels=8000,\n", + " tick_spacing=1,\n", + ")\n", + "\n", + "balance = 100_000\n", + "\n", + "mm.short_factor = 0.02\n", + "mm.long_factor = 0.02\n", + "\n", + "fair = mm._quote_price(\n", + " balance=balance, position=0, volume = 0\n", + ")\n", + "\n", + "single = mm._quote_price(\n", + " balance=balance, position=0, volume = 5\n", + ")\n", + "\n", + "double = mm._quote_price(\n", + " balance=2 * balance, position=0, volume = 10\n", + ")\n", + "\n", + "print(f\"f: {fair}, s: {single}, d: {double}\")" + ] + }, + { + "cell_type": "markdown", + "id": "b37aa817", + "metadata": {}, + "source": [ + "### Incoming AMM rebaselining" + ] + }, + { + "cell_type": "code", + "execution_count": null, + "id": "8575603a", + "metadata": {}, + "outputs": [], + "source": [ + "existing_mm = CFMMarketMaker(\n", + " initial_price=2000,\n", + " price_width_above=0.1,\n", + " price_width_below=0.1,\n", + " margin_multiple_at_lower=0.1,\n", + " margin_multiple_at_upper=0.1,\n", + " num_levels=8000,\n", + " tick_spacing=1,\n", + ")\n", + "\n", + "incoming_mm = CFMMarketMaker(\n", + " initial_price=2400,\n", + " price_width_above=5,\n", + " price_width_below=0.99,\n", + " margin_multiple_at_lower=2,\n", + " margin_multiple_at_upper=3,\n", + " num_levels=8000,\n", + " tick_spacing=1,\n", + ")\n", + "\n", + "balance = 10_000\n", + "existing_mm_balance = 10_000\n", + "\n", + "existing_mm.short_factor = 0.02\n", + "existing_mm.long_factor = 0.02\n", + "incoming_mm.short_factor = 0.02\n", + "incoming_mm.long_factor = 0.02\n", + "\n", + "lower_L_unit = (\n", + " incoming_mm.base_price_sqrt\n", + " * incoming_mm.lower_price_sqrt\n", + " / (incoming_mm.base_price_sqrt - incoming_mm.lower_price_sqrt)\n", + ")\n", + "\n", + "aep_lower = -1 * lower_L_unit * incoming_mm.base_price_sqrt * ((lower_L_unit / (lower_L_unit + incoming_mm.base_price_sqrt)) - 1)\n", + "volume_at_lower = incoming_mm.margin_multiple_at_lower * balance / (incoming_mm.lower_price * (1 - incoming_mm.margin_multiple_at_lower) + incoming_mm.margin_multiple_at_lower * aep_lower)\n", + "\n", + "\n", + "lower_L = (\n", + " volume_at_lower\n", + " * incoming_mm.base_price_sqrt\n", + " * incoming_mm.lower_price_sqrt\n", + " / (incoming_mm.base_price_sqrt - incoming_mm.lower_price_sqrt)\n", + ")\n" + ] + }, + { + "cell_type": "code", + "execution_count": null, + "id": "6c808160", + "metadata": {}, + "outputs": [], + "source": [ + "existing_mid = existing_mm._quote_price(existing_mm_balance, 0, 0)\n", + "\n", + "print(f\"Mid before is {existing_mid}\")\n", + "\n", + "to_rebaseline = incoming_mm._quantity_for_move(incoming_mm.base_price_sqrt, existing_mid**0.5, incoming_mm.base_price_sqrt, lower_L)\n", + "\n", + "print(f\"Rebaseline vol is {to_rebaseline}\")\n", + "\n", + "new_old_mid = incoming_mm._quote_price(balance, 0, 0)\n", + "\n", + "print(f\"mid for new was {new_old_mid}\")\n", + "\n", + "new_new_mid = incoming_mm._quote_price(balance, to_rebaseline, 0)\n", + "\n", + "print(f\"Now mid for new is {new_new_mid}\")\n" + ] + }, + { + "cell_type": "markdown", + "id": "58aa874e", + "metadata": {}, + "source": [ + "#### Ladder trading " + ] + }, + { + "cell_type": "code", + "execution_count": null, + "id": "5dee9001", + "metadata": {}, + "outputs": [], + "source": [ + "existing_mm = CFMMarketMaker(\n", + " initial_price=2000,\n", + " price_width_above=0.1,\n", + " price_width_below=0.1,\n", + " margin_multiple_at_upper=0.6,\n", + " margin_multiple_at_lower=0.6,\n", + " num_levels=8000,\n", + " tick_spacing=1,\n", + ")\n", + "\n", + "starting_pos = 0\n", + "px = 2000\n", + "balance = 8000\n", + "posn = 0\n", + "start_balance = balance\n", + "\n", + "step_size = 1\n", + "\n", + "lower_L = (\n", + " existing_mm.base_price_sqrt\n", + " * existing_mm.lower_price_sqrt\n", + " / (existing_mm.base_price_sqrt - existing_mm.lower_price_sqrt)\n", + ")\n", + "\n", + "aep = -1 * lower_L * existing_mm.base_price_sqrt * ((lower_L / (lower_L + existing_mm.base_price_sqrt)) - 1)\n", + "print(f\"aep is {aep}\")\n", + "print(f\"Requested multiple at lower bound is {existing_mm.margin_multiple_at_lower}\")\n", + "\n", + "volume_at_lower = existing_mm.margin_multiple_at_lower * balance / (existing_mm.lower_price * (1 - existing_mm.margin_multiple_at_lower) + existing_mm.margin_multiple_at_lower * aep)\n", + "\n", + "average_trade = 0\n", + "\n", + "lower_L = (\n", + " volume_at_lower\n", + " * existing_mm.base_price_sqrt\n", + " * existing_mm.lower_price_sqrt\n", + " / (existing_mm.base_price_sqrt - existing_mm.lower_price_sqrt)\n", + ")\n", + "\n", + "for i in range(1, 200):\n", + "\n", + " to_rebaseline = existing_mm._quantity_for_move(px**0.5, (px-1)**0.5, existing_mm.base_price_sqrt, lower_L)\n", + " to_rebaseline_price = existing_mm._quote_price(start_balance, posn, -1 * to_rebaseline)\n", + "\n", + " average_trade = (average_trade * posn + abs(to_rebaseline) * to_rebaseline_price) / (abs(to_rebaseline) + abs(posn))\n", + " px -= 1\n", + "\n", + " balance -= posn * step_size\n", + "\n", + " posn += to_rebaseline\n", + " print(f\"from {px + 1} to {px} takes volume {to_rebaseline} at price {to_rebaseline_price} with posn {posn} and balance {balance} average trade px {average_trade} implying leverage {posn * to_rebaseline_price / balance}\")\n", + "\n", + "print(f\"Loss is {start_balance - balance}\")\n", + "\n", + "for i in range(1, 200):\n", + "\n", + " to_rebaseline = existing_mm._quantity_for_move(px**0.5, (px+step_size)**0.5, existing_mm.base_price_sqrt, lower_L)\n", + " to_rebaseline_price = existing_mm._quote_price(start_balance, posn, to_rebaseline)\n", + " px += step_size\n", + " balance += posn\n", + "\n", + " posn -= to_rebaseline\n", + " print(f\"from {px + 1} to {px} takes volume {to_rebaseline} at price {to_rebaseline_price} with posn {posn} and balance {balance} average trade px {average_trade} implying leverage {posn * to_rebaseline_price / balance}\")\n" + ] + }, + { + "cell_type": "code", + "execution_count": null, + "id": "c475107d", + "metadata": {}, + "outputs": [], + "source": [ + "starting_pos = 0\n", + "px = 2000\n", + "start_balance = 1000\n", + "balance = 1000\n", + "posn = 0\n", + "\n", + "step_size = 1\n", + "\n", + "\n", + "upper_L_unit = (\n", + " existing_mm.upper_price_sqrt\n", + " * existing_mm.base_price_sqrt\n", + " / (existing_mm.upper_price_sqrt - existing_mm.base_price_sqrt)\n", + ")\n", + "\n", + "aep = -1 * upper_L_unit * existing_mm.upper_price_sqrt * ((upper_L_unit / (upper_L_unit + existing_mm.upper_price_sqrt)) - 1)\n", + "print(f\"aep is {aep}\")\n", + "print(f\"Requested multiple at upper bound is {existing_mm.margin_multiple_at_upper}\")\n", + "\n", + "volume_at_upper_incoming = existing_mm.margin_multiple_at_upper * balance / (existing_mm.upper_price * (1 + existing_mm.margin_multiple_at_upper) - existing_mm.margin_multiple_at_upper * aep)\n", + "\n", + "upper_L = (\n", + " volume_at_upper_incoming\n", + " * existing_mm.upper_price_sqrt\n", + " * existing_mm.base_price_sqrt\n", + " / (existing_mm.upper_price_sqrt - existing_mm.base_price_sqrt)\n", + ")\n", + "\n", + "\n", + "for i in range(1, 200):\n", + "\n", + " to_rebaseline = existing_mm._quantity_for_move(px**0.5, (px+1)**0.5, existing_mm.upper_price_sqrt, upper_L)\n", + " to_rebaseline_price = existing_mm._quote_price(balance, posn, to_rebaseline)\n", + " px += 1\n", + "\n", + " balance += posn * step_size\n", + " posn -= to_rebaseline\n", + "\n", + " print(f\"from {px - 1} to {px} takes volume {to_rebaseline} at price {to_rebaseline_price} with posn {posn} and balance {balance} implying leverage {- posn * to_rebaseline_price / balance}\")\n", + "\n", + "print(\"Returning\")\n", + "\n", + "for i in range(1, 200):\n", + "\n", + " to_rebaseline = existing_mm._quantity_for_move(px**0.5, (px+step_size)**0.5, existing_mm.upper_price_sqrt, upper_L)\n", + " to_rebaseline_price = existing_mm._quote_price(balance, posn, -1 * to_rebaseline)\n", + " px -= step_size\n", + " balance -= posn\n", + "\n", + " posn += to_rebaseline\n", + " print(f\"from {px + 1} to {px} takes volume {to_rebaseline} at price {to_rebaseline_price} with posn {posn} and balance {balance} implying leverage {- posn * to_rebaseline_price / balance}\")\n" + ] + }, + { + "cell_type": "markdown", + "id": "e0e75a17", + "metadata": {}, + "source": [ + "### Scenario Calculator" + ] + }, + { + "cell_type": "code", + "execution_count": null, + "id": "f0dff6e4", + "metadata": {}, + "outputs": [], + "source": [ + "upper_factor = 1300/1000 - 1\n", + "lower_factor = 0.1\n", + "base = 1000\n", + "\n", + "mm = CFMMarketMaker(\n", + " initial_price=base,\n", + " price_width_above=upper_factor,\n", + " price_width_below=lower_factor,\n", + " margin_multiple_at_upper=10,\n", + " margin_multiple_at_lower=1,\n", + " num_levels=8000,\n", + " tick_spacing=1,\n", + ")\n", + "\n", + "starting_pos = 0\n", + "balance = 10000\n", + "posn = 0\n", + "start_balance = balance\n", + "\n", + "unit_upper_L = (\n", + " mm.upper_price_sqrt\n", + " * mm.base_price_sqrt\n", + " / (mm.upper_price_sqrt - mm.base_price_sqrt)\n", + ")\n", + "\n", + "unit_lower_L = (\n", + " mm.lower_price_sqrt\n", + " * mm.base_price_sqrt\n", + " / (mm.base_price_sqrt - mm.lower_price_sqrt)\n", + ")\n", + "aep_lower = -1 * unit_lower_L * mm.base_price_sqrt * ((unit_lower_L / (unit_lower_L + mm.base_price_sqrt)) - 1)\n", + "aep_upper = -1 * unit_upper_L * mm.upper_price_sqrt * ((unit_upper_L / (unit_upper_L + mm.upper_price_sqrt)) - 1)\n", + "\n", + "volume_at_lower = mm.margin_multiple_at_lower * balance / (mm.lower_price * (1 - mm.margin_multiple_at_lower) + mm.margin_multiple_at_lower * aep_lower)\n", + "volume_at_upper = mm.margin_multiple_at_upper * balance / (mm.upper_price * (1 + mm.margin_multiple_at_upper) - mm.margin_multiple_at_upper * aep_upper)\n", + "\n", + "loss_at_lower = volume_at_lower * (mm.lower_price - aep_lower)\n", + "loss_at_upper = volume_at_upper * (mm.upper_price - aep_upper)\n", + "\n", + "print(f\"Position at lower would be {volume_at_lower} and position at upper would be {-1 * volume_at_upper} (Lower AEP {aep_lower}, Upper AEP {aep_upper})\")\n", + "print(f\"Implying leverage {volume_at_lower * mm.lower_price / (balance + loss_at_lower)} at lower and {volume_at_upper * mm.upper_price / (balance - loss_at_upper)} at upper\")" + ] + } + ], + "metadata": { + "kernelspec": { + "display_name": "Python 3 (ipykernel)", + "language": "python", + "name": "python3" + }, + "language_info": { + "codemirror_mode": { + "name": "ipython", + "version": 3 + }, + "file_extension": ".py", + "mimetype": "text/x-python", + "name": "python", + "nbconvert_exporter": "python", + "pygments_lexer": "ipython3", + "version": "3.11.8" + } + }, + "nbformat": 4, + "nbformat_minor": 5 +} diff --git a/protocol/0090-VAMM-automated_market_maker.md b/protocol/0090-VAMM-automated_market_maker.md new file mode 100644 index 000000000..0c3dffd49 --- /dev/null +++ b/protocol/0090-VAMM-automated_market_maker.md @@ -0,0 +1,333 @@ +# Automated Market Maker Framework + +## Summary + +The automated market maker (AMM) framework is designed to allow for the provision of an on-chain market making methodology which automatically provides prices according to a simple set of rules based on current market data. These rulesets are not created with the expectation of providing any profit nor of remaining solvent under any specific conditions, and so should be limited to conceptually simple setups. The initial methodology follows a concentrated-liquidity style constant-function market setup, with configurable maximum and minimum price bounds. + +An automated market maker is configured at a per-key level, and is enabled by submitting a transaction with the requisite parameters. At this point in time the protocol will move committed funds to a sub-account which will be used to manage margin for the AMM. Once enabled, the configuration will be added to the pool of available AMMs to be utilised by the matching engine. + +Each party may have only one AMM configuration per market. + +## Process Overview + +The configuration and resultant lifecycle of an automated market maker is as follows: + +- Party funds a key which will be used by the strategy with desired token amounts. +- Party submits a transaction containing configuration for the strategy on a given market. This will contain: + - Amount of funds to commit + - Price bounds (upper, lower, base) + - Margin ratios at upper and lower bound (ratio for leverage at bounds. Reciprocal of leverage multiplier e.g. 0.1 = 10x leverage) +- Additionally, the transaction should contain data related to the setup of the position but which does not need to be stored: + - Maximum slippage (%), used for rebasing position when creating/updating vAMM +- Once accepted, the network will transfer funds to a sub-account and use the other parameters for maintaining the position. +- At each block, the party's available balance (including margin and general accounts) for trading on the market will be checked. If the total balance is `0` the vAMM configuration will be stopped. +- The party is finally able to cancel the vAMM through a few different methods. They can choose to either set it into a mode in which it will only reduce position, eventually cancelling when/if the position reaches `0`, or choose to give up the existing position and associated required collateral. + +## Sub-Account Configuration + +Each main Vega key will have one associated sub account for a given market, on which an AMM may be set up. The account key should be generated through a hash of the main account key plus the ID of the market to generate a valid Vega address in a predictable manner. Outside of the AMM framework the sub-accounts are treated identically to any other account, they will have the standard associated margin/general accounts and be able to place orders if required as with any other account. The key differentiator is that no external party will have the private key to control these accounts directly. The maintenance of such an account will be performed through a few actions: + +- Creation: A sub-account will be funded when a user configures an AMM strategy with a set of criteria and a commitment amount. At this point in time the commitment amount will be transferred to the sub-account's general account and the AMM strategy will commence +- Cancellation: When the vAMM is cancelled the strategy specified will be followed. Either any positions associated with the vAMM will be abandoned and given up to the network liquidation engine to close out, along with any associated required collateral, or the vAMM will be set into a mode in which it can only reduce position over time. +- Amendment: Updates the strategy or commitment for a sub-account + +## Interface + +All AMM configurations should implement two key interfaces: + +- One taking simply the current state (`position` and `total funds`) and a trade (`volume`, `side`) and returning a quote price. This should also handle a trade of `volume = 0` to return a notional `fair price` +- The second taking (`position`, `total funds`, `side`, `start price`, `end price`) should return the full volume the AMM would trade between the two prices (inclusive). + +## AMM Configurations + +Initially there will only be one option for AMM behaviour, that of a constant-function curve, however there may be others available in future. As such, the parameters pertaining to this model in particular should be passed in their own structure such that the creation message is similar to: + +```json +{ + commitment, + market, + slippage_tolerance_percentage, + proposed_fee, + concentrated_liquidity_params: { + base_price, + lower_price, + upper_price, + margin_ratio_at_upper_bound, + margin_ratio_at_lower_bound, + } +} +``` + +### Concentrated Liquidity + +The `Concentrated Liquidity` AMM is a market maker utilising a Uniswap v3-style pricing curve for managing price based upon current market price. This allows for the market maker to automatically provide a pricing curve for any prices within some configurable range, alongside offering the capability to control risk by only trading within certain price bounds and out to known position limits. + +The concentrated liquidity market maker consists of two liquidity curves of prices joined at a given `base price`, an `upper` consisting of the prices above this price point and a `lower` for prices below it. At prices below the `base price` the market maker will be in a long position, and at prices above this `base price` the market maker will be in a short position. This is configured through a number of parameters: + +- **Base Price**: The base price is the central price for the market maker. When trading at this level the market maker will have a position of `0`. Volumes for prices above this level will be taken from the `upper` curve and volumes for prices below will be taken from the `lower` curve. +- **Upper Price**: The maximum price bound for market making. Prices between the `base price` and this price will have volume placed, with no orders above this price. This is optional and if not supplied no volume will be placed above `base price`. At these prices the market maker will always be short +- **Lower Price**: The minimum price bound for market making. Prices between the `base price` and this will have volume placed, with no orders below this price. This is optional and if not supplied no volume will be placed below `base price`. At these prices the market maker will always be long +- **Commitment**: This is the initial volume of funds to transfer into the sub account for use in market making. If this amount is not currently available in the main account's general account the transaction will fail. +- **Leverage at Bounds**: The exact volume scaling is defined by the position at the upper and lower prices. To determine this the commitment must be compared with what leverage that might allow at the price bounds. Using this parameter allows them to set a value such that `position = remaining funds * leverage at bound*`, however with the restriction that commitment must still be `>= initial margin`. This parameter should be optional. There is a separate parameter for each potential bound. + - **Upper Bound Leverage**: `leverage_at_upper_bound` + - **Lower Bound Leverage**: `leverage_at_lower_bound` + +Note that the independent long and short ranges mean that at `base price` the market maker will be flat with respect to the market with a `0` position. This means that a potential market maker with some inherent exposure elsewhere (likely long in many cases as a token holder) can generate a position which is always either opposite to their position elsewhere (with a capped size), thus offsetting pre-existing exposure, or zero. + +Additionally, as all commitments require some processing overhead on the core, there should be a network parameter `market.amm.minCommitmentQuantum` which defines a minimum quantum for commitment. Any `create` or `amend` transaction where `commitment / asset quantum < market.amm.minCommitmentQuantum` should be rejected. + +### Creation/Amendment Process + +#### Creation + +A `Concentrated Liquidity` AMM has an inherent linkage between position and implied price. By configuration, this position is `0` at `base price` but non-zero above and below that (assuming both an upper and lower bound have been provided), however it is possible to configure an AMM such that this `base price` is far from the market's current `mark price`. In order to bring the vAMM in line with where it "should" be the vAMM will determine whether the order book is currently able to synchronise the vAMM and reject the transaction if not + + 1. If the AMM's `base price` is between the current `best bid` and `best ask` on the market (including other active vAMMs) it is marked as created and enters normal quoting with no trade necessary. + 1. If the AMM's `base price` is below the current `best bid` and the AMM has an upper range specified, then the vAMM would need to become short in order to synchronise with the market. In order to do this, the protocol will query each price level in turn starting from `best bid` and: + 1. At each level: + 1. Check the full volume available across all limit orders and other vAMMs at this price and every higher bid (store a running cumulative volume in order to track this). + 1. Check the volume required for the incoming vAMM to have a fair price at that level. + 1. If the volume required is less than the full cumulative volume including this level, place a single order on the market for the volume required at the *previous* price level, with a price equal to the *current* price level. e.g. With: + - `best bid` at `10 USDT` + - Cumulative volume at `8 USDT` equal to `4` contracts + - Bid offers for `4` contracts at `7 USDT` + - And a vAMM which would be short `5` contracts for a fair price at `8 USDT` and short `4` contracts at `7 USDT` + - Enter a limit order to sell `5` contracts for `7 USDT` into the order book and allow it to match. + 1. If a price level is reached such that the current price is more than the max slippage specified away from the best bid, reject the transaction. + 1. If there is no upper range specified, it is marked as created immediately. + 1. If the AMM's `base price` is above the current `best ask` and the AMM has a lower range specified, then the vAMM would need to become short in order to synchronise with the market. Follow an identical process as above but instead on increasing price levels from `best ask` + 1. If there is no lower range specified, it is marked as created immediately. + +#### Amendment + +A similar process is followed in the case of amendments. Changes to the `upper`, `lower` or `base` price, or the `commitment amount` will affect the position implied at a certain price, meaning that the market maker may need to enter an aggressive trade to synchronise. In general, the behaviour above will be followed. As the vAMM may be currently holding a position, the existing position should be compared to that required at both sides (best bid/ask) of the order book to determine whether buying or selling is necessary. If the current position is between that required at best bid and best ask the amendment succeeds without requiring a trade. + +If reducing the `commitment amount` then only funds contained within the AMMs `general` account are eligible for removal. If the deduction is less than the `general` account's balance then the reduced funds will be removed immediately and the AMM will enter `single-sided` mode as specified above to reduce the position. If a deduction of greater than the `general` account is requested then the transaction is rejected and no changes are made. + + +#### Cancellation + +In addition to amending to reduce the size a user may also cancel their AMM entirely. In order to do this they must submit a transaction containing only a field `Reduction Strategy` which can take two values: + +- `Abandon Position`: In this case, any existing position the AMM holds is given up to the network to close as a liquidation. This is performed in two steps: + - All funds in the AMM's `general` account are transferred back to the party who created the AMM. + - The position is marked as requiring liquidation and is taken over by the network through the usual liquidation processes. All funds in the margin account are transferred to the network's insurance pool as in a forced liquidation +- `Reduce-Only`: This moves the AMM to a reduce-only state, in which case the position is reduced over time and ranges dynamically update to ensure no further position is taken. As such: + - If the AMM is currently short, the `lower bound` is removed + - If the AMM is currently long, the `upper bound` is removed + - The `upper`/`lower` bound (if the AMM is currently short/long) is then set to the AMM's current `fair price`. In this mode the AMM should only ever quote on the side which will reduce it's position (it's `upper`/`lower` bound should always be equal to the current `fair price` belief). + - Once the position reaches `0` the AMM can be cancelled and all funds in the general account can be returned to the creating party + - This acts similarly to the mode when an AMM is synchronising, except that the position will be closed in pieces as the price moves towards the `base price` rather than all at once at the nearest price. + +Note that, whilst an `Abandon Position` transaction immediately closes the AMM a `Reduce-Only` transaction will keep it active for an uncertain amount of time into the future. During this time, any Amendment transactions received should move the AMM out of `Reduce-Only` mode and back into standard continuous operation. + +### Determining Volumes and Prices + +Although AMM prices are not placed onto the book as orders it is necessary to be able to be able to quote prices for a given volume, or know what trading volume would move the fair price to a certain level. + +The volume to offer at each price level is determined by whether the price level falls within the upper or lower price bands alongside the market maker's current position. In order to calculate this, use the concept of `Virtual Liquidity` from Uniswap's concentrated liquidity model, corresponding to a theoretical shifted version of the actual liquidity curve to map to an infinite range liquidity curve. The exact mathematics of this can be found in the Uniswap v3 whitepaper and are expanded in depth in the useful guide [Liquidity Math in Uniswap v3](http://atiselsts.github.io/pdfs/uniswap-v3-liquidity-math.pdf). Here will be covered cover only the steps needed to obtain prices/volumes without much exposition. + +The AMM position can be thought of as two separate liquidity provision curves, one between `upper price` and `base price`, and another between `base price` and `lower price`. Within each of these, the AMM is buying/selling position on the market in exchange for the quote currency. As the price lowers the AMM is buying position and reducing currency, and as the price rises the AMM is selling position and increasing currency. + +One outcome of this is that the curve between `base price` and `lower price` is marginally easier to conceptualise directly from our parameters. At the lowest price side of a curve (`lower price` in this case) the market should be fully in the market contract position, whilst at the highest price (`base price` in this case) it should be fully sold out into cash. This is exactly the formulation used, where at `base price` a zero position is used and a cash amount of `commitment amount`. However given that there is likely to be some degree of leverage allowed on the market this is not directly the amount of funds to calculate using. An AMM with a `commitment amount` of `X` is ultimately defined by the requirement of using `X` in margin at the outer price bounds, so work backwards from that requirement to determine the theoretical cash value. Next calculate the two ranges separately to determine two different `Liquidity` values for the two ranges, which is a value used to later define volumes required to move the price a specified value. + +One can calculate a scaling factor that is the smaller of a multiplier specified in the commitment (`leverage_at_bounds`, either upper or lower depending on the side considered) or the market's worst case margin option. If `leverage_at_bounds` for the relevant side is not set then the market's worst case initial margin is taken automatically + +$$ +r_f = \min(l_b, \frac{1}{ (f_s + f_l) \cdotp f_i}) , +$$ + +where $l_b$ is the sided value `leverage_at_bounds` (`upper ratio` if the upper band is being considered and `lower ratio` if the lower band is), $f_s$ is the market's sided risk factor (different for long and short positions), $f_l$ is the market's linear slippage component and $f_i$ is the market's initial margin factor. + +A few components are needed to calculate the target position at the bounds, which will be used to generate a liquidity value for each curve. First, in order to calculate the average entry price for the full volume traded across the range one can calculate this liquidity, or $L_u$ value, for a range assuming a position of $1$ at the bounds (as the average entry price is invariant to scaling of volume across the curve) + +$$ +L_u = \frac{\sqrt{p_u} \sqrt{p_l}}{\sqrt{p_u} - \sqrt{p_l}} , +$$ + +where $p_u$ is the price at the top of the range (`upper price` for the upper range and `base price` for the lower range) and $p_l$ is the price at the bottom of the range (`base price` for the lower range and `lower price` for the lower range). This gives the two `L` values for the two ranges. With this the average entry price can be calculated as + +$$ +p_a = L_u p_u (1 - \frac{L_u}{L_u + p_u}) , +$$ + +where $p_a$ is the average execution price across the range and other values are as defined above. With this, the volumes required to trade to the bounds of the ranges are: + +$$ +P_{v_l} = \frac{r_f b}{p_l (1 - r_f) + r_f p_a} , +$$ +$$ +P_{v_u} = \frac{r_f b}{p_u (1 + r_f) - r_f p_a} , +$$ + +where $r_f$ is the `short` factor for the upper range and the `long` factor for the lower range, `b` is the current total balance of the vAMM across all accounts, $P_{v_l}$ is the theoretical volume and the bottom of the lower bound and $P_{v_u}$ is the (absolute value of the) theoretical volume at the top of the upper bound. The final $L$ scores can then be reached with the equation + +$$ +L = P_v \cdot \frac{\sqrt{p_u} \sqrt{p_l}}{\sqrt{p_u} - \sqrt{p_l}} = P_v L_u, +$$ + +where $P_v$ is the virtual position from the previous formula, $p_u$ and $p_l$ are as defined above. This gives the two `L` values for the two ranges. + +#### Fair price + +From here the first step is calculating a `fair` price, which can be done by utilising the `L` value for the respective range to calculate `virtual` values for the pool balances. From here on `y` will be the cash balance of the pool and `x` the position. + + 1. First, identify the current position, `P`. If it is `0` then the current fair price is the base price. + 1. If `P != 0` then calculate the implied price from the current position using the virtual position $P_v$ which is equal to $P$ when $P > 0$ or $P + \frac{c}{p_u} \cdotp r_f$ where $P < 0$. + 1. The fair price can then be calculated as + +$$ +p_f = \frac{\sqrt{p_u}}{P_v \cdotp \sqrt{p_u} \cdotp \frac{1}{L} + 1}^2 , +$$ + +where $p_u$ is `base price` when $P > 0$ or `upper price` when $P < 0$. + +#### Price to trade a given volume + +Finally, the protocol needs to calculate the inverse of the previous section. That is, given a volume bought from/sold to the AMM, at what price should the trade be executed. This could be calculated naively by summing across all the smallest increment volume differences, however this would be computationally inefficient and can be optimised by instead considering the full trade size. + + +To calculate this, the interface will need the `starting price` $p_s$, `ending price` $p_e$, `upper price of the current range` $p_u$ (`upper price` if `P < 0` else `base price`), `lower price of the current range` $p_l$ (`base price` if `P < 0` else `lower price`), the volume to trade $\Delta x$ and the `L` value for the current range. At `P = 0` use the values for the range which the volume change will cause the position to move into. + +First, the steps for calculating a fair price should be followed in order to obtain the implied price. Next the virtual `x` and `y` balances must be found: + + 1. If `P > 0`: + 1. The virtual `x` of the position can be calculated as $x_v = P + \frac{L}{\sqrt{p_b}}$, where $L$ is the value for the lower range, $P$ is the market position and $p_b$ is the `base price`. + 1. The virtual `y` can be calculated as $y_v = L * \sqrt{p_f}$ where $p_f$ is the fair price calculated above. + 1. If `P < 0`: + 1. The virtual `x` of the position can be calculated as $x_v = P + \frac{c}{p_u} \cdotp r_f + \frac{L}{\sqrt{p_u}}$ where $p_u$ is the `upper price`. + 1. The virtual `y` can be calculated as $y_v = L * \sqrt{p_f}$ where $p_f$ is the fair price calculated above. + +Once obtained, the price can be obtained from the fundamental requirement of the product $y \cdot x$ remaining constant. This gives the relationship + +$$ +y_v \cdot x_v = (y_v + \Delta y) \cdot (x_v - \Delta x) , +$$ + +From which $\Delta y$ must be calculated + +$$ +\Delta y = \frac{y_v \cdot x_v}{x_v - \Delta x} - y_v , +$$ + +Thus giving a final execution price to return of $\frac{\Delta y}{\Delta x}$. + +#### Volume between two prices + +For the second interface one needs to calculate the volume which would be posted to the book between two price levels. In order to calculate this for an AMM one is ultimately asking the question "what volume of swap would cause the fair price to move from price A to price B?" + +To calculate this, the interface will need the `starting price` $p_s$, `ending price` $p_e$, `upper price of the current range` $p_u$ (`upper price` if `P < 0` else `base price`) and the `L` value for the current range. At `P = 0` use the values for the range which the volume change will cause the position to move into. + +First, calculate the implied position at `starting price` and `ending price` and return the difference. + +For a given price $p$ calculate implied position $P_i$ with + +$$ +P_i = L \cdot \frac{\sqrt{p_u} - \sqrt{p}}{\sqrt{p} \cdotp \sqrt{p_u}} , +$$ + +Then simply return the absolute difference between these two prices. + +## Determining Liquidity Contribution + +The provided liquidity from an AMM commitment must be determined for two reasons. Firstly to decide instantaneous distribution of liquidity fees between the various liquidity types and secondly to calculate a virtual liquidity commitment amount for assigning AMM users with an ELS value. This will be used for determining the distribution of ELS-eligible fees on a market along with voting weight in market change proposals. + +As an AMM does not directly place orders on the book this calculation first needs to infer what the orders would be at each level within the eligible price bounds (those required by SLA parameters on the given market). From here any given AMM curve should implement functionality to take two prices and return the volume it would place to trade fully across that range. Calling this function across the price range out to lower and upper SLA bounds retrieves the full order book shape for each AMM. + +Once these are retrieved, the price / volume points should be combined with a precomputed array of the probability of trading at each price level to calculate the liquidity supplied on each side of the orderbook as defined in [probability of trading](./0034-PROB-prob_weighted_liquidity_measure.ipynb). Once this is calculated, use this value as the instantaneous liquidity score for fee distribution as defined in [setting fees and rewards](./0042-LIQF-setting_fees_and_rewarding_lps.md). + +As the computation of this virtual order shape may be heavy when run across a large number of passive AMMs the number of AMMs updated per block should be throttled to a fixed maximum number, updating on a rolling frequency, or when updated/first created. + +A given AMM's average liquidity score across the epoch should also be tracked, giving a time-weighted average at the end of each epoch (including `0` values for any time when the AMM either did not exist or was not providing liquidity on one side of the book). From this, a virtual stake amount can be calculated by dividing through by the `market.liquidity.stakeToCcyVolume` value and the AMM key' +s ELS updated as normal. + +## Setting Fees + +The `proposed_fee` provided as part of the AMM construction contributes to the fee determination logic on the market, if a setup where LPs decide on the market fee is in use. In the case where it is the AMM's current assigned ELS, or the running average liquidity provided so far if the commitment was made in the current epoch, is used for weighting the AMM's vote for the fee. + +## Market Settlement + +At market settlement, an AMM's position will be settled alongside all others as if they are a standard party. Once settlement is complete, any remaining funds in the AMM's account will be transferred back to the creator's general account and the AMM can be removed. + +## Acceptance Criteria + +- When `market.amm.minCommitmentQuantum` is `1`, mid price of the market `100`, a user with `1000 USDT` is able to create a vAMM with commitment `1000`, base price `100`, upper price `150`, lower price `85` and leverage ratio at each bound `0.25`. (0090-VAMM-001) +- When `market.amm.minCommitmentQuantum` is `1`, mid price of the market `100`, a user with `1000 USDT` is able to create a vAMM with commitment `1000`, base price `100`, no upper price, lower price `85` and leverage ratio at lower bound `0.25`. (0090-VAMM-002) +- When `market.amm.minCommitmentQuantum` is `1`, mid price of the market `100`, a user with `1000 USDT` is able to create a vAMM with commitment `1000`, base price `100`, upper price `150`, no lower price and leverage ratio at upper bound `0.25`. (0090-VAMM-003) + +- When `market.amm.minCommitmentQuantum` is `1`, mid price of the market `100`, a user with `100 USDT` is unable to create a vAMM with commitment `1000`, and any other combination of settings. (0090-VAMM-004) +- When `market.amm.minCommitmentQuantum` is `1000`, mid price of the market `100`, a user with `1000 USDT` is able to create a vAMM with commitment `100`, and any other combination of settings. (0090-VAMM-005) + +- When `market.amm.minCommitmentQuantum` is `1000`, mid price of the market `100`, and a user with `1000 USDT` creates a vAMM with commitment `1000`, base price `100`, upper price `150`, lower price `85` and leverage ratio at each bound `0.25`: + - If other traders trade to move the market mid price to `140` the vAMM has a short position. (0090-VAMM-006) + - If other traders trade to move the market mid price to `90` the vAMM has a long position (0090-VAMM-007) + - If other traders trade to move the market mid price to `150` the vAMM will post no further sell orders above this price, and the vAMM's position notional value will be equal to `4x` its total account balance. (0090-VAMM-008) + - If other traders trade to move the market mid price to `85` the vAMM will post no further buy orders below this price, and the vAMM's position notional value will be equal to `4x` its total account balance.(0090-VAMM-009) + - If other traders trade to move the market mid price to `110` and then trade to move the mid price back to `100` the vAMM will have a position of `0`. (0090-VAMM-010) + - If other traders trade to move the market mid price to `90` and then trade to move the mid price back to `100` the vAMM will have a position of `0`. (0090-VAMM-011) + - If other traders trade to move the market mid price to `90` and then in one trade move the mid price to `110` then trade to move the mid price back to `100` the vAMM will have a position of `0`. (0090-VAMM-012) + - If other traders trade to move the market mid price to `90` and then move the mid price back to `100` in several trades of varying size, the vAMM will have a position of `0`. (0090-VAMM-013) + - If other traders trade to move the market mid price to `90` and then in one trade move the mid price to `110` then trade to move the mid price to `120` the vAMM will have a larger (more negative) but comparable position to if they had been moved straight from `100` to `120`. (0090-VAMM-014) + +- A vAMM which has been created and is active contributes with it's proposed fee level to the active fee setting mechanism. (0090-VAMM-015) +- At the end of an epoch, the vAMM's virtual ELS should be equal to the ELS of a regular LP with the same committed volume on the book who joined at the end of the same epoch as the vAMM did (i.e. if a vAMM has an average volume on each side of the book each epoch of 10k USDT, their ELS should be equal to that of a regular LP who has a commitment which requires supplying 10k USDT who joined at the same time as them). (0090-VAMM-016) + - A vAMM's virtual ELS should grow at the same rate as a full LP's ELS who joined at the end of the epoch in which the vAMM joined (0090-VAMM-017) +- A vAMM can vote in market update proposals with the additional weight of their ELS (i.e. not just from governance token holdings). (0090-VAMM-018) + +- If a vAMM is cancelled with `Abandon Position` then it is closed immediately. All funds which were in the `general` account of the vAMM are returned to the user who created the vAMM and the remaining position and margin funds are moved to the network to close out as it would a regular defaulted position. (0090-VAMM-019) + +- If a vAMM is cancelled and set in `Reduce-Only` mode when it is currently long, then: (0090-VAMM-020) + - It creates no further buy orders even if the current price is above the configured lower price. + - When one of it's sell orders is executed it still does not produce buy orders, and correctly quotes sell orders from a higher price. + - When the position reaches `0` the vAMM is closed and all funds are released to the user after the next mark to market. + + +- If a vAMM is cancelled and set in `Reduce-Only` mode when it is currently short, then: (0090-VAMM-021) + - It creates no further sell orders even if the current price is below the configured upper price. + - When one of it's buy orders is executed it still does not produce sell orders, and correctly quotes buy orders from a lower price. + - When the position reaches `0` the vAMM is closed and all funds are released to the user after the next mark to market. + +- If a vAMM is cancelled and set in `Reduce-Only` mode when it currently has no position then all funds are released after the next mark to market. (0090-VAMM-022) + +- If a vAMM is cancelled and set into `Reduce-Only` mode, then an amend is sent by the user who created it, the vAMM is amended according to those instructions and is moved out of `Reduce-Only` mode back into normal operation. (0090-VAMM-023) + +- When `market.amm.minCommitmentQuantum` is `1000`, mid price of the market `100`, and a user with `1000 USDT` creates a vAMM with commitment `1000`, base price `100`, upper price `150`, lower price `85` and leverage ratio at each bound `0.25`: + - If other traders trade to move the market mid price to `140` the vAMM has a short position. (0090-VAMM-024) + - If the vAMM is then amended such that it has a new base price of `140` it should attempt to place a trade to rebalance it's position to `0` at a mid price of `140`. + - If that trade can execute with the slippage as configured in the request then the transaction is accepted. (0090-VAMM-025) + - If the trade cannot execute with the slippage as configured in the request then the transaction is rejected and no changes to the vAMM are made. (0090-VAMM-026) + +- When a user with `1000 USDT` creates a vAMM with commitment `1000`, base price `100`, upper price `150`, lower price `85` and leverage ratio at each bound `0.25`, if other traders trade to move the market mid price to `140` quotes with a mid price of `140` (volume quotes above `140` should be sells, volume quotes below `140` should be buys). (0090-VAMM-027) + +- When a user with `1000 USDT` creates a vAMM with commitment `1000`, base price `100`, upper price `150`, lower price `85` and leverage ratio at each bound `0.25`, the volume quoted to move from price `100` to price `110` in one step is the same as the sum of the volumes to move in 10 steps of `1` e.g. `100` -> `101`, `101` -> `102` etc. (0090-VAMM-028) + +- When a user with `1000 USDT` creates a vAMM with commitment `1000`, base price `100`, upper price `150`, lower price `85` and leverage ratio at each bound `0.25`, the volume quoted to move from price `100` to price `90` in one step is the same as the sum of the volumes to move in 10 steps of `1` e.g. `100` -> `99`, `99` -> `98` etc. (0090-VAMM-029) + +- When a user with `1000 USDT` creates a vAMM with commitment `1000`, base price `100`, upper price `150`, lower price `85` and leverage ratio at each bound `0.25`: + 1. Take quoted volumes to move to `110` and `90` + 1. Execute a trade of the quoted size to move the fair price to `110` + 1. Take a quote to move to price `90` + 1. Ensure this is equal to the sum of the quotes from step `1` (with the volume from `100` to `110` negated) (0090-VAMM-030) + +- When an AMM is active on a market at time of settlement with a position in a well collateralised state, the market can settle successfully and then all funds on the AMM key are transferred back to the main party's account (0090-VAMM-031) + +- When an AMM is active on a market at time of settlement but the settlement price means that the party is closed out no funds are transfeered back to the main party's account (0090-VAMM-032) + +- An AMM with base price `1000`, upper price `1100`, lower price `900` and current position `0`: + - Quotes a volume of `8.216` units to buy to move fair price to `900` + - Quotes a price of `948.683` to buy `8.216` units + - Quotes a volume of `7.814` units to sell to move fair price to `1100` + - Quotes a price of `1048.809` to sell `7.814` units + +- An AMM with base price `1000`, upper price `1100`, lower price `900` and current position short `7.814`: + - Quotes a volume of `0` units to buy above `1100` + - Quotes a volume of `7.814` units to buy to move fair price to `1000` + - Quotes a price of `1048.809` to buy `7.814` units + - Quotes a price of `997.488` to sell `16.030` units + - Does not quote a price to sell `17` units + +- With an existing book consisting solely of one vAMM (at any fair price) a new vAMM entering the market at a differing base price to the existing vAMM's current price, but where upper and lower bounds of each are far beyond the base/fair prices, triggers a trade between the two vAMMs, after which they both have the same fair price and the book is not crossed. + +- With an existing book consisting solely of one vAMM (at any fair price) a new vAMM entering the market at a differing base price to the existing vAMM's current price, with upper and lower bounds set such that the entire structure is separate to the existing vAMM (e.g. the incoming vAMM's lower price is greater than the existing vAMM's upper price), a trade occurs between the two AMMs leaving at least one of them at the extreme edge of their quoting range. + +- With two vAMMs existing on the market, and no other orders, both of which have the same fair price, another counterparty placing a large buy order for a given volume, followed by a large sell order for the same volume, results in the vAMMs both taking a position and then returning to `0` position, with a balance increase equal to the maker fees received plus those for the incoming trader crossing the spread. diff --git a/protocol/features.json b/protocol/features.json index 95523eba0..855ae9b4e 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -537,11 +537,7 @@ }, "Explicit liquidation range": { "milestone": "colosseo", - "acs": [ - "0012-POSR-031", - "0012-POSR-032", - "0012-POSR-033" - ] + "acs": ["0012-POSR-031", "0012-POSR-032", "0012-POSR-033"] }, "Community Tags": { "milestone": "colosseo", @@ -613,6 +609,57 @@ "0057-TRAN-079" ] }, + "vAMMs": { + "milestone": "colosseo_II", + "acs": [ + "0042-LIQF-063", + "0042-LIQF-064", + "0042-LIQF-065", + "0090-VAMM-001", + "0090-VAMM-002", + "0090-VAMM-003", + "0090-VAMM-004", + "0090-VAMM-005", + "0090-VAMM-006", + "0090-VAMM-007", + "0090-VAMM-008", + "0090-VAMM-009", + "0090-VAMM-010", + "0090-VAMM-011", + "0090-VAMM-012", + "0090-VAMM-013", + "0090-VAMM-014", + "0090-VAMM-015", + "0090-VAMM-016", + "0090-VAMM-017", + "0090-VAMM-018", + "0090-VAMM-019", + "0090-VAMM-020", + "0090-VAMM-021", + "0090-VAMM-022", + "0090-VAMM-023", + "0090-VAMM-024", + "0090-VAMM-025", + "0090-VAMM-026", + "0090-VAMM-027", + "0090-VAMM-028", + "0090-VAMM-029", + "0090-VAMM-030", + "0090-VAMM-031", + "0090-VAMM-032", + "0057-TRAN-070", + "0056-REWA-111", + "0056-REWA-112", + "0026-AUCT-033", + "0026-AUCT-034", + "0026-AUCT-035", + "0026-AUCT-036", + "0026-AUCT-037", + "0014-NP-VAMM-001", + "0014-NP-VAMM-002", + "0014-NP-VAMM-003" + ] + }, "Unknown": { "milestone": "unknown", "acs": [] diff --git a/wordlist.txt b/wordlist.txt index e9fa28623..af422bc70 100644 --- a/wordlist.txt +++ b/wordlist.txt @@ -6,6 +6,9 @@ ABIs actioned Allowlist allowlisted +AMM +AMM's +AMMs antiwhaling API APIs @@ -31,6 +34,7 @@ cashflows CCP ccy cdot +cdotp ceil ceiled CFD @@ -73,6 +77,7 @@ delegateable delegator delegators deterministically +differentiator discoverability disincentivise DLT @@ -114,6 +119,7 @@ frontend funder FX GBP +geq Geth Getters GFA @@ -147,6 +153,8 @@ int64 integrations intrablock IOC +joinable +joinable JSON keyholder keypair @@ -176,6 +184,8 @@ margined margining marketID math +mathbb +mathbf MDPs mempool Merkle @@ -187,9 +197,9 @@ misconfiguration MTM mu multisig -multisigs MultisigControl multisignature +multisigs NFTs nonfungible OAUTH @@ -216,6 +226,7 @@ PoS PoW PoWs pre +precomputed pro protobuf Pseudocode @@ -223,7 +234,10 @@ pseudorandom pubkey quant rata +rebalance +rebalancing rebased +rebasing recollateralise ReferralSet reimplemented @@ -237,8 +251,10 @@ RFQ roadmap Ropsten RPC +rulesets runnable runtime +rz scalability scalable Scholes @@ -251,6 +267,7 @@ sharded siskas SLA Solana +sqrt src SSD SSL @@ -299,6 +316,8 @@ undelegations undeployed underlyings unencrypted +Uniswap +Uniswap's unitless unmarshal unnominated @@ -307,6 +326,8 @@ unstake unstaked unstakes unstaking +unsynchronised +Unsynchronised untriggered unvested url @@ -318,7 +339,9 @@ validator validator's validators vAMM +vAMM's vAMMs +vee vega vegaprotocol vegatools @@ -336,9 +359,3 @@ wBTC wei whitepaper Yubikey -joinable -mathbb -geq -vee -mathbf -rz \ No newline at end of file From 268a9ce8cc6165cf60e8863ed9369cbfd721d25f Mon Sep 17 00:00:00 2001 From: wwestgarth Date: Tue, 30 Apr 2024 09:34:09 +0100 Subject: [PATCH 1107/1171] chore: fix typos and add in sqrt's to align with notebook --- protocol/0090-VAMM-automated_market_maker.md | 13 +++++++------ 1 file changed, 7 insertions(+), 6 deletions(-) diff --git a/protocol/0090-VAMM-automated_market_maker.md b/protocol/0090-VAMM-automated_market_maker.md index 0c3dffd49..b3e02a6bb 100644 --- a/protocol/0090-VAMM-automated_market_maker.md +++ b/protocol/0090-VAMM-automated_market_maker.md @@ -52,8 +52,8 @@ Initially there will only be one option for AMM behaviour, that of a constant-fu base_price, lower_price, upper_price, - margin_ratio_at_upper_bound, - margin_ratio_at_lower_bound, + leverage_at_upper_bound, + leverage_at_lower_bound, } } ``` @@ -145,10 +145,10 @@ $$ L_u = \frac{\sqrt{p_u} \sqrt{p_l}}{\sqrt{p_u} - \sqrt{p_l}} , $$ -where $p_u$ is the price at the top of the range (`upper price` for the upper range and `base price` for the lower range) and $p_l$ is the price at the bottom of the range (`base price` for the lower range and `lower price` for the lower range). This gives the two `L` values for the two ranges. With this the average entry price can be calculated as +where $p_u$ is the price at the top of the range (`upper price` for the upper range and `base price` for the lower range) and $p_l$ is the price at the bottom of the range (`base price` for the upper range and `lower price` for the lower range). This gives the two `L` values for the two ranges. With this the average entry price can be calculated as $$ -p_a = L_u p_u (1 - \frac{L_u}{L_u + p_u}) , +p_a = L_u \sqrt{p_u} (1 - \frac{L_u}{L_u + \sqrt{p_u}}) , $$ where $p_a$ is the average execution price across the range and other values are as defined above. With this, the volumes required to trade to the bounds of the ranges are: @@ -156,6 +156,7 @@ where $p_a$ is the average execution price across the range and other values are $$ P_{v_l} = \frac{r_f b}{p_l (1 - r_f) + r_f p_a} , $$ + $$ P_{v_u} = \frac{r_f b}{p_u (1 + r_f) - r_f p_a} , $$ @@ -173,7 +174,7 @@ where $P_v$ is the virtual position from the previous formula, $p_u$ and $p_l$ a From here the first step is calculating a `fair` price, which can be done by utilising the `L` value for the respective range to calculate `virtual` values for the pool balances. From here on `y` will be the cash balance of the pool and `x` the position. 1. First, identify the current position, `P`. If it is `0` then the current fair price is the base price. - 1. If `P != 0` then calculate the implied price from the current position using the virtual position $P_v$ which is equal to $P$ when $P > 0$ or $P + \frac{c}{p_u} \cdotp r_f$ where $P < 0$. + 1. If `P != 0` then calculate the implied price from the current position using the virtual position $P_v$ which is equal to $P$ when $P > 0$ or $P + P_{v_u}$ where $P < 0$. 1. The fair price can then be calculated as $$ @@ -195,7 +196,7 @@ First, the steps for calculating a fair price should be followed in order to obt 1. The virtual `x` of the position can be calculated as $x_v = P + \frac{L}{\sqrt{p_b}}$, where $L$ is the value for the lower range, $P$ is the market position and $p_b$ is the `base price`. 1. The virtual `y` can be calculated as $y_v = L * \sqrt{p_f}$ where $p_f$ is the fair price calculated above. 1. If `P < 0`: - 1. The virtual `x` of the position can be calculated as $x_v = P + \frac{c}{p_u} \cdotp r_f + \frac{L}{\sqrt{p_u}}$ where $p_u$ is the `upper price`. + 1. The virtual `x` of the position can be calculated as $x_v = P + P_{v_u} + \frac{L}{\sqrt{p_u}}$ where $p_u$ is the `upper price` and $P_{v_u}$ is the theoretical volume at the upper bound. 1. The virtual `y` can be calculated as $y_v = L * \sqrt{p_f}$ where $p_f$ is the fair price calculated above. Once obtained, the price can be obtained from the fundamental requirement of the product $y \cdot x$ remaining constant. This gives the relationship From ab320eaafbc439d25ca49fb160a1b2d7301b6ff0 Mon Sep 17 00:00:00 2001 From: wwestgarth Date: Tue, 30 Apr 2024 10:26:24 +0100 Subject: [PATCH 1108/1171] fix notepad sign error too --- protocol/0090-VAMM-automated_market_maker.ipynb | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0090-VAMM-automated_market_maker.ipynb b/protocol/0090-VAMM-automated_market_maker.ipynb index 8af8b49b3..550fb18a8 100644 --- a/protocol/0090-VAMM-automated_market_maker.ipynb +++ b/protocol/0090-VAMM-automated_market_maker.ipynb @@ -364,7 +364,7 @@ "volume_at_lower = mm.margin_multiple_at_lower * balance / (mm.lower_price * (1 - mm.margin_multiple_at_lower) + mm.margin_multiple_at_lower * aep_lower)\n", "\n", "aep_upper = -1 * upper_L_unit * mm.upper_price_sqrt * ((upper_L_unit / (upper_L_unit + mm.upper_price_sqrt)) - 1)\n", - "volume_at_upper = mm.margin_multiple_at_upper * balance / (mm.upper_price * (1 - mm.margin_multiple_at_upper) - mm.margin_multiple_at_upper * aep_upper)\n", + "volume_at_upper = mm.margin_multiple_at_upper * balance / (mm.upper_price * (1 + mm.margin_multiple_at_upper) - mm.margin_multiple_at_upper * aep_upper)\n", "\n", "upper_L = (\n", " volume_at_upper\n", From c1f226ffe470ff84b679414209afb47faa817e71 Mon Sep 17 00:00:00 2001 From: Witold Date: Tue, 7 May 2024 16:10:22 +0200 Subject: [PATCH 1109/1171] refactor: add support for capped futures and binary options --- protocol/0016-PFUT-product_builtin_future.md | 47 ++++++++++++++++ protocol/0018-RSKM-quant_risk_models.ipynb | 13 +++++ protocol/0019-MCAL-margin_calculator.md | 31 ++++++++++- protocol/features.json | 58 ++++++++++++++++---- 4 files changed, 138 insertions(+), 11 deletions(-) diff --git a/protocol/0016-PFUT-product_builtin_future.md b/protocol/0016-PFUT-product_builtin_future.md index cf062b928..80170ad48 100644 --- a/protocol/0016-PFUT-product_builtin_future.md +++ b/protocol/0016-PFUT-product_builtin_future.md @@ -14,6 +14,13 @@ Futures are a simple "delta one" product and the first product supported by Vega Validation: none required as these are validated by the asset and data source frameworks. +Optional parameters: + +1. `max_price`: specifies the price cap for the market, an integer understood in the context of market decimal places, +1. `binary_settlement`: if set to `true` settlement price other than `0` or `max_price` will be ignored. + +Validation: `max_price` > 0. + ## 2. Settlement assets 1. Returns `[cash_settled_future.settlement_asset]`. @@ -55,6 +62,30 @@ cash_settled_future.settlement_data(event) { } ``` +## 2. Additional considerations around optional parameters + +Optional parameters allow creating capped futures (all prices including settlement price must be in the range `[0, max_price]`) or binary options (all intermediate prices must be in the range `[0, max_price]`, settlement price bust be either `0` or `max_price`) markets. + +### 2.1 Order price validation + +If `max_price` is specified the order prices should be validated so that the maximum price of any order is `max_price`. Peg orders should be validated so that if the resulting price would be higher at any point it gets temporarily capped at `max_price`. + +### 2.2 Mark price validation + +If `max_price` is specified, mark price candidates greater than `max_price` should be ignored and [mark-to-market settlement](./0003-MTMK-mark_to_market_settlement.md) should not be carried out until a mark price within the `[0, max_price]` range arrives. + +### 2.3 Settlement price validation + +If `max_price` is specified: + +- When `binary_settlement` parameter is set to `false` any value `0 <= settlement_price <= max_price` should be accepted as a settlement price. +- When `binary_settlement` parameter is set to `true` only `settlement_price=0` or `settlement_price=max_price` should be accepted. +- Any other values get ignored and market does not settle, instead it still waits for subsequent values from the settlement oracle until a value which passes the above conditions arrives. + +## 3. Binary options + +Please note that selecting a future prodcut with `max_price` specified and `binary_settlement` flag set to `true` allows representing binary options markets. + ## Acceptance Criteria 1. Create a Cash Settled Future with trading termination triggered by a date/time based data source (0016-PFUT-001) @@ -69,3 +100,19 @@ cash_settled_future.settlement_data(event) { 1. Lifecycle events are processed atomically as soon as they are triggered, i.e. the above condition always holds even for two or more transactions arriving at effectively the same time - only the transaction that is sequenced first triggers final settlement (0016-PFUT-010) 1. Once a market is finally settled, the mark price is equal to the settlement data and this is exposed on event bus and market data APIs (0016-PFUT-011) 1. Assure [settment-at-expiry.feature](https://github.com/vegaprotocol/vega/blob/develop/core/integration/features/verified/0002-STTL-settlement_at_expiry.feature) executes correctly (0016-PFUT-012) + +Optional parameters: + +1. Attempt to specify a `max_price` of `0` fails. (0016-PFUT-013) +1. When `max_price` is specified, an order with a `price > max_price` gets rejected. (0016-PFUT-014) +1. When `max_price` is specified and the reference of a pegged sell order moves so that the implied order price is higher than `max_price` the implied order price gets capped at. `max_price` (0016-PFUT-015) +1. When `max_price` is specified and market is setup to use oracle based mark price and the value received from oracle is less than `max_price` then it gets used as is and mark-to-market flows are calculated according to that price. (0016-PFUT-016) +1. When `max_price` is specified and the market is setup to use oracle based mark price and the value received from oracle is greater than `max_price` then it gets ignored and mark-to-market settlement doesn't occur until a mark price candidate within the `[0, max_price]` range arrives. (0016-PFUT-017) +1. When `max_price` is specified and `binary_settlement` flag is set to `false`, and the final settlement price candidate received from the oracle is less than or equal to `max_price` then it gets used as is and the final cashflows are calculated according to that price. (0016-PFUT-018) +1. When `max_price` is specified and the final settlement price candidate received from the oracle is greater than `max_price` the value gets ignored, next a value equal to `max_price` comes in from the settlement oracle and market settles correctly. The market behaves in this way irrespective of how `binary_settlement` flag is set. (0016-PFUT-019) +1. When `max_price` is specified, the `binary_settlement` flag is set to `true` and the final settlement price candidate received from the oracle is greater than `0` and less than `max_price` the value gets ignored, next a value of `0` comes in from the settlement oracle and market settles correctly. (0016-PFUT-020) +1. When `max_price` is specified and the market is ran in a [fully-collateralised mode](./0019-MCAL-margin_calculator.md#fully-collateralised) and it has parties with open positions settling it at a price of `max_price` works correctly and the sum of all final settlement cashflows equals 0 (loss socialisation does not happen). Assuming general account balances of all parties were `0` after opening the positions and all of their funds were in the margin accounts: long parties end up with balances equal to `position size * max_price` and short parties end up with `0` balances. (0016-PFUT-021) +1. When `max_price` is specified and the market is ran in a [fully-collateralised mode](./0019-MCAL-margin_calculator.md#fully-collateralised) and it has parties with open positions settling it at a price of `0` works correctly and the sum of all final settlement cashflows equals 0 (loss socialisation does not happen). Assuming general account balances of all parties were `0` after opening the positions and all of their funds were in the margin accounts: short parties end up with balances equal to `abs(position size) * max_price` and long parties end up with `0` balances. (0016-PFUT-022) +1. When `max_price` is specified and the market is ran in a [fully-collateralised mode](./0019-MCAL-margin_calculator.md#fully-collateralised) and a party opens a long position at a `max_price`, no closeout happens when mark to market settlement is carried out at a price of `0`. (0016-PFUT-023) +1. When `max_price` is specified and the market is ran in a [fully-collateralised mode](./0019-MCAL-margin_calculator.md#fully-collateralised) and a party opens a short position at a price of `0`, no closeout happens when mark to market settlement is carried out at a `max_price`. (0016-PFUT-024) +1. Futures market can be created without specifying any of the [optional paramters](#1-product-parameters). (0016-PFUT-025) diff --git a/protocol/0018-RSKM-quant_risk_models.ipynb b/protocol/0018-RSKM-quant_risk_models.ipynb index 09a2381b1..36a6205bf 100644 --- a/protocol/0018-RSKM-quant_risk_models.ipynb +++ b/protocol/0018-RSKM-quant_risk_models.ipynb @@ -102,6 +102,19 @@ "\n" ] }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "## Wrapped risk models\n", + "\n", + "For certain products it might be possible to certain aspects of market's reliance on risk model while keeping other dependencies in places.\n", + "\n", + "### Fully-collateralised\n", + "\n", + "For products with pre-defined finite price range (e.g. [a futures contracts with [`max_price`](./0016-PFUT-product_builtin_future.md#1-product-parameters) parameter specified]) it is possible to make positions fully-collateralised so that for any position a margin can be chosen such that the party stays solvent at any price the market may attain. Using this mode removes the reliance on risk-factors, however the risk model might still be used for other aspects of market's functioning. To signify this and make it transparent to the user a fully-collateralised wrapped risk model is used in those cases." + ] + }, { "attachments": {}, "cell_type": "markdown", diff --git a/protocol/0019-MCAL-margin_calculator.md b/protocol/0019-MCAL-margin_calculator.md index 3ef857909..e2146aefd 100644 --- a/protocol/0019-MCAL-margin_calculator.md +++ b/protocol/0019-MCAL-margin_calculator.md @@ -425,6 +425,16 @@ There should be an additional amount `limit price x size x margin factor = 15910 - All order margin balances are restored after a protocol upgrade (0019-MCAL-152). - The `margin mode` and `margin factor` of any given party must be preserved after a protocol upgrade (0019-MCAL-153). +## Acceptance Criteria (Fully collateralised mode) + +Assume a [capped future](./0093-CFUT-product_builtin_capped_future.md) market with a `max price = 100` and mark-to-market cashflows being exchanged every block: + +- Party A posts an order to buy `10` contracts at a price of `30`, there's no other volume in that price range so the order lands on the book and the maintenance and initial margin levels for the party and order margin account balance are all equal to `300`. (0019-MCAL-154) +- Party B posts an order to sell `15` contracts at a price of `20`, a trade is generated for `10` contracts at price of `30` with party A. The maintenance and initial margin levels party A remains at `300`, order margin account balance is now `0` and margin account balance is `300`, the position is `10` and there are no open orders. The maintenance and initial margin levels for party B are equal to `10 * (100 - 30) + 5 * (100 - 20) = 1100`, the margin account balance is `700`, order margin account balance is `400`, the position is `-10` and the remaining volume on the book from this party is `5` at a price of `20`. (0019-MCAL-155) +- Party B posts an order to buy `10` contracts at a price of `18`, the orders get placed on the book and margin levels as well margin account balances and position remain unchanged. (0019-MCAL-156) +- Party B posts an order to buy `30` contracts at a price of `16`, the orders get placed on the book, the maintenance and initial margin levels for party B grow to `1180`, and the margin account balance remains unchanged at `700` and the order margin account balance grows to `480 = max (5 * (100 - 20), 30 * 16)`. The position remains unchanged at `-10`. (0019-MCAL-157) +- Party A posts an order to sell `20` contracts at a price of `17`. A trade is generated for `10` contracts at a price of `18` with party B. A sell order for `10` contracts at a price of `17` from party A gets added to the book. The maintenance and initial margin levels for party A is now `10 * (100 - 17) = 830`, the position is `0` and the remaining volume on the book from this party is `10` at a price of `18`. Party A lost `120` on its position, hence `830 - (300 - 120) = 410` additional funds get moved from the general account as part of the transaction which submitted the order to sell `20` at `17`. Party B now has a position of `0` and following orders open on the book: sell `5` at `20` and buy `30` at `16`. The maintenance and initial margin levels are `max(5 * (100 - 20), 30 * 16) = 480`. The margin account momentarily becomes `820` (`700` + `120` of gains from the now closed position of `-10`), order margin account balance is `480`, hence `820` gets released back into the general account and margin account becomes `0`. (0019-MCAL-158) + ## Summary The *margin calculator* returns the set of margin levels for a given *actual position*, along with the amount of additional margin (if any) required to support the party's *potential position* (i.e. active orders including any that are parked/untriggered/undeployed). @@ -432,7 +442,9 @@ The *margin calculator* returns the set of margin levels for a given *actual pos ### Margining modes -The system can operate in one of two margining modes for each position. +#### Partially-collateralised + +The system can operate in one of two partially-collateralised margining modes for each position. The current mode will be stored alongside of party's position record. 1. **Cross-margin mode (default)**: this is the mode used by all newly created positions. @@ -444,6 +456,23 @@ This includes completely new positions and increases to position size. Other tha *never* be searched for additional funds (a position will be allowed to be closed out instead), nor will profits be moved into the general account from the margin account. +#### Fully-collateralised + +For certain derivatives markets it may be possible to collateralise the position in full so that there's no default risk for any party. + +If a product specifies an upper bound on price (`max price`) (e.g. [capped future](./0093-CFUT-product_builtin_capped_future.md)) then a fully-collateralised [wrapped risk model](./0018-RSKM-quant_risk_models.ipynb) can be specified for the market. If such a risk model is chosen then, it's mandatory for all parties (it's not possible to self-select any of the above partially-collateralised margining modes). + +In this mode long positions provide `position size * average entry price` in initial margin, whereas shorts provide `postion size * (max price - average entry price)`. The initial margin level is only re-evaluated when party changes their position. The [mark-to-market](./0003-MTMK-mark_to_market_settlement.md) is carried out as usual. Maintenance and initial margin levels should be set to the same value. Margin search and release levels are set to `0` and never used. + +In this mode it is not possible for a party to be liquidated. Even if the price moves to the extremes of zero or the `max price` and parties may therefore have zero in their margin account, the parties must not be liquidated. Fully collateralised means that the posted collateral explicitly covers all eventualities and positions will only be closed at final settlement at maturity. + +Order margin is calculated as per [isolated margin mode](#placing-an-order) with: + +- `side margin = limit price * size` for buy orders +- `side margin = (max price - limit price) * size` for sell orders. + +Same calculation should be applied during auction (unlike in isolated margin mode). + ### Actual position margin levels 1. **Maintenance margin**: the minimum margin a party must have in their margin account to avoid the position being liquidated. diff --git a/protocol/features.json b/protocol/features.json index 855ae9b4e..3b3355ae0 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -25,22 +25,29 @@ }, "Isolated margin": { "milestone": "colosseo", - "acs": ["0019-MCAL-208"] + "acs": [ + "0019-MCAL-208" + ] }, "Closeout trades and auctions": { "milestone": "colosseo", - "acs": ["0012-POSR-030"] + "acs": [ + "0012-POSR-030" + ] }, "Market suspended/resumed before enactment": { "milestone": "colosseo", "acs": [ - "0043-MKTL-011", - "0043-MKTL-012", - "0043-MKTL-013"] + "0043-MKTL-011", + "0043-MKTL-012", + "0043-MKTL-013" + ] }, "Teams": { "milestone": "colosseo", - "acs": ["0083-RFPR-068"] + "acs": [ + "0083-RFPR-068" + ] }, "Spot": { "milestone": "colosseo", @@ -533,11 +540,17 @@ }, "Perpetual funding rates": { "milestone": "colosseo", - "acs": ["0053-PERP-036"] + "acs": [ + "0053-PERP-036" + ] }, "Explicit liquidation range": { "milestone": "colosseo", - "acs": ["0012-POSR-031", "0012-POSR-032", "0012-POSR-033"] + "acs": [ + "0012-POSR-031", + "0012-POSR-032", + "0012-POSR-033" + ] }, "Community Tags": { "milestone": "colosseo", @@ -557,7 +570,9 @@ }, "LPs voting without gov token": { "milestone": "colosseo", - "acs": ["0028-GOVE-185"] + "acs": [ + "0028-GOVE-185" + ] }, "Reward Improvements": { "milestone": "colosseo", @@ -660,8 +675,31 @@ "0014-NP-VAMM-003" ] }, + "Capped Futures": { + "milestone": "colosseo_II", + "acs": [ + "0016-PFUT-013", + "0016-PFUT-014", + "0016-PFUT-015", + "0016-PFUT-016", + "0016-PFUT-017", + "0016-PFUT-018", + "0016-PFUT-019", + "0016-PFUT-020", + "0016-PFUT-021", + "0016-PFUT-022", + "0016-PFUT-023", + "0016-PFUT-024", + "0016-PFUT-025", + "0019-MCAL-154", + "0019-MCAL-155", + "0019-MCAL-156", + "0019-MCAL-157", + "0019-MCAL-158" + ] + }, "Unknown": { "milestone": "unknown", "acs": [] } -} +} \ No newline at end of file From 43c2df8d0e4a030534ba3f9bd7e04287c55a7c3c Mon Sep 17 00:00:00 2001 From: Tom Date: Tue, 14 May 2024 14:56:11 +0100 Subject: [PATCH 1110/1171] feat: Remove mention of synchronised state for vAMMs from auction uncrossing process (#2269) --- 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 e0eeb76cc..bd85400c3 100644 --- a/protocol/0026-AUCT-auctions.md +++ b/protocol/0026-AUCT-auctions.md @@ -51,7 +51,7 @@ We can also imagine that an auction period could come to an end once a give numb Once the auction period finishes, vega needs to figure out the best price for the order range in the book which can be uncrossed. The first stage in this is to calculate the Volume Maximising Price Range - the range of prices (which will be a contiguous range in an unconstrained order book) at which the highest total quantity of trades can occur. -For including [AMM](./0090-VAMM-automated_market_maker.md) configurations in the auction uncrossing process and volume maximising price range, create two lists of independent copies of all currently active vAMMs, including those which are currently in `single-sided` mode due to being unsynchronised. Ensure that the price range under consideration (lowest ask - highest bid) is expanded to cover the current best bid/ask prices of all vAMMs. For vAMMs which are currently unsynchronised, take their best bid/ask to be their current fair price. When iterating through the price ranges the vAMMs should be updated after each price level checked as if they have traded that volume before checking the next level. Unsynchronised vAMMs may quote on both sides of the book (as there is no current price towards which they should be trading) but will not necessarily be marked synchronised as a result of the price auction uncrossing. +For including [AMM](./0090-VAMM-automated_market_maker.md) configurations in the calculation of expected uncrossing price of the auction process and volume maximising price range, create two lists of independent copies of all currently active vAMMs. Ensure that the price range under consideration (lowest ask - highest bid) is expanded to cover the current best bid/ask prices of all vAMMs. When iterating through the price ranges the vAMMs should be updated after each price level checked as if they have traded that volume before checking the next level. vAMMs may quote on both sides of the book as long as they are not in reduce-only mode. When actually uncrossing the market, vAMMs should act as normal when trades from one side are being sent in to matching. Initially we will use the mid price within this range. For example, if the volume maximising range is 98-102, we would price all trades in the uncrossing at 100 ((minimum price of range+maximum price of range)/2). In future there will be other options, which will be selectable via a network parameter specified at market creation, and changeable through governance. These other options are not yet specified. From b35b6d3dcb95970710790a40d95c17ffc507a978 Mon Sep 17 00:00:00 2001 From: Witold Date: Tue, 14 May 2024 17:09:06 +0200 Subject: [PATCH 1111/1171] refactor: enable CI for colosseo_II --- .github/workflows/quality_check.yml | 1 + 1 file changed, 1 insertion(+) diff --git a/.github/workflows/quality_check.yml b/.github/workflows/quality_check.yml index 24b201724..87d9506e8 100644 --- a/.github/workflows/quality_check.yml +++ b/.github/workflows/quality_check.yml @@ -10,6 +10,7 @@ name: "Quality checks" - cosmicelevator - palazzo - colosseo + - colosseo_II env: GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} From d797450301b1f75e1fceebe7a5d2992f1701ea59 Mon Sep 17 00:00:00 2001 From: Witold Date: Tue, 14 May 2024 17:21:24 +0200 Subject: [PATCH 1112/1171] chore: fix spelling errors --- protocol/0016-PFUT-product_builtin_future.md | 2 +- protocol/0090-VAMM-automated_market_maker.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/protocol/0016-PFUT-product_builtin_future.md b/protocol/0016-PFUT-product_builtin_future.md index 80170ad48..83f49405a 100644 --- a/protocol/0016-PFUT-product_builtin_future.md +++ b/protocol/0016-PFUT-product_builtin_future.md @@ -84,7 +84,7 @@ If `max_price` is specified: ## 3. Binary options -Please note that selecting a future prodcut with `max_price` specified and `binary_settlement` flag set to `true` allows representing binary options markets. +Please note that selecting a future product with `max_price` specified and `binary_settlement` flag set to `true` allows representing binary options markets. ## Acceptance Criteria diff --git a/protocol/0090-VAMM-automated_market_maker.md b/protocol/0090-VAMM-automated_market_maker.md index b3e02a6bb..56695fbff 100644 --- a/protocol/0090-VAMM-automated_market_maker.md +++ b/protocol/0090-VAMM-automated_market_maker.md @@ -312,7 +312,7 @@ At market settlement, an AMM's position will be settled alongside all others as - When an AMM is active on a market at time of settlement with a position in a well collateralised state, the market can settle successfully and then all funds on the AMM key are transferred back to the main party's account (0090-VAMM-031) -- When an AMM is active on a market at time of settlement but the settlement price means that the party is closed out no funds are transfeered back to the main party's account (0090-VAMM-032) +- When an AMM is active on a market at time of settlement but the settlement price means that the party is closed out no funds are transferred back to the main party's account (0090-VAMM-032) - An AMM with base price `1000`, upper price `1100`, lower price `900` and current position `0`: - Quotes a volume of `8.216` units to buy to move fair price to `900` From 68c45966a2c31c5c4fd2096ee24da6f67bc6159a Mon Sep 17 00:00:00 2001 From: Witold Date: Tue, 14 May 2024 17:34:11 +0200 Subject: [PATCH 1113/1171] chore: fix approbation errors --- .github/workflows/quality_check.yml | 2 +- .../0014-NP-VAMM-bounds-estimations.md | 2 +- .../0042-LIQF-setting_fees_and_rewarding_lps.md | 6 +++--- protocol/0056-REWA-rewards_overview.md | 4 ++-- protocol/features.json | 13 ++++++++----- 5 files changed, 15 insertions(+), 12 deletions(-) diff --git a/.github/workflows/quality_check.yml b/.github/workflows/quality_check.yml index 87d9506e8..0082c4434 100644 --- a/.github/workflows/quality_check.yml +++ b/.github/workflows/quality_check.yml @@ -74,7 +74,7 @@ jobs: - name: "Run Check file names" run: | - npx github:vegaprotocol/approbation check-filenames --specs="{./non-protocol-specs/**/*.md,./protocol/**/*.md,./protocol/**/*.ipynb}" + npx github:vegaprotocol/approbation check-filenames --specs="{./non-protocol-specs/**/*.md,./protocol/**/*.md}" - name: "Run Check Features" run: | diff --git a/non-protocol-specs/0014-NP-VAMM-bounds-estimations.md b/non-protocol-specs/0014-NP-VAMM-bounds-estimations.md index 8f58158ee..30802a298 100644 --- a/non-protocol-specs/0014-NP-VAMM-bounds-estimations.md +++ b/non-protocol-specs/0014-NP-VAMM-bounds-estimations.md @@ -111,7 +111,7 @@ When a key is specified, the existence of any current vAMM should be checked and 1. Liquidation Price at Lower Bound: 454.545 -- For a request specifying (base, upper, lower, leverage_upper, leverage_lower, commitment) as (1000, 1300, 900, 1, 5, 100) the response is (0014-NP-VAMM-001): +- For a request specifying (base, upper, lower, leverage_upper, leverage_lower, commitment) as (1000, 1300, 900, 1, 5, 100) the response is (0014-NP-VAMM-004): 1. Loss on Commitment at Upper Bound: 10.948 1. Loss on Commitment at Lower Bound: 21.289 diff --git a/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md b/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md index 917f51886..37af4d9e9 100644 --- a/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md +++ b/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md @@ -462,6 +462,6 @@ Example 1, generated with [supplementary worksheet](https://docs.google.com/spre ### vAMM behaviour -- All vAMMs active on a market at the end of an epoch receive SLA bonus rebalancing payments with `0` penalty fraction. (0042-LIQF-063) -- A vAMM active on a market during an epoch, which was cancelled prior to the end of an epoch, receives SLA bonus rebalancing payments with `0` penalty fraction. (0042-LIQF-064) -- A vAMMs cancelled in a previous epoch does not receive anything and is not considered during SLA rebalancing at the end of an epoch(0042-LIQF-065) +- All vAMMs active on a market at the end of an epoch receive SLA bonus rebalancing payments with `0` penalty fraction. (0042-LIQF-092) +- A vAMM active on a market during an epoch, which was cancelled prior to the end of an epoch, receives SLA bonus rebalancing payments with `0` penalty fraction. (0042-LIQF-093) +- A vAMMs cancelled in a previous epoch does not receive anything and is not considered during SLA rebalancing at the end of an epoch(0042-LIQF-094) diff --git a/protocol/0056-REWA-rewards_overview.md b/protocol/0056-REWA-rewards_overview.md index 79740b52e..4030222db 100644 --- a/protocol/0056-REWA-rewards_overview.md +++ b/protocol/0056-REWA-rewards_overview.md @@ -1141,5 +1141,5 @@ At the end of epoch 2, 10000 VEGA rewards should be distributed to the `ETHUSDT` ## vAMMs -- If an AMM sub-key earns rewards which would be transferred to it's vesting account, these rewards are instead transferred to the parent key's vesting account with a `from_key` field specifying the sub-key (0056-REWA-152). -- If an AMM sub-key earns rewards which would be transferred to it's locked account, these rewards are instead transferred to the parent key's locked account with a `from_key` field specifying the sub-key (0056-REWA-153). +- If an AMM sub-key earns rewards which would be transferred to it's vesting account, these rewards are instead transferred to the parent key's vesting account with a `from_key` field specifying the sub-key (0056-REWA-168). +- If an AMM sub-key earns rewards which would be transferred to it's locked account, these rewards are instead transferred to the parent key's locked account with a `from_key` field specifying the sub-key (0056-REWA-169). diff --git a/protocol/features.json b/protocol/features.json index 3b3355ae0..7dc4b6958 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -363,7 +363,9 @@ "0056-REWA-164", "0056-REWA-165", "0056-REWA-166", - "0056-REWA-167" + "0056-REWA-167", + "0056-REWA-168", + "0056-REWA-169" ] }, "Spot stretch": { @@ -627,9 +629,9 @@ "vAMMs": { "milestone": "colosseo_II", "acs": [ - "0042-LIQF-063", - "0042-LIQF-064", - "0042-LIQF-065", + "0042-LIQF-092", + "0042-LIQF-093", + "0042-LIQF-094", "0090-VAMM-001", "0090-VAMM-002", "0090-VAMM-003", @@ -672,7 +674,8 @@ "0026-AUCT-037", "0014-NP-VAMM-001", "0014-NP-VAMM-002", - "0014-NP-VAMM-003" + "0014-NP-VAMM-003", + "0014-NP-VAMM-004" ] }, "Capped Futures": { From a698950baca64d8bca9f67816b8eb00c1cb17bac Mon Sep 17 00:00:00 2001 From: Witold Date: Tue, 7 May 2024 16:11:37 +0200 Subject: [PATCH 1114/1171] refactor: add support for hardcoded risk factors --- protocol/0018-RSKM-quant_risk_models.ipynb | 334 +++++++++++---------- 1 file changed, 169 insertions(+), 165 deletions(-) diff --git a/protocol/0018-RSKM-quant_risk_models.ipynb b/protocol/0018-RSKM-quant_risk_models.ipynb index 36a6205bf..ae8b7633c 100644 --- a/protocol/0018-RSKM-quant_risk_models.ipynb +++ b/protocol/0018-RSKM-quant_risk_models.ipynb @@ -1,166 +1,170 @@ { - "cells": [ - { - "attachments": {}, - "cell_type": "markdown", - "metadata": {}, - "source": [ - "# Quantitative risk models\n", - "\n", - "\n", - "## Summary\n", - "Vega can use different risk models as for different underlying assets and different derivatives one has to choose an appropriate model. Every quantitative risk model used by Vega needs to be able to provide the following.\n", - "\n", - "1. Risk factors, currently for futures but for other products as Vega develops. The risk factor *linearizes* the risk measure used for margin requirements. See `0019-MCAL-margin_calculator.md` for details of how these are used.\n", - "1. Given a probability level $\\alpha \\in (0.9,1)$, time horizon $\\tau > 0$ and current price $S$ return the $\\Delta^-$ and $\\Delta^+$ such that \n", - "$$\n", - "\\mathbb P(S-\\Delta^- \\leq S_\\tau \\leq S+\\Delta^+) \\geq 1-\\alpha\\,.\n", - "$$\n", - "See the price monitoring spec for details of how these are used.\n", - "1. Given current price $S$, time horizon $\\tau > 0$, a list of price levels $S < S_1 < S_2 < \\cdots < S_N^+$ return the probability of trading at each of these price levels defined below. See \"Probability weighted liquidity measure\" spec for how these are used.\n", - "1. Calibration outputs (not required for first release of Mainnet, model parameters result from governance vote per market).\n", - "\n", - "The “quant risk suite” with Vega consists a _quantitative risk model_, _margin calculator_ and _calibrator_.\n", - "\n", - "A market parameter specifies which _quantitative risk model_ is used for a given risk universe (market, see Section 3.5 of the Vega white paper).\n", - "\n", - "\n", - "## Reference-level explanation\n", - "\n", - "### _Quantitative risk model_\n", - "The relevant quantitative risk model for a market is specified on a tradeable instrument. The role of the quantitative risk model is to calculate **risk factors** which are used in the **_margin calculator_** (see below)\n", - "as well as probabilities of various price moves used for price monitoring and measuring liquidity. \n", - "\n", - "To achieve this it utilises the quantitative maths library.\n", - "\n", - "The quantitative risk model may take one or more of the following as inputs:\n", - "* risk parameters (e.g. volatility)\n", - "* product parameters (e.g. minimum contract size)\n", - "* order book data (full current order book with volume aggregated at price levels)\n", - "* position data (for each trader)\n", - "* event data (e.g. passage of time) (Not for Futures / Nicenet )\n", - "\n", - "The quantitative risk model returns two risk factors:\n", - "\n", - "1. Rounded Long position risk factor\n", - "1. Rounded Short position risk factor\n", - "\n", - "The quantitative risk model is able to utilise a relevant method from the quant math library to perform the calculations.\n", - "\n", - "The quant math library calculates:\n", - "1. Long position risk factor\n", - "1. Short position risk factor\n", - "1. Guaranteed accuracy (applicable to both risk factors)\n", - "1. The max move up/down ($\\Delta^-$ and $\\Delta^+$ defined in the [Summary](#Summary)) given current price level and a projection horizon such that the resulting prices are within a specified probability level.\n", - "1. Probability of trading at a given price level (see below).\n", - "\n", - "#### Calculating the probability of trading\n", - "This is well defined only if we have best bid $S_{\\text{best bid}}$ and best ask $S_{\\text{best ask}}$ on the order book. \n", - "The rest of information comes from the quant risk model that has the probability density of price distribution at time horizon $\\tau > 0$ i.e. we have \n", - "$$\n", - "f(x;S) = \\mathbb P(S_\\tau \\in [x, x+dx) | S)\\,, \n", - "$$\n", - "where $S$ is current price level and $S_\\tau$ is a future price, after time $\\tau > 0$.\n", - "\n", - "Given a price level $S$, time horizon $\\tau > 0$, a list of price levels $S < S_1 < S_2 < \\cdots < S_{N^+}$ or a list of price levels $S > S_1 > S_2 > \\cdots > S_{N^-}$ return the probability of trading $p(S_i)$ at each of these as defined below. \n", - "\n", - "1. If $S_i \\in [S_{\\text{best bid}}, S_{\\text{best ask}}]$ for $i=1,\\ldots,N^+$ or $i=1,\\ldots,N^-$ return $p(S_i) = 1$. \n", - "That is, between best bid and best ask the probability of trading is one. \n", - "2. If $S_i > S_{\\text{best ask}}$ for $i=1,\\ldots,N^+$ then return \n", - "$$\n", - "p(S_i) = \\int_{S_i}^{S_{max}} f(x;S_{\\text{best ask}})\\,dx\n", - "$$\n", - "3. If $S_i < S_{\\text{best bid}}$ for $ =1,\\ldots,N^-$ then return\n", - "$$\n", - "p(S_i) = \\int_{S_{min}}^{S_i} f(x;S_{\\text{best bid}})\\,dx\\,.\n", - "$$\n", - "\n", - "#### When to not update risk factors\n", - "\n", - "The call to the quantitative math library should *only* be made if any of the above inputs have changed from last time; if no input has changed then the quantitative risk model doesn't need to update the risk factors. \n", - "\n", - "#### When to update risk factors\n", - "\n", - "Risk factors are an input to the [margin calculation](./0019-MCAL-margin_calculators.md) and are calculated using a quantitative risk model.\n", - "\n", - "Risk factors are updated if \n", - "* An update risk factors call is not already in progress asynchronously; AND\n", - "* Any of the required inputs to risk factors change. Examples 1. when the calibrator has updated any risk parameters. 2. a specified period of time has elapsed (period can = 0 for always recalculate) for re-calculating risk factors. This period of time is defined as a risk parameter (see [market framework](./0001-MKTF-market_framework.md)).\n", - "\n", - "Risk factors are also updated if on creation of a new market that does not yet have risk factors, as any active market needs to have risk factors.\n", - "\n", - "#### Risk factors and consensus\n", - "\n", - "All new risk factors will need to be agreed via consensus when either (or both): \n", - "- asynchronous updates\n", - "- the other cause will be due to floating point non-determinism\n", - "\n", - "The rounding should remove all digits beyond the guaranteed accuracy. \n", - "\n", - "Example: If `Long position risk factor = 1.23456789` and `Guaranteed accuracy = 0.001` then \n", - "`Rounded Long position risk factor = 1.234`. \n", - "\n" - ] - }, - { - "cell_type": "markdown", - "metadata": {}, - "source": [ - "## Wrapped risk models\n", - "\n", - "For certain products it might be possible to certain aspects of market's reliance on risk model while keeping other dependencies in places.\n", - "\n", - "### Fully-collateralised\n", - "\n", - "For products with pre-defined finite price range (e.g. [a futures contracts with [`max_price`](./0016-PFUT-product_builtin_future.md#1-product-parameters) parameter specified]) it is possible to make positions fully-collateralised so that for any position a margin can be chosen such that the party stays solvent at any price the market may attain. Using this mode removes the reliance on risk-factors, however the risk model might still be used for other aspects of market's functioning. To signify this and make it transparent to the user a fully-collateralised wrapped risk model is used in those cases." - ] - }, - { - "attachments": {}, - "cell_type": "markdown", - "metadata": {}, - "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. 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)" - ] - }, - { - "cell_type": "markdown", - "metadata": {}, - "source": [] - } - ], - "metadata": { - "kernelspec": { - "display_name": "Python 3", - "language": "python", - "name": "python3" - }, - "language_info": { - "codemirror_mode": { - "name": "ipython", - "version": 3 - }, - "file_extension": ".py", - "mimetype": "text/x-python", - "name": "python", - "nbconvert_exporter": "python", - "pygments_lexer": "ipython3", - "version": "3.9.6" - }, - "vscode": { - "interpreter": { - "hash": "31f2aee4e71d21fbe5cf8b01ff0e069b9275f58929596ceb00d14d90e3e16cd6" - } - } - }, - "nbformat": 4, - "nbformat_minor": 2 -} + "cells": [ + { + "attachments": {}, + "cell_type": "markdown", + "metadata": {}, + "source": [ + "# Quantitative risk models\n", + "\n", + "\n", + "## Summary\n", + "Vega can use different risk models as for different underlying assets and different derivatives one has to choose an appropriate model. Every quantitative risk model used by Vega needs to be able to provide the following.\n", + "\n", + "1. Risk factors, currently for futures but for other products as Vega develops. The risk factor *linearizes* the risk measure used for margin requirements. See `0019-MCAL-margin_calculator.md` for details of how these are used.\n", + "1. Given a probability level $\\alpha \\in (0.9,1)$, time horizon $\\tau > 0$ and current price $S$ return the $\\Delta^-$ and $\\Delta^+$ such that \n", + "$$\n", + "\\mathbb P(S-\\Delta^- \\leq S_\\tau \\leq S+\\Delta^+) \\geq 1-\\alpha\\,.\n", + "$$\n", + "See the price monitoring spec for details of how these are used.\n", + "1. Given current price $S$, time horizon $\\tau > 0$, a list of price levels $S < S_1 < S_2 < \\cdots < S_N^+$ return the probability of trading at each of these price levels defined below. See \"Probability weighted liquidity measure\" spec for how these are used.\n", + "1. Calibration outputs (not required for first release of Mainnet, model parameters result from governance vote per market).\n", + "\n", + "The “quant risk suite” with Vega consists a _quantitative risk model_, _margin calculator_ and _calibrator_.\n", + "\n", + "A market parameter specifies which _quantitative risk model_ is used for a given risk universe (market, see Section 3.5 of the Vega white paper).\n", + "\n", + "\n", + "## Reference-level explanation\n", + "\n", + "### _Quantitative risk model_\n", + "The relevant quantitative risk model for a market is specified on a tradeable instrument. The role of the quantitative risk model is to calculate **risk factors** which are used in the **_margin calculator_** (see below)\n", + "as well as probabilities of various price moves used for price monitoring and measuring liquidity. \n", + "\n", + "To achieve this it utilises the quantitative maths library.\n", + "\n", + "The quantitative risk model may take one or more of the following as inputs:\n", + "* risk parameters (e.g. volatility)\n", + "* product parameters (e.g. minimum contract size)\n", + "* order book data (full current order book with volume aggregated at price levels)\n", + "* position data (for each trader)\n", + "* event data (e.g. passage of time) (Not for Futures / Nicenet )\n", + "\n", + "The quantitative risk model returns two risk factors:\n", + "\n", + "1. Rounded Long position risk factor\n", + "1. Rounded Short position risk factor\n", + "\n", + "The quantitative risk model is able to utilise a relevant method from the quant math library to perform the calculations.\n", + "\n", + "The quant math library calculates:\n", + "1. Long position risk factor\n", + "1. Short position risk factor\n", + "1. Guaranteed accuracy (applicable to both risk factors)\n", + "1. The max move up/down ($\\Delta^-$ and $\\Delta^+$ defined in the [Summary](#Summary)) given current price level and a projection horizon such that the resulting prices are within a specified probability level.\n", + "1. Probability of trading at a given price level (see below).\n", + "\n", + "#### Calculating the probability of trading\n", + "This is well defined only if we have best bid $S_{\\text{best bid}}$ and best ask $S_{\\text{best ask}}$ on the order book. \n", + "The rest of information comes from the quant risk model that has the probability density of price distribution at time horizon $\\tau > 0$ i.e. we have \n", + "$$\n", + "f(x;S) = \\mathbb P(S_\\tau \\in [x, x+dx) | S)\\,, \n", + "$$\n", + "where $S$ is current price level and $S_\\tau$ is a future price, after time $\\tau > 0$.\n", + "\n", + "Given a price level $S$, time horizon $\\tau > 0$, a list of price levels $S < S_1 < S_2 < \\cdots < S_{N^+}$ or a list of price levels $S > S_1 > S_2 > \\cdots > S_{N^-}$ return the probability of trading $p(S_i)$ at each of these as defined below. \n", + "\n", + "1. If $S_i \\in [S_{\\text{best bid}}, S_{\\text{best ask}}]$ for $i=1,\\ldots,N^+$ or $i=1,\\ldots,N^-$ return $p(S_i) = 1$. \n", + "That is, between best bid and best ask the probability of trading is one. \n", + "2. If $S_i > S_{\\text{best ask}}$ for $i=1,\\ldots,N^+$ then return \n", + "$$\n", + "p(S_i) = \\int_{S_i}^{S_{max}} f(x;S_{\\text{best ask}})\\,dx\n", + "$$\n", + "3. If $S_i < S_{\\text{best bid}}$ for $ =1,\\ldots,N^-$ then return\n", + "$$\n", + "p(S_i) = \\int_{S_{min}}^{S_i} f(x;S_{\\text{best bid}})\\,dx\\,.\n", + "$$\n", + "\n", + "#### When to not update risk factors\n", + "\n", + "The call to the quantitative math library should *only* be made if any of the above inputs have changed from last time; if no input has changed then the quantitative risk model doesn't need to update the risk factors. \n", + "\n", + "#### When to update risk factors\n", + "\n", + "Risk factors are an input to the [margin calculation](./0019-MCAL-margin_calculators.md) and are calculated using a quantitative risk model.\n", + "\n", + "Risk factors are updated if \n", + "* An update risk factors call is not already in progress asynchronously; AND\n", + "* Any of the required inputs to risk factors change. Examples 1. when the calibrator has updated any risk parameters. 2. a specified period of time has elapsed (period can = 0 for always recalculate) for re-calculating risk factors. This period of time is defined as a risk parameter (see [market framework](./0001-MKTF-market_framework.md)).\n", + "\n", + "Risk factors are also updated if on creation of a new market that does not yet have risk factors, as any active market needs to have risk factors.\n", + "\n", + "#### Risk factors and consensus\n", + "\n", + "All new risk factors will need to be agreed via consensus when either (or both): \n", + "- asynchronous updates\n", + "- the other cause will be due to floating point non-determinism\n", + "\n", + "The rounding should remove all digits beyond the guaranteed accuracy. \n", + "\n", + "Example: If `Long position risk factor = 1.23456789` and `Guaranteed accuracy = 0.001` then \n", + "`Rounded Long position risk factor = 1.234`. \n", + "\n" + ] + }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "## Wrapped risk models\n", + "\n", + "For certain products it might be possible to certain aspects of market's reliance on risk model while keeping other dependencies in places.\n", + "\n", + "### Fully-collateralised\n", + "\n", + "For products with pre-defined finite price range (e.g. [a futures contracts with [`max_price`](./0016-PFUT-product_builtin_future.md#1-product-parameters) parameter specified]) it is possible to make positions fully-collateralised so that for any position a margin can be chosen such that the party stays solvent at any price the market may attain. Using this mode removes the reliance on risk-factors, however the risk model might still be used for other aspects of market's functioning. To signify this and make it transparent to the user a fully-collateralised wrapped risk model is used in those cases.\n", + "\n", + "### Hardcoded risk factors\n", + "\n", + "For markets which should ignore model-implied risk factors and use hardcoded values instead a wrapped risk model should be used to signify that. The specified risk factors should be used wherever risk factors are expected and other model-implied outputs should be used for all other calculations based on a risk-model." + ] + }, + { + "attachments": {}, + "cell_type": "markdown", + "metadata": {}, + "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. 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)" + ] + }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [] + } + ], + "metadata": { + "kernelspec": { + "display_name": "Python 3", + "language": "python", + "name": "python3" + }, + "language_info": { + "codemirror_mode": { + "name": "ipython", + "version": 3 + }, + "file_extension": ".py", + "mimetype": "text/x-python", + "name": "python", + "nbconvert_exporter": "python", + "pygments_lexer": "ipython3", + "version": "3.9.6" + }, + "vscode": { + "interpreter": { + "hash": "31f2aee4e71d21fbe5cf8b01ff0e069b9275f58929596ceb00d14d90e3e16cd6" + } + } + }, + "nbformat": 4, + "nbformat_minor": 2 +} \ No newline at end of file From 211b92904fc7ea2bebef444d4a539e3b390cf7c6 Mon Sep 17 00:00:00 2001 From: Witold Date: Wed, 8 May 2024 11:18:55 +0200 Subject: [PATCH 1115/1171] refactor: add explicit liquidity score --- ...042-LIQF-setting_fees_and_rewarding_lps.md | 7 +++++-- ...instantaneous_liquidity_scoring_funcion.md | 21 +++++++++++++++++++ 2 files changed, 26 insertions(+), 2 deletions(-) create mode 100644 protocol/0091-ILSF-instantaneous_liquidity_scoring_funcion.md diff --git a/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md b/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md index 37af4d9e9..2c05e1615 100644 --- a/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md +++ b/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md @@ -216,10 +216,13 @@ An existing LP has `average entry valuation 1090.9` and `S=110`. Currently the s ``` -### Calculating the instantaneous liquidity score +### Calculating the 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 instantaneous liquidity score. + +It can be based either on [probability of trading](./0034-PROB-prob_weighted_liquidity_measure.ipynb) at each price level or an [explicit scoring function](./0091-ILSF-instantaneous_liquidity_scoring_funcion.md). The purpose of it is to decide on the relative value of volume placed close to the mid price versus that further away from it. + For orders outside the tightest price monitoring bounds set probability of trading to 0. For orders which have less than 10% [probability of trading], we set the probability to 0 when calculating liquidity score. Note that parked [pegged orders](./0037-OPEG-pegged_orders.md) and not-yet-triggered [stop orders](./0014-ORDT-order_types.md) are not included. diff --git a/protocol/0091-ILSF-instantaneous_liquidity_scoring_funcion.md b/protocol/0091-ILSF-instantaneous_liquidity_scoring_funcion.md new file mode 100644 index 000000000..8637cf76b --- /dev/null +++ b/protocol/0091-ILSF-instantaneous_liquidity_scoring_funcion.md @@ -0,0 +1,21 @@ +# Instantaneous liquidity scoring function + +## Summary + +While by default the market uses probability of trading to calculate the [liquidity score](./0042-LIQF-setting_fees_and_rewarding_lps.md#calculating-the-instantaneous-liquidity-score) it should also be possible to explicitly prescribe the instantaneous liquidity scoring function. When such function is specified then it gets used for liquidity score calculation and probability of trading is ignored. + +## Specifying the function + +The function gets specified sparately for each side of the book as: + +* `reference`: reference point to which offset from each `point` is to be applied. It can be MID or BEST BID / BEST ASK depending on the side of the book for which the function is specified. +* `points`: collection of `(offset, value)` tuples prodiving a discrete representation of the function. Tuple `(10,0.4)` means that the value of the instantaneous liquidity function for a price level of reference point with an offset of `10` is `0.4` (specified in the same way as for [pegged orders](./0037-OPEG-pegged_orders.md)). +* `interpolation strategy`: prescribes a way in which price levels not covered by `points` should be calculated. Should be either `flat` resulting in a piecewise-constant function (starting from a lowest offest the value specified for it is assumed to prevail until the next offset is reached) or `linear` resulting in a linear interpolation between points. + +Flat extrapolation is always carried out, that is when price level greater than point with a highset offset or smaller than that with a lowest offset needs to be scored we use the nearest values that's been specified. + +Validation: +* same as pegged orders for `reference` and `offset`, +* at least two `points` must be specified. + +When liquidity scoring function is not specified [probability of trading](./0034-PROB-prob_weighted_liquidity_measure.ipynb) should be used for [liquidity score](./0042-LIQF-setting_fees_and_rewarding_lps.md#calculating-the-instantaneous-liquidity-score) calculation by default. It should also be possible to change it back to a `nil` value later on in market's life to stop using the function prescibed before and return to the default behaviour. \ No newline at end of file From 7af88dc946b52502f42ee35ea50cbb3129028743 Mon Sep 17 00:00:00 2001 From: Witold Date: Thu, 9 May 2024 11:23:46 +0200 Subject: [PATCH 1116/1171] refactor: add model free triggers --- protocol/0032-PRIM-price_monitoring.md | 12 +++++++++++- 1 file changed, 11 insertions(+), 1 deletion(-) diff --git a/protocol/0032-PRIM-price_monitoring.md b/protocol/0032-PRIM-price_monitoring.md index 480b05572..ab620a1b8 100644 --- a/protocol/0032-PRIM-price_monitoring.md +++ b/protocol/0032-PRIM-price_monitoring.md @@ -4,8 +4,10 @@ The dynamics of market price movements are such that prices don't always represent the participants' true average view of the price, but are instead artefacts of the market microstructure: sometimes low liquidity and/or a large quantity of order volume can cause the price to diverge from the true market price. It is impossible to tell at any point in time if this has happened or not. -As a result, we assume that relatively small moves are "real" and that larger moves might not be. Price monitoring exists to determine the real price in the latter case. Distinguishing between small and large moves can be highly subjective and market-dependent. We are going to rely on the risk model to formalise this process. Risk model can be used to obtain the probability distribution of prices at a future point in time given the current price. A price monitoring trigger can be constructed using a fixed horizon and probability level. +As a result, we assume that relatively small moves are "real" and that larger moves might not be. Price monitoring exists to determine the real price in the latter case. Distinguishing between small and large moves can be highly subjective and market-dependent. +We are going to rely on the risk model to formalise this process. Risk model can be used to obtain the probability distribution of prices at a future point in time given the current price. A price monitoring trigger can be constructed using a fixed horizon and probability level. To give an example: get the price distribution in an hour as implied by the risk model given the current mid price, if after the hour has passed and the actual mid price is beyond what the model implied (either too low or too high) with some chosen probability level (say 99%), then we'd characterise such market move as large. In general we may want to use a few such triggers per market (i.e. different horizon and probability level pairs). The framework should be able to trigger a price protection auction period with any valid trading mode. +We're also going to allow specifying triggers directly as the maximum valid moves with respect to the reference price. In that case the `maxUpMoveFactor`, `maxDownMoveFactor` can be specified for a given horizon, such that a price is considered valid as long as it's in the range `[reference_price(horizon) * maxDownMoveFactor, [reference)price(horizon) * maxUpMoveFactor]`, where `[reference_price(horizon)` is the reference price corresponding to the specified horizon - obtained in exactly the same way as in the case of a model-based trigger. As mentioned above, price monitoring is meant to stop large market movements that are not "real" from occurring, rather than just detect them after the fact. To that end, it is necessary to pre-process every transaction and check if it triggers the price monitoring action. If pre-processing the transaction doesn't result in the trigger being activated then it should be "committed" by generating the associated events and modifying the order book accordingly (e.g. generate a trade and take the orders that matched off the book). On the other hand if the trigger is activated and the submitted transaction is valid for auction mode, the entire order book **along with that transaction** needs to be processed via price protection auction. If the transaction which activate the trigger is not valid for auction, then it should get rejected and market should continue in the current trading mode. Auction period associated with a given distribution projection horizon and probability level will be specified as part of market setup. Once the auction period finishes the trading should resume in regular fashion (unless other triggers are active, more on that in [reference-level explanation](#reference-level-explanation)). @@ -44,6 +46,7 @@ Likewise, pre-processing transactions will be needed as part of the [fees spec]( #### Market +##### Model-based triggers - `priceMonitoringParameters` - an array of more price monitoring parameters with the following fields: - `horizon` - price projection horizon expressed as a year fraction over which price is to be projected by the risk model and compared to the actual market moves during that period. Must be positive. - `probability` - probability level used in price monitoring. Must be in the [0.9,1) range. @@ -55,6 +58,13 @@ If any of the above parameters or the risk model gets modified in any way, the p - the auction end time implied by the currently running auction/extension should remain unchanged, - when auction uncrosses price monitoring should get reset using the updated parameters. +##### Model-free triggers + +- `modelFreePriceMonitoringParameters` - an array of more price monitoring parameters with the following fields: + - `horizon` - price projection horizon expressed as a year fraction over which price is to be projected by the risk model and compared to the actual market moves during that period. Must be positive. + - `maxUpMoveFactor` - a factor to be applied to the reference price (for the specified horizon) so that the maximum valid price is `reference_price(horizon) * maxUpMoveFactor`. Must be greater than `1`. + - `maxDownMoveFactor` - a factor to be applied to the reference price (for the specified horizon) so that the minimum valid price is `reference_price(horizon) * maxDownMoveFactor`. Must be less than `1`. + #### Network - `market.monitor.price.defaultParameters`: Specifies default market parameters outlined in the previous paragraph. These will be used if market parameters don't get explicitly specified. From 5ea9bc0759a68514795b901744341484a3382cb3 Mon Sep 17 00:00:00 2001 From: Witold Date: Tue, 14 May 2024 10:57:19 +0200 Subject: [PATCH 1117/1171] refactor: add ACs --- protocol/0016-PFUT-product_builtin_future.md | 3 ++ protocol/0019-MCAL-margin_calculator.md | 4 +++ protocol/0032-PRIM-price_monitoring.md | 3 ++ ...042-LIQF-setting_fees_and_rewarding_lps.md | 28 +++++++++++++++++++ ...3-PERP-product_builtin_perpetual_future.md | 6 ++++ ...instantaneous_liquidity_scoring_funcion.md | 4 +-- protocol/features.json | 16 +++++++++++ 7 files changed, 62 insertions(+), 2 deletions(-) diff --git a/protocol/0016-PFUT-product_builtin_future.md b/protocol/0016-PFUT-product_builtin_future.md index 83f49405a..31a418d8a 100644 --- a/protocol/0016-PFUT-product_builtin_future.md +++ b/protocol/0016-PFUT-product_builtin_future.md @@ -116,3 +116,6 @@ Optional parameters: 1. When `max_price` is specified and the market is ran in a [fully-collateralised mode](./0019-MCAL-margin_calculator.md#fully-collateralised) and a party opens a long position at a `max_price`, no closeout happens when mark to market settlement is carried out at a price of `0`. (0016-PFUT-023) 1. When `max_price` is specified and the market is ran in a [fully-collateralised mode](./0019-MCAL-margin_calculator.md#fully-collateralised) and a party opens a short position at a price of `0`, no closeout happens when mark to market settlement is carried out at a `max_price`. (0016-PFUT-024) 1. Futures market can be created without specifying any of the [optional paramters](#1-product-parameters). (0016-PFUT-025) +1. Futures market can be created with a wrapped risk model with [hardcoded risk factors](./0018-RSKM-quant_risk_models.ipynb). (0016-PFUT-026) +1. Updating a risk model on a futures market with regular risk model to a wrapped risk model with [hardcoded risk factors](./0018-RSKM-quant_risk_models.ipynb) results in recalculation of all margin levels in line with hardcoded values and collateral search/release where appropriate. (0016-PFUT-027) +1. Updating a risk model on a futures market with a wrapped risk model with [hardcoded risk factors](./0018-RSKM-quant_risk_models.ipynb) to a regular risk model results in recalculation of all margin levels in line with the specified risk model (hardcoded value are no longer used) and collateral search/release where appropriate. (0016-PFUT-028) diff --git a/protocol/0019-MCAL-margin_calculator.md b/protocol/0019-MCAL-margin_calculator.md index e2146aefd..22b575027 100644 --- a/protocol/0019-MCAL-margin_calculator.md +++ b/protocol/0019-MCAL-margin_calculator.md @@ -435,6 +435,10 @@ Assume a [capped future](./0093-CFUT-product_builtin_capped_future.md) market wi - Party B posts an order to buy `30` contracts at a price of `16`, the orders get placed on the book, the maintenance and initial margin levels for party B grow to `1180`, and the margin account balance remains unchanged at `700` and the order margin account balance grows to `480 = max (5 * (100 - 20), 30 * 16)`. The position remains unchanged at `-10`. (0019-MCAL-157) - Party A posts an order to sell `20` contracts at a price of `17`. A trade is generated for `10` contracts at a price of `18` with party B. A sell order for `10` contracts at a price of `17` from party A gets added to the book. The maintenance and initial margin levels for party A is now `10 * (100 - 17) = 830`, the position is `0` and the remaining volume on the book from this party is `10` at a price of `18`. Party A lost `120` on its position, hence `830 - (300 - 120) = 410` additional funds get moved from the general account as part of the transaction which submitted the order to sell `20` at `17`. Party B now has a position of `0` and following orders open on the book: sell `5` at `20` and buy `30` at `16`. The maintenance and initial margin levels are `max(5 * (100 - 20), 30 * 16) = 480`. The margin account momentarily becomes `820` (`700` + `120` of gains from the now closed position of `-10`), order margin account balance is `480`, hence `820` gets released back into the general account and margin account becomes `0`. (0019-MCAL-158) +## Acceptance Criteria (Hardcoded risk factors) + +- When a wrapped model with hardcoded risk factors is used then margin calculations depend entire on the hardcoded values and updating the nested risk model has no effect on margins (0019-MCAL-159) + ## Summary The *margin calculator* returns the set of margin levels for a given *actual position*, along with the amount of additional margin (if any) required to support the party's *potential position* (i.e. active orders including any that are parked/untriggered/undeployed). diff --git a/protocol/0032-PRIM-price_monitoring.md b/protocol/0032-PRIM-price_monitoring.md index ab620a1b8..01791bd6c 100644 --- a/protocol/0032-PRIM-price_monitoring.md +++ b/protocol/0032-PRIM-price_monitoring.md @@ -151,3 +151,6 @@ to the risk model and obtains the range of valid up/down price moves per each of - 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) - For all available mark price calculation methodologies: the price history used by the price monitoring engine is in line with market's mark price history. (0032-PRIM-039) - For all available mark-price calculation methodologies: the mark price update candidate gets rejected if it violates the price monitoring engine bounds. (0032-PRIM-040) +- Model-free triggers can be added to the market at creation time along with regular triggers. (0032-PRIM-041) +- Model-free triggers can be added to the market during market update along with regular triggers. (0032-PRIM-042) +- Adding a model-free trigger with `maxUpMoveFactor = 1.1` and `maxDownMoveFactor = 0.95` results in bonds with max valid price of `110` and min valid price of `95` when a reference price is `100`. When time passes so that the reference price becomes `90` then the resulting max valid price is `99` and min valid price is `85.5`. Violating any of these bounds results in an auction. (0032-PRIM-043) \ No newline at end of file diff --git a/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md b/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md index 2c05e1615..27476d839 100644 --- a/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md +++ b/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md @@ -468,3 +468,31 @@ Example 1, generated with [supplementary worksheet](https://docs.google.com/spre - All vAMMs active on a market at the end of an epoch receive SLA bonus rebalancing payments with `0` penalty fraction. (0042-LIQF-092) - A vAMM active on a market during an epoch, which was cancelled prior to the end of an epoch, receives SLA bonus rebalancing payments with `0` penalty fraction. (0042-LIQF-093) - A vAMMs cancelled in a previous epoch does not receive anything and is not considered during SLA rebalancing at the end of an epoch(0042-LIQF-094) + +### Explicit instantaneous liquidity scoring function + +When market is setup with [explicit instantaneous liquidity scoring function](./0091-ILSF-instantaneous_liquidity_scoring_funcion.md) as follows: +- buy-side: + - reference: BEST_BID + - points: [(0,0.25),(1,0)] + - interpolation strategy: FLAT + +- sell-side: + - reference: BEST_ASK + - points: [(0,0.35),(1,0)] + - interpolation strategy: FLAT + +then all the buy orders deployed at `BEST_BID` get an instantaneous liquidity score of `0.25`, all sell orders deployed at `BEST_ASK` get a score of `0.35` and all other orders get a score of `0`. Updating the risk model has no effect on those scores. (0042-LIQF-095) + +When market is setup with [explicit instantaneous liquidity scoring function](./0091-ILSF-instantaneous_liquidity_scoring_funcion.md) as follows: +- buy-side: + - reference: MID + - points: [(0,0.4),(200,0.2)] + - interpolation strategy: FLAT + +- sell-side: + - reference: MID + - points: [(0,0.5),(300,0.3)] + - interpolation strategy: FLAT + +the decimal places for the asset are, the decimal places for the market are and tick size is. Then buy orders pegged to MID with an offset of `100` get a score of `0.3`, orders with offset of `200` get a score of `0.2` and orders with and offset of `300` also get a score of `0.2`. Sell orders pegged to MID with an offset of `150` get a score of `0.4`, orders with an offset of `300` get a score of `0.3` and orders with an offset of `400` also get a score of `0.3`. Updating the risk model has no effect on those scores. (0042-LIQF-096) diff --git a/protocol/0053-PERP-product_builtin_perpetual_future.md b/protocol/0053-PERP-product_builtin_perpetual_future.md index 063494a64..8902c9e21 100644 --- a/protocol/0053-PERP-product_builtin_perpetual_future.md +++ b/protocol/0053-PERP-product_builtin_perpetual_future.md @@ -369,3 +369,9 @@ Launch a perpetual futures market which sets `internalCompositePrice` to `Nil` ( Launch a perpetual futures market which sets `internalCompositePrice` to a configuration which uses the impact notional price from the order book. for the "vega side price" for funding calculation. Submit a market update proposal to change this `Nil` (so that mark price gets used for the vega side price). Observe that the new methodology for funding calculations is applied correctly from enactment onwards. (0053-PERP-045). Launch a perpetual futures market which uses the "Last Traded Price" for the "vega side price" for funding calculation. Submit a market update proposal to change this to a composite price with a configuration which uses the impact notional price from the order book. Observe that the new methodology for funding calculations is applied correctly from enactment onwards. (0053-PERP-046). + +Perps market can be created with a wrapped risk model with [hardcoded risk factors](./0018-RSKM-quant_risk_models.ipynb). (0053-PERP-047) + +Updating a risk model on a perps market with regular risk model to a wrapped risk model with [hardcoded risk factors](./0018-RSKM-quant_risk_models.ipynb) results in recalculation of all margin levels in line with hardcoded values and collateral search/release where appropriate. (0053-PERP-048) + +Updating a risk model on a perps market with a wrapped risk model with [hardcoded risk factors](./0018-RSKM-quant_risk_models.ipynb) to a regular risk model results in recalculation of all margin levels in line with the specified risk model (hardcoded value are no longer used) and collateral search/release where appropriate. (0053-PERP-049) diff --git a/protocol/0091-ILSF-instantaneous_liquidity_scoring_funcion.md b/protocol/0091-ILSF-instantaneous_liquidity_scoring_funcion.md index 8637cf76b..aa8695635 100644 --- a/protocol/0091-ILSF-instantaneous_liquidity_scoring_funcion.md +++ b/protocol/0091-ILSF-instantaneous_liquidity_scoring_funcion.md @@ -8,9 +8,9 @@ While by default the market uses probability of trading to calculate the [liquid The function gets specified sparately for each side of the book as: -* `reference`: reference point to which offset from each `point` is to be applied. It can be MID or BEST BID / BEST ASK depending on the side of the book for which the function is specified. +* `reference`: reference point to which offset from each `point` is to be applied. It can be `MID` or `BEST BID` / `BEST ASK` depending on the side of the book for which the function is specified. * `points`: collection of `(offset, value)` tuples prodiving a discrete representation of the function. Tuple `(10,0.4)` means that the value of the instantaneous liquidity function for a price level of reference point with an offset of `10` is `0.4` (specified in the same way as for [pegged orders](./0037-OPEG-pegged_orders.md)). -* `interpolation strategy`: prescribes a way in which price levels not covered by `points` should be calculated. Should be either `flat` resulting in a piecewise-constant function (starting from a lowest offest the value specified for it is assumed to prevail until the next offset is reached) or `linear` resulting in a linear interpolation between points. +* `interpolation strategy`: prescribes a way in which price levels not covered by `points` should be calculated. Should be either `FLAT` resulting in a piecewise-constant function (starting from a lowest offest the value specified for it is assumed to prevail until the next offset is reached) or `LINEAR` resulting in a linear interpolation between points. Flat extrapolation is always carried out, that is when price level greater than point with a highset offset or smaller than that with a lowest offset needs to be scored we use the nearest values that's been specified. diff --git a/protocol/features.json b/protocol/features.json index 7dc4b6958..1700f10c9 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -701,6 +701,22 @@ "0019-MCAL-158" ] }, + "Model-free alternatives": { + "milestone": "colosseo_II", + "acs": [ + "0016-PFUT-026", + "0016-PFUT-027", + "0016-PFUT-028", + "0053-PERP-047", + "0053-PERP-048", + "0053-PERP-049", + "0032-PRIM-041", + "0032-PRIM-042", + "0032-PRIM-043", + "0042-LIQF-095", + "0042-LIQF-096" + ] + }, "Unknown": { "milestone": "unknown", "acs": [] From 158d15d691a3693cc114b03d9edbcce14fed583a Mon Sep 17 00:00:00 2001 From: Witold Date: Tue, 14 May 2024 17:46:44 +0200 Subject: [PATCH 1118/1171] chore: fix CI errors --- protocol/0032-PRIM-price_monitoring.md | 6 +++-- ...042-LIQF-setting_fees_and_rewarding_lps.md | 26 ++++++++++--------- ...instantaneous_liquidity_scoring_funcion.md | 11 ++++---- wordlist.txt | 1 + 4 files changed, 25 insertions(+), 19 deletions(-) diff --git a/protocol/0032-PRIM-price_monitoring.md b/protocol/0032-PRIM-price_monitoring.md index 01791bd6c..5a51f15ba 100644 --- a/protocol/0032-PRIM-price_monitoring.md +++ b/protocol/0032-PRIM-price_monitoring.md @@ -4,7 +4,7 @@ The dynamics of market price movements are such that prices don't always represent the participants' true average view of the price, but are instead artefacts of the market microstructure: sometimes low liquidity and/or a large quantity of order volume can cause the price to diverge from the true market price. It is impossible to tell at any point in time if this has happened or not. -As a result, we assume that relatively small moves are "real" and that larger moves might not be. Price monitoring exists to determine the real price in the latter case. Distinguishing between small and large moves can be highly subjective and market-dependent. +As a result, we assume that relatively small moves are "real" and that larger moves might not be. Price monitoring exists to determine the real price in the latter case. Distinguishing between small and large moves can be highly subjective and market-dependent. We are going to rely on the risk model to formalise this process. Risk model can be used to obtain the probability distribution of prices at a future point in time given the current price. A price monitoring trigger can be constructed using a fixed horizon and probability level. To give an example: get the price distribution in an hour as implied by the risk model given the current mid price, if after the hour has passed and the actual mid price is beyond what the model implied (either too low or too high) with some chosen probability level (say 99%), then we'd characterise such market move as large. In general we may want to use a few such triggers per market (i.e. different horizon and probability level pairs). The framework should be able to trigger a price protection auction period with any valid trading mode. We're also going to allow specifying triggers directly as the maximum valid moves with respect to the reference price. In that case the `maxUpMoveFactor`, `maxDownMoveFactor` can be specified for a given horizon, such that a price is considered valid as long as it's in the range `[reference_price(horizon) * maxDownMoveFactor, [reference)price(horizon) * maxUpMoveFactor]`, where `[reference_price(horizon)` is the reference price corresponding to the specified horizon - obtained in exactly the same way as in the case of a model-based trigger. @@ -47,6 +47,7 @@ Likewise, pre-processing transactions will be needed as part of the [fees spec]( #### Market ##### Model-based triggers + - `priceMonitoringParameters` - an array of more price monitoring parameters with the following fields: - `horizon` - price projection horizon expressed as a year fraction over which price is to be projected by the risk model and compared to the actual market moves during that period. Must be positive. - `probability` - probability level used in price monitoring. Must be in the [0.9,1) range. @@ -153,4 +154,5 @@ to the risk model and obtains the range of valid up/down price moves per each of - For all available mark-price calculation methodologies: the mark price update candidate gets rejected if it violates the price monitoring engine bounds. (0032-PRIM-040) - Model-free triggers can be added to the market at creation time along with regular triggers. (0032-PRIM-041) - Model-free triggers can be added to the market during market update along with regular triggers. (0032-PRIM-042) -- Adding a model-free trigger with `maxUpMoveFactor = 1.1` and `maxDownMoveFactor = 0.95` results in bonds with max valid price of `110` and min valid price of `95` when a reference price is `100`. When time passes so that the reference price becomes `90` then the resulting max valid price is `99` and min valid price is `85.5`. Violating any of these bounds results in an auction. (0032-PRIM-043) \ No newline at end of file +- Adding a model-free trigger with `maxUpMoveFactor = 1.1` and `maxDownMoveFactor = 0.95` results in bonds with max valid price of `110` and min valid price of `95` when a reference price is `100`. When time passes so that the reference price becomes `90` then the resulting max valid price is `99` and min valid price is `85.5`. Violating any of these bounds results in an auction. (0032-PRIM-043 +) diff --git a/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md b/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md index 27476d839..dacab0165 100644 --- a/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md +++ b/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md @@ -472,27 +472,29 @@ Example 1, generated with [supplementary worksheet](https://docs.google.com/spre ### Explicit instantaneous liquidity scoring function When market is setup with [explicit instantaneous liquidity scoring function](./0091-ILSF-instantaneous_liquidity_scoring_funcion.md) as follows: + - buy-side: - - reference: BEST_BID - - points: [(0,0.25),(1,0)] - - interpolation strategy: FLAT + - reference: BEST_BID + - points: [(0,0.25),(1,0)] + - interpolation strategy: FLAT - sell-side: - - reference: BEST_ASK - - points: [(0,0.35),(1,0)] - - interpolation strategy: FLAT + - reference: BEST_ASK + - points: [(0,0.35),(1,0)] + - interpolation strategy: FLAT then all the buy orders deployed at `BEST_BID` get an instantaneous liquidity score of `0.25`, all sell orders deployed at `BEST_ASK` get a score of `0.35` and all other orders get a score of `0`. Updating the risk model has no effect on those scores. (0042-LIQF-095) When market is setup with [explicit instantaneous liquidity scoring function](./0091-ILSF-instantaneous_liquidity_scoring_funcion.md) as follows: + - buy-side: - - reference: MID - - points: [(0,0.4),(200,0.2)] - - interpolation strategy: FLAT + - reference: MID + - points: [(0,0.4),(200,0.2)] + - interpolation strategy: FLAT - sell-side: - - reference: MID - - points: [(0,0.5),(300,0.3)] - - interpolation strategy: FLAT + - reference: MID + - points: [(0,0.5),(300,0.3)] + - interpolation strategy: FLAT the decimal places for the asset are, the decimal places for the market are and tick size is. Then buy orders pegged to MID with an offset of `100` get a score of `0.3`, orders with offset of `200` get a score of `0.2` and orders with and offset of `300` also get a score of `0.2`. Sell orders pegged to MID with an offset of `150` get a score of `0.4`, orders with an offset of `300` get a score of `0.3` and orders with an offset of `400` also get a score of `0.3`. Updating the risk model has no effect on those scores. (0042-LIQF-096) diff --git a/protocol/0091-ILSF-instantaneous_liquidity_scoring_funcion.md b/protocol/0091-ILSF-instantaneous_liquidity_scoring_funcion.md index aa8695635..88d4d1ffe 100644 --- a/protocol/0091-ILSF-instantaneous_liquidity_scoring_funcion.md +++ b/protocol/0091-ILSF-instantaneous_liquidity_scoring_funcion.md @@ -6,16 +6,17 @@ While by default the market uses probability of trading to calculate the [liquid ## Specifying the function -The function gets specified sparately for each side of the book as: +The function gets specified separately for each side of the book as: * `reference`: reference point to which offset from each `point` is to be applied. It can be `MID` or `BEST BID` / `BEST ASK` depending on the side of the book for which the function is specified. -* `points`: collection of `(offset, value)` tuples prodiving a discrete representation of the function. Tuple `(10,0.4)` means that the value of the instantaneous liquidity function for a price level of reference point with an offset of `10` is `0.4` (specified in the same way as for [pegged orders](./0037-OPEG-pegged_orders.md)). -* `interpolation strategy`: prescribes a way in which price levels not covered by `points` should be calculated. Should be either `FLAT` resulting in a piecewise-constant function (starting from a lowest offest the value specified for it is assumed to prevail until the next offset is reached) or `LINEAR` resulting in a linear interpolation between points. +* `points`: collection of `(offset, value)` tuples providing a discrete representation of the function. Tuple `(10,0.4)` means that the value of the instantaneous liquidity function for a price level of reference point with an offset of `10` is `0.4` (specified in the same way as for [pegged orders](./0037-OPEG-pegged_orders.md)). +* `interpolation strategy`: prescribes a way in which price levels not covered by `points` should be calculated. Should be either `FLAT` resulting in a piecewise-constant function (starting from a lowest offset the value specified for it is assumed to prevail until the next offset is reached) or `LINEAR` resulting in a linear interpolation between points. -Flat extrapolation is always carried out, that is when price level greater than point with a highset offset or smaller than that with a lowest offset needs to be scored we use the nearest values that's been specified. +Flat extrapolation is always carried out, that is when price level greater than point with a highest offset or smaller than that with a lowest offset needs to be scored we use the nearest values that's been specified. Validation: + * same as pegged orders for `reference` and `offset`, * at least two `points` must be specified. -When liquidity scoring function is not specified [probability of trading](./0034-PROB-prob_weighted_liquidity_measure.ipynb) should be used for [liquidity score](./0042-LIQF-setting_fees_and_rewarding_lps.md#calculating-the-instantaneous-liquidity-score) calculation by default. It should also be possible to change it back to a `nil` value later on in market's life to stop using the function prescibed before and return to the default behaviour. \ No newline at end of file +When liquidity scoring function is not specified [probability of trading](./0034-PROB-prob_weighted_liquidity_measure.ipynb) should be used for [liquidity score](./0042-LIQF-setting_fees_and_rewarding_lps.md#calculating-the-instantaneous-liquidity-score) calculation by default. It should also be possible to change it back to a `nil` value later on in market's life to stop using the function prescribed before and return to the default behaviour. diff --git a/wordlist.txt b/wordlist.txt index af422bc70..6a5608b5a 100644 --- a/wordlist.txt +++ b/wordlist.txt @@ -220,6 +220,7 @@ permissioned permissionless PERP perps +piecewise PME PnL PoS From d14a1d2447b35172ccd225be8d00df656d4b6f67 Mon Sep 17 00:00:00 2001 From: Vegaklaus <62546834+Vegaklaus@users.noreply.github.com> Date: Wed, 15 May 2024 01:10:58 -0700 Subject: [PATCH 1119/1171] Update 0031-ETHB-ethereum_bridge_spec.md Replaced confirmations with ETH finality. --- protocol/0031-ETHB-ethereum_bridge_spec.md | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/protocol/0031-ETHB-ethereum_bridge_spec.md b/protocol/0031-ETHB-ethereum_bridge_spec.md index e3795e69d..6d9b60f32 100644 --- a/protocol/0031-ETHB-ethereum_bridge_spec.md +++ b/protocol/0031-ETHB-ethereum_bridge_spec.md @@ -26,9 +26,11 @@ 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'. 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. +It used to be normal behaviour when validating transfers to wait a certain number of blocks for a deposit to be 'confirmed'. With the new version of Ethereum, an additiona;l mechanism exists that assures finallity of a block +that can be used instead, which leads to cleaner results. -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. +We use this mechanism for all Ethereum related finality requirements. For legacy reasons ,there is still a parameter +defining the number of confirmations previously used, but this parameter is ignored now. ## Reference-level explanation @@ -115,7 +117,7 @@ The Ethereum Bridge uses 1 network parameter, `blockchains.ethereumConfig`, a JS | `staking_bridge_contract` | {string, integer} | `{address: "0xCcB517899f714BD1B2f32931fF429aDEdDd02A93", deployment_height: 1}` | The addresses to listen to for [staking events](./0059-STKG-simple_staking_and_delegating.md). | | `token_vesting_contract` | {string, integer} | `{address: "0xCcB517899f714BD1B2f32931fF429aDEdDd02A93", deployment_height: 1}` | The addresses to listen to for [vesting contract events](./0059-STKG-simple_staking_and_delegating.md). | | `multisig_control_contract` | {string, integer} | `{address: "0xCcB517899f714BD1B2f32931fF429aDEdDd02A93", deployment_height: 1}` | The addresses to listen to for multisig control event | -| `confirmations` | Integer | `3` | Block confirmations to wait for before confirming an action | +| `confirmations` | Integer | `3` | Block confirmations to wait for before confirming an action (legacy) | ### Full example From 43ccf1e1ef360b357658de2c07da5f11bf247aa4 Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Wed, 15 May 2024 09:49:53 +0100 Subject: [PATCH 1120/1171] feat: add validation for fully-collateralised mode --- protocol/0019-MCAL-margin_calculator.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/protocol/0019-MCAL-margin_calculator.md b/protocol/0019-MCAL-margin_calculator.md index 22b575027..76c950811 100644 --- a/protocol/0019-MCAL-margin_calculator.md +++ b/protocol/0019-MCAL-margin_calculator.md @@ -477,6 +477,8 @@ Order margin is calculated as per [isolated margin mode](#placing-an-order) with Same calculation should be applied during auction (unlike in isolated margin mode). +Validation: `fully-collateralised mode` can only set to `true` when `binary_settlement` is set to `true` + ### Actual position margin levels 1. **Maintenance margin**: the minimum margin a party must have in their margin account to avoid the position being liquidated. From 45300dce6f8bd4de016d90119065f7aadf2a20c6 Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Wed, 15 May 2024 10:25:24 +0100 Subject: [PATCH 1121/1171] feat: remove added validation on fully collateralised mode --- protocol/0019-MCAL-margin_calculator.md | 2 -- 1 file changed, 2 deletions(-) diff --git a/protocol/0019-MCAL-margin_calculator.md b/protocol/0019-MCAL-margin_calculator.md index 76c950811..22b575027 100644 --- a/protocol/0019-MCAL-margin_calculator.md +++ b/protocol/0019-MCAL-margin_calculator.md @@ -477,8 +477,6 @@ Order margin is calculated as per [isolated margin mode](#placing-an-order) with Same calculation should be applied during auction (unlike in isolated margin mode). -Validation: `fully-collateralised mode` can only set to `true` when `binary_settlement` is set to `true` - ### Actual position margin levels 1. **Maintenance margin**: the minimum margin a party must have in their margin account to avoid the position being liquidated. From 48cb444a03ea873384633f0bc560a779b3d4d2de Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Wed, 15 May 2024 10:42:33 +0100 Subject: [PATCH 1122/1171] feat: add validation for capped futures --- protocol/0016-PFUT-product_builtin_future.md | 7 ++++++- protocol/0019-MCAL-margin_calculator.md | 2 ++ protocol/features.json | 4 +++- 3 files changed, 11 insertions(+), 2 deletions(-) diff --git a/protocol/0016-PFUT-product_builtin_future.md b/protocol/0016-PFUT-product_builtin_future.md index 31a418d8a..facfd7462 100644 --- a/protocol/0016-PFUT-product_builtin_future.md +++ b/protocol/0016-PFUT-product_builtin_future.md @@ -64,7 +64,7 @@ cash_settled_future.settlement_data(event) { ## 2. Additional considerations around optional parameters -Optional parameters allow creating capped futures (all prices including settlement price must be in the range `[0, max_price]`) or binary options (all intermediate prices must be in the range `[0, max_price]`, settlement price bust be either `0` or `max_price`) markets. +Optional parameters allow creating capped futures (all prices including settlement price must be in the range `[0, max_price]`) or binary options (all intermediate prices must be in the range `[0, max_price]`, settlement price must be either `0` or `max_price`) markets. ### 2.1 Order price validation @@ -86,6 +86,11 @@ If `max_price` is specified: Please note that selecting a future product with `max_price` specified and `binary_settlement` flag set to `true` allows representing binary options markets. +Validation: + +- `fully-collateralised mode` is only allowed when there is a `max_price` specified +- `binary_settlement` is only allowed when there is a `max_price` specified + ## Acceptance Criteria 1. Create a Cash Settled Future with trading termination triggered by a date/time based data source (0016-PFUT-001) diff --git a/protocol/0019-MCAL-margin_calculator.md b/protocol/0019-MCAL-margin_calculator.md index 22b575027..c54358bc9 100644 --- a/protocol/0019-MCAL-margin_calculator.md +++ b/protocol/0019-MCAL-margin_calculator.md @@ -434,6 +434,8 @@ Assume a [capped future](./0093-CFUT-product_builtin_capped_future.md) market wi - Party B posts an order to buy `10` contracts at a price of `18`, the orders get placed on the book and margin levels as well margin account balances and position remain unchanged. (0019-MCAL-156) - Party B posts an order to buy `30` contracts at a price of `16`, the orders get placed on the book, the maintenance and initial margin levels for party B grow to `1180`, and the margin account balance remains unchanged at `700` and the order margin account balance grows to `480 = max (5 * (100 - 20), 30 * 16)`. The position remains unchanged at `-10`. (0019-MCAL-157) - Party A posts an order to sell `20` contracts at a price of `17`. A trade is generated for `10` contracts at a price of `18` with party B. A sell order for `10` contracts at a price of `17` from party A gets added to the book. The maintenance and initial margin levels for party A is now `10 * (100 - 17) = 830`, the position is `0` and the remaining volume on the book from this party is `10` at a price of `18`. Party A lost `120` on its position, hence `830 - (300 - 120) = 410` additional funds get moved from the general account as part of the transaction which submitted the order to sell `20` at `17`. Party B now has a position of `0` and following orders open on the book: sell `5` at `20` and buy `30` at `16`. The maintenance and initial margin levels are `max(5 * (100 - 20), 30 * 16) = 480`. The margin account momentarily becomes `820` (`700` + `120` of gains from the now closed position of `-10`), order margin account balance is `480`, hence `820` gets released back into the general account and margin account becomes `0`. (0019-MCAL-158) +- `fully-collateralised mode` is only allowed when there is a `max_price` specified (0019-MCAL-170) +- `binary_settlement` is only allowed when there is a `max_price` specified (0019-MCAL-171) ## Acceptance Criteria (Hardcoded risk factors) diff --git a/protocol/features.json b/protocol/features.json index 1700f10c9..678586ab2 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -698,7 +698,9 @@ "0019-MCAL-155", "0019-MCAL-156", "0019-MCAL-157", - "0019-MCAL-158" + "0019-MCAL-158", + "0019-MCAL-170", + "0019-MCAL-171" ] }, "Model-free alternatives": { From 18514c8b3516fcd5b884e682774ccacd83ad9f50 Mon Sep 17 00:00:00 2001 From: Witold Date: Wed, 15 May 2024 17:43:15 +0200 Subject: [PATCH 1123/1171] refactor: modify specs in line with implementation --- protocol/0016-PFUT-product_builtin_future.md | 18 ++++++++++-------- protocol/0019-MCAL-margin_calculator.md | 2 +- protocol/0031-ETHB-ethereum_bridge_spec.md | 4 ++-- ...53-PERP-product_builtin_perpetual_future.md | 6 +++--- protocol/features.json | 6 ++++-- 5 files changed, 20 insertions(+), 16 deletions(-) diff --git a/protocol/0016-PFUT-product_builtin_future.md b/protocol/0016-PFUT-product_builtin_future.md index facfd7462..b3dbe1246 100644 --- a/protocol/0016-PFUT-product_builtin_future.md +++ b/protocol/0016-PFUT-product_builtin_future.md @@ -16,6 +16,7 @@ Validation: none required as these are validated by the asset and data source fr Optional parameters: +1. `fully_collateralised`: when set to `true` margins will be calculated so that orders and positions are [fully-collateralised](./0019-MCAL-margin_calculator.md#fully-collateralised). This flag can only be specified at market creation time. It cannot be modified on an existing market. 1. `max_price`: specifies the price cap for the market, an integer understood in the context of market decimal places, 1. `binary_settlement`: if set to `true` settlement price other than `0` or `max_price` will be ignored. @@ -86,7 +87,7 @@ If `max_price` is specified: Please note that selecting a future product with `max_price` specified and `binary_settlement` flag set to `true` allows representing binary options markets. -Validation: +Validation: - `fully-collateralised mode` is only allowed when there is a `max_price` specified - `binary_settlement` is only allowed when there is a `max_price` specified @@ -116,11 +117,12 @@ Optional parameters: 1. When `max_price` is specified and `binary_settlement` flag is set to `false`, and the final settlement price candidate received from the oracle is less than or equal to `max_price` then it gets used as is and the final cashflows are calculated according to that price. (0016-PFUT-018) 1. When `max_price` is specified and the final settlement price candidate received from the oracle is greater than `max_price` the value gets ignored, next a value equal to `max_price` comes in from the settlement oracle and market settles correctly. The market behaves in this way irrespective of how `binary_settlement` flag is set. (0016-PFUT-019) 1. When `max_price` is specified, the `binary_settlement` flag is set to `true` and the final settlement price candidate received from the oracle is greater than `0` and less than `max_price` the value gets ignored, next a value of `0` comes in from the settlement oracle and market settles correctly. (0016-PFUT-020) -1. When `max_price` is specified and the market is ran in a [fully-collateralised mode](./0019-MCAL-margin_calculator.md#fully-collateralised) and it has parties with open positions settling it at a price of `max_price` works correctly and the sum of all final settlement cashflows equals 0 (loss socialisation does not happen). Assuming general account balances of all parties were `0` after opening the positions and all of their funds were in the margin accounts: long parties end up with balances equal to `position size * max_price` and short parties end up with `0` balances. (0016-PFUT-021) -1. When `max_price` is specified and the market is ran in a [fully-collateralised mode](./0019-MCAL-margin_calculator.md#fully-collateralised) and it has parties with open positions settling it at a price of `0` works correctly and the sum of all final settlement cashflows equals 0 (loss socialisation does not happen). Assuming general account balances of all parties were `0` after opening the positions and all of their funds were in the margin accounts: short parties end up with balances equal to `abs(position size) * max_price` and long parties end up with `0` balances. (0016-PFUT-022) -1. When `max_price` is specified and the market is ran in a [fully-collateralised mode](./0019-MCAL-margin_calculator.md#fully-collateralised) and a party opens a long position at a `max_price`, no closeout happens when mark to market settlement is carried out at a price of `0`. (0016-PFUT-023) -1. When `max_price` is specified and the market is ran in a [fully-collateralised mode](./0019-MCAL-margin_calculator.md#fully-collateralised) and a party opens a short position at a price of `0`, no closeout happens when mark to market settlement is carried out at a `max_price`. (0016-PFUT-024) +1. When `max_price` is specified and the market is ran in a fully-collateralised mode and it has parties with open positions settling it at a price of `max_price` works correctly and the sum of all final settlement cashflows equals 0 (loss socialisation does not happen). Assuming general account balances of all parties were `0` after opening the positions and all of their funds were in the margin accounts: long parties end up with balances equal to `position size * max_price` and short parties end up with `0` balances. (0016-PFUT-021) +1. When `max_price` is specified and the market is ran in a fully-collateralised mode and it has parties with open positions settling it at a price of `0` works correctly and the sum of all final settlement cashflows equals 0 (loss socialisation does not happen). Assuming general account balances of all parties were `0` after opening the positions and all of their funds were in the margin accounts: short parties end up with balances equal to `abs(position size) * max_price` and long parties end up with `0` balances. (0016-PFUT-022) +1. When `max_price` is specified and the market is ran in a fully-collateralised mode and a party opens a long position at a `max_price`, no closeout happens when mark to market settlement is carried out at a price of `0`. (0016-PFUT-023) +1. When `max_price` is specified and the market is ran in a fully-collateralised mode and a party opens a short position at a price of `0`, no closeout happens when mark to market settlement is carried out at a `max_price`. (0016-PFUT-024) 1. Futures market can be created without specifying any of the [optional paramters](#1-product-parameters). (0016-PFUT-025) -1. Futures market can be created with a wrapped risk model with [hardcoded risk factors](./0018-RSKM-quant_risk_models.ipynb). (0016-PFUT-026) -1. Updating a risk model on a futures market with regular risk model to a wrapped risk model with [hardcoded risk factors](./0018-RSKM-quant_risk_models.ipynb) results in recalculation of all margin levels in line with hardcoded values and collateral search/release where appropriate. (0016-PFUT-027) -1. Updating a risk model on a futures market with a wrapped risk model with [hardcoded risk factors](./0018-RSKM-quant_risk_models.ipynb) to a regular risk model results in recalculation of all margin levels in line with the specified risk model (hardcoded value are no longer used) and collateral search/release where appropriate. (0016-PFUT-028) +1. Futures market can be created with a with [hardcoded risk factors](./0018-RSKM-quant_risk_models.ipynb). (0016-PFUT-026) +1. Updating a risk model on a futures market with regular risk model to with [hardcoded risk factors](./0018-RSKM-quant_risk_models.ipynb) results in recalculation of all margin levels in line with hardcoded values and collateral search/release where appropriate. (0016-PFUT-027) +1. Updating a risk model on a futures market with [hardcoded risk factors](./0018-RSKM-quant_risk_models.ipynb) to a regular risk model results in recalculation of all margin levels in line with the specified risk model (hardcoded value are no longer used) and collateral search/release where appropriate. (0016-PFUT-028) +1. It's not possible to modify the `fully-collateralised` flag with a market update transaction. (0016-PFUT-029) diff --git a/protocol/0019-MCAL-margin_calculator.md b/protocol/0019-MCAL-margin_calculator.md index c54358bc9..b25710485 100644 --- a/protocol/0019-MCAL-margin_calculator.md +++ b/protocol/0019-MCAL-margin_calculator.md @@ -466,7 +466,7 @@ general account from the margin account. For certain derivatives markets it may be possible to collateralise the position in full so that there's no default risk for any party. -If a product specifies an upper bound on price (`max price`) (e.g. [capped future](./0093-CFUT-product_builtin_capped_future.md)) then a fully-collateralised [wrapped risk model](./0018-RSKM-quant_risk_models.ipynb) can be specified for the market. If such a risk model is chosen then, it's mandatory for all parties (it's not possible to self-select any of the above partially-collateralised margining modes). +If a product specifies an upper bound on price (`max price`) (e.g. [capped future](./0093-CFUT-product_builtin_capped_future.md)) then a fully-collateralised mode can be specified for the market. If it is chosen then, it's mandatory for all parties (it's not possible to self-select any of the above partially-collateralised margining modes). In this mode long positions provide `position size * average entry price` in initial margin, whereas shorts provide `postion size * (max price - average entry price)`. The initial margin level is only re-evaluated when party changes their position. The [mark-to-market](./0003-MTMK-mark_to_market_settlement.md) is carried out as usual. Maintenance and initial margin levels should be set to the same value. Margin search and release levels are set to `0` and never used. diff --git a/protocol/0031-ETHB-ethereum_bridge_spec.md b/protocol/0031-ETHB-ethereum_bridge_spec.md index 6d9b60f32..391c0c834 100644 --- a/protocol/0031-ETHB-ethereum_bridge_spec.md +++ b/protocol/0031-ETHB-ethereum_bridge_spec.md @@ -26,8 +26,8 @@ Each bridge contains two primary functions and emits two primary events, each ta ### Block confirmations -It used to be normal behaviour when validating transfers to wait a certain number of blocks for a deposit to be 'confirmed'. With the new version of Ethereum, an additiona;l mechanism exists that assures finallity of a block -that can be used instead, which leads to cleaner results. +It used to be normal behaviour when validating transfers to wait a certain number of blocks for a deposit to be 'confirmed'. With the new version of Ethereum, an additional mechanism exists that assures finality of a block +that can be used instead, which leads to cleaner results. We use this mechanism for all Ethereum related finality requirements. For legacy reasons ,there is still a parameter defining the number of confirmations previously used, but this parameter is ignored now. diff --git a/protocol/0053-PERP-product_builtin_perpetual_future.md b/protocol/0053-PERP-product_builtin_perpetual_future.md index 8902c9e21..b4c663bb1 100644 --- a/protocol/0053-PERP-product_builtin_perpetual_future.md +++ b/protocol/0053-PERP-product_builtin_perpetual_future.md @@ -370,8 +370,8 @@ Launch a perpetual futures market which sets `internalCompositePrice` to a confi Launch a perpetual futures market which uses the "Last Traded Price" for the "vega side price" for funding calculation. Submit a market update proposal to change this to a composite price with a configuration which uses the impact notional price from the order book. Observe that the new methodology for funding calculations is applied correctly from enactment onwards. (0053-PERP-046). -Perps market can be created with a wrapped risk model with [hardcoded risk factors](./0018-RSKM-quant_risk_models.ipynb). (0053-PERP-047) +Perps market can be created with [hardcoded risk factors](./0018-RSKM-quant_risk_models.ipynb). (0053-PERP-047) -Updating a risk model on a perps market with regular risk model to a wrapped risk model with [hardcoded risk factors](./0018-RSKM-quant_risk_models.ipynb) results in recalculation of all margin levels in line with hardcoded values and collateral search/release where appropriate. (0053-PERP-048) +Updating a risk model on a perps market with [hardcoded risk factors](./0018-RSKM-quant_risk_models.ipynb) results in recalculation of all margin levels in line with hardcoded values and collateral search/release where appropriate. (0053-PERP-048) -Updating a risk model on a perps market with a wrapped risk model with [hardcoded risk factors](./0018-RSKM-quant_risk_models.ipynb) to a regular risk model results in recalculation of all margin levels in line with the specified risk model (hardcoded value are no longer used) and collateral search/release where appropriate. (0053-PERP-049) +Updating a risk model on a perps market with [hardcoded risk factors](./0018-RSKM-quant_risk_models.ipynb) to a regular risk model results in recalculation of all margin levels in line with the specified risk model (hardcoded value are no longer used) and collateral search/release where appropriate. (0053-PERP-049) diff --git a/protocol/features.json b/protocol/features.json index 678586ab2..817bf72cc 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -700,7 +700,8 @@ "0019-MCAL-157", "0019-MCAL-158", "0019-MCAL-170", - "0019-MCAL-171" + "0019-MCAL-171", + "0016-PFUT-029" ] }, "Model-free alternatives": { @@ -716,7 +717,8 @@ "0032-PRIM-042", "0032-PRIM-043", "0042-LIQF-095", - "0042-LIQF-096" + "0042-LIQF-096", + "0019-MCAL-159" ] }, "Unknown": { From 70c57b08a3b9bfd3354dcc8a6c90e702dd44986f Mon Sep 17 00:00:00 2001 From: Tom Date: Wed, 22 May 2024 13:15:26 +0100 Subject: [PATCH 1124/1171] feat: AMM Order Book Estimation (#2281) * feat: Adding spec for order book estimations --- .../0015-NP-OBES-order-book-estimations.md | 33 ++++++++++++++++ protocol/features.json | 38 ++++++------------- wordlist.txt | 1 + 3 files changed, 45 insertions(+), 27 deletions(-) create mode 100644 non-protocol-specs/0015-NP-OBES-order-book-estimations.md diff --git a/non-protocol-specs/0015-NP-OBES-order-book-estimations.md b/non-protocol-specs/0015-NP-OBES-order-book-estimations.md new file mode 100644 index 000000000..84f0fb5e1 --- /dev/null +++ b/non-protocol-specs/0015-NP-OBES-order-book-estimations.md @@ -0,0 +1,33 @@ + +# AMM Order Book Levels Estimator + +Whilst generating a limit order book shape, i.e. the prices and associated volumes available at each price, is trivially achievable by simply aggregating the various component limit orders, this is harder to achieve for the active AMMs on a market. This is due to the fact that the volumes at which they would trade each price level within their range is not immediately obtainable without some calculations. Whilst these calculations are not heavy, and are routinely performed as part of trading, expanding out the entire range of an AMM with a large range may be prohibitive both in time taken (when updating frequently) and also in storage space, as there may be a non-zero volume at every possible tick level over a large range, necessitating a large array in which to store it. + +In order to alleviate these issues, a heuristic should be used to govern how these AMMs are expanded out into levels for display, both in terms of how frequently these levels are updated and how far away from the mid price levels are calculated at each price level vs a larger gap. This spec aims to codify that heuristic. + +## Update Frequency + +The largest improvement to processing requirements from update frequency heuristics comes from the fact that an AMM will only update it's price levels when it is either amended or someone trades with it. Therefore the calculations generating a curve of volumes from AMM prices should be cached between these points and only updated when an AMM is amended or when a trade with an AMM occurs. This can be further improved if all curves from individual AMMs are stored separately alongside an aggregate volume in which case only the impacted AMM curve can be updated whilst all others remain static. + +## Update Depth + +The second consideration is the depth to which markets should be expanded at every individual price level, and what should be done after this point. As this information is purely used for informational purposes these options can be set (including some sensible defaults) at a per-datanode level rather than mandating a single set across the network. These values should be applicable across markets, so are defined in percentage terms: + + 1. **amm_full_expansion_percentage**: This is the percentage difference above and below the market mid price to which the AMMs should be fully expanded at each price level. + 1. **amm_estimate_step_percentage**: Once above (or below) these bounds the calculation should only occur at larger steps. These step sizes are governed in percentage terms again (and are in reference to a percentage of the mid price). + 1. **amm_max_estimated_steps**: The maximum number of estimated steps to return. Once this number have been calculated nothing further is returned. + +The calculation of the order book shape should combine these three values by using the `volume to trade between two price levels` calculations utilised by the core engine to iteratively calculate the volume quoted by a given AMM at each price level outwards from the centre. (Note that AMMs which were outside of range at the initial mid price may come into range during the iteration and should be included if so.) Once the percentage full expansion bounds have been reached the gaps between prices become those specified by the step percentage value, however the calculation remains the same beyond that. + + +## Acceptance criteria + +- With `amm_full_expansion_percentage` set to `5%`, `amm_estimate_step_percentage` set to `1%`and `amm_max_estimated_steps` set to `10`, when the mid-price is 100 then the order book expansion should return (0015-NP-OBES-001): + - Volume levels at every valid tick between `95` and `105` + - Volume levels outside that at every `1` increment from `106` to `115` and `94` to `85` + - No volume levels above `115` or below `85` + +- With `amm_full_expansion_percentage` set to `3%`, `amm_estimate_step_percentage` set to `5%`and `amm_max_estimated_steps` set to `2`, when the mid-price is 100 then the order book expansion should return (0015-NP-OBES-002): + - Volume levels at every valid tick between `97` and `103` + - Volume levels outside that at every `1` increment from `108` to `116` and `92` to `87` + - No volume levels above `116` or below `87` diff --git a/protocol/features.json b/protocol/features.json index 817bf72cc..dac15d14d 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -25,29 +25,19 @@ }, "Isolated margin": { "milestone": "colosseo", - "acs": [ - "0019-MCAL-208" - ] + "acs": ["0019-MCAL-208"] }, "Closeout trades and auctions": { "milestone": "colosseo", - "acs": [ - "0012-POSR-030" - ] + "acs": ["0012-POSR-030"] }, "Market suspended/resumed before enactment": { "milestone": "colosseo", - "acs": [ - "0043-MKTL-011", - "0043-MKTL-012", - "0043-MKTL-013" - ] + "acs": ["0043-MKTL-011", "0043-MKTL-012", "0043-MKTL-013"] }, "Teams": { "milestone": "colosseo", - "acs": [ - "0083-RFPR-068" - ] + "acs": ["0083-RFPR-068"] }, "Spot": { "milestone": "colosseo", @@ -542,17 +532,11 @@ }, "Perpetual funding rates": { "milestone": "colosseo", - "acs": [ - "0053-PERP-036" - ] + "acs": ["0053-PERP-036"] }, "Explicit liquidation range": { "milestone": "colosseo", - "acs": [ - "0012-POSR-031", - "0012-POSR-032", - "0012-POSR-033" - ] + "acs": ["0012-POSR-031", "0012-POSR-032", "0012-POSR-033"] }, "Community Tags": { "milestone": "colosseo", @@ -572,9 +556,7 @@ }, "LPs voting without gov token": { "milestone": "colosseo", - "acs": [ - "0028-GOVE-185" - ] + "acs": ["0028-GOVE-185"] }, "Reward Improvements": { "milestone": "colosseo", @@ -675,7 +657,9 @@ "0014-NP-VAMM-001", "0014-NP-VAMM-002", "0014-NP-VAMM-003", - "0014-NP-VAMM-004" + "0014-NP-VAMM-004", + "0015-NP-OBES-001", + "0015-NP-OBES-002" ] }, "Capped Futures": { @@ -725,4 +709,4 @@ "milestone": "unknown", "acs": [] } -} \ No newline at end of file +} diff --git a/wordlist.txt b/wordlist.txt index 6a5608b5a..990e720be 100644 --- a/wordlist.txt +++ b/wordlist.txt @@ -153,6 +153,7 @@ int64 integrations intrablock IOC +iteratively joinable joinable JSON From 86fac3bd7da2f8d33ae8ef76d5411bcc8be7c901 Mon Sep 17 00:00:00 2001 From: Tom Date: Thu, 23 May 2024 11:55:56 +0100 Subject: [PATCH 1125/1171] feat: Additional vAMM ACs (#2287) * feat: A few more vAMM ACs --- protocol/0042-LIQF-setting_fees_and_rewarding_lps.md | 6 ++++++ protocol/0090-VAMM-automated_market_maker.md | 9 ++++----- protocol/features.json | 7 ++++++- 3 files changed, 16 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 dacab0165..88fad0027 100644 --- a/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md +++ b/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md @@ -469,6 +469,12 @@ Example 1, generated with [supplementary worksheet](https://docs.google.com/spre - A vAMM active on a market during an epoch, which was cancelled prior to the end of an epoch, receives SLA bonus rebalancing payments with `0` penalty fraction. (0042-LIQF-093) - A vAMMs cancelled in a previous epoch does not receive anything and is not considered during SLA rebalancing at the end of an epoch(0042-LIQF-094) +- a vAMM which was active on the market throughout the epoch but with an active range which never overlapped with the SLA range is counted with an implied commitment of `0`. (0042-LIQF-107) +- A vAMM which was active on the market with an average of `10000` liquidity units (`price * volume`) provided across the epoch, and where the `market.liquidity.stakeToCcyVolume` value is `100`, will have an implied commitment of `100`. (0042-LIQF-108) +- A vAMM which was active on the market with an average of `10000` liquidity units (`price * volume`) provided for half the epoch, and then `0` for the second half of the epoch (as the price was out of the vAMM's configured range), and where the `market.liquidity.stakeToCcyVolume` value is `100`, will have an implied commitment of `50`. (0042-LIQF-109) +- A vAMM which was active on the market with an average of `10000` liquidity units (`price * volume`) provided for half the epoch, and then is cancelled for the second half of the epoch, and where the `market.liquidity.stakeToCcyVolume` value is `100`, will have an implied commitment of `50`. (0042-LIQF-110) +- A vAMM which was active on the market with an average of `10000` liquidity units (`price * volume`) provided for half the epoch, and then `5000` for the second half of the epoch (as the price was out of the vAMM's configured range), and where the `market.liquidity.stakeToCcyVolume` value is `100`, will have an implied commitment of `75`. (0042-LIQF-111) + ### Explicit instantaneous liquidity scoring function When market is setup with [explicit instantaneous liquidity scoring function](./0091-ILSF-instantaneous_liquidity_scoring_funcion.md) as follows: diff --git a/protocol/0090-VAMM-automated_market_maker.md b/protocol/0090-VAMM-automated_market_maker.md index 56695fbff..24e4d00b0 100644 --- a/protocol/0090-VAMM-automated_market_maker.md +++ b/protocol/0090-VAMM-automated_market_maker.md @@ -239,8 +239,7 @@ Once these are retrieved, the price / volume points should be combined with a pr As the computation of this virtual order shape may be heavy when run across a large number of passive AMMs the number of AMMs updated per block should be throttled to a fixed maximum number, updating on a rolling frequency, or when updated/first created. -A given AMM's average liquidity score across the epoch should also be tracked, giving a time-weighted average at the end of each epoch (including `0` values for any time when the AMM either did not exist or was not providing liquidity on one side of the book). From this, a virtual stake amount can be calculated by dividing through by the `market.liquidity.stakeToCcyVolume` value and the AMM key' -s ELS updated as normal. +A given AMM's average liquidity score across the epoch should also be tracked, giving a time-weighted average at the end of each epoch (including `0` values for any time when the AMM either did not exist or was not providing liquidity on one side of the book). From this, a virtual stake amount can be calculated by dividing through by the `market.liquidity.stakeToCcyVolume` value and the AMM key's ELS updated as normal. ## Setting Fees @@ -327,8 +326,8 @@ At market settlement, an AMM's position will be settled alongside all others as - Quotes a price of `997.488` to sell `16.030` units - Does not quote a price to sell `17` units -- With an existing book consisting solely of one vAMM (at any fair price) a new vAMM entering the market at a differing base price to the existing vAMM's current price, but where upper and lower bounds of each are far beyond the base/fair prices, triggers a trade between the two vAMMs, after which they both have the same fair price and the book is not crossed. +- With an existing book consisting solely of one vAMM (at any fair price) a new vAMM entering the market at a differing base price to the existing vAMM's current price, but where upper and lower bounds of each are far beyond the base/fair prices, triggers a trade between the two vAMMs, after which they both have the same fair price and the book is not crossed. (0090-VAMM-033) -- With an existing book consisting solely of one vAMM (at any fair price) a new vAMM entering the market at a differing base price to the existing vAMM's current price, with upper and lower bounds set such that the entire structure is separate to the existing vAMM (e.g. the incoming vAMM's lower price is greater than the existing vAMM's upper price), a trade occurs between the two AMMs leaving at least one of them at the extreme edge of their quoting range. +- With an existing book consisting solely of one vAMM (at any fair price) a new vAMM entering the market at a differing base price to the existing vAMM's current price, with upper and lower bounds set such that the entire structure is separate to the existing vAMM (e.g. the incoming vAMM's lower price is greater than the existing vAMM's upper price), a trade occurs between the two AMMs leaving at least one of them at the extreme edge of their quoting range. (0090-VAMM-034) -- With two vAMMs existing on the market, and no other orders, both of which have the same fair price, another counterparty placing a large buy order for a given volume, followed by a large sell order for the same volume, results in the vAMMs both taking a position and then returning to `0` position, with a balance increase equal to the maker fees received plus those for the incoming trader crossing the spread. +- With two vAMMs existing on the market, and no other orders, both of which have the same fair price, another counterparty placing a large buy order for a given volume, followed by a large sell order for the same volume, results in the vAMMs both taking a position and then returning to `0` position, with a balance increase equal to the maker fees received plus those for the incoming trader crossing the spread. (0090-VAMM-035) diff --git a/protocol/features.json b/protocol/features.json index dac15d14d..9e969ce0d 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -659,7 +659,12 @@ "0014-NP-VAMM-003", "0014-NP-VAMM-004", "0015-NP-OBES-001", - "0015-NP-OBES-002" + "0015-NP-OBES-002", + "0042-LIQF-107", + "0042-LIQF-108", + "0042-LIQF-109", + "0042-LIQF-110", + "0042-LIQF-111" ] }, "Capped Futures": { From 65d68caa1d0ba944cc1193137bfe5f09f4c8263f Mon Sep 17 00:00:00 2001 From: wwestgarth Date: Tue, 28 May 2024 09:29:29 +0100 Subject: [PATCH 1126/1171] chore: add new AMM rebasing ACs to feature json --- protocol/features.json | 3 +++ 1 file changed, 3 insertions(+) diff --git a/protocol/features.json b/protocol/features.json index 9e969ce0d..17c40a61f 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -646,6 +646,9 @@ "0090-VAMM-030", "0090-VAMM-031", "0090-VAMM-032", + "0090-VAMM-033", + "0090-VAMM-034", + "0090-VAMM-035", "0057-TRAN-070", "0056-REWA-111", "0056-REWA-112", From 34d731fe822bd3edbf83d9ce0d11f387bd5feca9 Mon Sep 17 00:00:00 2001 From: Charlie Date: Tue, 14 May 2024 17:22:09 +0100 Subject: [PATCH 1127/1171] feat: proposers can cancel their own proposals --- protocol/0028-GOVE-governance.md | 31 ++++++++++++++++++++++++++++++- protocol/features.json | 9 +++++++++ 2 files changed, 39 insertions(+), 1 deletion(-) diff --git a/protocol/0028-GOVE-governance.md b/protocol/0028-GOVE-governance.md index 62e9f7923..375d5c9d8 100644 --- a/protocol/0028-GOVE-governance.md +++ b/protocol/0028-GOVE-governance.md @@ -120,7 +120,7 @@ Note that this is validation is in units of time from current time i.e. if the p at e.g. `09:00:00 on 1st Jan 2021` and `governance.proposal.asset.minEnact` is `72h` then the proposal must contain enactment date/time that after `09:00:00 on 4th Jan 2021`. If there is `governance.proposal.asset.maxEnact` of e.g. `360h` then the proposed enactment date / time must be before `09:00:00 on 16th Jan 2021`. -## Editing and/or cancelling a proposal is not possible +## Editing a proposal A proposal cannot be edited, once created. The only possible action is to vote for or against a proposal, or submit a new proposal. @@ -131,6 +131,27 @@ If a proposal is created and later a different outcome is preferred by network p Which of these makes most sense will depend on the type of change, the timing of the events, and how the rest of the community votes for the initial proposal. +## Cancelling a proposal + +A proposal can be cancelled under certain conditions by, and only by, the party which created the proposal. To avoid situations where the community may have acted upon proposals they "expected" to pass, a party can only cancel their proposal before a certain "cancellation threshold" is reached. + +This cancellation threshold is a fixed point before the proposal closing time. The duration of the period in which a proposal cannot be cancelled is defined by the network parameter `governance.proposalCancellationThreshold` (a duration string defaulting to `24h0m0s`). + +i.e. Given the `governance.proposalCancellationThreshold` is `24h0m0s` a party will be able to cancel their proposal 1 day before the proposal closing time. + +### Mechanics + +A party can cancel their proposal by simply voting against it with any vote value. + +- If the current time is before the cancellation threshold, the proposal is instantly rejected. +- If the current time is after the cancellation threshold, the vote is treated normally as a vote against a proposal. + +Note the following additional details: + +- a cancelling vote against a proposal must pass all typical vote checks and spam protections, i.e. who party who removes stake after creating a proposal and no longer meets the requirement will not be able to cancel their proposal. + +- if at the time of creating a proposal the closing time is within the period defined by `governance.proposalCancellationThreshold`. The proposal will still be valid and accepted by the network but the party will be not have a opportunity to cancel the proposal. + ## Outcome At the conclusion of the voting period the network will calculate two values: @@ -774,3 +795,11 @@ The voting to approve the batch happens, the batch passes, the value of the prop - A voter's equity-like share does not give them any additional voting weight when voting on a market community tags update proposal. (0028-GOVE-174) - A proposal to add community tags with any community tags longer than `governance.proposal.market.maxCommunityTagLength` is rejected as invalid (0028-GOVE-175) - A proposal to remove community tags with any community tags longer than `governance.proposal.market.maxCommunityTagLength` is rejected as invalid (0028-GOVE-176) + +#### Cancelling Proposals + +- Given a proposal with a closing time further than `governance.proposalCancellationThreshold` from the current time, if the party which created the proposal votes against it, the proposal will be instantaneously rejected (0028-GOVE-188) +- Given a proposal with a closing time less than `governance.proposalCancellationThreshold` from the current time, if the party which created the proposal votes against it, the not be instantaneously rejected At closing time, if the proposal meets the criteria to be accepted it will pass (0028-GOVE-189) +- Given a proposal with a closing time less than `governance.proposalCancellationThreshold` from the current time, if the party which created the proposal votes against it, the not be instantaneously rejected. At closing time, if the proposal does not meet the criteria to be accepted it will be rejected (0028-GOVE-190) + +- Given a proposal with a closing time further than `governance.proposalCancellationThreshold` from the current time, if the party which did not create the proposal votes against it, the proposal will not be instantaneously rejected (0028-GOVE-191) diff --git a/protocol/features.json b/protocol/features.json index 9e969ce0d..8c2433378 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -710,6 +710,15 @@ "0019-MCAL-159" ] }, + "Cancelling Proposals": { + "milestone": "colosseo_II", + "acs": [ + "0028-GOVE-188", + "0028-GOVE-189", + "0028-GOVE-190", + "0028-GOVE-191" + ] + }, "Unknown": { "milestone": "unknown", "acs": [] From d0142aaf8c2fe4328b2328a2702fee4894d440dd Mon Sep 17 00:00:00 2001 From: Charlie <99198652+cdummett@users.noreply.github.com> Date: Wed, 15 May 2024 11:47:30 +0100 Subject: [PATCH 1128/1171] chore: apply suggestions from review Co-authored-by: candida-d <62548908+candida-d@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 375d5c9d8..53b71075f 100644 --- a/protocol/0028-GOVE-governance.md +++ b/protocol/0028-GOVE-governance.md @@ -150,7 +150,7 @@ Note the following additional details: - a cancelling vote against a proposal must pass all typical vote checks and spam protections, i.e. who party who removes stake after creating a proposal and no longer meets the requirement will not be able to cancel their proposal. -- if at the time of creating a proposal the closing time is within the period defined by `governance.proposalCancellationThreshold`. The proposal will still be valid and accepted by the network but the party will be not have a opportunity to cancel the proposal. +- if at the time of creating a proposal the closing time is within the period defined by `governance.proposalCancellationThreshold`. The proposal will still be valid and accepted by the network but the party will not have an opportunity to cancel the proposal. ## Outcome From 88fb5c0ded952b03db3a069872cd36c8afeeb081 Mon Sep 17 00:00:00 2001 From: Charlie Date: Wed, 15 May 2024 11:50:00 +0100 Subject: [PATCH 1129/1171] fix: correct acceptance criteria typo --- 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 53b71075f..baa36d72b 100644 --- a/protocol/0028-GOVE-governance.md +++ b/protocol/0028-GOVE-governance.md @@ -799,7 +799,7 @@ The voting to approve the batch happens, the batch passes, the value of the prop #### Cancelling Proposals - Given a proposal with a closing time further than `governance.proposalCancellationThreshold` from the current time, if the party which created the proposal votes against it, the proposal will be instantaneously rejected (0028-GOVE-188) -- Given a proposal with a closing time less than `governance.proposalCancellationThreshold` from the current time, if the party which created the proposal votes against it, the not be instantaneously rejected At closing time, if the proposal meets the criteria to be accepted it will pass (0028-GOVE-189) -- Given a proposal with a closing time less than `governance.proposalCancellationThreshold` from the current time, if the party which created the proposal votes against it, the not be instantaneously rejected. At closing time, if the proposal does not meet the criteria to be accepted it will be rejected (0028-GOVE-190) +- Given a proposal with a closing time less than `governance.proposalCancellationThreshold` from the current time, if the party which created the proposal votes against it, the proposal will not be instantaneously rejected. At closing time, if the proposal meets the criteria to be accepted it will pass (0028-GOVE-189) +- Given a proposal with a closing time less than `governance.proposalCancellationThreshold` from the current time, if the party which created the proposal votes against it, the proposal will not be instantaneously rejected.. At closing time, if the proposal does not meet the criteria to be accepted it will be rejected (0028-GOVE-190) - Given a proposal with a closing time further than `governance.proposalCancellationThreshold` from the current time, if the party which did not create the proposal votes against it, the proposal will not be instantaneously rejected (0028-GOVE-191) From f86c06baffa49420236a08e336096e4729fd345a Mon Sep 17 00:00:00 2001 From: Charlie Date: Wed, 15 May 2024 11:50:27 +0100 Subject: [PATCH 1130/1171] fix: refactor network parameter --- protocol/0028-GOVE-governance.md | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/protocol/0028-GOVE-governance.md b/protocol/0028-GOVE-governance.md index baa36d72b..7d69e7e0c 100644 --- a/protocol/0028-GOVE-governance.md +++ b/protocol/0028-GOVE-governance.md @@ -135,9 +135,9 @@ Which of these makes most sense will depend on the type of change, the timing of A proposal can be cancelled under certain conditions by, and only by, the party which created the proposal. To avoid situations where the community may have acted upon proposals they "expected" to pass, a party can only cancel their proposal before a certain "cancellation threshold" is reached. -This cancellation threshold is a fixed point before the proposal closing time. The duration of the period in which a proposal cannot be cancelled is defined by the network parameter `governance.proposalCancellationThreshold` (a duration string defaulting to `24h0m0s`). +This cancellation threshold is a fixed point before the proposal closing time. The duration of the period in which a proposal cannot be cancelled is defined by the network parameter `governance.proposal.cancellationThreshold` (a duration string defaulting to `24h0m0s`). -i.e. Given the `governance.proposalCancellationThreshold` is `24h0m0s` a party will be able to cancel their proposal 1 day before the proposal closing time. +i.e. Given the `governance.proposal.cancellationThreshold` is `24h0m0s` a party will be able to cancel their proposal 1 day before the proposal closing time. ### Mechanics @@ -150,7 +150,7 @@ Note the following additional details: - a cancelling vote against a proposal must pass all typical vote checks and spam protections, i.e. who party who removes stake after creating a proposal and no longer meets the requirement will not be able to cancel their proposal. -- if at the time of creating a proposal the closing time is within the period defined by `governance.proposalCancellationThreshold`. The proposal will still be valid and accepted by the network but the party will not have an opportunity to cancel the proposal. +- if at the time of creating a proposal the closing time is within the period defined by `governance.proposal.cancellationThreshold`. The proposal will still be valid and accepted by the network but the party will not have an opportunity to cancel the proposal. ## Outcome @@ -798,8 +798,8 @@ The voting to approve the batch happens, the batch passes, the value of the prop #### Cancelling Proposals -- Given a proposal with a closing time further than `governance.proposalCancellationThreshold` from the current time, if the party which created the proposal votes against it, the proposal will be instantaneously rejected (0028-GOVE-188) -- Given a proposal with a closing time less than `governance.proposalCancellationThreshold` from the current time, if the party which created the proposal votes against it, the proposal will not be instantaneously rejected. At closing time, if the proposal meets the criteria to be accepted it will pass (0028-GOVE-189) -- Given a proposal with a closing time less than `governance.proposalCancellationThreshold` from the current time, if the party which created the proposal votes against it, the proposal will not be instantaneously rejected.. At closing time, if the proposal does not meet the criteria to be accepted it will be rejected (0028-GOVE-190) +- Given a proposal with a closing time further than `governance.proposal.cancellationThreshold` from the current time, if the party which created the proposal votes against it, the proposal will be instantaneously rejected (0028-GOVE-188) +- Given a proposal with a closing time less than `governance.proposal.cancellationThreshold` from the current time, if the party which created the proposal votes against it, the proposal will not be instantaneously rejected. At closing time, if the proposal meets the criteria to be accepted it will pass (0028-GOVE-189) +- Given a proposal with a closing time less than `governance.proposal.cancellationThreshold` from the current time, if the party which created the proposal votes against it, the proposal will not be instantaneously rejected.. At closing time, if the proposal does not meet the criteria to be accepted it will be rejected (0028-GOVE-190) -- Given a proposal with a closing time further than `governance.proposalCancellationThreshold` from the current time, if the party which did not create the proposal votes against it, the proposal will not be instantaneously rejected (0028-GOVE-191) +- Given a proposal with a closing time further than `governance.proposal.cancellationThreshold` from the current time, if the party which did not create the proposal votes against it, the proposal will not be instantaneously rejected (0028-GOVE-191) From 362313b1ae7ff1bbad4a6a1c110c4d113461357d Mon Sep 17 00:00:00 2001 From: Charlie Date: Wed, 15 May 2024 11:59:20 +0100 Subject: [PATCH 1131/1171] chore: apply review suggestions --- 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 7d69e7e0c..0fec8ae23 100644 --- a/protocol/0028-GOVE-governance.md +++ b/protocol/0028-GOVE-governance.md @@ -800,6 +800,6 @@ The voting to approve the batch happens, the batch passes, the value of the prop - Given a proposal with a closing time further than `governance.proposal.cancellationThreshold` from the current time, if the party which created the proposal votes against it, the proposal will be instantaneously rejected (0028-GOVE-188) - Given a proposal with a closing time less than `governance.proposal.cancellationThreshold` from the current time, if the party which created the proposal votes against it, the proposal will not be instantaneously rejected. At closing time, if the proposal meets the criteria to be accepted it will pass (0028-GOVE-189) -- Given a proposal with a closing time less than `governance.proposal.cancellationThreshold` from the current time, if the party which created the proposal votes against it, the proposal will not be instantaneously rejected.. At closing time, if the proposal does not meet the criteria to be accepted it will be rejected (0028-GOVE-190) +- Given a proposal with a closing time less than `governance.proposal.cancellationThreshold` from the current time, if the party which created the proposal votes against it, the proposal will not be instantaneously rejected. At closing time, if the proposal does not meet the criteria to be accepted it will be rejected (0028-GOVE-190) - Given a proposal with a closing time further than `governance.proposal.cancellationThreshold` from the current time, if the party which did not create the proposal votes against it, the proposal will not be instantaneously rejected (0028-GOVE-191) From c8b5e63636147c23ae00a9df63100aeee87a142f Mon Sep 17 00:00:00 2001 From: Charlie <99198652+cdummett@users.noreply.github.com> Date: Mon, 20 May 2024 12:11:03 +0100 Subject: [PATCH 1132/1171] chore: apply review feedback Co-authored-by: candida-d <62548908+candida-d@users.noreply.github.com> --- protocol/0028-GOVE-governance.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/protocol/0028-GOVE-governance.md b/protocol/0028-GOVE-governance.md index 0fec8ae23..00680467d 100644 --- a/protocol/0028-GOVE-governance.md +++ b/protocol/0028-GOVE-governance.md @@ -122,7 +122,7 @@ If there is `governance.proposal.asset.maxEnact` of e.g. `360h` then the propose ## Editing a proposal -A proposal cannot be edited, once created. The only possible action is to vote for or against a proposal, or submit a new proposal. +A proposal cannot be edited once submitted to the network. The only possible actions are to cancel within the threshold, vote for or against a proposal, or submit a new proposal. If a proposal is created and later a different outcome is preferred by network participants, two courses of action are possible: @@ -150,7 +150,7 @@ Note the following additional details: - a cancelling vote against a proposal must pass all typical vote checks and spam protections, i.e. who party who removes stake after creating a proposal and no longer meets the requirement will not be able to cancel their proposal. -- if at the time of creating a proposal the closing time is within the period defined by `governance.proposal.cancellationThreshold`. The proposal will still be valid and accepted by the network but the party will not have an opportunity to cancel the proposal. +- if at the time of creating a proposal the closing time is within the period defined by `governance.proposal.cancellationThreshold`, the proposal will still be valid and accepted by the network but the party will not have an opportunity to cancel the proposal. ## Outcome @@ -798,8 +798,8 @@ The voting to approve the batch happens, the batch passes, the value of the prop #### Cancelling Proposals -- Given a proposal with a closing time further than `governance.proposal.cancellationThreshold` from the current time, if the party which created the proposal votes against it, the proposal will be instantaneously rejected (0028-GOVE-188) -- Given a proposal with a closing time less than `governance.proposal.cancellationThreshold` from the current time, if the party which created the proposal votes against it, the proposal will not be instantaneously rejected. At closing time, if the proposal meets the criteria to be accepted it will pass (0028-GOVE-189) -- Given a proposal with a closing time less than `governance.proposal.cancellationThreshold` from the current time, if the party which created the proposal votes against it, the proposal will not be instantaneously rejected. At closing time, if the proposal does not meet the criteria to be accepted it will be rejected (0028-GOVE-190) +- Given a proposal with a closing time further than `governance.proposal.cancellationThreshold` from the current time, if the party that created the proposal votes against it, the proposal will be instantaneously rejected (0028-GOVE-188) +- Given a proposal with a closing time less than `governance.proposal.cancellationThreshold` from the current time, if the party that created the proposal votes against it, the proposal will not be instantaneously rejected. At closing time, if the proposal meets the criteria to be accepted it will pass (0028-GOVE-189) +- Given a proposal with a closing time less than `governance.proposal.cancellationThreshold` from the current time, if the party that created the proposal votes against it, the proposal will not be instantaneously rejected. At closing time, if the proposal does not meet the criteria to be accepted it will be rejected (0028-GOVE-190) -- Given a proposal with a closing time further than `governance.proposal.cancellationThreshold` from the current time, if the party which did not create the proposal votes against it, the proposal will not be instantaneously rejected (0028-GOVE-191) +- Given a proposal with a closing time further than `governance.proposal.cancellationThreshold` from the current time, if a party that did not create the proposal votes against it, the proposal will not be instantaneously rejected (0028-GOVE-191) From c827bf0137f23601d6ca4be9845d923e339e2736 Mon Sep 17 00:00:00 2001 From: Charlie <99198652+cdummett@users.noreply.github.com> Date: Mon, 20 May 2024 13:50:30 +0100 Subject: [PATCH 1133/1171] chore: apply suggestions from code review Co-authored-by: Tom --- 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 00680467d..3f5b59f92 100644 --- a/protocol/0028-GOVE-governance.md +++ b/protocol/0028-GOVE-governance.md @@ -137,7 +137,7 @@ A proposal can be cancelled under certain conditions by, and only by, the party This cancellation threshold is a fixed point before the proposal closing time. The duration of the period in which a proposal cannot be cancelled is defined by the network parameter `governance.proposal.cancellationThreshold` (a duration string defaulting to `24h0m0s`). -i.e. Given the `governance.proposal.cancellationThreshold` is `24h0m0s` a party will be able to cancel their proposal 1 day before the proposal closing time. +i.e. Given the `governance.proposal.cancellationThreshold` is `24h0m0s` a party will be able to cancel their proposal up until 1 day before the proposal closing time. ### Mechanics From 8bb2c5fa33458f0a8fec8133f91869f3dabb7505 Mon Sep 17 00:00:00 2001 From: Charlie Date: Wed, 29 May 2024 11:02:32 +0100 Subject: [PATCH 1134/1171] chore: address review feedback --- protocol/0028-GOVE-governance.md | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/protocol/0028-GOVE-governance.md b/protocol/0028-GOVE-governance.md index 3f5b59f92..c455c2c6f 100644 --- a/protocol/0028-GOVE-governance.md +++ b/protocol/0028-GOVE-governance.md @@ -135,13 +135,17 @@ Which of these makes most sense will depend on the type of change, the timing of A proposal can be cancelled under certain conditions by, and only by, the party which created the proposal. To avoid situations where the community may have acted upon proposals they "expected" to pass, a party can only cancel their proposal before a certain "cancellation threshold" is reached. -This cancellation threshold is a fixed point before the proposal closing time. The duration of the period in which a proposal cannot be cancelled is defined by the network parameter `governance.proposal.cancellationThreshold` (a duration string defaulting to `24h0m0s`). +This cancellation threshold is a fixed point before the proposal closing time. The duration of the period in which a proposal cannot be cancelled is defined by the network parameter `governance.proposal.cancellationThreshold` (a duration string defaulting to `23h0m0s`). +<<<<<<< Updated upstream i.e. Given the `governance.proposal.cancellationThreshold` is `24h0m0s` a party will be able to cancel their proposal up until 1 day before the proposal closing time. +======= +i.e. Given the `governance.proposal.cancellationThreshold` is `23h0m0s` a party will be able to cancel their proposal 23 hours before the proposal closing time. +>>>>>>> Stashed changes ### Mechanics -A party can cancel their proposal by simply voting against it with any vote value. +A party can cancel their proposal by simply voting against it with a no vote. - If the current time is before the cancellation threshold, the proposal is instantly rejected. - If the current time is after the cancellation threshold, the vote is treated normally as a vote against a proposal. From 2b1c081f3c992cba7b3354be82003d96506ab89d Mon Sep 17 00:00:00 2001 From: Charlie Date: Wed, 29 May 2024 11:12:31 +0100 Subject: [PATCH 1135/1171] fix: correct rebase conflicts --- protocol/0028-GOVE-governance.md | 4 ---- 1 file changed, 4 deletions(-) diff --git a/protocol/0028-GOVE-governance.md b/protocol/0028-GOVE-governance.md index c455c2c6f..bedf799e1 100644 --- a/protocol/0028-GOVE-governance.md +++ b/protocol/0028-GOVE-governance.md @@ -137,11 +137,7 @@ A proposal can be cancelled under certain conditions by, and only by, the party This cancellation threshold is a fixed point before the proposal closing time. The duration of the period in which a proposal cannot be cancelled is defined by the network parameter `governance.proposal.cancellationThreshold` (a duration string defaulting to `23h0m0s`). -<<<<<<< Updated upstream -i.e. Given the `governance.proposal.cancellationThreshold` is `24h0m0s` a party will be able to cancel their proposal up until 1 day before the proposal closing time. -======= i.e. Given the `governance.proposal.cancellationThreshold` is `23h0m0s` a party will be able to cancel their proposal 23 hours before the proposal closing time. ->>>>>>> Stashed changes ### Mechanics From 83f15968556a1fef7f94b9870235ca1789f6a038 Mon Sep 17 00:00:00 2001 From: Charlie Date: Thu, 23 May 2024 12:13:24 +0100 Subject: [PATCH 1136/1171] feat: add AMM vesting bonus mechanics --- protocol/0056-REWA-rewards_overview.md | 5 ++- protocol/0085-RVST-rewards_vesting.md | 47 ++++++++++++++++++++++++++ protocol/features.json | 18 +++++++--- 3 files changed, 63 insertions(+), 7 deletions(-) diff --git a/protocol/0056-REWA-rewards_overview.md b/protocol/0056-REWA-rewards_overview.md index 4030222db..a775889e4 100644 --- a/protocol/0056-REWA-rewards_overview.md +++ b/protocol/0056-REWA-rewards_overview.md @@ -239,7 +239,7 @@ The entire reward account balance is paid out every epoch unless the total value 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). -Any rewards which would be distributed to an AMM sub-key should instead be sent to the parent key's corresponding account. These transfers should be labelled with a field `from_key` which specifies the sub-key as the original recipient. This field should be blank for rewards earned by a standard key. +Any rewards earned by an AMM sub-key should be sent as normal to the relevant vesting account for that sub-key. The party owning the sub-key will be able to withdraw any vested rewards using a regular one-off transfer specifying a `from` key (as per the mechanics detailed [here](./0057-TRAN-transfers.md)), or alternatively leave the reward in the vesting / vested accounts to receive a multiplier on any future rewards (as per the mechanics detailed [here])(./0085-RVST-rewards_vesting.md#clarification-for-amm-sub-accounts). ### Distributing rewards amongst entities @@ -1141,5 +1141,4 @@ At the end of epoch 2, 10000 VEGA rewards should be distributed to the `ETHUSDT` ## vAMMs -- If an AMM sub-key earns rewards which would be transferred to it's vesting account, these rewards are instead transferred to the parent key's vesting account with a `from_key` field specifying the sub-key (0056-REWA-168). -- If an AMM sub-key earns rewards which would be transferred to it's locked account, these rewards are instead transferred to the parent key's locked account with a `from_key` field specifying the sub-key (0056-REWA-169). +- If an AMM sub-key earns rewards, they are transferred into the sub-keys vesting account and locked for the appropriate period before vesting (0056-REWA-170). diff --git a/protocol/0085-RVST-rewards_vesting.md b/protocol/0085-RVST-rewards_vesting.md index 6c4938b58..858caf2ec 100644 --- a/protocol/0085-RVST-rewards_vesting.md +++ b/protocol/0085-RVST-rewards_vesting.md @@ -39,6 +39,30 @@ Alternatively, they can leave their rewards in the vested account to increase th Note, a party will be unable to transfer funds in to the vested account. +### Clarification for AMM sub accounts + +For a party which has created one or more AMMs, any rewards earned by those AMMs will be paid into the relevant vesting account of the sub-key associated with that AMM (and then vested over time into the sub-keys vested account). When calculating the rewards balance used to set the multiplier in this case, the balance of each of a parties sub-keys vesting and vested accounts should be aggregated, and the resulting rewards multiplier set for all sub-keys. + +For example: + +```pseudo +- A party has accumulated the following rewards + - locked_quantum_amount = 20 + - vesting_quantum_amount = 30 + - vested_quantum_amount = 150 + +- And has created an AMM which has accumulated the following rewards + - locked_quantum_amount = 200 + - vesting_quantum_amount = 300 + - vested_quantum_amount = 1500 + +Their total reward balance should be (20+30+50) + (200+300+500) = (100) + (1000) = 1100 +``` + +A party will be able to rewards earned by an AMM sub-key by submitting a transfer transaction signed with their primary key. This transfer must be from the sub-keys vested account and to the primary keys general account. As with the mechanics for redeeming rewards normally from a primary key's general account, these transfers will not incur any fees and if transferring the full balance will not be subject to the minimum quantum transfer amount requirement. + +Note, as with normal redemptions, once the rewards are transferred from the sub-keys vested account, the funds will no longer contribute to the total reward balance. + ### Determining the rewards bonus multiplier 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. @@ -105,3 +129,26 @@ Must expose the following: 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) + +### Contributions from AMM sub-keys + +- Given a party with multiple AMM subkeys, each of the subkeys locked rewards should contribute to the parties total quantum balance. (0085-RVST-015) +- Given a party with multiple AMM subkeys, each of the subkeys vesting rewards should contribute to the parties total quantum balance. (0085-RVST-016) +- Given a party with multiple AMM subkeys, each of the subkeys vested rewards should contribute to the parties total quantum balance. (0085-RVST-017) +- Given a party with multiple AMM subkeys, redeemed rewards should not contribute to the parties total quantum balance. (0085-RVST-018) +- Given a party with multiple AMM subkeys each earning rewards in assets using different quantums, contributions from each subkey should be scaled correctly by the assets quantum. (0085-RVST-019) + +- Given a party with multiple AMM subkeys, the parties `reward_distribution_bonus_multiplier` should be set equal to the value in the highest tier where they fulfil the `minimum_quantum_balance` required. This multiplier must also be given to each of the parties subkeys and applied for future rewards. (0085-RVST-020) + +### Redemptions from AMM sub-keys + +- A party attempting to transfer funds from an AMM sub-key's vested account will be rejected if the party does not own the sub-key. (0085-RVST-021) +- A party attempting to transfer funds from an AMM sub-key's vested account will be accepted if the party owns the sub-key. (0085-RVST-022) + +- Given a party owns the relevant sub-key, attempting to transfer funds into the sub-key's vesting account will be rejected. (0085-RVST-023) +- Given a party owns the relevant sub-key, attempting to transfer funds into the sub-key's vested account will be rejected. (0085-RVST-024) +- Given a party owns the relevant sub-key, attempting to transfer funds from the sub-key's vested account to any account other than the parties general account will be rejected. (0085-RVST-025) + +- Given a non-zero transfer fee factor, a party redeeming funds from an appropriate sub-key's vested account will incur no fees. (0085-RVST-026) +- A party redeeming funds will not be subject to the minimum transfer requirement if transferring the full balance. The transfer should be accepted. (0085-RVST-027) +- A party redeeming funds will be subject to the minimum transfer requirement if transferring less than the full balance. The transfer should be rejected. (0085-RVST-028) diff --git a/protocol/features.json b/protocol/features.json index 8c2433378..bea8a8618 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -476,8 +476,8 @@ "0004-AMND-038", "0004-AMND-039", "0004-AMND-040", - "0004-AMND-041", "0004-AMND-042", + "0004-AMND-041", "0004-AMND-043", "0004-AMND-044", "0004-AMND-045", @@ -647,8 +647,6 @@ "0090-VAMM-031", "0090-VAMM-032", "0057-TRAN-070", - "0056-REWA-111", - "0056-REWA-112", "0026-AUCT-033", "0026-AUCT-034", "0026-AUCT-035", @@ -664,7 +662,19 @@ "0042-LIQF-108", "0042-LIQF-109", "0042-LIQF-110", - "0042-LIQF-111" + "0042-LIQF-111", + "0056-REWA-170", + "0085-RVST-015", + "0085-RVST-016", + "0085-RVST-017", + "0085-RVST-018", + "0085-RVST-019", + "0085-RVST-020", + "0085-RVST-021", + "0085-RVST-022", + "0085-RVST-023", + "0085-RVST-024", + "0085-RVST-025" ] }, "Capped Futures": { From f6de366a68c43ae8bf20d53739b26918f9854a4d Mon Sep 17 00:00:00 2001 From: Charlie <99198652+cdummett@users.noreply.github.com> Date: Wed, 29 May 2024 10:45:08 +0100 Subject: [PATCH 1137/1171] chore: apply suggestions from code review Co-authored-by: Tom --- protocol/0085-RVST-rewards_vesting.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0085-RVST-rewards_vesting.md b/protocol/0085-RVST-rewards_vesting.md index 858caf2ec..e0daf9de6 100644 --- a/protocol/0085-RVST-rewards_vesting.md +++ b/protocol/0085-RVST-rewards_vesting.md @@ -59,7 +59,7 @@ For example: Their total reward balance should be (20+30+50) + (200+300+500) = (100) + (1000) = 1100 ``` -A party will be able to rewards earned by an AMM sub-key by submitting a transfer transaction signed with their primary key. This transfer must be from the sub-keys vested account and to the primary keys general account. As with the mechanics for redeeming rewards normally from a primary key's general account, these transfers will not incur any fees and if transferring the full balance will not be subject to the minimum quantum transfer amount requirement. +A party will be able to redeem rewards earned by an AMM sub-key by submitting a transfer transaction signed with their primary key. This transfer must be from the sub-keys vested account and to the primary keys general account. As with the mechanics for redeeming rewards normally from a primary key's general account, these transfers will not incur any fees and if transferring the full balance will not be subject to the minimum quantum transfer amount requirement. Note, as with normal redemptions, once the rewards are transferred from the sub-keys vested account, the funds will no longer contribute to the total reward balance. From 2d35692c25c3b38b0820ab8524e88983e6cb8f4b Mon Sep 17 00:00:00 2001 From: Charlie Date: Wed, 29 May 2024 10:46:07 +0100 Subject: [PATCH 1138/1171] chore: address feedback from code review --- protocol/0085-RVST-rewards_vesting.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/protocol/0085-RVST-rewards_vesting.md b/protocol/0085-RVST-rewards_vesting.md index e0daf9de6..907206291 100644 --- a/protocol/0085-RVST-rewards_vesting.md +++ b/protocol/0085-RVST-rewards_vesting.md @@ -54,7 +54,7 @@ For example: - And has created an AMM which has accumulated the following rewards - locked_quantum_amount = 200 - vesting_quantum_amount = 300 - - vested_quantum_amount = 1500 + - vested_quantum_amount = 500 Their total reward balance should be (20+30+50) + (200+300+500) = (100) + (1000) = 1100 ``` @@ -150,5 +150,5 @@ Must expose the following: - Given a party owns the relevant sub-key, attempting to transfer funds from the sub-key's vested account to any account other than the parties general account will be rejected. (0085-RVST-025) - Given a non-zero transfer fee factor, a party redeeming funds from an appropriate sub-key's vested account will incur no fees. (0085-RVST-026) -- A party redeeming funds will not be subject to the minimum transfer requirement if transferring the full balance. The transfer should be accepted. (0085-RVST-027) -- A party redeeming funds will be subject to the minimum transfer requirement if transferring less than the full balance. The transfer should be rejected. (0085-RVST-028) +- A party redeeming funds from a sub-key's vested account will not be subject to the minimum transfer requirement if transferring the full balance. The transfer should be accepted. (0085-RVST-027) +- A party redeeming funds from a sub-key's vested account will be subject to the minimum transfer requirement if transferring less than the full balance. The transfer should be rejected. (0085-RVST-028) From 0353a24ba81a5273dc995a0fa60da1592a606b3a Mon Sep 17 00:00:00 2001 From: Charlie Date: Wed, 29 May 2024 10:50:34 +0100 Subject: [PATCH 1139/1171] fix: corrections for checks --- protocol/0085-RVST-rewards_vesting.md | 16 ++++++++-------- protocol/features.json | 4 +--- 2 files changed, 9 insertions(+), 11 deletions(-) diff --git a/protocol/0085-RVST-rewards_vesting.md b/protocol/0085-RVST-rewards_vesting.md index 907206291..c91f37e29 100644 --- a/protocol/0085-RVST-rewards_vesting.md +++ b/protocol/0085-RVST-rewards_vesting.md @@ -61,7 +61,7 @@ Their total reward balance should be (20+30+50) + (200+300+500) = (100) + (1000) A party will be able to redeem rewards earned by an AMM sub-key by submitting a transfer transaction signed with their primary key. This transfer must be from the sub-keys vested account and to the primary keys general account. As with the mechanics for redeeming rewards normally from a primary key's general account, these transfers will not incur any fees and if transferring the full balance will not be subject to the minimum quantum transfer amount requirement. -Note, as with normal redemptions, once the rewards are transferred from the sub-keys vested account, the funds will no longer contribute to the total reward balance. +Note, as with redeeming rewards from primary vesting accounts, once the rewards are transferred from the sub-keys vested account, the funds will no longer contribute to the total reward balance. ### Determining the rewards bonus multiplier @@ -132,15 +132,15 @@ Must expose the following: ### Contributions from AMM sub-keys -- Given a party with multiple AMM subkeys, each of the subkeys locked rewards should contribute to the parties total quantum balance. (0085-RVST-015) -- Given a party with multiple AMM subkeys, each of the subkeys vesting rewards should contribute to the parties total quantum balance. (0085-RVST-016) -- Given a party with multiple AMM subkeys, each of the subkeys vested rewards should contribute to the parties total quantum balance. (0085-RVST-017) -- Given a party with multiple AMM subkeys, redeemed rewards should not contribute to the parties total quantum balance. (0085-RVST-018) -- Given a party with multiple AMM subkeys each earning rewards in assets using different quantums, contributions from each subkey should be scaled correctly by the assets quantum. (0085-RVST-019) +- Given a party with multiple AMM sub-keys, each of the sub-keys locked rewards should contribute to the parties total quantum balance. (0085-RVST-015) +- Given a party with multiple AMM sub-keys, each of the sub-keys vesting rewards should contribute to the parties total quantum balance. (0085-RVST-016) +- Given a party with multiple AMM sub-keys, each of the sub-keys vested rewards should contribute to the parties total quantum balance. (0085-RVST-017) +- Given a party with multiple AMM sub-keys, redeemed rewards should not contribute to the parties total quantum balance. (0085-RVST-018) +- Given a party with multiple AMM sub-keys each earning rewards in assets using different quantum values, contributions from each sub-key should be scaled correctly by the assets quantum. (0085-RVST-019) -- Given a party with multiple AMM subkeys, the parties `reward_distribution_bonus_multiplier` should be set equal to the value in the highest tier where they fulfil the `minimum_quantum_balance` required. This multiplier must also be given to each of the parties subkeys and applied for future rewards. (0085-RVST-020) +- Given a party with multiple AMM sub-keys, the parties `reward_distribution_bonus_multiplier` should be set equal to the value in the highest tier where they fulfil the `minimum_quantum_balance` required. This multiplier must also be given to each of the parties sub-keys and applied for future rewards. (0085-RVST-020) -### Redemptions from AMM sub-keys +### Redeeming rewards from AMM sub-keys - A party attempting to transfer funds from an AMM sub-key's vested account will be rejected if the party does not own the sub-key. (0085-RVST-021) - A party attempting to transfer funds from an AMM sub-key's vested account will be accepted if the party owns the sub-key. (0085-RVST-022) diff --git a/protocol/features.json b/protocol/features.json index bea8a8618..5ec4b891e 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -353,9 +353,7 @@ "0056-REWA-164", "0056-REWA-165", "0056-REWA-166", - "0056-REWA-167", - "0056-REWA-168", - "0056-REWA-169" + "0056-REWA-167" ] }, "Spot stretch": { From ccc29029ee7850fb5f9ef43bb9aa58b53505817b Mon Sep 17 00:00:00 2001 From: Charlie Date: Wed, 29 May 2024 21:14:09 +0100 Subject: [PATCH 1140/1171] chore: fix broken link --- 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 a775889e4..5ef2b5b8b 100644 --- a/protocol/0056-REWA-rewards_overview.md +++ b/protocol/0056-REWA-rewards_overview.md @@ -239,7 +239,7 @@ The entire reward account balance is paid out every epoch unless the total value 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). -Any rewards earned by an AMM sub-key should be sent as normal to the relevant vesting account for that sub-key. The party owning the sub-key will be able to withdraw any vested rewards using a regular one-off transfer specifying a `from` key (as per the mechanics detailed [here](./0057-TRAN-transfers.md)), or alternatively leave the reward in the vesting / vested accounts to receive a multiplier on any future rewards (as per the mechanics detailed [here])(./0085-RVST-rewards_vesting.md#clarification-for-amm-sub-accounts). +Any rewards earned by an AMM sub-key should be sent as normal to the relevant vesting account for that sub-key. The party owning the sub-key will be able to withdraw any vested rewards using a regular one-off transfer specifying a `from` key (as per the mechanics detailed [here](./0057-TRAN-transfers.md)), or alternatively leave the reward in the vesting / vested accounts to receive a multiplier on any future rewards (as per the mechanics detailed [here](./0085-RVST-rewards_vesting.md#clarification-for-amm-sub-accounts). ### Distributing rewards amongst entities From e3307b7ee5d0e648382fde16cf4df79d0faf3ee2 Mon Sep 17 00:00:00 2001 From: Charlie Date: Fri, 31 May 2024 09:49:17 +0100 Subject: [PATCH 1141/1171] fix: volatility metric is reciprocal of variance --- protocol/0056-REWA-rewards_overview.md | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/protocol/0056-REWA-rewards_overview.md b/protocol/0056-REWA-rewards_overview.md index 4030222db..0f73d6a3b 100644 --- a/protocol/0056-REWA-rewards_overview.md +++ b/protocol/0056-REWA-rewards_overview.md @@ -130,13 +130,15 @@ Note, as a position can not be created on a Spot market. Trading activity on a S 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 variance 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, call this variance $\sigma^2$. Given the set: $$R = \{r_i \mid i = 1, 2, \ldots, N\}$$ -The reward metric $m_{rv}$ is the variance of the set $R$. +The reward metric $m_{rv}$ is the reciprocal of the variance of the set $R$. + +$$m_{rv} = \frac{1}{\sigma^2}$$ Note, as a position can not be created on a Spot market. Trading activity on a Spot market will not contribute to this reward metric. @@ -1039,8 +1041,8 @@ At the end of epoch 2, 10000 VEGA rewards should be distributed to the `ETHUSDT` ### 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 return volatility 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, their returns volatility reward metric should equal the reciprocal of 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 return volatility reward metric should be the reciprocal of the variance of their relative returns in each market (0056-REWA-090). ### Realised returns From b305824b3265523725b66c0e3d49585e5805436e Mon Sep 17 00:00:00 2001 From: Witold Date: Fri, 24 May 2024 13:16:57 +0200 Subject: [PATCH 1142/1171] refactor: clarify AC --- protocol/0019-MCAL-margin_calculator.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0019-MCAL-margin_calculator.md b/protocol/0019-MCAL-margin_calculator.md index b25710485..148170e37 100644 --- a/protocol/0019-MCAL-margin_calculator.md +++ b/protocol/0019-MCAL-margin_calculator.md @@ -439,7 +439,7 @@ Assume a [capped future](./0093-CFUT-product_builtin_capped_future.md) market wi ## Acceptance Criteria (Hardcoded risk factors) -- When a wrapped model with hardcoded risk factors is used then margin calculations depend entire on the hardcoded values and updating the nested risk model has no effect on margins (0019-MCAL-159) +- When a risk model with hardcoded risk factors is used on a regular (NOT fully-collateralised) market then margin calculations depend entirely on the hardcoded values and updating other risk model parameters has no effect on margins (0019-MCAL-159) ## Summary From af0823c049d82a89a1753a49392ddc4bd467331a Mon Sep 17 00:00:00 2001 From: Witold Date: Fri, 24 May 2024 13:27:35 +0200 Subject: [PATCH 1143/1171] refactor: add fully-collateralised bit to position estimate --- non-protocol-specs/0013-NP-POSE-position-estimate.md | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/non-protocol-specs/0013-NP-POSE-position-estimate.md b/non-protocol-specs/0013-NP-POSE-position-estimate.md index 22bb45fe1..0335fa7dd 100644 --- a/non-protocol-specs/0013-NP-POSE-position-estimate.md +++ b/non-protocol-specs/0013-NP-POSE-position-estimate.md @@ -46,6 +46,10 @@ The position estimate request has an additional `include_collateral_increase_in_ The endpoint request contains additional optional argument `scale_liquidation_price_to_market_decimals`. When set to `false` the liquidation price estimates are scaled to asset decimal places, when set to `true` these estimates are scaled to market decimal places. +### Price cap + +When a price cap is specified it should be assumed that the estimate is to be provided for a [capped futures](./../protocol/0016-PFUT-product_builtin_future.md#1-product-parameters) market. The liquidation price estimate should not be returned in that case and margin levels as well collateral increase estimate should be as per fully-collateralised margin [spec](./../protocol/0019-MCAL-margin_calculator.md#fully-collateralised). + ## Acceptance criteria 1. In isolated margin mode the request with `0` open volume and one or more limit orders specified results in a non-zero order margin in the margin level estimate and margin mode correctly representing isolated margin mode. (0013-NP-POSE-001) From 2e4e8f89489a11d1833bdda5ebb88841c1c97b4b Mon Sep 17 00:00:00 2001 From: Witold Date: Tue, 4 Jun 2024 17:03:27 +0200 Subject: [PATCH 1144/1171] refactor: addresss review comment --- non-protocol-specs/0013-NP-POSE-position-estimate.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/non-protocol-specs/0013-NP-POSE-position-estimate.md b/non-protocol-specs/0013-NP-POSE-position-estimate.md index 0335fa7dd..28af3027d 100644 --- a/non-protocol-specs/0013-NP-POSE-position-estimate.md +++ b/non-protocol-specs/0013-NP-POSE-position-estimate.md @@ -48,7 +48,7 @@ The endpoint request contains additional optional argument `scale_liquidation_pr ### Price cap -When a price cap is specified it should be assumed that the estimate is to be provided for a [capped futures](./../protocol/0016-PFUT-product_builtin_future.md#1-product-parameters) market. The liquidation price estimate should not be returned in that case and margin levels as well collateral increase estimate should be as per fully-collateralised margin [spec](./../protocol/0019-MCAL-margin_calculator.md#fully-collateralised). +When a price cap is specified it should be assumed that the estimate is to be provided for a [capped futures](./../protocol/0016-PFUT-product_builtin_future.md#1-product-parameters) market. Margin levels as well collateral increase estimate should be as per fully-collateralised margin [spec](./../protocol/0019-MCAL-margin_calculator.md#fully-collateralised). If in addition to a price cap the `fully_collateralised` flag is set to `true` then the liquidation price estimate should be `nil`. ## Acceptance criteria From 15d613ee1af79962f95c95a33f37d8536c926365 Mon Sep 17 00:00:00 2001 From: Tom Date: Wed, 5 Jun 2024 17:06:43 +0100 Subject: [PATCH 1145/1171] feat: Spot AMM specification (#2257) * feat: Spot AMM specification --- protocol/0090-VAMM-automated_market_maker.md | 14 +- .../0092-SAMM-spot_automated_market_maker.md | 226 ++++++++++++++++++ protocol/features.json | 16 +- 3 files changed, 248 insertions(+), 8 deletions(-) create mode 100644 protocol/0092-SAMM-spot_automated_market_maker.md diff --git a/protocol/0090-VAMM-automated_market_maker.md b/protocol/0090-VAMM-automated_market_maker.md index 24e4d00b0..b6d51f8f8 100644 --- a/protocol/0090-VAMM-automated_market_maker.md +++ b/protocol/0090-VAMM-automated_market_maker.md @@ -6,7 +6,7 @@ The automated market maker (AMM) framework is designed to allow for the provisio An automated market maker is configured at a per-key level, and is enabled by submitting a transaction with the requisite parameters. At this point in time the protocol will move committed funds to a sub-account which will be used to manage margin for the AMM. Once enabled, the configuration will be added to the pool of available AMMs to be utilised by the matching engine. -Each party may have only one AMM configuration per market. +Each party may have only one AMM configuration per market, and both Spot and Futures markets are eligible, with the behaviour differing slightly for each. ## Process Overview @@ -28,7 +28,8 @@ The configuration and resultant lifecycle of an automated market maker is as fol Each main Vega key will have one associated sub account for a given market, on which an AMM may be set up. The account key should be generated through a hash of the main account key plus the ID of the market to generate a valid Vega address in a predictable manner. Outside of the AMM framework the sub-accounts are treated identically to any other account, they will have the standard associated margin/general accounts and be able to place orders if required as with any other account. The key differentiator is that no external party will have the private key to control these accounts directly. The maintenance of such an account will be performed through a few actions: - Creation: A sub-account will be funded when a user configures an AMM strategy with a set of criteria and a commitment amount. At this point in time the commitment amount will be transferred to the sub-account's general account and the AMM strategy will commence -- Cancellation: When the vAMM is cancelled the strategy specified will be followed. Either any positions associated with the vAMM will be abandoned and given up to the network liquidation engine to close out, along with any associated required collateral, or the vAMM will be set into a mode in which it can only reduce position over time. +- Cancellation: When the vAMM is cancelled the strategy specified will be followed: + - For futures, either any positions associated with the vAMM will be abandoned and given up to the network liquidation engine to close out, along with any associated required collateral, or the vAMM will be set into a mode in which it can only reduce position over time. - Amendment: Updates the strategy or commitment for a sub-account ## Interface @@ -58,7 +59,7 @@ Initially there will only be one option for AMM behaviour, that of a constant-fu } ``` -### Concentrated Liquidity +### Concentrated Liquidity - Futures The `Concentrated Liquidity` AMM is a market maker utilising a Uniswap v3-style pricing curve for managing price based upon current market price. This allows for the market maker to automatically provide a pricing curve for any prices within some configurable range, alongside offering the capability to control risk by only trading within certain price bounds and out to known position limits. @@ -80,6 +81,8 @@ Additionally, as all commitments require some processing overhead on the core, t #### Creation +##### Futures + A `Concentrated Liquidity` AMM has an inherent linkage between position and implied price. By configuration, this position is `0` at `base price` but non-zero above and below that (assuming both an upper and lower bound have been provided), however it is possible to configure an AMM such that this `base price` is far from the market's current `mark price`. In order to bring the vAMM in line with where it "should" be the vAMM will determine whether the order book is currently able to synchronise the vAMM and reject the transaction if not 1. If the AMM's `base price` is between the current `best bid` and `best ask` on the market (including other active vAMMs) it is marked as created and enters normal quoting with no trade necessary. @@ -100,13 +103,16 @@ A `Concentrated Liquidity` AMM has an inherent linkage between position and impl #### Amendment +##### Futures + A similar process is followed in the case of amendments. Changes to the `upper`, `lower` or `base` price, or the `commitment amount` will affect the position implied at a certain price, meaning that the market maker may need to enter an aggressive trade to synchronise. In general, the behaviour above will be followed. As the vAMM may be currently holding a position, the existing position should be compared to that required at both sides (best bid/ask) of the order book to determine whether buying or selling is necessary. If the current position is between that required at best bid and best ask the amendment succeeds without requiring a trade. If reducing the `commitment amount` then only funds contained within the AMMs `general` account are eligible for removal. If the deduction is less than the `general` account's balance then the reduced funds will be removed immediately and the AMM will enter `single-sided` mode as specified above to reduce the position. If a deduction of greater than the `general` account is requested then the transaction is rejected and no changes are made. - #### Cancellation +##### Futures + In addition to amending to reduce the size a user may also cancel their AMM entirely. In order to do this they must submit a transaction containing only a field `Reduction Strategy` which can take two values: - `Abandon Position`: In this case, any existing position the AMM holds is given up to the network to close as a liquidation. This is performed in two steps: diff --git a/protocol/0092-SAMM-spot_automated_market_maker.md b/protocol/0092-SAMM-spot_automated_market_maker.md new file mode 100644 index 000000000..e98156967 --- /dev/null +++ b/protocol/0092-SAMM-spot_automated_market_maker.md @@ -0,0 +1,226 @@ +# Spot Automated Market Maker Framework + +## Summary + +The automated market maker (AMM) framework is designed to allow for the provision of an on-chain market making methodology which automatically provides prices according to a simple set of rules based on current market data. These rulesets are not created with the expectation of providing any profit nor of remaining solvent under any specific conditions, and so should be limited to conceptually simple setups. The initial methodology follows a concentrated-liquidity style constant-function market setup, with configurable maximum and minimum price bounds. + +An automated market maker is configured at a per-key level, and is enabled by submitting a transaction with the requisite parameters. At this point in time the protocol will move committed funds to a sub-account which will be used to manage margin for the AMM. Once enabled, the configuration will be added to the pool of available AMMs to be utilised by the matching engine. + +Each party may have only one AMM configuration per market, and both Spot and Futures markets are eligible, with the behaviour differing slightly for each. + +## Process Overview + +The configuration and resultant lifecycle of an automated market maker is as follows: + +- Party funds a key which will be used by the strategy with desired token amounts. +- Party submits a transaction containing configuration for the strategy on a given market. This will contain: + - Amount of base token to commit OR Amount of quote token to commit + - Price bounds (upper, lower) +- Once accepted, the network will transfer funds to a sub-account and use the other parameters for maintaining the position. +- The party can cancel the AMM at any time, with the spot balances immediately returned to their general accounts. + +## Sub-Account Configuration + +Each main Vega key will have one associated sub account for a given market, on which an AMM may be set up. The account key should be generated through a hash of the main account key plus the ID of the market to generate a valid Vega address in a predictable manner. Outside of the AMM framework the sub-accounts are treated identically to any other account, they will have the standard associated margin/general accounts and be able to place orders if required as with any other account. The key differentiator is that no external party will have the private key to control these accounts directly. The maintenance of such an account will be performed through a few actions: + +- Creation: A sub-account will be funded when a user configures an AMM strategy with a set of criteria and a commitment amount. At this point in time the commitment amount will be transferred to the sub-account's general account and the AMM strategy will commence +- Cancellation: When the AMM is cancelled, balances are immediately returned to the user. +- Amendment: Updates the strategy or commitment for a sub-account + +## Interface + +All AMM configurations should implement two key interfaces: + +- One taking simply the current state (`position` and `total funds`) and a trade (`volume`, `side`) and returning a quote price. This should also handle a trade of `volume = 0` to return a notional `fair price` (for a spot AMM this being the ratio of virtual balances of the two tokens.) +- The second taking (`position`, `total funds`, `side`, `start price`, `end price`) should return the full volume the AMM would trade between the two prices (inclusive). + +## AMM Configurations + +Initially there will only be one option for AMM behaviour, that of a constant-function curve, however there may be others available in future. As such, the parameters pertaining to this model in particular should be passed in their own structure such that the creation message is similar to: + +```json +{ + base_commitment, + quote_commitment, + reference_price, + market, + slippage_tolerance_percentage, + proposed_fee, + concentrated_liquidity_params: { + upper_price, + lower_price, + } +} +``` + +### Concentrated Liquidity - Spot + +The `Concentrated Liquidity` AMM is a market maker utilising a Uniswap v3-style pricing curve for managing price based upon current market price. This allows for the market maker to automatically provide a pricing curve for any prices within some configurable range. + +The concentrated liquidity market maker consists of a liquidity curve of prices specified by a given `upper price` at which the market maker will be fully in the `quote` currency and a `lower price` at which the market maker will be fully in the `base` currency. This is configured through a number of parameters: + +- **Upper Price**: The maximum price bound for market making. Prices between the `lower price` and this price will have volume placed, with no orders above this price. At this price the AMM will be fully in the `quote` currency. +- **Lower Price**: The minimum price bound for market making. Prices between the `upper price` and this price will have volume placed, with no orders below this price. At this price the AMM will be fully in the `base` currency. +- **Reference Price**: The price at which the specified commitment amount is the account's balance of that token (e.g. if this is the current market price, the commitment amount specified is exactly what will be taken). Note that by design if this price is above the `upper price` a non-zero base commitment specification is invalid, as is a non-zero quote commitment specification if this is below the `lower price`. +- One of: + - **Commitment Base**: This is the initial volume of base token to transfer into the sub account for use in market making. If this amount is not currently available in the main account's general account the transaction will fail. If specified, the amount of quote token to transfer is implied from current market conditions. + - **Commitment Quote**: This is the initial volume of quote token to transfer into the sub account for use in market making. If this amount is not currently available in the main account's general account the transaction will fail. If specified, the amount of base token to transfer is implied from current market conditions. + +Additionally, as all commitments require some processing overhead on the core, there should be a network parameter `market.amm.minCommitmentQuantum` which defines a minimum quantum for commitment. Any `create` or `amend` transaction where `quote commitment / quote asset quantum + base commitment / base asset quantum < market.amm.minCommitmentQuantum` should be rejected. + +### Creation/Amendment Process + +#### Creation + +A `Concentrated Liquidity` AMM has an inherent linkage between position and implied price. By configuration, this position is fully in the quote asset at `upper price` and moves towards being fully in the base asset at `lower price`, however it is possible to configure an AMM such that this range is either covering, above or below the current market price. In order to bring the AMM in line with where it "should" be the AMM will take either the amount of base or quote asset desired and then imply the volume of the other at the current market price. The protocol will then attempt to take both amounts of assets from the user. + + 1. A `market effective price` will be determined: + 1. If there is currently a `best bid` and `best ask` (including existing AMMs) and the market is in continuous trading then the mid price will be used. + 2. If there is only a bid or only an ask, and the market is in continuous trading, then that best bid or ask will be used. + 3. If the market is in auction the mark price will be used, or if that is unavailable then the indicative uncrossing price + 2. An `L` value will be calculated for the liquidity as specified below. + 3. The correct balances of base and quote tokens will be calculated given the `L` value and the `market effective price` + 4. These correct balances will be transferred from the user's balances to the AMM's. If they cannot be transferred the transaction will be rejected. + +#### Amendment + +The process as above will be followed. By utilising the new reference price, market price and calculated liquidity values the AMM's balance will be adjusted to be correct by transferring from/to the user's general accounts. + +#### Cancellation + +The AMM can be cancelled immediately and balances of both tokens will be transferred back to the user's general accounts. + +### Determining Volumes and Prices + +Although AMM prices are not placed onto the book as orders it is necessary to be able to be able to quote prices for a given volume, or know what trading volume would move the fair price to a certain level. + +The volume to offer at each price level is determined by whether the price level falls between the upper and lower price bands alongside the market maker's current position. In order to calculate this, use the concept of `Virtual Liquidity` from Uniswap's concentrated liquidity model, corresponding to a theoretical shifted version of the actual liquidity curve to map to an infinite range liquidity curve. The exact mathematics of this can be found in the Uniswap v3 whitepaper and are expanded in depth in the useful guide [Liquidity Math in Uniswap v3](http://atiselsts.github.io/pdfs/uniswap-v3-liquidity-math.pdf). Here will be covered cover only the steps needed to obtain prices/volumes without much exposition. + +The most important value to calculate is the liquidity, or $L$ value, which determines the balances of each token at any given price level. This can be uniquely determined from the specification of the bound prices, reference price and reference quantity. + +Calling the reference price specified $p_r$, and the price bounds $p_u$ and $p_l$ for the upper and lower bounds respectively, if $p_r <= p_l$ then + +$$ +L = c_b \frac{\sqrt{p_l} \sqrt{p_u}}{\sqrt{p_u} - \sqrt{p_l}} , +$$ + +$$ +c_q = 0 , +$$ + +where $c_b$ is the base commitment value specified (note that as $p_r <= p_l$ it would be invalid to specify a quote commitment value). Similarly, if $p_r >= p_u$ then + +$$ +L = \frac{c_q}{\sqrt{p_u} - \sqrt{p_l}} , +$$ + +$$ +c_b = 0 , +$$ + + +where $c_q$ is the quote commitment value specified (note that as $p_r >= p_l$ it would be invalid to specify a base commitment value). + +In the final case where $p_l < p_r < p_u$ we can think of there being two separate ranges, one above (from $p_r$ to $p_u$) and one below ($p_l$ to $p_r$). In the upper range the AMM is fully in the base asset, in the lower it is fully in the quote asset. Thus, the protocol can take the specified commitment value, calculate $L$ with that on the relevant range. + +Concretely: + +If $c_q$ is specified + +$$ +L = \frac{c_q}{\sqrt{p_r} - \sqrt{p_l}} , +$$ + +$$ +c_b = L \frac{\sqrt{p_u} - \sqrt{p_r}}{\sqrt{p_u} \sqrt{p_r}} +$$ + +and if $c_b$ is specified + +$$ +L = c_b \frac{\sqrt{p_l} \sqrt{p_r}}{\sqrt{p_r} - \sqrt{p_l}} , +$$ + +$$ +c_q = L (\sqrt{p_r} - \sqrt{p_l}) , +$$ + +#### Fair price + +The fair price can then be calculated as + +$$ +p_f = \frac{b_q + L \sqrt{p_l}}{b_b + \frac{L}{\sqrt{p_u}}} , +$$ + +where $b_q$ is the current balance of the quote token and $b_b$ is the current balance of the base token. + +#### Price to trade a given volume + +Finally, the protocol needs to calculate the inverse of the previous section. That is, given a volume bought from/sold to the AMM, at what price should the trade be executed. This could be calculated naively by summing across all the smallest increment volume differences, however this would be computationally inefficient and can be optimised by instead considering the full trade size. + +First, the virtual `x` and `y` balances must be found (where `x` is the base balance and `y` is the quote balance): + +$$ +x_v = b_b + \frac{L}{\sqrt{p_u}} , +$$ + +$$ +y_v = b_q + L \sqrt{p_l} , +$$ + +Once obtained, the price can be obtained from the fundamental requirement of the product $y \cdot x$ remaining constant. This gives the relationship + +$$ +y_v \cdot x_v = (y_v + \Delta y) \cdot (x_v - \Delta x) , +$$ + +From which $\Delta y$ must be calculated + +$$ +\Delta y = \frac{y_v \cdot x_v}{x_v - \Delta x} - y_v , +$$ + +Thus giving a final execution price to return of $\frac{\Delta y}{\Delta x}$. + +#### Volume between two prices + +For the second interface one needs to calculate the volume which would be posted to the book between two price levels. In order to calculate this for an AMM one is ultimately asking the question "what volume of swap would cause the fair price to move from price A to price B?" + +To calculate this, the interface will need the `starting price` $p_s$, `ending price` $p_e$, `upper price` $p_u$ and the `L`. At `Q = 0` (a position of `0` in the quote asset `Q`) use the values for the range which the volume change will cause the position to move into. + +First, calculate the implied position at `starting price` and `ending price` and return the difference. + +For a given price $p$ calculate implied position in the quote asset $Q_i$ with + +$$ +Q_i = L \cdot \frac{\sqrt{p_u} - \sqrt{p}}{\sqrt{p} \cdotp \sqrt{p_u}} , +$$ + +Then simply return the absolute difference between these two values. + +## Determining Liquidity Contribution + +Liquidity contribution for spot AMMs should be determined identically to that for futures market vAMMs in [0090-SAMM](./0090-SAMM-automated_market_maker.md) + +## Setting Fees + +The `proposed_fee` provided as part of the AMM construction contributes to the fee determination logic on the market, if a setup where LPs decide on the market fee is in use. In the case where it is the AMM's current assigned ELS, or the running average liquidity provided so far if the commitment was made in the current epoch, is used for weighting the AMM's vote for the fee. + +## Market Settlement + +At market settlement, an AMM's position will be settled alongside all others as if they are a standard party. Once settlement is complete, any remaining funds in the AMM's account will be transferred back to the creator's general account and the AMM can be removed. + + +## Acceptance Criteria + +- When `market.amm.minCommitmentQuantum` is `1`, mid price of the market `ETH/USDT` is `100`, a user with `1000 USDT` is able to create an AMM with commitment `1000 USDT`, lower price `100`, upper price `150`, reference price `100`. (0092-SAMM-001) +- When `market.amm.minCommitmentQuantum` is `1`, mid price of the market `ETH/USDT` is `100`, a user with `1000 USDT` is unable to create an AMM with commitment `1000 USDT`, lower price `100`, upper price `150`, reference price `150`. (0092-SAMM-002) +- When `market.amm.minCommitmentQuantum` is `1`, mid price of the market `ETH/USDT` is `100`, a user with `1000 USDT` is able to create an AMM with commitment `1 ETH`, lower price `100`, upper price `150`, reference price `150`. (0092-SAMM-003) +- When `market.amm.minCommitmentQuantum` is `100`, mid price of the market `ETH/USDT` is `100`, a user with `10 USDT` is unable to create an AMM with commitment `10 USDT`, lower price `100`, upper price `150`, reference price `150`. (0092-SAMM-004) + +- When `market.amm.minCommitmentQuantum` is `1`, mid price of the market `ETH/USDT` is `100`, a user with `1 ETH` is able to create an AMM with commitment `1 ETH`, lower price `80`, upper price `100`, reference price `100`. (0092-SAMM-005) +- When `market.amm.minCommitmentQuantum` is `1`, mid price of the market `ETH/USDT` is `100`, a user with `1 ETH` is unable to create an AMM with commitment `1 ETH`, lower price `80`, upper price `100`, reference price `80`. (0092-SAMM-006) + +- When `market.amm.minCommitmentQuantum` is `1`, mid price of the market `ETH/USDT` is `100`, a user with `1 ETH` and `100 USDT` is able to create an AMM with commitment `1 ETH`, lower price `80`, upper price `130`, reference price `100`. (0092-SAMM-007) +- When `market.amm.minCommitmentQuantum` is `1`, mid price of the market `ETH/USDT` is `100`, a user with `1 ETH` and `99 USDT` is unable to create an AMM with commitment `1 ETH`, lower price `80`, upper price `130`, reference price `100`. (0092-SAMM-008) diff --git a/protocol/features.json b/protocol/features.json index 1cb35d044..e25f5ff3d 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -723,11 +723,19 @@ }, "Cancelling Proposals": { "milestone": "colosseo_II", + "acs": ["0028-GOVE-188", "0028-GOVE-189", "0028-GOVE-190", "0028-GOVE-191"] + }, + "Spot AMM": { + "milestone": "genbu_temple", "acs": [ - "0028-GOVE-188", - "0028-GOVE-189", - "0028-GOVE-190", - "0028-GOVE-191" + "0092-SAMM-001", + "0092-SAMM-002", + "0092-SAMM-003", + "0092-SAMM-004", + "0092-SAMM-005", + "0092-SAMM-006", + "0092-SAMM-007", + "0092-SAMM-008" ] }, "Unknown": { From 9d587e7a87f2215d5cbba2245096f3e42826ad20 Mon Sep 17 00:00:00 2001 From: Tom Date: Thu, 6 Jun 2024 18:27:49 +0100 Subject: [PATCH 1146/1171] feat: Fixing vAMM equation (#2297) * feat: Tweak to vamm equation --- non-protocol-specs/0014-NP-VAMM-bounds-estimations.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/non-protocol-specs/0014-NP-VAMM-bounds-estimations.md b/non-protocol-specs/0014-NP-VAMM-bounds-estimations.md index 30802a298..9641f7ad6 100644 --- a/non-protocol-specs/0014-NP-VAMM-bounds-estimations.md +++ b/non-protocol-specs/0014-NP-VAMM-bounds-estimations.md @@ -46,7 +46,7 @@ $$ where $p_u$ is the price at the upper end of the range (`upper price` for the upper range and `base price` for the lower range) and $p_l$ is the corresponding lower price for the range. With this, the average entry price can be found to be $$ -p_a = L_u p_u (1 - \frac{L_u}{L_u + p_u}) , +p_a = L_u \sqrt{p_u} (1 - \frac{L_u}{L_u + \sqrt{p_u}}) , $$ where $p_a$ is the average execution price across the range and other values are as defined above. Finally, the risk factor which will be used for calculating leverage at bounds From 08ac72307f44c6e5b7aac030fc65750b7331211b Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Thu, 13 Jun 2024 11:56:34 +0100 Subject: [PATCH 1147/1171] feat: add AC for vAMM during opening auction --- protocol/0042-LIQF-setting_fees_and_rewarding_lps.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md b/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md index 88fad0027..7a8593e94 100644 --- a/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md +++ b/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md @@ -474,6 +474,8 @@ Example 1, generated with [supplementary worksheet](https://docs.google.com/spre - A vAMM which was active on the market with an average of `10000` liquidity units (`price * volume`) provided for half the epoch, and then `0` for the second half of the epoch (as the price was out of the vAMM's configured range), and where the `market.liquidity.stakeToCcyVolume` value is `100`, will have an implied commitment of `50`. (0042-LIQF-109) - A vAMM which was active on the market with an average of `10000` liquidity units (`price * volume`) provided for half the epoch, and then is cancelled for the second half of the epoch, and where the `market.liquidity.stakeToCcyVolume` value is `100`, will have an implied commitment of `50`. (0042-LIQF-110) - A vAMM which was active on the market with an average of `10000` liquidity units (`price * volume`) provided for half the epoch, and then `5000` for the second half of the epoch (as the price was out of the vAMM's configured range), and where the `market.liquidity.stakeToCcyVolume` value is `100`, will have an implied commitment of `75`. (0042-LIQF-111) +- A vAMM which was active when market is in opening auction, if they submit AMM with the same implied commitment as normal LP, then they should get the same liquidity fee as normal LP in the next epoch (0042-LIQF-112) + ### Explicit instantaneous liquidity scoring function From d7055c8be544efa8b0732dae15dbc17eb92acd88 Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Thu, 13 Jun 2024 11:58:33 +0100 Subject: [PATCH 1148/1171] chore: typo --- 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 7a8593e94..a4c88badd 100644 --- a/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md +++ b/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md @@ -474,7 +474,7 @@ Example 1, generated with [supplementary worksheet](https://docs.google.com/spre - A vAMM which was active on the market with an average of `10000` liquidity units (`price * volume`) provided for half the epoch, and then `0` for the second half of the epoch (as the price was out of the vAMM's configured range), and where the `market.liquidity.stakeToCcyVolume` value is `100`, will have an implied commitment of `50`. (0042-LIQF-109) - A vAMM which was active on the market with an average of `10000` liquidity units (`price * volume`) provided for half the epoch, and then is cancelled for the second half of the epoch, and where the `market.liquidity.stakeToCcyVolume` value is `100`, will have an implied commitment of `50`. (0042-LIQF-110) - A vAMM which was active on the market with an average of `10000` liquidity units (`price * volume`) provided for half the epoch, and then `5000` for the second half of the epoch (as the price was out of the vAMM's configured range), and where the `market.liquidity.stakeToCcyVolume` value is `100`, will have an implied commitment of `75`. (0042-LIQF-111) -- A vAMM which was active when market is in opening auction, if they submit AMM with the same implied commitment as normal LP, then they should get the same liquidity fee as normal LP in the next epoch (0042-LIQF-112) +- A vAMM that was active during the market's opening auction should receive the same liquidity fee as a normal LP in the next epoch if they submit an AMM with the same implied commitment (0042-LIQF-112) ### Explicit instantaneous liquidity scoring function From 4b47aedb3220e6ccc7e9198900ce9aced2f3c2aa Mon Sep 17 00:00:00 2001 From: David Siska <62546419+davidsiska-vega@users.noreply.github.com> Date: Thu, 13 Jun 2024 12:32:06 +0100 Subject: [PATCH 1149/1171] fix: reword --- 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 a4c88badd..051c1dbe5 100644 --- a/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md +++ b/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md @@ -474,7 +474,7 @@ Example 1, generated with [supplementary worksheet](https://docs.google.com/spre - A vAMM which was active on the market with an average of `10000` liquidity units (`price * volume`) provided for half the epoch, and then `0` for the second half of the epoch (as the price was out of the vAMM's configured range), and where the `market.liquidity.stakeToCcyVolume` value is `100`, will have an implied commitment of `50`. (0042-LIQF-109) - A vAMM which was active on the market with an average of `10000` liquidity units (`price * volume`) provided for half the epoch, and then is cancelled for the second half of the epoch, and where the `market.liquidity.stakeToCcyVolume` value is `100`, will have an implied commitment of `50`. (0042-LIQF-110) - A vAMM which was active on the market with an average of `10000` liquidity units (`price * volume`) provided for half the epoch, and then `5000` for the second half of the epoch (as the price was out of the vAMM's configured range), and where the `market.liquidity.stakeToCcyVolume` value is `100`, will have an implied commitment of `75`. (0042-LIQF-111) -- A vAMM that was active during the market's opening auction should receive the same liquidity fee as a normal LP in the next epoch if they submit an AMM with the same implied commitment (0042-LIQF-112) +- If a vAMM was active during the market's opening auction if the opening auction ended and if trades were placed before the end of an epoch the vAMM should receive liquidity fee at epoch boundary (just like a normal LP that submitted bond during opening auction and then met the SLA) (0042-LIQF-112) ### Explicit instantaneous liquidity scoring function From ac29937f9dcd42b8ffe9e9c39af067376337a044 Mon Sep 17 00:00:00 2001 From: Tom Date: Wed, 19 Jun 2024 11:06:51 +0100 Subject: [PATCH 1150/1171] feat: Updates to fix up equations (#2303) --- .../0014-NP-VAMM-bounds-estimations.md | 15 ++++++++------- 1 file changed, 8 insertions(+), 7 deletions(-) diff --git a/non-protocol-specs/0014-NP-VAMM-bounds-estimations.md b/non-protocol-specs/0014-NP-VAMM-bounds-estimations.md index 9641f7ad6..c9fcd02ce 100644 --- a/non-protocol-specs/0014-NP-VAMM-bounds-estimations.md +++ b/non-protocol-specs/0014-NP-VAMM-bounds-estimations.md @@ -14,6 +14,7 @@ The API should take a pool's specification parameters and output various metrics 1. Leverage At Upper Price 1. Leverage At Lower Price 1. Commitment Amount + 1. Market ID 1. Optional: Party Key And then return the metrics: @@ -55,7 +56,7 @@ $$ r_f = \min(l_b, \frac{1}{ (f_s + f_l) \cdotp f_i}) , $$ -where $l_b$ is the sided value `leverage_at_bounds` (`upper ratio` if the upper band is being considered and `lower ratio` if the lower band is), $f_s$ is the market's sided risk factor (different for long and short positions), $f_l$ is the market's linear slippage component and $f_i$ is the market's initial margin factor. +where $l_b$ is the sided value `leverage_at_bounds` (`upper ratio` if the upper band is being considered and `lower ratio` if the lower band is), $f_s$ is the market's sided risk factor (different for long and short positions), $f_l$ is the market's linear slippage component and $f_i$ is the market's initial margin factor. This will result in two separate values to use for $r_f$, one for the lower range and one for the upper range. ### Position at Bounds @@ -69,7 +70,7 @@ $$ P_{v_u} = \frac{r_f b}{p_u (1 + r_f) - r_f p_a} , $$ -where $r_f$ is the `short` factor for the upper range and the `long` factor for the lower range, `b` is the current total balance of the vAMM across all accounts, $P_{v_l}$ is the theoretical volume and the bottom of the lower bound and $P_{v_u}$ is the (absolute value of the) theoretical volume at the top of the upper bound. +where $r_f$ is the `short` factor for the upper range and the `long` factor for the lower range, `b` is the current total balance of the vAMM across all accounts, $p_u$ and $p_l$ are as defined above, $P_{v_l}$ is the theoretical volume and the bottom of the lower bound and $P_{v_u}$ is the (absolute value of the) theoretical volume at the top of the upper bound. ### Loss on Commitment at Bound @@ -77,7 +78,7 @@ where $r_f$ is the `short` factor for the upper range and the `long` factor for For the loss on commitment at bound, one needs to use the average entry price, bound price and the position at the bounds $$ -l_c = |p_a - p_b| \cdot P_b , +l_c = |(p_a - p_b) \cdot P_b |, $$ where $P_b$ is the position at bounds (Either $P_{v_l}$ or $P_{v_u}$), $p_a$ is the average entry price and $p_b$ is the price at the corresponding outer bound. Note that this is an absolute value of loss, so outstanding balance at bounds would be `initial balance - $L_c$`. @@ -88,10 +89,10 @@ where $P_b$ is the position at bounds (Either $P_{v_l}$ or $P_{v_u}$), $p_a$ is Using a similar methodology to the standard estimations for liquidation price and the above calculated values, an estimate for liquidation prices above and below the range can be obtained with $$ -p_{liq} = \frac{b - l_c - P_b \cdot p_b}{\abs{P_b} \cdot m_r - P_b} , +p_{liq} = \frac{b - l_c - P_b \cdot p_b}{|P_b| \cdot (f_l + m_r) - P_b} , $$ -where $p_{liq}$ is the liquidation price (above or below the specified ranges), $b$ is the original commitment balance, $l_c$ is the loss on commitment at the relevant bound, $P_b$ is the position at the relevant bound, $p_b$ is the price at the bound and $m_r$ is the market's long or short risk factor (short for the upper price bound as the position will be negative and long for the lower). +where $p_{liq}$ is the liquidation price (above or below the specified ranges), $b$ is the original commitment balance, $l_c$ is the loss on commitment at the relevant bound, $P_b$ is the position at the relevant bound, $p_b$ is the price at the bound, $f_l$ is the linear slippage factor for the market and $m_r$ is the market's long or short risk factor (short for the upper price bound as the position will be negative and long for the lower). ## Specified Key @@ -101,7 +102,7 @@ When a key is specified, the existence of any current vAMM should be checked and ## Acceptance criteria -- For a request specifying (base, upper, lower, leverage_upper, leverage_lower, commitment) as (1000, 1100, 900, 2, 2, 100) the response is (0014-NP-VAMM-001): +- For a request specifying (base, upper, lower, leverage_upper, leverage_lower, commitment, short risk factor, long risk factor, market slippage factor) as (1000, 1100, 900, 2, 2, 100, 0.01, 0.01, 0) the response is (0014-NP-VAMM-001): 1. Loss on Commitment at Upper Bound: 8.515 1. Loss on Commitment at Lower Bound: 9.762 @@ -111,7 +112,7 @@ When a key is specified, the existence of any current vAMM should be checked and 1. Liquidation Price at Lower Bound: 454.545 -- For a request specifying (base, upper, lower, leverage_upper, leverage_lower, commitment) as (1000, 1300, 900, 1, 5, 100) the response is (0014-NP-VAMM-004): +- For a request specifying (base, upper, lower, leverage_upper, leverage_lower, commitment, short risk factor, long risk factor, market slippage factor) as (1000, 1300, 900, 1, 5, 100, 0.01, 0.01, 0) the response is (0014-NP-VAMM-004): 1. Loss on Commitment at Upper Bound: 10.948 1. Loss on Commitment at Lower Bound: 21.289 From c7c25fc417ebf46c473f232c6b5f1f9345f199e0 Mon Sep 17 00:00:00 2001 From: Tom Date: Wed, 19 Jun 2024 15:40:22 +0100 Subject: [PATCH 1151/1171] feat: tx trade ordering (#2231) * feat: Order trade transactions within a block --- protocol/0001-MKTF-market_framework.md | 3 +- protocol/0028-GOVE-governance.md | 3 ++ .../0093-TRTO-trading_transaction_ordering.md | 47 +++++++++++++++++++ protocol/features.json | 24 ++++++++++ 4 files changed, 76 insertions(+), 1 deletion(-) create mode 100644 protocol/0093-TRTO-trading_transaction_ordering.md diff --git a/protocol/0001-MKTF-market_framework.md b/protocol/0001-MKTF-market_framework.md index 6579c5bcd..3d32d838a 100644 --- a/protocol/0001-MKTF-market_framework.md +++ b/protocol/0001-MKTF-market_framework.md @@ -33,7 +33,8 @@ Data: - If this is negative e.g. -3 this means that the smallest order and position is of size 1000. - Accepted values are `-6,...,-1,0,1,2,...,6`. - **Tick size**: the minimum change in quote price for the market. Order prices and offsets for pegged orders must be given as an exact multiple of the tick size. For example if the tick size is 0.02 USD. then a price of 100.02 USD is acceptable and a price of 100.03 USD is not. The tick size of a market can be updated through governance. Note, the tick size should be specified in terms of the market decimals, e.g. for a scaled tick size of `0.02` (USDT) in a market using `5` decimal places, the tick size would be set to `2000`. -- **Liquidation strategy**: A field specifying the liquidation strategy for the market. Please refer to [0012-POSR-position_resolution](./0012-POSR-position_resolution.md#managing-networks-position) for supported strategies. +- **Liquidation strategy**: A field specifying the liquidation strategy for the market. Please refer to [0012-POSR-position_resolution](./0012-POSR-position_resolution.md#managing-networks-position) for supported strategies. +- **Transaction Prioritisation**: A boolean, whether to enable [transaction prioritisation](./0092-TRTO-trading_transaction_ordering.md). Note: it is agreed that initially the integer representation of the full precision of both order and positions can be required to fit into an int64, so this means that the largest position/order size possible reduces by a factor of ten for every extra decimal place used. This also means that, for instance, it would not be possible to create a `BTCUSD` market that allows order/position sizes equivalent to 1 sat. diff --git a/protocol/0028-GOVE-governance.md b/protocol/0028-GOVE-governance.md index bedf799e1..b609255e1 100644 --- a/protocol/0028-GOVE-governance.md +++ b/protocol/0028-GOVE-governance.md @@ -579,6 +579,8 @@ APIs should also exist for clients to: - A market proposal with position decimal places not in `{-6,...,-1,0,1,2,...,6}` gets rejected. (0028-GOVE-062) For product spot: (0028-GOVE-075) - A market proposal with a tick size less than or equal to `0` gets rejected (0028-GOVE-180). - At enactment, a market change proposal updating the tick size leaves in place all orders where the quoted price is not an exact multiple of `10^-mdp` (where `mdp` is the market decimal places) (0028-GOVE-182). +- At enactment, a market with `Transaction Prioritisation` enabled will have transactions re-prioritised as defined in [transaction prioritisation](./0092-TRTO-trading_transaction_ordering.md) (0028-GOVE-192). +- At enactment, a market with `Transaction Prioritisation` disabled will not have transactions re-prioritised (0028-GOVE-193). #### Market change proposals @@ -623,6 +625,7 @@ APIs should also exist for clients to: - A market change proposal specifying a new tick size less than or equal to `0` gets rejected (0028-GOVE-184). - At enactment, a market change proposal updating the tick size cancels all pegged orders where their offset is no longer an exact integer multiple of the tick size (0028-GOVE-183). - A market LP with ELS > 0 can vote on a market change proposal even if the key doesn't meet the `governance.proposal.updateMarket.minVoterBalance` for governance token. (0028-GOVE-185). +- An amendment to a market to enable or disable `Transaction Prioritisation` will have that effect immediately upon enactment. (0028-GOVE-194) #### Network parameter change proposals diff --git a/protocol/0093-TRTO-trading_transaction_ordering.md b/protocol/0093-TRTO-trading_transaction_ordering.md new file mode 100644 index 000000000..e72eeb86e --- /dev/null +++ b/protocol/0093-TRTO-trading_transaction_ordering.md @@ -0,0 +1,47 @@ +# Trading Transaction Ordering + +In order for an exchange to offer competitive prices for parties arriving and wishing to trade immediately, others have to be willing to place limit orders on the book which will remain there and wait for an incoming order to match with it. These are required for a limit order book to exist (as implied by the name) but expose the party placing the initial limit order to a range of risks, as often the reason these orders will eventually trade is because the price has become unfavourable to the party who placed the order, but they either have not realised or have not had a chance to cancel the order yet. This is often referred to as "toxic flow". Whilst another party obviously gains from this transaction, it is generally acknowledged that the higher a given venue's proportion of toxic flow to more balanced flow, the wider market makers will end up quoting to avoid being the victim of this. This issue is particularly present when considering a decentralised exchange with a publicly available mempool and higher latency than a centralised exchange, both giving potential toxic flow a significant edge. As such, exchange and transaction designs which allow for the reduction of this without unfairly impacting other parties using the network may allow for the exchange as a whole to provide traders with better prices than otherwise. This specification covers one such proposed methodology, comprising of a specified ordering of order executions on a given market. + +## Execution Ordering + +Trading transactions (those which create, update or remove orders of any type on any market) should be executed in a specific way once included in a block. This ordering is per-market (inter-market ordering is unspecified). The functionality can be enabled/disabled at a per-market level through market governance. When disabled for a given market, all transactions are sorted as normal with no delays applied. + +Chiefly, when enabled all transactions which would cancel an order or create post-only orders should be executed first before transactions which could create trades, within which all cancellations should be executed prior to post-only orders. The ordering of the transactions in this way means that, at the time of each block being created, all parties who are contributing to creating an order book have an opportunity to update their prices prior to anyone who would capitalise on temporary stale prices, regardless of which transaction reached the validator's pre-block transaction pool first. This ordering can still be seen to be a "fair" transaction ordering, as parties cannot take actions which would cause a trade, but only take action to avoid trading at a price they no longer desire (or indeed to improve a price prior to trade-creating transactions' arrival). + +Furthermore, transactions which can cause a trade by acting aggressively, such as non-post-only orders and amends, will be delayed by a number of blocks, governed by a network parameter `market.aggressiveOrderBlockDelay`, prior to execution. This results in the pattern where: + + 1. Prior to block N, post only order A and market order B arrive to the chain, these are both included in block N. + 1. When block N is executed, order A takes effect. + 1. Prior to block N + 1, post only order C then market order D and finally a cancellation of order A arrive to the chain, these are both included in block N + 1. + 1. When block N + 1 is executed, the cancellation of order A first takes effect, then the post-only order C, then finally market order B. + 1. When block N + 2 is executed, market order D takes effect + +## Batch Transactions + +Batch transactions, as they contain different order types, must be handled slightly differently. In the initial version, they will remain to be executed as one unit. When determining execution position, the protocol will inspect the components of the batch transaction. If the transaction contains any order creation messages which are not post-only, or any order amends at all, the entire batch will be delayed as if it were a transaction which could create trades (as some component of it could). If the batch contains exclusively cancellations and/or post-only limit orders then it will be executed in the expedited head-of-block mode specified above. Batches will still be executed all at once as specified, in the order cancellations -> amendments -> creations. The total ordering of executions when including batches should be: + + 1. Standalone Cancellations + 1. Batches (containing both cancellations and order creations) + 1. Standalone Creations + +## Acceptance criteria + +- A batch transaction including only cancellations and/or post-only limit orders is executed at the top of the block alongside standalone post-only limit orders and cancellations. (0093-TRTO-001) +- A batch transaction including either a non-post-only order or an amendment is delayed by one block and then executed after the expedited transactions in that later block. (0093-TRTO-002) +- Cancellation transactions always occur before: + - Market orders (0093-TRTO-003) + - Non post-only limit orders (0093-TRTO-004) + - Order Amends (0093-TRTO-005) + - post-only limit orders (0093-TRTO-013) +- Post-only transactions always occur before: + - Market orders (0093-TRTO-006) + - Non post-only limit orders (0093-TRTO-007) + - Order Amends (0093-TRTO-008) +- Potentially aggressive orders take effect on the market exactly one block after they are included in a block (i.e for an order which is included in block N it hits the market in block N+1). This is true for: + - Market orders (0093-TRTO-009) + - Non post-only limit orders (0093-TRTO-010) + - Order Amends (0093-TRTO-011) +- An expedited batch transaction is executed after cancellations but before standalone post-only creations (0093-TRTO-012) +- The transaction ordering functionality can be enabled/disabled on a per-market level (0093-TRTO-015) +- With two active markets, with one having transaction ordering enabled and one disabled, transactions are correctly sorted/delayed on the market with it enabled whilst the other has transactions executed in arrival order. (0093-TRTO-014) +- When `market.aggressiveOrderBlockDelay` is set to `1` aggressive orders are delayed by a single block on eligible markets. If it is amended via governance to `5` then all aggressive orders after enactment of this change will be delayed by `5` blocks instead. (0093-TRTO-016) diff --git a/protocol/features.json b/protocol/features.json index e25f5ff3d..daebd7d8b 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -725,6 +725,30 @@ "milestone": "colosseo_II", "acs": ["0028-GOVE-188", "0028-GOVE-189", "0028-GOVE-190", "0028-GOVE-191"] }, + "Transaction Ordering": { + "milestone": "colosseo_II", + "acs": [ + "0093-TRTO-001", + "0093-TRTO-002", + "0093-TRTO-003", + "0093-TRTO-004", + "0093-TRTO-005", + "0093-TRTO-006", + "0093-TRTO-007", + "0093-TRTO-008", + "0093-TRTO-009", + "0093-TRTO-010", + "0093-TRTO-011", + "0093-TRTO-012", + "0093-TRTO-013", + "0093-TRTO-014", + "0093-TRTO-015", + "0093-TRTO-016", + "0028-GOVE-192", + "0028-GOVE-194", + "0028-GOVE-193" + ] + }, "Spot AMM": { "milestone": "genbu_temple", "acs": [ From cea248826d1f597fa6b7d727e1e31a9a6b8c86a9 Mon Sep 17 00:00:00 2001 From: Tom Date: Thu, 20 Jun 2024 17:16:33 +0100 Subject: [PATCH 1152/1171] feat: AMM Estimates (#2282) * feat: Estimate within range --- protocol/0026-AUCT-auctions.md | 2 +- .../0090-VAMM-automated_market_maker.ipynb | 129 +++++++++++++++++- protocol/0090-VAMM-automated_market_maker.md | 2 +- 3 files changed, 129 insertions(+), 4 deletions(-) diff --git a/protocol/0026-AUCT-auctions.md b/protocol/0026-AUCT-auctions.md index bd85400c3..0ee427c6c 100644 --- a/protocol/0026-AUCT-auctions.md +++ b/protocol/0026-AUCT-auctions.md @@ -51,7 +51,7 @@ We can also imagine that an auction period could come to an end once a give numb Once the auction period finishes, vega needs to figure out the best price for the order range in the book which can be uncrossed. The first stage in this is to calculate the Volume Maximising Price Range - the range of prices (which will be a contiguous range in an unconstrained order book) at which the highest total quantity of trades can occur. -For including [AMM](./0090-VAMM-automated_market_maker.md) configurations in the calculation of expected uncrossing price of the auction process and volume maximising price range, create two lists of independent copies of all currently active vAMMs. Ensure that the price range under consideration (lowest ask - highest bid) is expanded to cover the current best bid/ask prices of all vAMMs. When iterating through the price ranges the vAMMs should be updated after each price level checked as if they have traded that volume before checking the next level. vAMMs may quote on both sides of the book as long as they are not in reduce-only mode. When actually uncrossing the market, vAMMs should act as normal when trades from one side are being sent in to matching. +For including [AMM](./0090-VAMM-automated_market_maker.md) configurations in the calculation of expected uncrossing price of the auction process and volume maximising price range, create two lists of independent copies of all currently active vAMMs. Ensure that the price range under consideration (lowest ask - highest bid) is expanded to cover the current best bid/ask prices of all vAMMs. Separately, calculate a price step size defined by either the smallest tick size or, if this would result in more steps between lowest ask and highest bid than allowed by `market.liquidity.maxAmmCalculationLevels` instead divide the price range into `market.liquidity.maxAmmCalculationLevels` and calculate the price step required for this. Additionally, add all price bounds for vAMMs which are within the auction bounds to the checked levels. Then iterate through these price levels, moving the vAMMs to each by querying their volume between the two bounds and counting this as a single trade at the price farther from mid. Add these volumes to those of individual limit orders when calculating the uncrossing price. vAMMs may quote on both sides of the book as long as they are not in reduce-only mode. When actually uncrossing the market, vAMMs should act as normal when trades from one side are being sent in to matching. Initially we will use the mid price within this range. For example, if the volume maximising range is 98-102, we would price all trades in the uncrossing at 100 ((minimum price of range+maximum price of range)/2). In future there will be other options, which will be selectable via a network parameter specified at market creation, and changeable through governance. These other options are not yet specified. diff --git a/protocol/0090-VAMM-automated_market_maker.ipynb b/protocol/0090-VAMM-automated_market_maker.ipynb index 550fb18a8..97711d085 100644 --- a/protocol/0090-VAMM-automated_market_maker.ipynb +++ b/protocol/0090-VAMM-automated_market_maker.ipynb @@ -7,7 +7,7 @@ "metadata": {}, "outputs": [], "source": [ - "import numpy\n", + "import numpy as np\n", "from typing import Optional, Tuple, List\n", "from collections import namedtuple\n", "import matplotlib.pyplot as plt" @@ -761,6 +761,131 @@ "print(f\"Position at lower would be {volume_at_lower} and position at upper would be {-1 * volume_at_upper} (Lower AEP {aep_lower}, Upper AEP {aep_upper})\")\n", "print(f\"Implying leverage {volume_at_lower * mm.lower_price / (balance + loss_at_lower)} at lower and {volume_at_upper * mm.upper_price / (balance - loss_at_upper)} at upper\")" ] + }, + { + "cell_type": "markdown", + "id": "2553a194", + "metadata": {}, + "source": [ + "### Curve Estimator" + ] + }, + { + "cell_type": "code", + "execution_count": null, + "id": "aec95eb6", + "metadata": {}, + "outputs": [], + "source": [ + "upper_factor = 1300/1000 - 1\n", + "lower_factor = 0.1\n", + "base = 1000\n", + "\n", + "mm = CFMMarketMaker(\n", + " initial_price=base,\n", + " price_width_above=upper_factor,\n", + " price_width_below=lower_factor,\n", + " margin_multiple_at_upper=10,\n", + " margin_multiple_at_lower=1,\n", + " num_levels=8000,\n", + " tick_spacing=1,\n", + ")" + ] + }, + { + "cell_type": "code", + "execution_count": null, + "id": "e2fc7416", + "metadata": {}, + "outputs": [], + "source": [ + "trade_size = 100\n", + "\n", + "def execution_price(volume_to_trade: float, price_levels: list[(float, float)]):\n", + " '''First value in price_levels is price, second is volume\n", + " '''\n", + " weighted_execution_price = 0\n", + " traded_vol = 0\n", + " for level in price_levels:\n", + " if level[1] > volume_to_trade:\n", + " weighted_execution_price += volume_to_trade * level[0]\n", + " traded_vol += volume_to_trade\n", + " volume_to_trade = 0\n", + " else:\n", + " weighted_execution_price += level[1] * level[0]\n", + " volume_to_trade -= level[1]\n", + " traded_vol += level[1]\n", + " if volume_to_trade <= 0:\n", + " break\n", + " return weighted_execution_price / traded_vol\n", + "\n", + "def gen_levels(start_px: float, end_px: float, num_divisions: int, amm: CFMMarketMaker, amm_balance: float) -> list[(float, float)]:\n", + " last_level = start_px\n", + "\n", + " unit_upper_L = (\n", + " amm.upper_price_sqrt\n", + " * amm.base_price_sqrt\n", + " / (amm.upper_price_sqrt - amm.base_price_sqrt)\n", + " )\n", + " aep = -1 * unit_upper_L * amm.upper_price_sqrt * ((unit_upper_L / (unit_upper_L + amm.upper_price_sqrt)) - 1)\n", + " volume_at_upper_incoming = amm.margin_multiple_at_upper * amm_balance / (amm.upper_price * (1 + amm.margin_multiple_at_upper) - amm.margin_multiple_at_upper * aep)\n", + "\n", + " upper_L = (\n", + " volume_at_upper_incoming\n", + " * amm.upper_price_sqrt\n", + " * amm.base_price_sqrt\n", + " / (amm.upper_price_sqrt - amm.base_price_sqrt)\n", + " )\n", + "\n", + " orders = []\n", + " for level in np.linspace(start_px, end_px, num=num_divisions):\n", + " if level == start_px:\n", + " continue\n", + " orders.append((level, amm._quantity_for_move(last_level**0.5, level**0.5, amm.upper_price_sqrt, upper_L)))\n", + " last_level = level\n", + " return orders" + ] + }, + { + "cell_type": "code", + "execution_count": null, + "id": "24a0ee68", + "metadata": {}, + "outputs": [], + "source": [ + "STEPS_IN_RANGE = 100\n", + "RANGE_LOW = base\n", + "RANGE_HIGH = 2 * RANGE_LOW\n", + "TICK_SIZE = 0.01\n", + "TRADE_SIZE = 100\n", + "MM_BALANCE = 10_000\n", + "\n", + "num_divisions_to_test = [x for x in range(100, 10000, 5)]\n" + ] + }, + { + "cell_type": "code", + "execution_count": null, + "id": "b9b009e9", + "metadata": {}, + "outputs": [], + "source": [ + "prices = []\n", + "\n", + "for div in num_divisions_to_test:\n", + " levels = gen_levels(RANGE_LOW, RANGE_HIGH, div, mm, MM_BALANCE)\n", + " prices.append(execution_price(TRADE_SIZE, levels))\n", + "\n", + "plt.plot(num_divisions_to_test, prices)" + ] + }, + { + "cell_type": "code", + "execution_count": null, + "id": "37264648", + "metadata": {}, + "outputs": [], + "source": [] } ], "metadata": { @@ -779,7 +904,7 @@ "name": "python", "nbconvert_exporter": "python", "pygments_lexer": "ipython3", - "version": "3.11.8" + "version": "3.10.14" } }, "nbformat": 4, diff --git a/protocol/0090-VAMM-automated_market_maker.md b/protocol/0090-VAMM-automated_market_maker.md index b6d51f8f8..a73706597 100644 --- a/protocol/0090-VAMM-automated_market_maker.md +++ b/protocol/0090-VAMM-automated_market_maker.md @@ -243,7 +243,7 @@ As an AMM does not directly place orders on the book this calculation first need Once these are retrieved, the price / volume points should be combined with a precomputed array of the probability of trading at each price level to calculate the liquidity supplied on each side of the orderbook as defined in [probability of trading](./0034-PROB-prob_weighted_liquidity_measure.ipynb). Once this is calculated, use this value as the instantaneous liquidity score for fee distribution as defined in [setting fees and rewards](./0042-LIQF-setting_fees_and_rewarding_lps.md). -As the computation of this virtual order shape may be heavy when run across a large number of passive AMMs the number of AMMs updated per block should be throttled to a fixed maximum number, updating on a rolling frequency, or when updated/first created. +As the computation of this virtual order shape may be heavy when run across a large number of passive AMMs the number of AMMs updated per block should be throttled to a fixed maximum number, updating on a rolling frequency, or when updated/first created. Additionally, a network parameter of `market.liquidity.maxAmmCalculationLevels` should be used to determine the maximum number of levels to be used between the upper and lower SLA bounds. If this number is exceeded the space between upper and lower should be linearly interpolated to produce at most this many sampling points and an estimate using those price levels be used instead. A given AMM's average liquidity score across the epoch should also be tracked, giving a time-weighted average at the end of each epoch (including `0` values for any time when the AMM either did not exist or was not providing liquidity on one side of the book). From this, a virtual stake amount can be calculated by dividing through by the `market.liquidity.stakeToCcyVolume` value and the AMM key's ELS updated as normal. From fcb76c49f056df7e02252391466550a3e3de92e1 Mon Sep 17 00:00:00 2001 From: Witold Date: Fri, 21 Jun 2024 18:26:05 +0200 Subject: [PATCH 1153/1171] refactor: first stab at max block auction --- protocol/0094-PRAC-protective_auctions.md | 48 +++++++++++++++++++++++ 1 file changed, 48 insertions(+) create mode 100644 protocol/0094-PRAC-protective_auctions.md diff --git a/protocol/0094-PRAC-protective_auctions.md b/protocol/0094-PRAC-protective_auctions.md new file mode 100644 index 000000000..c01125d73 --- /dev/null +++ b/protocol/0094-PRAC-protective_auctions.md @@ -0,0 +1,48 @@ +# Protective auctions + +The protocol has a number of protective [auctions](./0026-AUCT-auctions.md) to gather more information from market participants before carrying on with price discovery process at times of increased uncertainty or when continuous functioning of the network is disrupted. + +## Per-market auctions + +Per-market auction applies to an individual market only and are triggered by actions related directly to that market. + +### Mark price monitoring + +Mark [price monitoring](./0032-PRIM-price_monitoring.md) is triggered when the next mark price would be significantly higher than what the mark-price history implies. + +### Trade price monitoring + +Trade [price monitoring](./0032-PRIM-price_monitoring.md) is triggered when the next traded price would be significantly higher than what the mark-price history implies. + +### Governance + +Individual markets can also be put into protective auctions using a [governance](./0028-GOVE-governance.md#6-change-market-state) action. + +## Network-wide auctions + +Network-wide auctions put all of the markets running on a given network into auction. The triggers for those types of auctions are related to functioning of a network as a whole. + +### Block time auctions + +Block time auctions get triggered when the block time exceeds one of the predefined thresholds expressed in seconds. This should be done as soon as the time since the beginning of the last known block is more than any of the specified thresholds. Once such conditions get detected no more transactions relating to markets get processed before all the markets get put into auction mode. The duration of such an auction should be fixed and related to the block length. +The allowed thresholds and resulting auction periods should be implemented as a lookup-up table, sorted in the ascending order of the threshold and checked backwards. The resulting auction periods should not be summed - the auction period associated with the largest allowed threshold less than the detected block time should be used as the resulting auction duration. + +## Acceptance criteria + +- When the network resumes after a crash (irrespective of how that was achieved) no trades get generated. All markets go into an auction of the same duration. Trades may only be generated in any market once the network-wide auction ends. (0094-PRAC-001) + +- When the network resumes after a [protocol upgrade](./0075-PLUP-protocol_upgrades.md) no trades get generated. All markets go into an auction of the same duration. Trades may only be generated in any market once the network-wide auction ends. (0094-PRAC-002) + +- When the lookup table for the network-wide auction is specified as: + + | Threshold | Network-wide auction duration | + | --------- | ----------------------------- | + | `3s` | `1min` | + | `40s` | `10min` | + | `2min` | `1h` | + +and at some point network determines that the length of the last block was 90s, the network then immediately goes into a network-wide auction with a duration of `10min`. (0094-PRAC-003) + +- A market which has been in a per-market auction which was triggered before the network-wide auction was initiated remains in auction mode even if the exit condition for the original per-market auction gets satisfied before the network-wide auction ends. No intermediate trades get generated even in the presence of non-zero indicative volume at the point of that market's per-market auction exit condition being satisfied. The market only goes back into its default trading mode and possibly generates trades once the network-wide auction ends. (0094-PRAC-004) + +- A market which has been in a per-market auction which was triggered before the network-wide auction was initiated remains in auction mode once the network-wide auction ends if the exit condition for the original per-market auction hasn't been met at that point and no intermediate trades get generated even in the presence of non-zero indicative volume at the point of network-wide auction end. (0094-PRAC-005) From 53051cde1496dcf4d951f0c2e2e3f290c0e728be Mon Sep 17 00:00:00 2001 From: Witold Date: Mon, 24 Jun 2024 10:42:36 +0200 Subject: [PATCH 1154/1171] refactor: add defaults --- protocol/0094-PRAC-protective_auctions.md | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/protocol/0094-PRAC-protective_auctions.md b/protocol/0094-PRAC-protective_auctions.md index c01125d73..95b7218c4 100644 --- a/protocol/0094-PRAC-protective_auctions.md +++ b/protocol/0094-PRAC-protective_auctions.md @@ -27,6 +27,17 @@ Network-wide auctions put all of the markets running on a given network into auc Block time auctions get triggered when the block time exceeds one of the predefined thresholds expressed in seconds. This should be done as soon as the time since the beginning of the last known block is more than any of the specified thresholds. Once such conditions get detected no more transactions relating to markets get processed before all the markets get put into auction mode. The duration of such an auction should be fixed and related to the block length. The allowed thresholds and resulting auction periods should be implemented as a lookup-up table, sorted in the ascending order of the threshold and checked backwards. The resulting auction periods should not be summed - the auction period associated with the largest allowed threshold less than the detected block time should be used as the resulting auction duration. +The default settings should be: + + | Threshold | Network-wide auction duration | + | --------- | ----------------------------- | + | `10s` | `1min` | + | `1min` | `5min` | + | `10min` | `1h` | + | `1h` | `1h` | + | `6h` | `3h` | + | `24h` | `6h` | + ## Acceptance criteria - When the network resumes after a crash (irrespective of how that was achieved) no trades get generated. All markets go into an auction of the same duration. Trades may only be generated in any market once the network-wide auction ends. (0094-PRAC-001) From 2d3431fe97055b422214a5a3a7931a3f80ad87cc Mon Sep 17 00:00:00 2001 From: Witold Date: Fri, 28 Jun 2024 13:40:56 +0200 Subject: [PATCH 1155/1171] refactor: formalise action interaction + ACs --- protocol/0094-PRAC-protective_auctions.md | 18 ++++++++++++++++-- 1 file changed, 16 insertions(+), 2 deletions(-) diff --git a/protocol/0094-PRAC-protective_auctions.md b/protocol/0094-PRAC-protective_auctions.md index 95b7218c4..b505f641b 100644 --- a/protocol/0094-PRAC-protective_auctions.md +++ b/protocol/0094-PRAC-protective_auctions.md @@ -35,8 +35,16 @@ The default settings should be: | `1min` | `5min` | | `10min` | `1h` | | `1h` | `1h` | - | `6h` | `3h` | - | `24h` | `6h` | + | `6h` | `3h` | + | `24h` | `6h` | + + + +## Interaction between different auction modes + +When market goes into auction mode from its default trading mode then the auction trigger which caused this should be listed as `trigger` on the API as long as that auction hasn't finished (including cases when it gets extended). + +When another trigger gets activated for the market then the end time of auction for that market should be the maximum of the original end time and that implied by the latest trigger. If the original end time is larger then nothing changes. If end time implied by the latest trigger is larger than the end time gets set to this value and the `extension_trigger` field gets set (or overwritten if market has already been in an extended auction at this point) to represent the latest trigger. Governance auction is assumed to have an infinite duration (it can only be ended with an appropriate governance auction and the timing of that action is generally unknown a priori). ## Acceptance criteria @@ -57,3 +65,9 @@ and at some point network determines that the length of the last block was 90s, - A market which has been in a per-market auction which was triggered before the network-wide auction was initiated remains in auction mode even if the exit condition for the original per-market auction gets satisfied before the network-wide auction ends. No intermediate trades get generated even in the presence of non-zero indicative volume at the point of that market's per-market auction exit condition being satisfied. The market only goes back into its default trading mode and possibly generates trades once the network-wide auction ends. (0094-PRAC-004) - A market which has been in a per-market auction which was triggered before the network-wide auction was initiated remains in auction mode once the network-wide auction ends if the exit condition for the original per-market auction hasn't been met at that point and no intermediate trades get generated even in the presence of non-zero indicative volume at the point of network-wide auction end. (0094-PRAC-005) + +- When market is in a price monitoring auction which is meant to finish at `10am`, but prior to that time a long block auction finishing at 11am gets triggered then the market stays in auction till `11am`, it's auction trigger is listed as price monitoring auction and it's extension trigger is listed as long block auction. (0094-PRAC-006) + +- When a market's `trigger` or `extension_trigger` is set to represent a governance suspension then no other triggers can affect the market. (0094-PRAC-007) + +- When a market's `trigger` and `extension_trigger` are set to represent that the market went into auction due to the price monitoring mechanism and was later extended by the same mechanism and the auction is meant to finish at `11am`, but now a long block auction is being triggered so that it ends at `10am` then this market is unaffected in any way. (0094-PRAC-008) \ No newline at end of file From 6618c62dcdf5fb34fc581a109ffebb1407cc318e Mon Sep 17 00:00:00 2001 From: Witold Date: Fri, 28 Jun 2024 13:41:12 +0200 Subject: [PATCH 1156/1171] refactor: remove supplied liquidity requirement from ACs --- protocol/0026-AUCT-auctions.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/protocol/0026-AUCT-auctions.md b/protocol/0026-AUCT-auctions.md index 0ee427c6c..b4a9c7504 100644 --- a/protocol/0026-AUCT-auctions.md +++ b/protocol/0026-AUCT-auctions.md @@ -170,14 +170,14 @@ 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, there is no need for the supplied liquidity to exceed a threshold to exit an auction. (0026-AUCT-038). 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](./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) + 4. past the enactment time if there are orders crossing on the book (there is no need for the supplied liquidity to exceed a threshold to exit an auction) but after the auction uncrossing we will not have + - best bid; it will still open. (0026-AUCT-039) + - or best ask; it will still open. (0026-AUCT-040) - 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 9b058ef6c66eedcbd153c4c8d93bd2de68f8f8dc Mon Sep 17 00:00:00 2001 From: Witold Date: Fri, 28 Jun 2024 13:50:08 +0200 Subject: [PATCH 1157/1171] chore: update approbation --- protocol/cosmic-features.json | 32 +++++++++++++------- protocol/features.json | 56 +++++++++++++++++++++++++++++------ 2 files changed, 69 insertions(+), 19 deletions(-) diff --git a/protocol/cosmic-features.json b/protocol/cosmic-features.json index fa19e42d6..d2c4b31b4 100644 --- a/protocol/cosmic-features.json +++ b/protocol/cosmic-features.json @@ -362,12 +362,9 @@ "0044-LIME-101", "0044-LIME-102", "0026-AUCT-016", - "0026-AUCT-017", "0026-AUCT-018", "0026-AUCT-019", "0026-AUCT-020", - "0026-AUCT-021", - "0026-AUCT-022", "0034-PROB-004", "0042-LIQF-055" ] @@ -465,7 +462,7 @@ "0062-SPAM-037" ] }, -"Rewards": { + "Rewards": { "milestone": "deployment-2", "acs": [ "0085-RVST-001", @@ -558,7 +555,7 @@ "0028-GOVE-152" ] }, - "Batch change proposals": { + "Batch change proposals": { "milestone": "deployment-3", "acs": [ "0028-GOVE-145", @@ -926,18 +923,33 @@ }, "Iceberg Orders": { "milestone": "cosmic-carryover", - "acs": ["0014-ORDT-069"] + "acs": [ + "0014-ORDT-069" + ] }, "Successor Markets": { "milestone": "cosmic-carryover", - "acs": ["0001-MKTF-008"] + "acs": [ + "0001-MKTF-008" + ] }, "Ethereum oracles": { "milestone": "cosmic-carryover", - "acs": ["0082-ETHD-035", "0082-ETHD-041"] + "acs": [ + "0082-ETHD-035", + "0082-ETHD-041" + ] }, "Stop Orders": { "milestone": "cosmic-carryover", - "acs": ["0079-TGAP-004", "0079-TGAP-005", "0014-ORDT-132", "0014-ORDT-133", "0014-ORDT-134", "0014-ORDT-135", "0014-ORDT-136"] + "acs": [ + "0079-TGAP-004", + "0079-TGAP-005", + "0014-ORDT-132", + "0014-ORDT-133", + "0014-ORDT-134", + "0014-ORDT-135", + "0014-ORDT-136" + ] } -} +} \ No newline at end of file diff --git a/protocol/features.json b/protocol/features.json index daebd7d8b..068b27f4d 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -25,19 +25,29 @@ }, "Isolated margin": { "milestone": "colosseo", - "acs": ["0019-MCAL-208"] + "acs": [ + "0019-MCAL-208" + ] }, "Closeout trades and auctions": { "milestone": "colosseo", - "acs": ["0012-POSR-030"] + "acs": [ + "0012-POSR-030" + ] }, "Market suspended/resumed before enactment": { "milestone": "colosseo", - "acs": ["0043-MKTL-011", "0043-MKTL-012", "0043-MKTL-013"] + "acs": [ + "0043-MKTL-011", + "0043-MKTL-012", + "0043-MKTL-013" + ] }, "Teams": { "milestone": "colosseo", - "acs": ["0083-RFPR-068"] + "acs": [ + "0083-RFPR-068" + ] }, "Spot": { "milestone": "colosseo", @@ -530,11 +540,17 @@ }, "Perpetual funding rates": { "milestone": "colosseo", - "acs": ["0053-PERP-036"] + "acs": [ + "0053-PERP-036" + ] }, "Explicit liquidation range": { "milestone": "colosseo", - "acs": ["0012-POSR-031", "0012-POSR-032", "0012-POSR-033"] + "acs": [ + "0012-POSR-031", + "0012-POSR-032", + "0012-POSR-033" + ] }, "Community Tags": { "milestone": "colosseo", @@ -554,7 +570,9 @@ }, "LPs voting without gov token": { "milestone": "colosseo", - "acs": ["0028-GOVE-185"] + "acs": [ + "0028-GOVE-185" + ] }, "Reward Improvements": { "milestone": "colosseo", @@ -723,7 +741,12 @@ }, "Cancelling Proposals": { "milestone": "colosseo_II", - "acs": ["0028-GOVE-188", "0028-GOVE-189", "0028-GOVE-190", "0028-GOVE-191"] + "acs": [ + "0028-GOVE-188", + "0028-GOVE-189", + "0028-GOVE-190", + "0028-GOVE-191" + ] }, "Transaction Ordering": { "milestone": "colosseo_II", @@ -749,6 +772,21 @@ "0028-GOVE-193" ] }, + "Long Block Auction": { + "milestone": "colosseo_II", + "acs": [ + "0026-AUCT-039", + "0026-AUCT-040", + "0094-PRAC-001", + "0094-PRAC-002", + "0094-PRAC-003", + "0094-PRAC-004", + "0094-PRAC-005", + "0094-PRAC-006", + "0094-PRAC-007", + "0094-PRAC-008" + ] + }, "Spot AMM": { "milestone": "genbu_temple", "acs": [ @@ -766,4 +804,4 @@ "milestone": "unknown", "acs": [] } -} +} \ No newline at end of file From 7c01b667d9ead58e55a2b67a3d5801accb87f0a4 Mon Sep 17 00:00:00 2001 From: Witold Date: Fri, 28 Jun 2024 13:51:54 +0200 Subject: [PATCH 1158/1171] chore: fix CI issues --- protocol/0094-PRAC-protective_auctions.md | 3 +-- wordlist.txt | 1 + 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/protocol/0094-PRAC-protective_auctions.md b/protocol/0094-PRAC-protective_auctions.md index b505f641b..5231ec8f9 100644 --- a/protocol/0094-PRAC-protective_auctions.md +++ b/protocol/0094-PRAC-protective_auctions.md @@ -39,7 +39,6 @@ The default settings should be: | `24h` | `6h` | - ## Interaction between different auction modes When market goes into auction mode from its default trading mode then the auction trigger which caused this should be listed as `trigger` on the API as long as that auction hasn't finished (including cases when it gets extended). @@ -70,4 +69,4 @@ and at some point network determines that the length of the last block was 90s, - When a market's `trigger` or `extension_trigger` is set to represent a governance suspension then no other triggers can affect the market. (0094-PRAC-007) -- When a market's `trigger` and `extension_trigger` are set to represent that the market went into auction due to the price monitoring mechanism and was later extended by the same mechanism and the auction is meant to finish at `11am`, but now a long block auction is being triggered so that it ends at `10am` then this market is unaffected in any way. (0094-PRAC-008) \ No newline at end of file +- When a market's `trigger` and `extension_trigger` are set to represent that the market went into auction due to the price monitoring mechanism and was later extended by the same mechanism and the auction is meant to finish at `11am`, but now a long block auction is being triggered so that it ends at `10am` then this market is unaffected in any way. (0094-PRAC-008) diff --git a/wordlist.txt b/wordlist.txt index 990e720be..b396ab1c2 100644 --- a/wordlist.txt +++ b/wordlist.txt @@ -229,6 +229,7 @@ PoW PoWs pre precomputed +priori pro protobuf Pseudocode From eb776c9a5d27f473ca603b6261843afffdb7195b Mon Sep 17 00:00:00 2001 From: Edd Date: Wed, 10 Jul 2024 16:18:08 +0100 Subject: [PATCH 1159/1171] milestone rejig --- protocol/features.json | 22 +++++++++++++++++----- 1 file changed, 17 insertions(+), 5 deletions(-) diff --git a/protocol/features.json b/protocol/features.json index 068b27f4d..8e1ea3aad 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -539,7 +539,7 @@ ] }, "Perpetual funding rates": { - "milestone": "colosseo", + "milestone": "historic_distillery", "acs": [ "0053-PERP-036" ] @@ -553,7 +553,7 @@ ] }, "Community Tags": { - "milestone": "colosseo", + "milestone": "colosseo_III", "acs": [ "0028-GOVE-168", "0028-GOVE-169", @@ -569,7 +569,7 @@ ] }, "LPs voting without gov token": { - "milestone": "colosseo", + "milestone": "historic_distillery", "acs": [ "0028-GOVE-185" ] @@ -625,7 +625,7 @@ ] }, "vAMMs": { - "milestone": "colosseo_II", + "milestone": "colosseo_III", "acs": [ "0042-LIQF-092", "0042-LIQF-093", @@ -740,7 +740,7 @@ ] }, "Cancelling Proposals": { - "milestone": "colosseo_II", + "milestone": "historic_distillery", "acs": [ "0028-GOVE-188", "0028-GOVE-189", @@ -800,6 +800,18 @@ "0092-SAMM-008" ] }, + "Fee mechanic changes": { + "milestone": "colosseo_II", + "acs": [] + }, + "LP 3.0": { + "milestone": "genbu_temple", + "acs": [] + }, + "Token Buyback auction": { + "milestone": "genbu_temple", + "acs": [] + }, "Unknown": { "milestone": "unknown", "acs": [] From f9d5280bfbd75dfc22785e01d6d37bdf0a45c2a7 Mon Sep 17 00:00:00 2001 From: Edd Date: Wed, 10 Jul 2024 17:03:16 +0100 Subject: [PATCH 1160/1171] fix fee mechanic milestone, reorder features --- protocol/features.json | 230 +++++++++++++++++++++-------------------- 1 file changed, 117 insertions(+), 113 deletions(-) diff --git a/protocol/features.json b/protocol/features.json index 8e1ea3aad..6d1532139 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -538,12 +538,7 @@ "0009-MRKP-037" ] }, - "Perpetual funding rates": { - "milestone": "historic_distillery", - "acs": [ - "0053-PERP-036" - ] - }, + "Explicit liquidation range": { "milestone": "colosseo", "acs": [ @@ -552,28 +547,8 @@ "0012-POSR-033" ] }, - "Community Tags": { - "milestone": "colosseo_III", - "acs": [ - "0028-GOVE-168", - "0028-GOVE-169", - "0028-GOVE-170", - "0028-GOVE-171", - "0028-GOVE-172", - "0028-GOVE-173", - "0028-GOVE-174", - "0028-GOVE-175", - "0028-GOVE-176", - "0028-GOVE-177", - "0028-GOVE-178" - ] - }, - "LPs voting without gov token": { - "milestone": "historic_distillery", - "acs": [ - "0028-GOVE-185" - ] - }, + + "Reward Improvements": { "milestone": "colosseo", "acs": [ @@ -624,78 +599,7 @@ "0057-TRAN-079" ] }, - "vAMMs": { - "milestone": "colosseo_III", - "acs": [ - "0042-LIQF-092", - "0042-LIQF-093", - "0042-LIQF-094", - "0090-VAMM-001", - "0090-VAMM-002", - "0090-VAMM-003", - "0090-VAMM-004", - "0090-VAMM-005", - "0090-VAMM-006", - "0090-VAMM-007", - "0090-VAMM-008", - "0090-VAMM-009", - "0090-VAMM-010", - "0090-VAMM-011", - "0090-VAMM-012", - "0090-VAMM-013", - "0090-VAMM-014", - "0090-VAMM-015", - "0090-VAMM-016", - "0090-VAMM-017", - "0090-VAMM-018", - "0090-VAMM-019", - "0090-VAMM-020", - "0090-VAMM-021", - "0090-VAMM-022", - "0090-VAMM-023", - "0090-VAMM-024", - "0090-VAMM-025", - "0090-VAMM-026", - "0090-VAMM-027", - "0090-VAMM-028", - "0090-VAMM-029", - "0090-VAMM-030", - "0090-VAMM-031", - "0090-VAMM-032", - "0090-VAMM-033", - "0090-VAMM-034", - "0090-VAMM-035", - "0057-TRAN-070", - "0026-AUCT-033", - "0026-AUCT-034", - "0026-AUCT-035", - "0026-AUCT-036", - "0026-AUCT-037", - "0014-NP-VAMM-001", - "0014-NP-VAMM-002", - "0014-NP-VAMM-003", - "0014-NP-VAMM-004", - "0015-NP-OBES-001", - "0015-NP-OBES-002", - "0042-LIQF-107", - "0042-LIQF-108", - "0042-LIQF-109", - "0042-LIQF-110", - "0042-LIQF-111", - "0056-REWA-170", - "0085-RVST-015", - "0085-RVST-016", - "0085-RVST-017", - "0085-RVST-018", - "0085-RVST-019", - "0085-RVST-020", - "0085-RVST-021", - "0085-RVST-022", - "0085-RVST-023", - "0085-RVST-024", - "0085-RVST-025" - ] - }, + "Capped Futures": { "milestone": "colosseo_II", "acs": [ @@ -739,15 +643,6 @@ "0019-MCAL-159" ] }, - "Cancelling Proposals": { - "milestone": "historic_distillery", - "acs": [ - "0028-GOVE-188", - "0028-GOVE-189", - "0028-GOVE-190", - "0028-GOVE-191" - ] - }, "Transaction Ordering": { "milestone": "colosseo_II", "acs": [ @@ -787,6 +682,98 @@ "0094-PRAC-008" ] }, + "Fee mechanic changes": { + "milestone": "colosseo_III", + "acs": [] + }, + "vAMMs": { + "milestone": "colosseo_III", + "acs": [ + "0042-LIQF-092", + "0042-LIQF-093", + "0042-LIQF-094", + "0090-VAMM-001", + "0090-VAMM-002", + "0090-VAMM-003", + "0090-VAMM-004", + "0090-VAMM-005", + "0090-VAMM-006", + "0090-VAMM-007", + "0090-VAMM-008", + "0090-VAMM-009", + "0090-VAMM-010", + "0090-VAMM-011", + "0090-VAMM-012", + "0090-VAMM-013", + "0090-VAMM-014", + "0090-VAMM-015", + "0090-VAMM-016", + "0090-VAMM-017", + "0090-VAMM-018", + "0090-VAMM-019", + "0090-VAMM-020", + "0090-VAMM-021", + "0090-VAMM-022", + "0090-VAMM-023", + "0090-VAMM-024", + "0090-VAMM-025", + "0090-VAMM-026", + "0090-VAMM-027", + "0090-VAMM-028", + "0090-VAMM-029", + "0090-VAMM-030", + "0090-VAMM-031", + "0090-VAMM-032", + "0090-VAMM-033", + "0090-VAMM-034", + "0090-VAMM-035", + "0057-TRAN-070", + "0026-AUCT-033", + "0026-AUCT-034", + "0026-AUCT-035", + "0026-AUCT-036", + "0026-AUCT-037", + "0014-NP-VAMM-001", + "0014-NP-VAMM-002", + "0014-NP-VAMM-003", + "0014-NP-VAMM-004", + "0015-NP-OBES-001", + "0015-NP-OBES-002", + "0042-LIQF-107", + "0042-LIQF-108", + "0042-LIQF-109", + "0042-LIQF-110", + "0042-LIQF-111", + "0056-REWA-170", + "0085-RVST-015", + "0085-RVST-016", + "0085-RVST-017", + "0085-RVST-018", + "0085-RVST-019", + "0085-RVST-020", + "0085-RVST-021", + "0085-RVST-022", + "0085-RVST-023", + "0085-RVST-024", + "0085-RVST-025" + ] + }, + "Community Tags": { + "milestone": "colosseo_III", + "acs": [ + "0028-GOVE-168", + "0028-GOVE-169", + "0028-GOVE-170", + "0028-GOVE-171", + "0028-GOVE-172", + "0028-GOVE-173", + "0028-GOVE-174", + "0028-GOVE-175", + "0028-GOVE-176", + "0028-GOVE-177", + "0028-GOVE-178" + ] + }, "Spot AMM": { "milestone": "genbu_temple", "acs": [ @@ -800,10 +787,6 @@ "0092-SAMM-008" ] }, - "Fee mechanic changes": { - "milestone": "colosseo_II", - "acs": [] - }, "LP 3.0": { "milestone": "genbu_temple", "acs": [] @@ -812,6 +795,27 @@ "milestone": "genbu_temple", "acs": [] }, + "Cancelling Proposals": { + "milestone": "historic_distillery", + "acs": [ + "0028-GOVE-188", + "0028-GOVE-189", + "0028-GOVE-190", + "0028-GOVE-191" + ] + }, + "Perpetual funding rates": { + "milestone": "historic_distillery", + "acs": [ + "0053-PERP-036" + ] + }, + "LPs voting without gov token": { + "milestone": "historic_distillery", + "acs": [ + "0028-GOVE-185" + ] + }, "Unknown": { "milestone": "unknown", "acs": [] From 9f8c0c9939ee6d851e873224b45195c423a2c5a9 Mon Sep 17 00:00:00 2001 From: Elias Van Ootegem Date: Fri, 12 Jul 2024 16:20:07 +0100 Subject: [PATCH 1161/1171] chore: remove impossible AC, but mention the behaviour in spec Signed-off-by: Elias Van Ootegem --- protocol/0016-PFUT-product_builtin_future.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/protocol/0016-PFUT-product_builtin_future.md b/protocol/0016-PFUT-product_builtin_future.md index b3dbe1246..e1b4444ac 100644 --- a/protocol/0016-PFUT-product_builtin_future.md +++ b/protocol/0016-PFUT-product_builtin_future.md @@ -92,6 +92,8 @@ Validation: - `fully-collateralised mode` is only allowed when there is a `max_price` specified - `binary_settlement` is only allowed when there is a `max_price` specified +Note that these fields are not specified on the market update types. Once a capped future is created and set to fully collateralised (and/or binary settlement), it cannot be changed. + ## Acceptance Criteria 1. Create a Cash Settled Future with trading termination triggered by a date/time based data source (0016-PFUT-001) @@ -125,4 +127,3 @@ Optional parameters: 1. Futures market can be created with a with [hardcoded risk factors](./0018-RSKM-quant_risk_models.ipynb). (0016-PFUT-026) 1. Updating a risk model on a futures market with regular risk model to with [hardcoded risk factors](./0018-RSKM-quant_risk_models.ipynb) results in recalculation of all margin levels in line with hardcoded values and collateral search/release where appropriate. (0016-PFUT-027) 1. Updating a risk model on a futures market with [hardcoded risk factors](./0018-RSKM-quant_risk_models.ipynb) to a regular risk model results in recalculation of all margin levels in line with the specified risk model (hardcoded value are no longer used) and collateral search/release where appropriate. (0016-PFUT-028) -1. It's not possible to modify the `fully-collateralised` flag with a market update transaction. (0016-PFUT-029) From e0628933121eba77349c844f3e927ddd94ac21a5 Mon Sep 17 00:00:00 2001 From: Elias Van Ootegem Date: Fri, 12 Jul 2024 16:25:33 +0100 Subject: [PATCH 1162/1171] chore: remove old AC from json Signed-off-by: Elias Van Ootegem --- protocol/features.json | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/protocol/features.json b/protocol/features.json index 6d1532139..e64160657 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -622,8 +622,7 @@ "0019-MCAL-157", "0019-MCAL-158", "0019-MCAL-170", - "0019-MCAL-171", - "0016-PFUT-029" + "0019-MCAL-171" ] }, "Model-free alternatives": { @@ -820,4 +819,4 @@ "milestone": "unknown", "acs": [] } -} \ No newline at end of file +} From 0e9ab96b3c6ef567aa4b2d784b9edec41ad6c173 Mon Sep 17 00:00:00 2001 From: Tom Date: Mon, 15 Jul 2024 14:37:06 +0100 Subject: [PATCH 1163/1171] feat: separate fee discount components (#2293) * feat: Adding separate discount factor components * feat: Adding separate discount factor components * feat: Add ACs * feat: Fix AC code * feat: Fix AC code * feat: Review comments * feat: Adding high volume maker rebate * feat: Fix up eqs * feat: Remove duplicative naming * chore: Fix up markdown * refactor: add default value --------- Co-authored-by: Witold --- protocol/0029-FEES-fees.md | 61 ++++++++---- .../0083-RFPR-on_chain_referral_program.md | 96 +++++++++++++++---- protocol/0084-VDPR-volume_discount_program.md | 54 ++++++++--- .../0095-HVMR-high_volume_maker_rebate.md | 26 +++++ protocol/features.json | 14 ++- 5 files changed, 196 insertions(+), 55 deletions(-) create mode 100644 protocol/0095-HVMR-high_volume_maker_rebate.md diff --git a/protocol/0029-FEES-fees.md b/protocol/0029-FEES-fees.md index 6573baea3..31f40d451 100644 --- a/protocol/0029-FEES-fees.md +++ b/protocol/0029-FEES-fees.md @@ -9,7 +9,7 @@ An order may cross with more than one other order, creating multiple trades. Eac The trading fee is: -`total_fee = infrastructure_fee + maker_fee + liquidity_fee` +`total_fee = infrastructure_fee + maker_fee + liquidity_fee + buyback_fee + treasury_fee` `infrastructure_fee = fee_factor[infrastructure] * trade_value_for_fee_purposes` @@ -17,6 +17,10 @@ The trading fee is: `liquidity_fee = fee_factor[liquidity] * trade_value_for_fee_purposes` +`buyback_fee = fee_factor[buyback] * trade_value_for_fee_purposes` + +`treasury_fee = fee_factor[treasury] * trade_value_for_fee_purposes` + Fees are calculated and collected in the settlement currency of the market, collected from the general account. Fees are collected first from the trader's account and then margin from account balance. If the general account doesn't have sufficient balance, then the remaining fee amount is collected from the margin account. If this is still insufficient then different rules apply between continuous trading and auctions (details below). Note that maker_fee = 0 if there is no maker, taker relationship between the trading parties (in particular auctions). @@ -25,14 +29,14 @@ 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 other and **before** rewards are calculated. +Note, discounts are calculated and applied one after the other and **before** rewards are calculated. Additionally, no benefit discounts can be applied to the treasury or buyback fee components as these may be required for the `high volume market maker rebate`. 1. Calculate any referral discounts due to the party. ```pseudo - 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) + infrastructure_fee_referral_discount = floor(original_infrastructure_fee * referral_infrastructure_discount_factor) + liquidity_fee_referral_discount = floor(original_liquidity_fee * referral_liquidity_discount_factor) + maker_fee_referral_discount = floor(original_maker_fee * referral_maker_discount_factor) ``` 1. Apply referral discounts to the original fee. @@ -46,9 +50,9 @@ Note, discounts are calculated and applied one after the other and **before** re 1. Calculate any volume discounts due to the party. ```pseudo - 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) + infrastructure_fee_volume_discount = floor(infrastructure_fee_after_referral_discount * volume_infrastructure_discount_factor) + liquidity_fee_volume_discount = floor(liquidity_fee_after_referral_discount * volume_liquidity_discount_factor) + maker_fee_volume_discount = floor(maker_fee_after_referral_discount * volume_maker_discount_factor) ``` 1. Apply any volume discounts to the fee after referral discounts. @@ -62,9 +66,9 @@ Note, discounts are calculated and applied one after the other and **before** re 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_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)) + infrastructure_fee_referral_reward = floor(infrastructure_fee_after_volume_discount * min(referral_infrastructure_reward_factor * referral_reward_multiplier, referralProgram.maxReferralRewardProportion)) + liquidity_fee_referral_reward = floor(liquidity_fee * min(liquidity_fee_after_volume_discount * min(referral_liquidity_reward_factor * referral_reward_multiplier, referralProgram.maxReferralRewardProportion))) + maker_fee_referral_reward = floor(maker_fee * min(maker_fee_after_volume_discount * min(referral_maker_reward_factor * referral_reward_multiplier, referralProgram.maxReferralRewardProportion))) ``` 1. Finally, update the fee components by applying the rewards. @@ -82,10 +86,14 @@ Note, discounts are calculated and applied one after the other and **before** re - infrastructure: staking/governance system/engine (network wide) - maker: market framework / market making (network wide) - liquidity: market making system (per market) +- treasury: Fees sent to network treasury for later usage via governance votes (network wide) +- buyback: Fees used to purchase governance tokens to the protocol via regular auctions (network wide) The infrastructure fee factor is set by a network parameter `market.fee.factors.infrastructureFee` and a reasonable default value is `fee_factor[infrastructure] = 0.0005 = 0.05%`. The maker fee factor is set by a network parameter `market.fee.factors.makerFee` and a reasonable default value is `fee_factor[maker] = 0.00025 = 0.025%`. The liquidity fee factor is set by an auction-like mechanism based on the liquidity provisions committed to the market, see [setting LP fees](./0042-LIQF-setting_fees_and_rewarding_lps.md). +The treasury fee factor is set by the network parameter `market.fee.factors.treasuryFee` with a default value should of `0`. +The buyback fee factor is set by the network parameter `market.fee.factors.buybackFee` with a default value should of `0`. trade_value_for_fee_purposes: @@ -107,15 +115,26 @@ If the transfer fails: 1. If we are in continuous trading mode, than trades should be discarded, any orders on the book that would have been hit should remain in place with previous remaining size intact and the incoming order should be rejected (not enough fees error). This functionality requires to match orders and create trades without changing the state of the order book or passing trades downstream so that the execution of the transaction can be discarded with no impact on the order book if needed. Other than the criteria whether to proceed or discard, this is exactly the same functionality required to implement [price monitoring](./0032-PRIM-price_monitoring.md). -2. If we are in auction mode, ignore the shortfall (and see more details below). +1. If we are in auction mode, ignore the shortfall (and see more details below). + +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 different components. -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. +Additionally, a `high_volume_market_maker_rebate` may be necessary which will be taken from the `treasury/buyback_fee` components. This will be calculated as: + +1. Determine whether the maker party of the trade (if there is one) qualifies for a `high volume market maker rebate` and, if so, at what rate. +1. Calculate the fee that this corresponds to as `high_volume_maker_fee = high_volume_factor * trade_value_for_fee_purposes`. +1. Take this fee from the `treasury_fee` and `buyback_fee` (protocol restrictions on governance changes ensure that `treasury_fee + buyback_fee >= high_volume_maker_fee` is always true) as a proportion of their relative sizes, i.e.: + 1. `high_volume_maker_fee = high_volume_factor * trade_value_for_fee_purposes` + 1. `treasury_fee = treasury_fee * (1 - high_volume_maker_fee / (treasury_fee + buyback_fee))` + 1. `buyback_fee = buyback_fee * (1 - high_volume_maker_fee / (treasury_fee + buyback_fee))` Now [apply benefit factors](#applying-benefit-factors) and then distribute funds from the "temporary fee bucket" as follows: 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 `maker_fee` and any `high_volume_maker_fee` are 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 `treasury_fee` is transferred to the treasury fee pool for that asset, where it will remain until community governance votes for transfers. +1. The `buyback_fee` is transferred to the buyback fee pool for that asset, where it will remain until community governance votes for transfers or a regular purchase program is set up. 1. The referral fee components (if any) can then be individually transferred to the relevant party (the referee). ### During Continuous Trading @@ -126,9 +145,9 @@ The "aggressor or price taker" pays the fee. The "passive or price maker" party ### Normal Auctions (including market protection and opening auctions) -During normal auctions there is no "price maker" both parties are "takers". Each side in a matched trade should contribute 1/2 of the infrastructure_fee + liquidity_fee. Note that this does not include a maker fee. +During normal auctions there is no "price maker" both parties are "takers". Each side in a matched trade should contribute 1/2 of the infrastructure_fee + liquidity_fee + treasury_fee + buyback_fee. Note that this does not include a maker fee. -Fees calculated and collected from general + margin as in continuous trading *but* if a party has insufficient capital to cover the trading fee then in auction the trade *still* *goes* *ahead* as long as the margin account should have enough left after paying the fees to cover maintenance level of margin for the orders and then converted trades. The fee is distributed so that the infrastructure_fee is paid first and only then the liquidity_fee. +Fees calculated and collected from general + margin as in continuous trading *but* if a party has insufficient capital to cover the trading fee then in auction the trade *still* *goes* *ahead* as long as the margin account should have enough left after paying the fees to cover maintenance level of margin for the orders and then converted trades. The fee is distributed so that the infrastructure_fee is paid first and only then the liquidity_fee/treasury_fee/buyback_fee. During an opening auction of a market, no fees are collected. @@ -168,7 +187,11 @@ 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 (assuming no volume discounts due to party) (0029-FEES-023) - - `infrastructure_referral_fee_discount` + - `infrastructure_fee_referral_discount` + - `liquidity_fee_referral_discount` + - `maker_fee_referral_discount` +1. Referee discounts with differing discounts across the three factors are correctly calculated and applied for each taker fee component during continuous trading (assuming no volume discounts due to party) (0029-FEES-034) + - `infrastructure_fee_referral_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 (assuming no volume discounts due to party) (0029-FEES-024) @@ -178,6 +201,10 @@ For example, Ether is 18 decimals (wei). The smallest unit, non divisible is 1 w - `infrastructure_fee_referral_reward` - `liquidity_fee_referral_reward` - `maker_fee_referral_reward` +1. Referrer rewards with differing reward factors are correctly calculated and transferred for each fee component during continuous trading (assuming no volume discounts due to party) (0029-FEES-035) + - `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 (assuming no volume discounts due to party) (0029-FEES-026) - `infrastructure_fee_referral_reward` - `liquidity_fee_referral_reward` diff --git a/protocol/0083-RFPR-on_chain_referral_program.md b/protocol/0083-RFPR-on_chain_referral_program.md index 39846dbe4..74da638d7 100644 --- a/protocol/0083-RFPR-on_chain_referral_program.md +++ b/protocol/0083-RFPR-on_chain_referral_program.md @@ -46,8 +46,14 @@ 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 referee's taker fees to be rewarded to the referrer - - `referral_discount_factor`: the proportion of the referee's taker fees to be discounted + - `referral_reward_factors`: the proportions of the referee's taker fees to be rewarded to the referrer + - `referral_maker_reward_factor`: the factor to reward the referrer from the maker fee component of any fees paid + - `referral_infrastructure_reward_factor`: the factor to reward the referrer from the infrastructure fee component of any fees paid + - `referral_liquidity_reward_factor`: the factor to reward the referrer from the liquidity provider fee component of any fees paid + - `referral_discount_factors`: the proportions of the referee's taker fees to be discounted + - `referral_maker_discount_factor`: the factor to discount the maker fee component of any fees paid + - `referral_infrastructure_discount_factor`: the factor to discount the infrastructure fee component of any fees paid + - `referral_liquidity_discount_factor`: the factor to discount the liquidity provider fee component of any fees paid - `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. @@ -61,20 +67,44 @@ message UpdateReferralProgram{ { "minimum_running_notional_taker_volume": 10000, "minimum_epochs": 1, - "referral_reward_factor": 0.001, - "referral_discount_factor": 0.001, + "referral_reward_factors": { + "referral_maker_reward_factor": 0.001, + "referral_infrastructure_reward_factor": 0.001, + "referral_liquidity_reward_factor": 0.001 + }, + "referral_discount_factors": { + "referral_maker_discount_factor": 0.001, + "referral_infrastructure_discount_factor": 0.001, + "referral_liquidity_discount_factor": 0.001 + } }, { "minimum_running_notional_taker_volume": 20000, "minimum_epochs": 7, - "referral_reward_factor": 0.005, - "referral_discount_factor": 0.005, + "referral_reward_factors": { + "referral_maker_reward_factor": 0.005, + "referral_infrastructure_reward_factor": 0.005, + "referral_liquidity_reward_factor": 0.005 + }, + "referral_discount_factors": { + "referral_maker_discount_factor": 0.005, + "referral_infrastructure_discount_factor": 0.005, + "referral_liquidity_discount_factor": 0.005 + }, }, { "minimum_running_notional_taker_volume": 30000, "minimum_epochs": 31, - "referral_reward_factor": 0.010, - "referral_discount_factor": 0.010, + "referral_reward_factors": { + "referral_maker_reward_factor": 0.01, + "referral_infrastructure_reward_factor": 0.01, + "referral_liquidity_reward_factor": 0.01 + }, + "referral_discount_factors": { + "referral_maker_discount_factor": 0.01, + "referral_infrastructure_discount_factor": 0.01, + "referral_liquidity_discount_factor": 0.01 + }, }, ], staking_tiers: [ @@ -103,11 +133,11 @@ 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.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 `0` and less than or equal to the network parameter `referralProgram.maxReferralRewardFactor`. +- all `referral_reward_factors` values must be greater than `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 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 `0` and be less than or equal to the network parameter `referralProgram.maxReferralDiscountFactor`. +- all `referral_discount_factors` values must be greater than `0` and be less than or equal to the network parameter `referralProgram.maxReferralDiscountFactor`. - `window_length` must be an integer strictly greater than zero. The referral program will start the epoch after the `enactment_timestamp` is reached. @@ -286,28 +316,28 @@ The network can then calculate the set's `referral_set_running_notional_taker_vo ### Setting benefit factors and reward multipliers -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. +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_factors` and `referral_discount_factors` for each referee. 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. +The `referral_reward_factors` 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 tier's `minimum_running_notional_taker_volume`. -The referee's `referral_reward_factor` is then set to the `referral_reward_factor` defined in the selected benefit tier. +The referee's `referral_reward_factors` are then set to the `referral_reward_factors` 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. +The `referral_discount_factors` 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 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 referee's `referral_discount_factor` is then set to the `referral_discount_factor` defined in the selected benefit tier. +The referee's `referral_discount_factors` are then set to the `referral_discount_factors` 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. @@ -329,20 +359,44 @@ Given: { "minimum_running_notional_taker_volume": 10000, "minimum_epochs": 0, - "referral_reward_factor": 0.001, - "referral_discount_factor": 0.001, + "referral_reward_factor": { + "maker_reward_factor": 0.001, + "infrastructure_reward_factor": 0.001, + "liquidity_reward_factor": 0.001 + }, + "referral_discount_factor": { + "maker_discount_factor": 0.001, + "infrastructure_discount_factor": 0.001, + "liquidity_discount_factor": 0.001 + }, }, { "minimum_running_notional_taker_volume": 20000, "minimum_epochs": 7, - "referral_reward_factor": 0.005, - "referral_discount_factor": 0.005, + "referral_reward_factor": { + "maker_reward_factor": 0.005, + "infrastructure_reward_factor": 0.005, + "liquidity_reward_factor": 0.005 + }, + "referral_discount_factor": { + "maker_discount_factor": 0.005, + "infrastructure_discount_factor": 0.005, + "liquidity_discount_factor": 0.005 + }, }, { "minimum_running_notional_taker_volume": 30000, "minimum_epochs": 31, - "referral_reward_factor": 0.010, - "referral_discount_factor": 0.010, + "referral_reward_factor": { + "maker_reward_factor": 0.01, + "infrastructure_reward_factor": 0.01, + "liquidity_reward_factor": 0. 01 + }, + "referral_discount_factor": { + "maker_discount_factor": 0.01, + "infrastructure_discount_factor": 0.01, + "liquidity_discount_factor": 0.01 + }, }, ] staking_tiers: [ diff --git a/protocol/0084-VDPR-volume_discount_program.md b/protocol/0084-VDPR-volume_discount_program.md index efbd1ef26..861e9811f 100644 --- a/protocol/0084-VDPR-volume_discount_program.md +++ b/protocol/0084-VDPR-volume_discount_program.md @@ -17,7 +17,10 @@ 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 + - `volume_discount_factors`: a dictionary with the following fields + - `maker_discount_factor`: the factor to discount the maker fee component of any fees paid + - `infrastructure_discount_factor`: the factor to discount the infrastructure fee component of any fees paid + - `lp_discount_factor`: the factor to discount the liquidity provider fee component of any fees paid - `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 @@ -27,15 +30,27 @@ message UpdateVolumeDiscountProgram{ benefit_tiers: [ { "minimum_party_running_notional_taker_volume": 1000, - "volume_discount_factor": 0.001, + "volume_discount_factors": { + "maker_discount_factor": 0.001, + "infrastructure_discount_factor": 0.001, + "lp_discount_factor": 0.001 + } }, { "minimum_party_running_notional_taker_volume": 20000, - "volume_discount_factor": 0.002, + "volume_discount_factors": { + "maker_discount_factor": 0.002, + "infrastructure_discount_factor": 0.002, + "lp_discount_factor": 0.002 + } }, { "minimum_party_running_notional_taker_volume": 30000, - "volume_discount_factor": 0.003, + "volume_discount_factors": { + "maker_discount_factor": 0.003, + "infrastructure_discount_factor": 0.003, + "lp_discount_factor": 0.003 + } }, ], end_of_program_timestamp: 123456789, @@ -49,7 +64,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`. +- all `volume_discount_factors` 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. @@ -78,15 +93,27 @@ Given: benefit_tiers=[ { "minimum_party_running_notional_taker_volume": 10000, - "volume_discount_factor": 0.001, + "volume_discount_factors": { + "maker_discount_factor": 0.001, + "infrastructure_discount_factor": 0.001, + "lp_discount_factor": 0.001 + } }, { "minimum_party_running_notional_taker_volume": 20000, - "volume_discount_factor": 0.005, + "volume_discount_factors": { + "maker_discount_factor": 0.005, + "infrastructure_discount_factor": 0.005, + "lp_discount_factor": 0.005 + } }, { "minimum_party_running_notional_taker_volume": 30000, - "volume_discount_factor": 0.010, + "volume_discount_factors": { + "maker_discount_factor": 0.05, + "infrastructure_discount_factor": 0.05, + "lp_discount_factor": 0.05 + } }, ] @@ -94,7 +121,9 @@ And: party_running_notional_taker_volume=22353 Then: - volume_discount_factor=0.005 + maker_volume_discount_factor=0.005 + infrastructure_volume_discount_factor=0.005 + lp_volume_discount_factor=0.005 ``` This benefit factor is then fixed for the duration of the next epoch. @@ -109,7 +138,7 @@ The Parties API should expose the following information: - a list of all **parties** (by `id`) and the following metrics: - current `party_running_notional_taker_volume` (value at the start of the epoch) - - current `volume_discount_factor` applied to fees + - current `volume_discount_factors` applied to fees - the total amount discounted for the party The Trades API should now also expose the following additional information for every trade: @@ -127,7 +156,7 @@ The Trades API should now also expose the following additional information for e - 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). + - all `volume_discount_factors` 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). @@ -143,6 +172,7 @@ The Trades API should now also expose the following additional information for e ### Setting benefit factors -1. At the start of an epoch, each parties `volume_discount_factor` is reevaluated and fixed for the epoch (0084-VDPR-012). +1. At the start of an epoch, each parties `volume_discount_factors` are 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). +1. A `volume_discount_factors` tier with differing factors across the three options has each factor set correctly (0084-VDPR-018). diff --git a/protocol/0095-HVMR-high_volume_maker_rebate.md b/protocol/0095-HVMR-high_volume_maker_rebate.md new file mode 100644 index 000000000..21e43dbb2 --- /dev/null +++ b/protocol/0095-HVMR-high_volume_maker_rebate.md @@ -0,0 +1,26 @@ +# High Volume Maker Rebate + +The high volume maker rebate program is a network-wide community governed set of parameters to provide an additional reward to market makers on the network who are involved in a significant fraction of all trading on the network. When enabled, eligible market makers receive an additional fraction of trading fees from trades in which they are involved on top of any standard received maker fee (and would receive this even were the default maker fee removed). + +## Configuration + +The configuration of the High Volume Maker rebate is performed very similarly to that of the [volume discount program](./0084-VDPR-volume_discount_program.md): +Enabling or changing the terms of the 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_maker_volume_fraction`: the required `party_maker_volume_fraction` for a party to access this tier + - `additional_maker_rebate`: the additional rebate factor (in percentage of `trade_value_for_fee_purposes`) a party at this tier will receive when they are the maker side of a trade +- `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 average a party's `maker_volume_fraction` + +## Application + +As variable fees for the taker depending upon with whom they are trading would not be a good experience, the additional maker rebate should be taken from a weighted combination of the network treasury and network buyback components of the total fee. The exact calculations are laid out in [0029-FEES](./0029-FEES-fees.md) but are broadly: + + 1. `high_volume_maker_fee = high_volume_factor * trade_value_for_fee_purposes` + 1. `treasury_fee = treasury_fee * (1 - high_volume_maker_fee / (treasury_fee + buyback_fee))` + 1. `buyback_fee = treasury_fee * (1 - buyback_fee / (treasury_fee + buyback_fee))` + +## Governance Requirements + +As the rebate possible level interacts with other fee settings there must be a restriction on it's possible values in governance change proposals. However, as both the rebate and the relevant fees could be changed at once the failure should occur at enactment of the proposal rather than initial validation. The criterion `max(additional_maker_rebate) <= market.fee.factors.treasuryFee + market.fee.factors.buybackFee` should be checked at changes of both the maker rebate program and the two fee factor values to ensure this constraint remains true. diff --git a/protocol/features.json b/protocol/features.json index e64160657..76377ba35 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -538,7 +538,6 @@ "0009-MRKP-037" ] }, - "Explicit liquidation range": { "milestone": "colosseo", "acs": [ @@ -547,8 +546,6 @@ "0012-POSR-033" ] }, - - "Reward Improvements": { "milestone": "colosseo", "acs": [ @@ -599,7 +596,6 @@ "0057-TRAN-079" ] }, - "Capped Futures": { "milestone": "colosseo_II", "acs": [ @@ -803,6 +799,14 @@ "0028-GOVE-191" ] }, + "Volume Discount Factor Customisation": { + "milestone": "colosseo_II", + "acs": [ + "0084-VDPR-015", + "0029-FEES-034", + "0029-FEES-035" + ] + }, "Perpetual funding rates": { "milestone": "historic_distillery", "acs": [ @@ -819,4 +823,4 @@ "milestone": "unknown", "acs": [] } -} +} \ No newline at end of file From 8ce6e8327f508e4c61cad3142476851b66717d7b Mon Sep 17 00:00:00 2001 From: Edd Date: Tue, 16 Jul 2024 16:25:41 +0100 Subject: [PATCH 1164/1171] rename 3 and rejig milestones --- protocol/features.json | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/protocol/features.json b/protocol/features.json index 76377ba35..3ff12d8f4 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -367,7 +367,7 @@ ] }, "Spot stretch": { - "milestone": "colosseo", + "milestone": "historic_distillery", "acs": [ "0029-FEES-015", "0029-FEES-016", @@ -622,7 +622,7 @@ ] }, "Model-free alternatives": { - "milestone": "colosseo_II", + "milestone": "suzuka_castle", "acs": [ "0016-PFUT-026", "0016-PFUT-027", @@ -678,11 +678,11 @@ ] }, "Fee mechanic changes": { - "milestone": "colosseo_III", + "milestone": "suzuka_castle", "acs": [] }, "vAMMs": { - "milestone": "colosseo_III", + "milestone": "suzuka_castle", "acs": [ "0042-LIQF-092", "0042-LIQF-093", @@ -754,7 +754,7 @@ ] }, "Community Tags": { - "milestone": "colosseo_III", + "milestone": "suzuka_castle", "acs": [ "0028-GOVE-168", "0028-GOVE-169", @@ -800,7 +800,7 @@ ] }, "Volume Discount Factor Customisation": { - "milestone": "colosseo_II", + "milestone": "suzuka_castle", "acs": [ "0084-VDPR-015", "0029-FEES-034", From 44ecde7531b3cbce5b695f37cfd70a9f453ed982 Mon Sep 17 00:00:00 2001 From: Edd Date: Wed, 17 Jul 2024 10:24:51 +0100 Subject: [PATCH 1165/1171] sorting --- protocol/features.json | 160 ++++++++++++++++++++--------------------- 1 file changed, 77 insertions(+), 83 deletions(-) diff --git a/protocol/features.json b/protocol/features.json index 3ff12d8f4..56e96884d 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -366,64 +366,7 @@ "0056-REWA-167" ] }, - "Spot stretch": { - "milestone": "historic_distillery", - "acs": [ - "0029-FEES-015", - "0029-FEES-016", - "0029-FEES-017", - "0029-FEES-018", - "0029-FEES-019", - "0029-FEES-020", - "0029-FEES-021", - "0029-FEES-022", - "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", - "0070-MKTD-010", - "0070-MKTD-011", - "0070-MKTD-012", - "0070-MKTD-013", - "0070-MKTD-014", - "0070-MKTD-015", - "0070-MKTD-022", - "0070-MKTD-024", - "0070-MKTD-025", - "0070-MKTD-026", - "0074-BTCH-012", - "0074-BTCH-015", - "0074-BTCH-016", - "0074-BTCH-019", - "0079-TGAP-006", - "0079-TGAP-007", - "0028-GOVE-186", - "0028-GOVE-187", - "0080-SPOT-024", - "0080-SPOT-025", - "0080-SPOT-026", - "0080-SPOT-027", - "0080-SPOT-028", - "0080-SPOT-029" - ] - }, + "Spot stop orders": { "milestone": "colosseo", "acs": [ @@ -621,23 +564,6 @@ "0019-MCAL-171" ] }, - "Model-free alternatives": { - "milestone": "suzuka_castle", - "acs": [ - "0016-PFUT-026", - "0016-PFUT-027", - "0016-PFUT-028", - "0053-PERP-047", - "0053-PERP-048", - "0053-PERP-049", - "0032-PRIM-041", - "0032-PRIM-042", - "0032-PRIM-043", - "0042-LIQF-095", - "0042-LIQF-096", - "0019-MCAL-159" - ] - }, "Transaction Ordering": { "milestone": "colosseo_II", "acs": [ @@ -677,6 +603,23 @@ "0094-PRAC-008" ] }, + "Model-free alternatives": { + "milestone": "suzuka_castle", + "acs": [ + "0016-PFUT-026", + "0016-PFUT-027", + "0016-PFUT-028", + "0053-PERP-047", + "0053-PERP-048", + "0053-PERP-049", + "0032-PRIM-041", + "0032-PRIM-042", + "0032-PRIM-043", + "0042-LIQF-095", + "0042-LIQF-096", + "0019-MCAL-159" + ] + }, "Fee mechanic changes": { "milestone": "suzuka_castle", "acs": [] @@ -799,14 +742,7 @@ "0028-GOVE-191" ] }, - "Volume Discount Factor Customisation": { - "milestone": "suzuka_castle", - "acs": [ - "0084-VDPR-015", - "0029-FEES-034", - "0029-FEES-035" - ] - }, + "Perpetual funding rates": { "milestone": "historic_distillery", "acs": [ @@ -819,6 +755,64 @@ "0028-GOVE-185" ] }, + "Spot stretch": { + "milestone": "historic_distillery", + "acs": [ + "0029-FEES-015", + "0029-FEES-016", + "0029-FEES-017", + "0029-FEES-018", + "0029-FEES-019", + "0029-FEES-020", + "0029-FEES-021", + "0029-FEES-022", + "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", + "0070-MKTD-010", + "0070-MKTD-011", + "0070-MKTD-012", + "0070-MKTD-013", + "0070-MKTD-014", + "0070-MKTD-015", + "0070-MKTD-022", + "0070-MKTD-024", + "0070-MKTD-025", + "0070-MKTD-026", + "0074-BTCH-012", + "0074-BTCH-015", + "0074-BTCH-016", + "0074-BTCH-019", + "0079-TGAP-006", + "0079-TGAP-007", + "0028-GOVE-186", + "0028-GOVE-187", + "0080-SPOT-024", + "0080-SPOT-025", + "0080-SPOT-026", + "0080-SPOT-027", + "0080-SPOT-028", + "0080-SPOT-029" + ] + }, "Unknown": { "milestone": "unknown", "acs": [] From e37430232999505d057b4b164ced8e0ea3ce32d2 Mon Sep 17 00:00:00 2001 From: Charlie Date: Tue, 16 Jul 2024 11:13:59 +0100 Subject: [PATCH 1166/1171] feat: change to average notional position --- protocol/0056-REWA-rewards_overview.md | 35 ++++++++++++++------------ protocol/features.json | 9 ++++++- 2 files changed, 27 insertions(+), 17 deletions(-) diff --git a/protocol/0056-REWA-rewards_overview.md b/protocol/0056-REWA-rewards_overview.md index bb2eafd9f..7e9153823 100644 --- a/protocol/0056-REWA-rewards_overview.md +++ b/protocol/0056-REWA-rewards_overview.md @@ -73,35 +73,36 @@ If the reward account balance is `0` at the end of the epoch for a given recurri Note, trading fees paid or received on Spot markets will contribute to fee-based reward metrics. -### Average position metric +### Average notional position metric -The average position metric, $m_{ap}$, measures each parties time-weighted average position over a number of epochs. +The average notional position metric, $m_{ap}$, measures each parties time-weighted average notional position over a number of epochs. -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. +At the start of each epoch, the network must reset each parties time weighted average notional 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. Note, to reduce computation the tracker is not updated on every mark price update, only on trades involving the relevant party. Let: -- $\bar{P}$ be the parties time weighted average position in the epoch so far -- $P_{n}$ be the parties position before their position changed +- $\bar{P}$ be the parties time weighted average notional position in the epoch so far +- $P_{n}$ be the parties notional 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 +- $S$ be the current mark price. -$$\bar{P} \leftarrow \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) + S \cdot \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. +At the end of the epoch, the network must store the parties time weighted average notional 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 +- $m_{ap}$ be the parties average notional position reward metric +- $\bar{P_{i}}$ be the parties time weighted average notional 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}$$ ### Relative return metric -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. +The relative return metric, $m_{rr}$, measures each parties average relative return, weighted by their time-weighted average position, over a number of epochs. At the end of each epoch, the network must calculate and store the parties relative returns as follows. @@ -1020,12 +1021,14 @@ At the end of epoch 2, 10000 VEGA rewards should be distributed to the `ETHUSDT` ### 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). +- If an eligible party opens a position at the beginning of the epoch, and the mark price does **not** change during the epoch, their average notional position reward metric should be equal to the notional value of the position at the end of the epoch (0056-REWA-171). +- If an eligible party opens a position at the beginning of the epoch, and the price changes during the epoch, their average notional position reward metric should be set equal to the notional value of the position at the end of the epoch (0056-REWA-172). +- If an eligible party held an open position at the start of the epoch, and the mark price does **not** change during the epoch, their average notional position reward metric should be equal to the notional value of the position at the end of the epoch (0056-REWA-173). +- If an eligible party held an open position at the start of the epoch, and the mark price does change during the epoch, their average notional position reward metric should be equal to the notional value of the position at the end of the epoch (0056-REWA-174). +- If an eligible party opens a position half way through the epoch, their average notional position reward metric should be half the notional value of the position at the end of the epoch (0056-REWA-175). +- If an eligible party held an open position at the start of the epoch and closes it half-way through the epoch, their average notional position reward metric should be equal to half the notional value of the position at the point they closed their position (0056-REWA-176). +- If an eligible party held positions in multiple in-scope markets, their average notional position reward metric should be the sum of their time-weighted-average-notional-position in each market (0056-REWA-177). +- If a `window_length>1` is specified in the recurring transfer, an eligible parties average notional position reward metric should be the average of their reward metrics over the last `window_length` epochs (0056-REWA-178). ### Relative returns diff --git a/protocol/features.json b/protocol/features.json index 56e96884d..f85f1320a 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -536,7 +536,14 @@ "0057-TRAN-076", "0057-TRAN-077", "0057-TRAN-078", - "0057-TRAN-079" + "0056-REWA-171", + "0056-REWA-172", + "0056-REWA-173", + "0056-REWA-174", + "0056-REWA-175", + "0056-REWA-176", + "0056-REWA-177", + "0056-REWA-178" ] }, "Capped Futures": { From 733fad7ccf299450fec3d08f031958d9ebcb4a72 Mon Sep 17 00:00:00 2001 From: Charlie Date: Mon, 15 Jul 2024 18:53:24 +0100 Subject: [PATCH 1167/1171] feat: calculate fraction of cumulative volume across window rather than average of fractions across window --- .../0095-HVMR-high_volume_maker_rebate.md | 46 ++++++++++++++++++- 1 file changed, 45 insertions(+), 1 deletion(-) diff --git a/protocol/0095-HVMR-high_volume_maker_rebate.md b/protocol/0095-HVMR-high_volume_maker_rebate.md index 21e43dbb2..564808b69 100644 --- a/protocol/0095-HVMR-high_volume_maker_rebate.md +++ b/protocol/0095-HVMR-high_volume_maker_rebate.md @@ -11,7 +11,51 @@ Enabling or changing the terms of the program can be proposed via governance. As - `minimum_party_maker_volume_fraction`: the required `party_maker_volume_fraction` for a party to access this tier - `additional_maker_rebate`: the additional rebate factor (in percentage of `trade_value_for_fee_purposes`) a party at this tier will receive when they are the maker side of a trade - `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 average a party's `maker_volume_fraction` +- `window_length`: the number of epochs over which to measure a party's cumulative maker volume. + + +## Calculation + +For each party, the network must track the maker volume they created in each epoch. + +At the start of an epoch the network should calculate each parties `party_maker_volume_fraction` by calculating what proportion of the maker volume over the last $m$ epochs a party made up (where m is the `window_length` set configured in the program), i.e. + +$$\text{partyMakerVolumeFraction} = \frac{\sum_{i=1}^{m}{V_i}_j}{\sum_{i=1}^{m}\sum_{j=1}^{n}{V_i}_j}$$ + +where: + +- ${V_i}_j$ is the maker volume of party `j` in epoch `i` + + +Each parties `additional_maker_rebate` is then fixed to the value in the highest tier they qualify for. A parties tier is defined as the highest tier for which their `party_maker_volume_fraction` is greater or equal to the tiers `minimum_party_maker_volume_fraction`. If a party does not qualify for any tier, their `additional_maker_rebate` is set to `0`. + +```pseudo +Given: + benefit_tiers=[ + { + "minimum_party_maker_volume_fraction": 0.1, + "additional_maker_rebate": 0.01, + }, + { + "minimum_party_maker_volume_fraction": 0.2, + "additional_maker_rebate": 0.02, + + }, + { + "minimum_party_maker_volume_fraction": 0.3, + "additional_maker_rebate": 0.03, + + }, + ] + +And: + party_maker_volume_fraction=0.23 + +Then: + additional_maker_rebate=0.02 +``` + +This `additional_maker_rebate` factor is then fixed for the duration of the next epoch. ## Application From ef95edd88d6041835061b6605c19deacc194ed89 Mon Sep 17 00:00:00 2001 From: Charlie Date: Mon, 15 Jul 2024 18:55:46 +0100 Subject: [PATCH 1168/1171] fix: update spellcheck --- spellcheck.yaml | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/spellcheck.yaml b/spellcheck.yaml index dd46032a7..e131996d5 100644 --- a/spellcheck.yaml +++ b/spellcheck.yaml @@ -38,6 +38,12 @@ matrix: # Ignore hugo/jinja tags - open: '{{' close: '}}' + # Ignore display LaTeX formulas ($$ ... $$) + - open: '\$\$' + close: '\$\$' + # Ignore display LaTeX formulas ($$ ... $$) + - open: '\$' + close: '\$' - pyspelling.filters.markdown: null - pyspelling.filters.html: comments: false From 619a4f5e2a4a12e73950b09578b413856e5977f9 Mon Sep 17 00:00:00 2001 From: David Siska <62546419+davidsiska-vega@users.noreply.github.com> Date: Fri, 26 Jul 2024 13:41:42 +0100 Subject: [PATCH 1169/1171] Order spam (#2188) * fix: clarify order spam * fix: clarify order spam * fix: clarify order spam * fix: clarify order spam * fix: clarify order spam * fix: clarify order spam * fix: clarify order spam * fix: clarify order spam * fix: clarify order spam * fix: clarify order spam * fix: wording Co-authored-by: Charlie <99198652+cdummett@users.noreply.github.com> * fix: spot correction Co-authored-by: Charlie <99198652+cdummett@users.noreply.github.com> * fix: clarify order spam * fix: clarify order spam * fix: clarify order spam * fix: clarify order spam * fix: clarify order spam * chore: clairfy spam protection for spot markets * fix: remove * fix: don't allow non-persistent orders that don't meet margin / value criteria * feat: Update spam tests on amendments * feat: Update spam tests on amendments * chore: revert inconsistent formatting * chore: fix markdownlint --------- Co-authored-by: Charlie <99198652+cdummett@users.noreply.github.com> Co-authored-by: Charlie Co-authored-by: Tom McLean --- protocol/0004-AMND-amends.md | 1 + protocol/0062-SPAM-spam_protection.md | 73 +++++++++++++++++++++++++++ protocol/features.json | 37 +++++++++++++- 3 files changed, 109 insertions(+), 2 deletions(-) diff --git a/protocol/0004-AMND-amends.md b/protocol/0004-AMND-amends.md index 4e618571b..fb8434cc9 100644 --- a/protocol/0004-AMND-amends.md +++ b/protocol/0004-AMND-amends.md @@ -27,6 +27,7 @@ - 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) +- An amendment which would result in the margin requirement for the order being smaller than `spam.order.minimalMarginQuantumMultiple` should fail with the order remaining unchanged (0004-AMND-061) For a party with no position on a given market: diff --git a/protocol/0062-SPAM-spam_protection.md b/protocol/0062-SPAM-spam_protection.md index 87cc36501..d71f80ce8 100644 --- a/protocol/0062-SPAM-spam_protection.md +++ b/protocol/0062-SPAM-spam_protection.md @@ -83,6 +83,41 @@ Further, each party is allowed to submit up to `n` transactions per epoch where **Note** `spam.protection.max.updatePartyProfile` must be an integer greater than or equal to `0` (and default to `5`). +### Transaction Spam + +#### Derivative markets + +Before any order or liquidity commitment is accepted for a perpetual futures or expiring futures check that the party has `margin + order margin + general > 0` with `margin` being the balance in the margin account for the relevant, `order margin` is the balance for the order margin if party is in isolated margin mode for the for the relevant market and `general` the balance in the general account for the relevant asset. Orders from parties that don't meet this criteria are rejected. This is to be done after the PoW check. + +Further, given the network parameter: `spam.order.minimalMarginQuantumMultiple` (between 0 and infinite) + +If the maintenance margin for a given transaction is smaller than the parameter `spam.order.minimalMarginQuantumMultiple`, then the transaction is pre-block rejected. +I.e. if `(rf + linear slippage param) x size x price < spam.order.minimalMarginQuantumMultiple x asset quantum amount` then the order is rejected. Here `rf` is the risk factor (and will be different for long and for short) `linear slippage param` is a market parameter and `size` and `price` are assumed to be correctly scaled by, PDPs and MDPs respectively. + +For pegged orders `mark price +/- offset` should be used in place of price. The `mark price` value can be cached from end of last block (if that helps for performance, we need this to be cheap). In opening auctions pegged orders should be rejected. + +For stop / position linked orders: we don't necessarily have either price or size. However there is a limit on the number per key so we let these through. + +Finally, if the market does not exist and thus the maintenance margin is not defined, the transaction is rejected. + +#### Spot markets + +Before any order or liquidity commitment is accepted for a spot market, check that the party has balances where `holding + general > 0` for the asset that the order is potentially disposing of / committing in terms of liquidity. Orders from parties that don't meet this criteria are rejected. This is to be done after the PoW check. + +Further, given the network parameter: `spam.order.minimalHoldingQuantumMultiple` (between 0 and infinite) + +If the holding requirement for a given transaction is smaller than the parameter `spam.order.minimalHoldingQuantumMultiple`, then the transaction is pre-block rejected. +I.e. if `size x price < spam.order.minimalHoldingQuantumMultiple x quote asset quantum amount` then the order is rejected. Here `size` and `price` are assumed to be correctly scaled by, PDPs and MDPs respectively. + +For pegged orders `last traded price +/- offset` should be used in place of price. The `last traded price` value can be cached from end of last block (if that helps for performance). In opening auctions pegged orders should be rejected. + +#### All markets + +The following points apply generally to both derivative and spot markets: + +- For amendments and cancellations: Check that the party has at least `spam.order.minimalMarginQuantumMultiple` margin within the margin account on the market of the order, implying they have active orders or positions on the market. If they do not then reject the transaction. +- For batch transactions: each order has to pass its own order spam check; if any order in the batch fails the check then reject the whole batch. +- Checks should be completed before the gas cost calculation as rejected transactions should not get into the calculation of the gas cost. ### Related topics @@ -128,4 +163,42 @@ 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.updatePartyProfile` `UpdatePartyProfile` transactions in an epoch should have any future `UpdatePartyProfile` transactions in that epoch **pre-block** rejected (0062-SPAM-038). - A party who has submitted more than `spam.protection.max.updatePartyProfile` `UpdatePartyProfile` transactions in the current epoch plus in the current block, should have their `UpdatePartyProfile` transactions submitted in the current block **pre-block** rejected (0062-SPAM-039). +- In a derivatives market, issue a set of orders starting with the minimum price, and doubling the order price with every order. Once the first order passes the spam filter, quadruple the parameter `spam.order.minimalMarginQuantumMultiple` and continue. Once the next order passes the filter, quadruple the quantum size for the underlying asset, and continue until an order passes the filter again. Verify that all rejected orders had a margin smaller than `spam.order.minimalMarginQuantumMultiple`, and all accepted ones one bigger or equal. (0062-SPAM-043). +- In a derivatives market, issue a set of orders for an existing, but not yet enacted market, starting with the minimum price, and doubling the order price with every order. Once the first order passes the spam filter, quadruple the parameter `spam.order.minimalMarginQuantumMultiple` and continue. Once the next order passes the filter, quadruple the quantum size for the underlying asset, and continue until an order passes the filter again. Verify that all rejected orders had a margin smaller than `spam.order.minimalMarginQuantumMultiple`, and all accepted ones one bigger or equal. (0062-SPAM-044). +- Create an order for a non-existing derivatives market, and verify that it is rejected by the spam filter. (0062-SPAM-045). +- In a derivatives market, pegged orders are rejected during an opening auction (0062-SPAM-047). +- In a derivatives market, Pegged orders are accepted once the market has a mark price and the mark price is used as the reference price for the spam check purposes and the order meets `spam.order.minimalMarginQuantumMultiple` requirement (0062-SPAM-048). +- In a derivatives market, pegged orders are rejected if the market has a mark price and the mark price is used as the reference price for the spam check purposes *but* the order fails `spam.order.minimalMarginQuantumMultiple` requirement (0062-SPAM-049). +- In a derivatives market, batch order is accepted if all orders in batch individually meet the `spam.order.minimalMarginQuantumMultiple` requirement (0062-SPAM-050). +- In a derivatives market, batch order is rejected if one or more orders in batch individually *fail to meet* the `spam.order.minimalMarginQuantumMultiple` requirement (0062-SPAM-062). +- In a derivatives market, order amends are accepted if the order with the new price / size meets the `spam.order.minimalMarginQuantumMultiple` requirement (0062-SPAM-051). +- In a derivatives market, order amends are rejected if the order with the new price / size meets *fails to meet* the `spam.order.minimalMarginQuantumMultiple` requirement (0062-SPAM-052). + +- In a spot market, issue a set of orders starting with the minimum price, and doubling the order price with every order. Once the first order passes the spam filter, quadruple the parameter `spam.order.minimalHoldingQuantumMultiple` and continue. Once the next order passes the filter, quadruple the quantum size for the underlying asset, and continue until an order passes the filter again. Verify that all rejected orders had a margin smaller than `spam.order.minimalHoldingQuantumMultiple`, and all accepted ones one bigger or equal. (0062-SPAM-064). +- In a spot market, pegged orders are rejected during an opening auction (0062-SPAM-066). +- In a spot market, pegged orders are accepted once the market has a last trade price and the last trade price is used as the reference price for the spam check purposes and the order meets `spam.order.minimalHoldingQuantumMultiple` requirement (0062-SPAM-067). +- In a spot market, pegged orders are rejected if the market has a last trade price and the last trade price is used as the reference price for the spam check purposes *but* the order fails `spam.order.minimalHoldingQuantumMultiple` requirement (0062-SPAM-068). +- In a spot market, batch order is accepted if all orders in batch individually meet the `spam.order.minimalHoldingQuantumMultiple` requirement (0062-SPAM-069). +- In a spot market, batch order is rejected if one or more orders in batch individually *fail to meet* the `spam.order.minimalHoldingQuantumMultiple` requirement (0062-SPAM-070). +- In a spot market, order amends are accepted if the order with the new price / size meets the `spam.order.minimalHoldingQuantumMultiple` requirement (0062-SPAM-071). +- In a spot market, order amends are rejected if the order with the new price / size meets *fails to meet* the `spam.order.minimalHoldingQuantumMultiple` requirement (0062-SPAM-072). + +#### Balance checks + +On perps and futures markets order are rejected `margin + order margin + general = 0` with `margin` being the margin account balance for the relevant market, `order margin` being the order margin account balance for the relevant market and general being the general account balance for the settlement asset for the market for + +- market orders in cross margin mode and in isolated margin mode (0062-SPAM-053). +- limit orders in cross margin mode and in isolated margin mode (0062-SPAM-054). +- pegged orders in cross margin mode and in isolated margin mode (0062-SPAM-055). +- liquidity commitment (0062-SPAM-056). +- stop-loss / position-linked order in cross margin mode and in isolated margin mode (0062-SPAM-057). + +On spot markets orders are rejected if `holding + general = 0` for the asset that the order is (or potentially is) disposing of with the following order types + +- market orders (0062-SPAM-063). +- limit orders (0062-SPAM-058). +- pegged orders (0062-SPAM-059). +- liquidity commitment (0062-SPAM-060). +- stop-loss / position-linked order (0062-SPAM-061). + > **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 f85f1320a..b0ea3f7e1 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -486,7 +486,40 @@ "acs": [ "0012-POSR-031", "0012-POSR-032", - "0012-POSR-033" + "0012-POSR-033"] + }, + "Order spam": { + "milestone": "colosseo_II", + "acs": [ + "0062-SPAM-043", + "0062-SPAM-044", + "0062-SPAM-045", + "0062-SPAM-047", + "0062-SPAM-048", + "0062-SPAM-049", + "0062-SPAM-050", + "0062-SPAM-051", + "0062-SPAM-052", + "0062-SPAM-053", + "0062-SPAM-054", + "0062-SPAM-055", + "0062-SPAM-056", + "0062-SPAM-057", + "0062-SPAM-058", + "0062-SPAM-059", + "0062-SPAM-060", + "0062-SPAM-061", + "0062-SPAM-062", + "0062-SPAM-063", + "0062-SPAM-064", + "0062-SPAM-066", + "0062-SPAM-067", + "0062-SPAM-068", + "0062-SPAM-069", + "0062-SPAM-070", + "0062-SPAM-071", + "0062-SPAM-072", + "0004-AMND-061" ] }, "Reward Improvements": { @@ -824,4 +857,4 @@ "milestone": "unknown", "acs": [] } -} \ No newline at end of file +} From e97ab907f6b763be7e8d8ae696ca82863dd55a36 Mon Sep 17 00:00:00 2001 From: Charlie <99198652+cdummett@users.noreply.github.com> Date: Mon, 29 Jul 2024 11:00:48 +0100 Subject: [PATCH 1170/1171] Revert "feat: average notional position" (#2320) --- protocol/0056-REWA-rewards_overview.md | 35 ++++++++++++-------------- protocol/features.json | 9 +------ 2 files changed, 17 insertions(+), 27 deletions(-) diff --git a/protocol/0056-REWA-rewards_overview.md b/protocol/0056-REWA-rewards_overview.md index 7e9153823..bb2eafd9f 100644 --- a/protocol/0056-REWA-rewards_overview.md +++ b/protocol/0056-REWA-rewards_overview.md @@ -73,36 +73,35 @@ If the reward account balance is `0` at the end of the epoch for a given recurri Note, trading fees paid or received on Spot markets will contribute to fee-based reward metrics. -### Average notional position metric +### Average position metric -The average notional position metric, $m_{ap}$, measures each parties time-weighted average notional position 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 notional 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. Note, to reduce computation the tracker is not updated on every mark price update, only on trades involving the relevant party. +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{P}$ be the parties time weighted average notional position in the epoch so far -- $P_{n}$ be the parties notional position before their position 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 -- $S$ be the current mark price. -$$\bar{P} \leftarrow \bar{P} \cdot \left(1 - \frac{t_{n}}{t}\right) + S \cdot \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 notional position and then calculate their average position 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_{ap}$ be the parties average notional position reward metric -- $\bar{P_{i}}$ be the parties time weighted average notional position in the $i$-th epoch +- $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_{ap} = \frac{\sum_{i}^{n}\bar{P_{i}}}{N}$$ ### Relative return metric -The relative return metric, $m_{rr}$, measures each parties average relative return, weighted by their time-weighted average position, over a number of epochs. +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 relative returns as follows. @@ -1021,14 +1020,12 @@ At the end of epoch 2, 10000 VEGA rewards should be distributed to the `ETHUSDT` ### Average Position -- If an eligible party opens a position at the beginning of the epoch, and the mark price does **not** change during the epoch, their average notional position reward metric should be equal to the notional value of the position at the end of the epoch (0056-REWA-171). -- If an eligible party opens a position at the beginning of the epoch, and the price changes during the epoch, their average notional position reward metric should be set equal to the notional value of the position at the end of the epoch (0056-REWA-172). -- If an eligible party held an open position at the start of the epoch, and the mark price does **not** change during the epoch, their average notional position reward metric should be equal to the notional value of the position at the end of the epoch (0056-REWA-173). -- If an eligible party held an open position at the start of the epoch, and the mark price does change during the epoch, their average notional position reward metric should be equal to the notional value of the position at the end of the epoch (0056-REWA-174). -- If an eligible party opens a position half way through the epoch, their average notional position reward metric should be half the notional value of the position at the end of the epoch (0056-REWA-175). -- If an eligible party held an open position at the start of the epoch and closes it half-way through the epoch, their average notional position reward metric should be equal to half the notional value of the position at the point they closed their position (0056-REWA-176). -- If an eligible party held positions in multiple in-scope markets, their average notional position reward metric should be the sum of their time-weighted-average-notional-position in each market (0056-REWA-177). -- If a `window_length>1` is specified in the recurring transfer, an eligible parties average notional position reward metric should be the average of their reward metrics over the last `window_length` epochs (0056-REWA-178). +- 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 diff --git a/protocol/features.json b/protocol/features.json index b0ea3f7e1..330642ede 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -569,14 +569,7 @@ "0057-TRAN-076", "0057-TRAN-077", "0057-TRAN-078", - "0056-REWA-171", - "0056-REWA-172", - "0056-REWA-173", - "0056-REWA-174", - "0056-REWA-175", - "0056-REWA-176", - "0056-REWA-177", - "0056-REWA-178" + "0057-TRAN-079" ] }, "Capped Futures": { From bdf2baeeb14fd483fd77a0d373d1214dce868c89 Mon Sep 17 00:00:00 2001 From: Charlie <99198652+cdummett@users.noreply.github.com> Date: Wed, 31 Jul 2024 14:52:00 +0100 Subject: [PATCH 1171/1171] chore: remove suzukacastle features from colosseo_II branch (#2325) * Revert "Merge pull request #2315 from vegaprotocol/feat/maker_rebate_update" This reverts commit 09dd85abd3086f77a9de5d568576c54426a1d881, reversing changes made to 44ecde7531b3cbce5b695f37cfd70a9f453ed982. * Revert "feat: separate fee discount components (#2293)" This reverts commit 0e9ab96b3c6ef567aa4b2d784b9edec41ad6c173. --- protocol/0029-FEES-fees.md | 61 ++++-------- .../0083-RFPR-on_chain_referral_program.md | 96 ++++--------------- protocol/0084-VDPR-volume_discount_program.md | 54 +++-------- .../0095-HVMR-high_volume_maker_rebate.md | 70 -------------- protocol/features.json | 5 +- spellcheck.yaml | 6 -- 6 files changed, 54 insertions(+), 238 deletions(-) delete mode 100644 protocol/0095-HVMR-high_volume_maker_rebate.md diff --git a/protocol/0029-FEES-fees.md b/protocol/0029-FEES-fees.md index 31f40d451..6573baea3 100644 --- a/protocol/0029-FEES-fees.md +++ b/protocol/0029-FEES-fees.md @@ -9,7 +9,7 @@ An order may cross with more than one other order, creating multiple trades. Eac The trading fee is: -`total_fee = infrastructure_fee + maker_fee + liquidity_fee + buyback_fee + treasury_fee` +`total_fee = infrastructure_fee + maker_fee + liquidity_fee` `infrastructure_fee = fee_factor[infrastructure] * trade_value_for_fee_purposes` @@ -17,10 +17,6 @@ The trading fee is: `liquidity_fee = fee_factor[liquidity] * trade_value_for_fee_purposes` -`buyback_fee = fee_factor[buyback] * trade_value_for_fee_purposes` - -`treasury_fee = fee_factor[treasury] * trade_value_for_fee_purposes` - Fees are calculated and collected in the settlement currency of the market, collected from the general account. Fees are collected first from the trader's account and then margin from account balance. If the general account doesn't have sufficient balance, then the remaining fee amount is collected from the margin account. If this is still insufficient then different rules apply between continuous trading and auctions (details below). Note that maker_fee = 0 if there is no maker, taker relationship between the trading parties (in particular auctions). @@ -29,14 +25,14 @@ 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 other and **before** rewards are calculated. Additionally, no benefit discounts can be applied to the treasury or buyback fee components as these may be required for the `high volume market maker rebate`. +Note, discounts are calculated and applied one after the other and **before** rewards are calculated. 1. Calculate any referral discounts due to the party. ```pseudo - infrastructure_fee_referral_discount = floor(original_infrastructure_fee * referral_infrastructure_discount_factor) - liquidity_fee_referral_discount = floor(original_liquidity_fee * referral_liquidity_discount_factor) - maker_fee_referral_discount = floor(original_maker_fee * referral_maker_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. @@ -50,9 +46,9 @@ Note, discounts are calculated and applied one after the other and **before** re 1. Calculate any volume discounts due to the party. ```pseudo - infrastructure_fee_volume_discount = floor(infrastructure_fee_after_referral_discount * volume_infrastructure_discount_factor) - liquidity_fee_volume_discount = floor(liquidity_fee_after_referral_discount * volume_liquidity_discount_factor) - maker_fee_volume_discount = floor(maker_fee_after_referral_discount * volume_maker_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. Apply any volume discounts to the fee after referral discounts. @@ -66,9 +62,9 @@ Note, discounts are calculated and applied one after the other and **before** re 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_after_volume_discount * min(referral_infrastructure_reward_factor * referral_reward_multiplier, referralProgram.maxReferralRewardProportion)) - liquidity_fee_referral_reward = floor(liquidity_fee * min(liquidity_fee_after_volume_discount * min(referral_liquidity_reward_factor * referral_reward_multiplier, referralProgram.maxReferralRewardProportion))) - maker_fee_referral_reward = floor(maker_fee * min(maker_fee_after_volume_discount * min(referral_maker_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. @@ -86,14 +82,10 @@ Note, discounts are calculated and applied one after the other and **before** re - infrastructure: staking/governance system/engine (network wide) - maker: market framework / market making (network wide) - liquidity: market making system (per market) -- treasury: Fees sent to network treasury for later usage via governance votes (network wide) -- buyback: Fees used to purchase governance tokens to the protocol via regular auctions (network wide) The infrastructure fee factor is set by a network parameter `market.fee.factors.infrastructureFee` and a reasonable default value is `fee_factor[infrastructure] = 0.0005 = 0.05%`. The maker fee factor is set by a network parameter `market.fee.factors.makerFee` and a reasonable default value is `fee_factor[maker] = 0.00025 = 0.025%`. The liquidity fee factor is set by an auction-like mechanism based on the liquidity provisions committed to the market, see [setting LP fees](./0042-LIQF-setting_fees_and_rewarding_lps.md). -The treasury fee factor is set by the network parameter `market.fee.factors.treasuryFee` with a default value should of `0`. -The buyback fee factor is set by the network parameter `market.fee.factors.buybackFee` with a default value should of `0`. trade_value_for_fee_purposes: @@ -115,26 +107,15 @@ If the transfer fails: 1. If we are in continuous trading mode, than trades should be discarded, any orders on the book that would have been hit should remain in place with previous remaining size intact and the incoming order should be rejected (not enough fees error). This functionality requires to match orders and create trades without changing the state of the order book or passing trades downstream so that the execution of the transaction can be discarded with no impact on the order book if needed. Other than the criteria whether to proceed or discard, this is exactly the same functionality required to implement [price monitoring](./0032-PRIM-price_monitoring.md). -1. If we are in auction mode, ignore the shortfall (and see more details below). - -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 different components. +2. If we are in auction mode, ignore the shortfall (and see more details below). -Additionally, a `high_volume_market_maker_rebate` may be necessary which will be taken from the `treasury/buyback_fee` components. This will be calculated as: - -1. Determine whether the maker party of the trade (if there is one) qualifies for a `high volume market maker rebate` and, if so, at what rate. -1. Calculate the fee that this corresponds to as `high_volume_maker_fee = high_volume_factor * trade_value_for_fee_purposes`. -1. Take this fee from the `treasury_fee` and `buyback_fee` (protocol restrictions on governance changes ensure that `treasury_fee + buyback_fee >= high_volume_maker_fee` is always true) as a proportion of their relative sizes, i.e.: - 1. `high_volume_maker_fee = high_volume_factor * trade_value_for_fee_purposes` - 1. `treasury_fee = treasury_fee * (1 - high_volume_maker_fee / (treasury_fee + buyback_fee))` - 1. `buyback_fee = buyback_fee * (1 - high_volume_maker_fee / (treasury_fee + buyback_fee))` +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 [apply benefit factors](#applying-benefit-factors) and then distribute funds from the "temporary fee bucket" as follows: 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` and any `high_volume_maker_fee` are transferred to the relevant party (the maker). +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 `treasury_fee` is transferred to the treasury fee pool for that asset, where it will remain until community governance votes for transfers. -1. The `buyback_fee` is transferred to the buyback fee pool for that asset, where it will remain until community governance votes for transfers or a regular purchase program is set up. 1. The referral fee components (if any) can then be individually transferred to the relevant party (the referee). ### During Continuous Trading @@ -145,9 +126,9 @@ The "aggressor or price taker" pays the fee. The "passive or price maker" party ### Normal Auctions (including market protection and opening auctions) -During normal auctions there is no "price maker" both parties are "takers". Each side in a matched trade should contribute 1/2 of the infrastructure_fee + liquidity_fee + treasury_fee + buyback_fee. Note that this does not include a maker fee. +During normal auctions there is no "price maker" both parties are "takers". Each side in a matched trade should contribute 1/2 of the infrastructure_fee + liquidity_fee. Note that this does not include a maker fee. -Fees calculated and collected from general + margin as in continuous trading *but* if a party has insufficient capital to cover the trading fee then in auction the trade *still* *goes* *ahead* as long as the margin account should have enough left after paying the fees to cover maintenance level of margin for the orders and then converted trades. The fee is distributed so that the infrastructure_fee is paid first and only then the liquidity_fee/treasury_fee/buyback_fee. +Fees calculated and collected from general + margin as in continuous trading *but* if a party has insufficient capital to cover the trading fee then in auction the trade *still* *goes* *ahead* as long as the margin account should have enough left after paying the fees to cover maintenance level of margin for the orders and then converted trades. The fee is distributed so that the infrastructure_fee is paid first and only then the liquidity_fee. During an opening auction of a market, no fees are collected. @@ -187,11 +168,7 @@ 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 (assuming no volume discounts due to party) (0029-FEES-023) - - `infrastructure_fee_referral_discount` - - `liquidity_fee_referral_discount` - - `maker_fee_referral_discount` -1. Referee discounts with differing discounts across the three factors are correctly calculated and applied for each taker fee component during continuous trading (assuming no volume discounts due to party) (0029-FEES-034) - - `infrastructure_fee_referral_discount` + - `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 (assuming no volume discounts due to party) (0029-FEES-024) @@ -201,10 +178,6 @@ For example, Ether is 18 decimals (wei). The smallest unit, non divisible is 1 w - `infrastructure_fee_referral_reward` - `liquidity_fee_referral_reward` - `maker_fee_referral_reward` -1. Referrer rewards with differing reward factors are correctly calculated and transferred for each fee component during continuous trading (assuming no volume discounts due to party) (0029-FEES-035) - - `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 (assuming no volume discounts due to party) (0029-FEES-026) - `infrastructure_fee_referral_reward` - `liquidity_fee_referral_reward` diff --git a/protocol/0083-RFPR-on_chain_referral_program.md b/protocol/0083-RFPR-on_chain_referral_program.md index 74da638d7..39846dbe4 100644 --- a/protocol/0083-RFPR-on_chain_referral_program.md +++ b/protocol/0083-RFPR-on_chain_referral_program.md @@ -46,14 +46,8 @@ 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_factors`: the proportions of the referee's taker fees to be rewarded to the referrer - - `referral_maker_reward_factor`: the factor to reward the referrer from the maker fee component of any fees paid - - `referral_infrastructure_reward_factor`: the factor to reward the referrer from the infrastructure fee component of any fees paid - - `referral_liquidity_reward_factor`: the factor to reward the referrer from the liquidity provider fee component of any fees paid - - `referral_discount_factors`: the proportions of the referee's taker fees to be discounted - - `referral_maker_discount_factor`: the factor to discount the maker fee component of any fees paid - - `referral_infrastructure_discount_factor`: the factor to discount the infrastructure fee component of any fees paid - - `referral_liquidity_discount_factor`: the factor to discount the liquidity provider fee component of any fees paid + - `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. @@ -67,44 +61,20 @@ message UpdateReferralProgram{ { "minimum_running_notional_taker_volume": 10000, "minimum_epochs": 1, - "referral_reward_factors": { - "referral_maker_reward_factor": 0.001, - "referral_infrastructure_reward_factor": 0.001, - "referral_liquidity_reward_factor": 0.001 - }, - "referral_discount_factors": { - "referral_maker_discount_factor": 0.001, - "referral_infrastructure_discount_factor": 0.001, - "referral_liquidity_discount_factor": 0.001 - } + "referral_reward_factor": 0.001, + "referral_discount_factor": 0.001, }, { "minimum_running_notional_taker_volume": 20000, "minimum_epochs": 7, - "referral_reward_factors": { - "referral_maker_reward_factor": 0.005, - "referral_infrastructure_reward_factor": 0.005, - "referral_liquidity_reward_factor": 0.005 - }, - "referral_discount_factors": { - "referral_maker_discount_factor": 0.005, - "referral_infrastructure_discount_factor": 0.005, - "referral_liquidity_discount_factor": 0.005 - }, + "referral_reward_factor": 0.005, + "referral_discount_factor": 0.005, }, { "minimum_running_notional_taker_volume": 30000, "minimum_epochs": 31, - "referral_reward_factors": { - "referral_maker_reward_factor": 0.01, - "referral_infrastructure_reward_factor": 0.01, - "referral_liquidity_reward_factor": 0.01 - }, - "referral_discount_factors": { - "referral_maker_discount_factor": 0.01, - "referral_infrastructure_discount_factor": 0.01, - "referral_liquidity_discount_factor": 0.01 - }, + "referral_reward_factor": 0.010, + "referral_discount_factor": 0.010, }, ], staking_tiers: [ @@ -133,11 +103,11 @@ 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.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_factors` values must be greater than `0` and less than or equal to the network parameter `referralProgram.maxReferralRewardFactor`. +- all `referral_reward_factor` values must be greater than `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 strictly greater than `0`. - all `referral_reward_multiplier` values must be a float value greater than or equal to `1`. -- all `referral_discount_factors` values must be greater than `0` and be less than or equal to the network parameter `referralProgram.maxReferralDiscountFactor`. +- all `referral_discount_factor` values must be greater than `0` and be less than or equal to the network parameter `referralProgram.maxReferralDiscountFactor`. - `window_length` must be an integer strictly greater than zero. The referral program will start the epoch after the `enactment_timestamp` is reached. @@ -316,28 +286,28 @@ The network can then calculate the set's `referral_set_running_notional_taker_vo ### Setting benefit factors and reward multipliers -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_factors` and `referral_discount_factors` 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 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_factors` should be set by identifying the "highest" benefit tier where the following conditions are fulfilled. +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 tier's `minimum_running_notional_taker_volume`. -The referee's `referral_reward_factors` are then set to the `referral_reward_factors` 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. #### Setting the referral discount factor -The `referral_discount_factors` should be set by identifying the "highest" benefit tier where **BOTH** the following conditions are fulfilled. +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 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 referee's `referral_discount_factors` are then set to the `referral_discount_factors` 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. @@ -359,44 +329,20 @@ Given: { "minimum_running_notional_taker_volume": 10000, "minimum_epochs": 0, - "referral_reward_factor": { - "maker_reward_factor": 0.001, - "infrastructure_reward_factor": 0.001, - "liquidity_reward_factor": 0.001 - }, - "referral_discount_factor": { - "maker_discount_factor": 0.001, - "infrastructure_discount_factor": 0.001, - "liquidity_discount_factor": 0.001 - }, + "referral_reward_factor": 0.001, + "referral_discount_factor": 0.001, }, { "minimum_running_notional_taker_volume": 20000, "minimum_epochs": 7, - "referral_reward_factor": { - "maker_reward_factor": 0.005, - "infrastructure_reward_factor": 0.005, - "liquidity_reward_factor": 0.005 - }, - "referral_discount_factor": { - "maker_discount_factor": 0.005, - "infrastructure_discount_factor": 0.005, - "liquidity_discount_factor": 0.005 - }, + "referral_reward_factor": 0.005, + "referral_discount_factor": 0.005, }, { "minimum_running_notional_taker_volume": 30000, "minimum_epochs": 31, - "referral_reward_factor": { - "maker_reward_factor": 0.01, - "infrastructure_reward_factor": 0.01, - "liquidity_reward_factor": 0. 01 - }, - "referral_discount_factor": { - "maker_discount_factor": 0.01, - "infrastructure_discount_factor": 0.01, - "liquidity_discount_factor": 0.01 - }, + "referral_reward_factor": 0.010, + "referral_discount_factor": 0.010, }, ] staking_tiers: [ diff --git a/protocol/0084-VDPR-volume_discount_program.md b/protocol/0084-VDPR-volume_discount_program.md index 861e9811f..efbd1ef26 100644 --- a/protocol/0084-VDPR-volume_discount_program.md +++ b/protocol/0084-VDPR-volume_discount_program.md @@ -17,10 +17,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_factors`: a dictionary with the following fields - - `maker_discount_factor`: the factor to discount the maker fee component of any fees paid - - `infrastructure_discount_factor`: the factor to discount the infrastructure fee component of any fees paid - - `lp_discount_factor`: the factor to discount the liquidity provider fee component of any fees paid + - `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 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 @@ -30,27 +27,15 @@ message UpdateVolumeDiscountProgram{ benefit_tiers: [ { "minimum_party_running_notional_taker_volume": 1000, - "volume_discount_factors": { - "maker_discount_factor": 0.001, - "infrastructure_discount_factor": 0.001, - "lp_discount_factor": 0.001 - } + "volume_discount_factor": 0.001, }, { "minimum_party_running_notional_taker_volume": 20000, - "volume_discount_factors": { - "maker_discount_factor": 0.002, - "infrastructure_discount_factor": 0.002, - "lp_discount_factor": 0.002 - } + "volume_discount_factor": 0.002, }, { "minimum_party_running_notional_taker_volume": 30000, - "volume_discount_factors": { - "maker_discount_factor": 0.003, - "infrastructure_discount_factor": 0.003, - "lp_discount_factor": 0.003 - } + "volume_discount_factor": 0.003, }, ], end_of_program_timestamp: 123456789, @@ -64,7 +49,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_factors` values must be greater than or equal to `0` and less than or equal to the network parameter `volumeDiscountProgram.maxVolumeDiscountFactor`. +- 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. @@ -93,27 +78,15 @@ Given: benefit_tiers=[ { "minimum_party_running_notional_taker_volume": 10000, - "volume_discount_factors": { - "maker_discount_factor": 0.001, - "infrastructure_discount_factor": 0.001, - "lp_discount_factor": 0.001 - } + "volume_discount_factor": 0.001, }, { "minimum_party_running_notional_taker_volume": 20000, - "volume_discount_factors": { - "maker_discount_factor": 0.005, - "infrastructure_discount_factor": 0.005, - "lp_discount_factor": 0.005 - } + "volume_discount_factor": 0.005, }, { "minimum_party_running_notional_taker_volume": 30000, - "volume_discount_factors": { - "maker_discount_factor": 0.05, - "infrastructure_discount_factor": 0.05, - "lp_discount_factor": 0.05 - } + "volume_discount_factor": 0.010, }, ] @@ -121,9 +94,7 @@ And: party_running_notional_taker_volume=22353 Then: - maker_volume_discount_factor=0.005 - infrastructure_volume_discount_factor=0.005 - lp_volume_discount_factor=0.005 + volume_discount_factor=0.005 ``` This benefit factor is then fixed for the duration of the next epoch. @@ -138,7 +109,7 @@ The Parties API should expose the following information: - a list of all **parties** (by `id`) and the following metrics: - current `party_running_notional_taker_volume` (value at the start of the epoch) - - current `volume_discount_factors` applied to fees + - current `volume_discount_factor` applied to fees - the total amount discounted for the party The Trades API should now also expose the following additional information for every trade: @@ -156,7 +127,7 @@ The Trades API should now also expose the following additional information for e - 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_factors` values must be greater than or equal to `0` and less than or equal to the network parameter `volumeDiscountProgram.maxVolumeDiscountFactor` (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). @@ -172,7 +143,6 @@ The Trades API should now also expose the following additional information for e ### Setting benefit factors -1. At the start of an epoch, each parties `volume_discount_factors` are reevaluated and fixed for the epoch (0084-VDPR-012). +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). -1. A `volume_discount_factors` tier with differing factors across the three options has each factor set correctly (0084-VDPR-018). diff --git a/protocol/0095-HVMR-high_volume_maker_rebate.md b/protocol/0095-HVMR-high_volume_maker_rebate.md deleted file mode 100644 index 564808b69..000000000 --- a/protocol/0095-HVMR-high_volume_maker_rebate.md +++ /dev/null @@ -1,70 +0,0 @@ -# High Volume Maker Rebate - -The high volume maker rebate program is a network-wide community governed set of parameters to provide an additional reward to market makers on the network who are involved in a significant fraction of all trading on the network. When enabled, eligible market makers receive an additional fraction of trading fees from trades in which they are involved on top of any standard received maker fee (and would receive this even were the default maker fee removed). - -## Configuration - -The configuration of the High Volume Maker rebate is performed very similarly to that of the [volume discount program](./0084-VDPR-volume_discount_program.md): -Enabling or changing the terms of the 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_maker_volume_fraction`: the required `party_maker_volume_fraction` for a party to access this tier - - `additional_maker_rebate`: the additional rebate factor (in percentage of `trade_value_for_fee_purposes`) a party at this tier will receive when they are the maker side of a trade -- `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 measure a party's cumulative maker volume. - - -## Calculation - -For each party, the network must track the maker volume they created in each epoch. - -At the start of an epoch the network should calculate each parties `party_maker_volume_fraction` by calculating what proportion of the maker volume over the last $m$ epochs a party made up (where m is the `window_length` set configured in the program), i.e. - -$$\text{partyMakerVolumeFraction} = \frac{\sum_{i=1}^{m}{V_i}_j}{\sum_{i=1}^{m}\sum_{j=1}^{n}{V_i}_j}$$ - -where: - -- ${V_i}_j$ is the maker volume of party `j` in epoch `i` - - -Each parties `additional_maker_rebate` is then fixed to the value in the highest tier they qualify for. A parties tier is defined as the highest tier for which their `party_maker_volume_fraction` is greater or equal to the tiers `minimum_party_maker_volume_fraction`. If a party does not qualify for any tier, their `additional_maker_rebate` is set to `0`. - -```pseudo -Given: - benefit_tiers=[ - { - "minimum_party_maker_volume_fraction": 0.1, - "additional_maker_rebate": 0.01, - }, - { - "minimum_party_maker_volume_fraction": 0.2, - "additional_maker_rebate": 0.02, - - }, - { - "minimum_party_maker_volume_fraction": 0.3, - "additional_maker_rebate": 0.03, - - }, - ] - -And: - party_maker_volume_fraction=0.23 - -Then: - additional_maker_rebate=0.02 -``` - -This `additional_maker_rebate` factor is then fixed for the duration of the next epoch. - -## Application - -As variable fees for the taker depending upon with whom they are trading would not be a good experience, the additional maker rebate should be taken from a weighted combination of the network treasury and network buyback components of the total fee. The exact calculations are laid out in [0029-FEES](./0029-FEES-fees.md) but are broadly: - - 1. `high_volume_maker_fee = high_volume_factor * trade_value_for_fee_purposes` - 1. `treasury_fee = treasury_fee * (1 - high_volume_maker_fee / (treasury_fee + buyback_fee))` - 1. `buyback_fee = treasury_fee * (1 - buyback_fee / (treasury_fee + buyback_fee))` - -## Governance Requirements - -As the rebate possible level interacts with other fee settings there must be a restriction on it's possible values in governance change proposals. However, as both the rebate and the relevant fees could be changed at once the failure should occur at enactment of the proposal rather than initial validation. The criterion `max(additional_maker_rebate) <= market.fee.factors.treasuryFee + market.fee.factors.buybackFee` should be checked at changes of both the maker rebate program and the two fee factor values to ensure this constraint remains true. diff --git a/protocol/features.json b/protocol/features.json index 330642ede..25ed39720 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -481,6 +481,7 @@ "0009-MRKP-037" ] }, + "Explicit liquidation range": { "milestone": "colosseo", "acs": [ @@ -522,6 +523,8 @@ "0004-AMND-061" ] }, + + "Reward Improvements": { "milestone": "colosseo", "acs": [ @@ -572,6 +575,7 @@ "0057-TRAN-079" ] }, + "Capped Futures": { "milestone": "colosseo_II", "acs": [ @@ -775,7 +779,6 @@ "0028-GOVE-191" ] }, - "Perpetual funding rates": { "milestone": "historic_distillery", "acs": [ diff --git a/spellcheck.yaml b/spellcheck.yaml index e131996d5..dd46032a7 100644 --- a/spellcheck.yaml +++ b/spellcheck.yaml @@ -38,12 +38,6 @@ matrix: # Ignore hugo/jinja tags - open: '{{' close: '}}' - # Ignore display LaTeX formulas ($$ ... $$) - - open: '\$\$' - close: '\$\$' - # Ignore display LaTeX formulas ($$ ... $$) - - open: '\$' - close: '\$' - pyspelling.filters.markdown: null - pyspelling.filters.html: comments: false