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>

protocol/0095-HVMR-high_volume_maker_rebate.md

@@ -11,51 +11,7 @@ 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 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.
+- `window_length`:  the number of epochs over which to average a party's `maker_volume_fraction`
 
 ## Application
 

protocol/features.json

@@ -239,7 +239,6 @@
       "0009-MRKP-037"
     ]
   },
-
   "Explicit liquidation range": {
     "milestone": "colosseo",
     "acs": [
@@ -248,8 +247,6 @@
       "0012-POSR-033"
     ]
   },
-
-
   "Reward Improvements": {
     "milestone": "colosseo",
     "acs": [
@@ -300,7 +297,6 @@
       "0057-TRAN-079"
     ]
   },
-
   "Capped Futures": {
     "milestone": "colosseo_II",
     "acs": [
@@ -504,6 +500,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": [
@@ -520,4 +524,4 @@
     "milestone": "unknown",
     "acs": []
   }
-}
+}