chore: update genbutemple branch with colosseo II (#2322)

* feat: add AC for vAMM during opening auction * chore: typo * fix: reword * feat: Updates to fix up equations (#2303) * feat: tx trade ordering (#2231) * feat: Order trade transactions within a block * feat: AMM Estimates (#2282) * feat: Estimate within range * refactor: first stab at max block auction * refactor: add defaults * refactor: formalise action interaction + ACs * refactor: remove supplied liquidity requirement from ACs * chore: update approbation * chore: fix CI issues * milestone rejig * fix fee mechanic milestone, reorder features * chore: remove impossible AC, but mention the behaviour in spec Signed-off-by: Elias Van Ootegem <elias@vega.xyz> * chore: remove old AC from json Signed-off-by: Elias Van Ootegem <elias@vega.xyz> * 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 <gawlikowicz@gmail.com> * rename 3 and rejig milestones * sorting * feat: change to average notional position * feat: calculate fraction of cumulative volume across window rather than average of fractions across window * fix: update spellcheck * 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 <charlie@vegaprotocol.io> Co-authored-by: Tom McLean <tom@vegaprotocol.io> * Revert "feat: average notional position" (#2320) * chore: bump LP 3.0 spec number --------- Signed-off-by: Elias Van Ootegem <elias@vega.xyz> Co-authored-by: Jiajia-Cui <jiajia@vega.xyz> Co-authored-by: David Siska <62546419+davidsiska-vega@users.noreply.github.com> Co-authored-by: Jiajia-Cui <92106936+Jiajia-Cui@users.noreply.github.com> Co-authored-by: Tom <tom@vegaprotocol.io> Co-authored-by: Witold <gawlikowicz@gmail.com> Co-authored-by: Witold <witold@vega.xyz> Co-authored-by: Edd <edd@vega.xyz> Co-authored-by: Elias Van Ootegem <elias@vega.xyz> Co-authored-by: Jeremy Letang <me@jeremyletang.com>
vegaprotocol · Sep 17, 2024 · f1c6154 · f1c6154
1 parent 5889f27
commit f1c6154
Show file tree

Hide file tree

Showing 5 changed files with 261 additions and 234 deletions.
diff --git a/protocol/0029-FEES-fees.md b/protocol/0029-FEES-fees.md
@@ -92,6 +92,8 @@ Note, discounts are calculated and applied one after the other and **before** re
 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`.
 
 The treasury fee factor is set by the network parameter `market.fee.factors.treasuryFee` can be changed through a network parameter update proposal. It has minimum allowable value of `0` maximum allowable value of `1` and a default of `0`.
 
@@ -208,7 +210,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) (<a name="0029-FEES-053" href="#0029-FEES-053">0029-FEES-053</a>)
+1. Referee discounts are correctly calculated and applied for each taker fee component during continuous trading (assuming no volume discounts due to party) (<a name="0029-FEES-023" href="#0029-FEES-023">0029-FEES-023</a>)
     - `infrastructure_fee_referral_discount`
     - `liquidity_fee_referral_discount`
     - `maker_fee_referral_discount`

diff --git a/protocol/0094-PRAC-protective_auctions.md b/protocol/0094-PRAC-protective_auctions.md
@@ -35,8 +35,15 @@ 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 +64,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. (<a name="0094-PRAC-004" href="#0094-PRAC-004">0094-PRAC-004</a>)
 
 - 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. (<a name="0094-PRAC-005" href="#0094-PRAC-005">0094-PRAC-005</a>)
+
+- 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.  (<a name="0094-PRAC-006" href="#0094-PRAC-006">0094-PRAC-006</a>)
+
+- When a market's `trigger` or `extension_trigger` is set to represent a governance suspension then no other triggers can affect the market.  (<a name="0094-PRAC-007" href="#0094-PRAC-007">0094-PRAC-007</a>)
+
+- 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.  (<a name="0094-PRAC-008" href="#0094-PRAC-008">0094-PRAC-008</a>)
diff --git a/protocol/0095-HVMR-high_volume_maker_rebate.md b/protocol/0095-HVMR-high_volume_maker_rebate.md
@@ -18,16 +18,16 @@ Enabling or changing the terms of the program can be proposed via governance. As
 
 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 party's `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.
+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}_j = \frac{\sum_{i=1}^{m} V_{i,j}}{\sum_{i=1}^{m} \sum_{k=1}^{n} V_{i,k}}$$
+$$\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 party's `additional_maker_rebate` is then fixed to the value in the highest tier they qualify for. A party's 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`.
+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:
@@ -65,78 +65,6 @@ As variable fees for the taker depending upon with whom they are trading would n
    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))`
 
-As the rebate is funded through the buyback and treasure fee, the effective rebate is capped to a maximum rebate factor which is the sum of the treasury and buy back factors, i.e.
+## Governance Requirements
 
-$$\text{effectiveAdditionalMakerRebate} = \min{(\text{additionalMakerRebate}, \text{market.fee.factors.treasuryFee} + \text{market.fee.factors.buybackFee})}$$
-
-As a party's $effectiveAdditionalMakerRebate$ is dependent on the network parameters defining the factors, if the fee factors are updated through governance during an epoch, calculation of the effective rebate should be re-triggered a party's current $additionalMakerRebate$ and the updated factors. Note in this case, the network should not recalculate which tier and $additionalMakerRebate$ a party qualifies for as this is only done on epoch boundaries.
-
-Any APIs which report a party's rebate factor should adhere to this cap and return the $effectiveAdditionalMakerRebate$.
-
-## Acceptance Criteria
-
-### Governance Proposals
-
-1. If an `UpdateVolumeRebateProgram` 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` (<a name="0095-HVMR-001" href="#0095-HVMR-001">0095-HVMR-001</a>).
-    - the number of tiers in `benefit_tiers` must be less than or equal to the network parameter `volumeRebateProgram.maxBenefitTiers` (<a name="0095-HVMR-002" href="#0095-HVMR-002">0095-HVMR-002</a>).
-    - all `minimum_party_maker_volume_fraction` values must be a float strictly greater than 0 (<a name="0095-HVMR-003" href="#0095-HVMR-003">0095-HVMR-003</a>).
-    - the `window_length` must be an integer strictly greater than zero (<a name="0095-HVMR-004" href="#0095-HVMR-004">0095-HVMR-004</a>).
-1. A volume rebate program should be started the first epoch change after the `enactment_datetime` is reached (<a name="0095-HVMR-005" href="#0095-HVMR-005">0095-HVMR-005</a>).
-1. A volume rebate program should be closed the first epoch change after the `end_of_program_timestamp` is reached (<a name="0095-HVMR-006" href="#0095-HVMR-006">0095-HVMR-006</a>).
-1. If a volume rebate program is already active and a proposal `enactment_datetime` is reached, the volume rebate program is updated at the next epoch change.
-    - Propose program A with `enactment_timestamp` ET1 and `end_of_program_timestamp` CT1 (<a name="0095-HVMR-007" href="#0095-HVMR-007">0095-HVMR-007</a>).
-    - Proposal for program A accepted and begins first epoch after ET1 (<a name="0095-HVMR-008" href="#0095-HVMR-008">0095-HVMR-008</a>).
-    - Propose program B with `enactment_timestamp` ET2 (ET2 > ET1 && ET2 < CT1) and `end_of_program_timestamp` CT1 (CT1 < CT2) (<a name="0095-HVMR-009" href="#0095-HVMR-009">0095-HVMR-009</a>).
-    - Proposal for program B accepted and overrides program A the first epoch after ET2 (<a name="0095-HVMR-010" href="#0095-HVMR-010">0095-HVMR-010</a>).
-    - Program is closed first epoch after CT2, there should be no active proposals (<a name="0095-HVMR-011" href="#0095-HVMR-011">0095-HVMR-011</a>).
-1. Updating any of the following network parameters whilst there is an active volume rebate program will not modify or cancel the active program in any way. The updated parameters will however be used to validate future volume rebate program proposals.
-    - `volumeRebateProgram.maxBenefitTiers` (<a name="0095-HVMR-012" href="#0095-HVMR-012">0095-HVMR-012</a>).
-
-### Maker volume fraction
-
-#### Contributing trades
-
-1. Each trade in which a party is the "maker" **should** contribute towards the party's maker volume fraction (<a name="0095-HVMR-013" href="#0095-HVMR-013">0095-HVMR-013</a>). For product spot (<a name="0095-HVMR-014" href="#0095-HVMR-014">0095-HVMR-014</a>).
-1. Each trade in which a party is the "taker" **should not** contribute towards the party's maker volume fraction (<a name="0095-HVMR-015" href="#0095-HVMR-015">0095-HVMR-015</a>). For product spot (<a name="0095-HVMR-016" href="#0095-HVMR-016">0095-HVMR-016</a>).
-1. A trade generated during auction uncrossing should not contribute to either party's maker volume fraction (<a name="0095-HVMR-017" href="#0095-HVMR-017">0095-HVMR-017</a>). For product spot (<a name="0095-HVMR-018" href="#0095-HVMR-018">0095-HVMR-018</a>).
-
-#### Evaluating contributions across windows
-
-1. Given a rebate program with a window length greater than zero. If a party generated an equal amount of volume in the current epoch to a party who created volume in a previous epoch in the window, then they should both have a maker volume fraction of `0.5`. (<a name="0095-HVMR-019" href="#0095-HVMR-019">0095-HVMR-019</a>). For product spot (<a name="0095-HVMR-020" href="#0095-HVMR-020">0095-HVMR-020</a>).
-1. Given a rebate program with a window length greater than zero. If a party generated an equal amount of volume in the current epoch to a party who created volume in a previous epoch which is no longer in the window, they the party should have a maker volume fraction of `1` (and the other party will have a fraction of `0`). (<a name="0095-HVMR-021" href="#0095-HVMR-021">0095-HVMR-021</a>). For product spot (<a name="0095-HVMR-022" href="#0095-HVMR-022">0095-HVMR-022</a>).
-
-#### Evaluating contributions across markets
-
-1. Given two parties' making markets in two separate derivative markets using settlement assets with different quantum values, if the party's generated equal volume (e.g. 10,000 USD) then they should both have a maker volume fraction of `0.5`. (<a name="0095-HVMR-023" href="#0095-HVMR-023">0095-HVMR-023</a>).
-1. Given two parties' making markets in two separate spot markets using quote assets with different quantum values, if the party's generated equal volume (e.g. 10,000 USD) then they should both have a maker volume fraction of `0.5`. (<a name="0095-HVMR-024" href="#0095-HVMR-024">0095-HVMR-024</a>).
-1. Given two parties' making markets in a separate derivative and spot market using a settlement and quote asset with different quantum values respectively, if the party's generated equal volume (e.g. 10,000 USD) then they should both have a maker volume fraction of `0.5`. (<a name="0095-HVMR-025" href="#0095-HVMR-025">0095-HVMR-025</a>).
-
-### Setting rebate factors
-
-1. At the start of an epoch, each party's `additional_rebate_factor` is reevaluated and fixed for the epoch (<a name="0095-HVMR-026" href="#0095-HVMR-026">0095-HVMR-026</a>).
-1. A party's `additional_rebate_factor`  is set equal to the factors in the highest benefit tier they qualify for (<a name="0095-HVMR-027" href="#0095-HVMR-027">0095-HVMR-027</a>).
-1. If a party does not qualify for the lowest tier, their `additional_rebate_factor`is set to `0` (<a name="0095-HVMR-028" href="#0095-HVMR-028">0095-HVMR-028</a>).
-
-#### Capping the effective rebate factor
-
-#### General behaviour
-
-1. Given the `treasury_fee_factor` is `0` If a party qualifies for a tier where the `additional_rebate_factor` is greater than `buyback_fee_factor`, their `effective_additional_rebate_factor` should be capped to a maximum and set to (`buyback_fee_factor` + `treasury_fee_factor`). In this case no treasury or buyback fees should be collected by the network for trades involving this party. (<a name="0095-HVMR-029" href="#0095-HVMR-029">0095-HVMR-029</a>).
-1. Given the `buyback_fee_factor` is `0`. If a party qualifies for a tier where the `additional_rebate_factor` is greater than `treasury_fee_factor`, their `effective_additional_rebate_factor` should be capped to a maximum and set to (`buyback_fee_factor` + `treasury_fee_factor`). In this case no treasury or buyback fees should be collected by the network for trades involving this party. (<a name="0095-HVMR-030" href="#0095-HVMR-030">0095-HVMR-030</a>).
-1. If a party qualifies for a tier where the `additional_rebate_factor` is greater than (`buyback_fee_factor` + `treasury_fee_factor`), their `effective_additional_rebate_factor` should be capped to a maximum and set to (`buyback_fee_factor` + `treasury_fee_factor`). In this case no treasury or buyback fees should be collected by the network for trades involving this party. (<a name="0095-HVMR-031" href="#0095-HVMR-031">0095-HVMR-031</a>).
-
-##### Program updates
-
-1. If the rebate program is updated such that the `additional_rebate_factor` in the tier the party currently qualifies for is reduced so that the party's new `additional_rebate_factor` is greater than (`buyback_fee_factor` + `treasury_fee_factor`), their `effective_additional_rebate_factor` should be capped to a maximum and set to (`buyback_fee_factor` + `treasury_fee_factor`). (<a name="0095-HVMR-032" href="#0095-HVMR-032">0095-HVMR-032</a>).
-1. If the rebate program is updated such that the `additional_rebate_factor` in the tier the party currently qualifies for is increased so that the party's new `additional_rebate_factor` is less than (`buyback_fee_factor` + `treasury_fee_factor`), their `effective_additional_rebate_factor` should be set to their current `additional_rebate_factor`. (<a name="0095-HVMR-033" href="#0095-HVMR-033">0095-HVMR-033</a>).
-
-#### Network parameter updates
-
-1. If the `buyback_fee_factor` is increased through a proposal in the middle of an epoch such that a party's `additional_rebate_factor` is greater than (`buyback_fee_factor` + `treasury_fee_factor`), their `effective_additional_rebate_factor` should be set to the new maximum (`buyback_fee_factor` + `treasury_fee_factor`). (<a name="0095-HVMR-034" href="#0095-HVMR-034">0095-HVMR-034</a>).
-1. If the `treasury_fee_factor` is increased through a proposal in the middle of an epoch such that a party's `additional_rebate_factor` is greater than (`buyback_fee_factor` + `treasury_fee_factor`), their `effective_additional_rebate_factor` should be set to the new maximum (`buyback_fee_factor` + `treasury_fee_factor`). (<a name="0095-HVMR-035" href="#0095-HVMR-035">0095-HVMR-035</a>).
-1. If the `buyback_fee_factor` and `treasury_fee_factor` are both increased through a batch proposal in the middle of an epoch such that a party's `additional_rebate_factor` is greater than (`buyback_fee_factor` + `treasury_fee_factor`), their `effective_additional_rebate_factor` should be set to the new maximum (`buyback_fee_factor` + `treasury_fee_factor`). (<a name="0095-HVMR-036" href="#0095-HVMR-036">0095-HVMR-036</a>).
-
-1. If the `buyback_fee_factor` is reduced through a proposal in the middle of an epoch such that a party's `additional_rebate_factor` is less than (`buyback_fee_factor` + `treasury_fee_factor`), their `effective_additional_rebate_factor` should be set to their current `additional_rebate_factor`. (<a name="0095-HVMR-037" href="#0095-HVMR-037">0095-HVMR-037</a>).
-1. If the `treasury_fee_factor` is reduced through a proposal in the middle of an epoch such that a party's `additional_rebate_factor` is less than (`buyback_fee_factor` + `treasury_fee_factor`), their `effective_additional_rebate_factor` should be set to their current `additional_rebate_factor`. (<a name="0095-HVMR-038" href="#0095-HVMR-038">0095-HVMR-038</a>).
-1. If the `buyback_fee_factor` and `treasury_fee_factor` are both reduced through a batch proposal in the middle of an epoch such that a party's current `additional_rebate_factor` is less than (`buyback_fee_factor` + `treasury_fee_factor`), their `effective_additional_rebate_factor` should be set to their current `additional_rebate_factor`. (<a name="0095-HVMR-039" href="#0095-HVMR-039">0095-HVMR-039</a>).
+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/0095-LIQM-liquidity_mechanisms.md → protocol/0096-LIQM-liquidity_mechanisms.md b/protocol/0095-LIQM-liquidity_mechanisms.md → protocol/0096-LIQM-liquidity_mechanisms.md