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 · b00aa4d · b00aa4d
1 parent 7081425
commit b00aa4d
Show file tree

Hide file tree

Showing 13 changed files with 587 additions and 221 deletions.
diff --git 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 (<a name="0004-AMND-018" href="#0004-AMND-018">0004-AMND-018</a>). For product spot: (<a name="0004-AMND-046" href="#0004-AMND-046">0004-AMND-046</a>)
 - Attempting to alter details on an expired order will cause the amend to be rejected (<a name="0004-AMND-019" href="#0004-AMND-019">0004-AMND-019</a>). For product spot: (<a name="0004-AMND-047" href="#0004-AMND-047">0004-AMND-047</a>)
 - 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 (<a name="0004-AMND-029" href="#0004-AMND-029">0004-AMND-029</a>). For product spot: (<a name="0004-AMND-048" href="#0004-AMND-048">0004-AMND-048</a>)
+- 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 (<a name="0004-AMND-061" href="#0004-AMND-061">0004-AMND-061</a>)
 
 For a party with no position on a given market:
 

diff --git 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 (<a name="0016-PFUT-001" href="#0016-PFUT-001">0016-PFUT-001</a>)
@@ -125,4 +127,3 @@ Optional parameters:
 1. Futures market can be created with a with [hardcoded risk factors](./0018-RSKM-quant_risk_models.ipynb). (<a name="0016-PFUT-026" href="#0016-PFUT-026">0016-PFUT-026</a>)
 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. (<a name="0016-PFUT-027" href="#0016-PFUT-027">0016-PFUT-027</a>)
 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. (<a name="0016-PFUT-028" href="#0016-PFUT-028">0016-PFUT-028</a>)
-1. It's not possible to modify the `fully-collateralised` flag with a market update transaction. (<a name="0016-PFUT-029" href="#0016-PFUT-029">0016-PFUT-029</a>)
diff --git 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). (<a name="0026-AUCT-017" href="#0026-AUCT-017">0026-AUCT-017</a>). 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: (<a name="0026-AUCT-029" href="#0026-AUCT-029">0026-AUCT-029</a>)
+    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. (<a name="0026-AUCT-038" href="#0026-AUCT-038">0026-AUCT-038</a>). 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: (<a name="0026-AUCT-029" href="#0026-AUCT-029">0026-AUCT-029</a>)
     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. (<a name="0026-AUCT-018" href="#0026-AUCT-018">0026-AUCT-018</a>)
     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 (<a name="0026-AUCT-019" href="#0026-AUCT-019">0026-AUCT-019</a>)
 		  - or if orders are cancelled such that the uncrossing volume will create open interest sufficiently small so that the original stake can support it. (<a name="0026-AUCT-020" href="#0026-AUCT-020">0026-AUCT-020</a>)
-    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. (<a name="0026-AUCT-021" href="#0026-AUCT-021">0026-AUCT-021</a>)
-		  - or best ask; it will still open. (<a name="0026-AUCT-022" href="#0026-AUCT-022">0026-AUCT-022</a>)
+    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. (<a name="0026-AUCT-039" href="#0026-AUCT-039">0026-AUCT-039</a>)
+		  - or best ask; it will still open. (<a name="0026-AUCT-040" href="#0026-AUCT-040">0026-AUCT-040</a>)
 - When entering an auction, all GFN orders will be cancelled. (<a name="0026-AUCT-015" href="#0026-AUCT-015">0026-AUCT-015</a>). For product spot: (<a name="0026-AUCT-031" href="#0026-AUCT-031">0026-AUCT-031</a>)
 - When leaving an auction, all GFA orders will be cancelled. (<a name="0026-AUCT-016" href="#0026-AUCT-016">0026-AUCT-016</a>). For product spot: (<a name="0026-AUCT-032" href="#0026-AUCT-032">0026-AUCT-032</a>)
 

diff --git a/protocol/0029-FEES-fees.md b/protocol/0029-FEES-fees.md
@@ -9,14 +9,18 @@ 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`
 
 `maker_fee =  fee_factor[maker]  * trade_value_for_fee_purposes`
 
 `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) (<a name="0029-FEES-023" href="#0029-FEES-023">0029-FEES-023</a>)
-    - `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) (<a name="0029-FEES-034" href="#0029-FEES-034">0029-FEES-034</a>)
+    - `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) (<a name="0029-FEES-024" href="#0029-FEES-024">0029-FEES-024</a>)
@@ -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) (<a name="0029-FEES-035" href="#0029-FEES-035">0029-FEES-035</a>)
+    - `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) (<a name="0029-FEES-026" href="#0029-FEES-026">0029-FEES-026</a>)
     - `infrastructure_fee_referral_reward`
     - `liquidity_fee_referral_reward`