code.vegaprotocol.io/vega@v0.79.0/core/integration/features/liquidity-provision/0044-LIME-062.feature (about) 1 Feature: Test changing market.liquidity.providersFeeCalculationTimeStep; 2 3 Background: 4 5 Given the margin calculator named "margin-calculator-1": 6 | search factor | initial factor | release factor | 7 | 1.2 | 1.5 | 1.7 | 8 Given the log normal risk model named "log-normal-risk-model": 9 | risk aversion | tau | mu | r | sigma | 10 | 0.000001 | 0.1 | 0 | 0 | 1.0 | 11 And the following network parameters are set: 12 | name | value | 13 | market.value.windowLength | 60s | 14 | network.markPriceUpdateMaximumFrequency | 0s | 15 | limits.markets.maxPeggedOrders | 6 | 16 | market.auction.minimumDuration | 1 | 17 | market.fee.factors.infrastructureFee | 0.001 | 18 | market.fee.factors.makerFee | 0.004 | 19 | market.liquidity.providersFeeCalculationTimeStep | 10s | 20 | market.liquidity.bondPenaltyParameter | 0.2 | 21 | market.liquidity.stakeToCcyVolume | 1 | 22 | market.liquidity.successorLaunchWindowLength | 1h | 23 | market.liquidity.sla.nonPerformanceBondPenaltySlope | 0.1 | 24 | market.liquidity.sla.nonPerformanceBondPenaltyMax | 0.6 | 25 | validators.epoch.length | 15s | 26 | market.liquidity.earlyExitPenalty | 0.25 | 27 | market.liquidity.maximumLiquidityFeeFactorLevel | 0.25 | 28 | market.liquidity.equityLikeShareFeeFraction | 1 | 29 30 Given the liquidity monitoring parameters: 31 | name | triggering ratio | time window | scaling factor | 32 | lqm-params | 1.0 | 20s | 1.0 | 33 34 #risk factor short:3.5569036 35 #risk factor long:0.801225765 36 And the following assets are registered: 37 | id | decimal places | 38 | USD | 0 | 39 And the fees configuration named "fees-config-1": 40 | maker fee | infrastructure fee | 41 | 0.0004 | 0.001 | 42 And the price monitoring named "price-monitoring": 43 | horizon | probability | auction extension | 44 | 3600 | 0.99 | 3 | 45 46 And the liquidity sla params named "SLA-1": 47 | price range | commitment min time fraction | performance hysteresis epochs | sla competition factor | 48 | 0.5 | 0.6 | 1 | 1.0 | 49 And the markets: 50 | id | quote name | asset | liquidity monitoring | risk model | margin calculator | auction duration | fees | price monitoring | data source config | linear slippage factor | quadratic slippage factor | sla params | 51 | ETH/MAR22 | USD | USD | lqm-params | log-normal-risk-model | margin-calculator-1 | 2 | fees-config-1 | price-monitoring | default-eth-for-future | 1e0 | 0 | SLA-1 | 52 53 Given the average block duration is "1" 54 @Now 55 Scenario: 001: lp1 and lp2 on the market ETH/MAR22, 0044-LIME-062 56 Given the parties deposit on asset's general account the following amount: 57 | party | asset | amount | 58 | lp1 | USD | 100000 | 59 | lp2 | USD | 100000 | 60 | party1 | USD | 1000000 | 61 | party2 | USD | 1000000 | 62 63 And the network moves ahead "1" blocks 64 And the parties submit the following liquidity provision: 65 | id | party | market id | commitment amount | fee | lp type | 66 | lp_1 | lp1 | ETH/MAR22 | 6000 | 0.02 | submission | 67 | lp_2 | lp2 | ETH/MAR22 | 4000 | 0.015 | submission | 68 69 Then the parties place the following orders: 70 | party | market id | side | volume | price | resulting trades | type | tif | reference | 71 | party1 | ETH/MAR22 | buy | 10 | 900 | 0 | TYPE_LIMIT | TIF_GTC | | 72 | party1 | ETH/MAR22 | buy | 1 | 1000 | 0 | TYPE_LIMIT | TIF_GTC | | 73 | party2 | ETH/MAR22 | sell | 10 | 1100 | 0 | TYPE_LIMIT | TIF_GTC | | 74 | party2 | ETH/MAR22 | sell | 1 | 1000 | 0 | TYPE_LIMIT | TIF_GTC | | 75 | lp1 | ETH/MAR22 | buy | 10 | 950 | 0 | TYPE_LIMIT | TIF_GTC | lp1-b | 76 | lp2 | ETH/MAR22 | buy | 10 | 970 | 0 | TYPE_LIMIT | TIF_GTC | lp2-b | 77 | lp2 | ETH/MAR22 | sell | 10 | 1020 | 0 | TYPE_LIMIT | TIF_GTC | lp2-s | 78 | lp1 | ETH/MAR22 | sell | 10 | 1050 | 0 | TYPE_LIMIT | TIF_GTC | lp1-s | 79 80 Then the opening auction period ends for market "ETH/MAR22" 81 And the following trades should be executed: 82 | buyer | price | size | seller | 83 | party1 | 1000 | 1 | party2 | 84 85 When the network moves ahead "4" blocks 86 And the market data for the market "ETH/MAR22" should be: 87 | mark price | trading mode | horizon | min bound | max bound | target stake | supplied stake | open interest | 88 | 1000 | TRADING_MODE_CONTINUOUS | 3600 | 973 | 1027 | 3556 | 10000 | 1 | 89 90 91 Then the network moves ahead "1" epochs 92 Then the following network parameters are set: 93 | name | value | 94 | market.liquidity.providersFeeCalculationTimeStep | 3s | 95 96 # As we are still within the epoch, the change to 3s distributions should not occur yet, so we make a trade 97 And the parties place the following orders: 98 | party | market id | side | volume | price | resulting trades | type | tif | reference | 99 | party1 | ETH/MAR22 | sell | 2 | 1000 | 0 | TYPE_LIMIT | TIF_GTC | | 100 | party2 | ETH/MAR22 | buy | 2 | 1000 | 1 | TYPE_LIMIT | TIF_GTC | | 101 102 # Then forward enough blocks that the 3s setting would have caused a distribution and place another trade 103 Then the network moves ahead "4" blocks 104 And the parties place the following orders: 105 | party | market id | side | volume | price | resulting trades | type | tif | reference | 106 | party1 | ETH/MAR22 | buy | 2 | 1000 | 0 | TYPE_LIMIT | TIF_GTC | | 107 | party2 | ETH/MAR22 | sell | 2 | 1000 | 1 | TYPE_LIMIT | TIF_GTC | | 108 109 Then the network moves ahead "8" blocks 110 111 # Now forward enough that a distribution does occur at the original 10s frequency and see one took place with the 112 # volume from both orders in one transfer, implying nothing happened between the two orders 113 Then the following transfers should happen: 114 | from | to | from account | to account | market id | amount | asset | 115 | market | lp1 | ACCOUNT_TYPE_FEES_LIQUIDITY | ACCOUNT_TYPE_LP_LIQUIDITY_FEES | ETH/MAR22 | 36 | USD | 116 | market | lp2 | ACCOUNT_TYPE_FEES_LIQUIDITY | ACCOUNT_TYPE_LP_LIQUIDITY_FEES | ETH/MAR22 | 24 | USD | 117 118 # We are now nearly at the epoch boundary, so place an order just before 119 Then the parties place the following orders: 120 | party | market id | side | volume | price | resulting trades | type | tif | reference | 121 | party1 | ETH/MAR22 | sell | 2 | 1000 | 0 | TYPE_LIMIT | TIF_GTC | | 122 | party2 | ETH/MAR22 | buy | 2 | 1000 | 1 | TYPE_LIMIT | TIF_GTC | | 123 124 Then the network moves ahead "1" epochs 125 # And once we pass the epoch, this is distributed to the fee accounts at the new frequency 126 And the following transfers should happen: 127 | from | to | from account | to account | market id | amount | asset | 128 | market | lp1 | ACCOUNT_TYPE_FEES_LIQUIDITY | ACCOUNT_TYPE_LP_LIQUIDITY_FEES | ETH/MAR22 | 18 | USD | 129 | market | lp2 | ACCOUNT_TYPE_FEES_LIQUIDITY | ACCOUNT_TYPE_LP_LIQUIDITY_FEES | ETH/MAR22 | 12 | USD | 130 131 # So now if we place a new trade 132 Then the parties place the following orders: 133 | party | market id | side | volume | price | resulting trades | type | tif | reference | 134 | party1 | ETH/MAR22 | buy | 3 | 1000 | 0 | TYPE_LIMIT | TIF_GTC | | 135 | party2 | ETH/MAR22 | sell | 3 | 1000 | 1 | TYPE_LIMIT | TIF_GTC | | 136 Then the network moves ahead "4" blocks 137 # Forward past the distribution frequency cutoff and place another 138 Then the parties place the following orders: 139 | party | market id | side | volume | price | resulting trades | type | tif | reference | 140 | party1 | ETH/MAR22 | sell | 4 | 1000 | 0 | TYPE_LIMIT | TIF_GTC | | 141 | party2 | ETH/MAR22 | buy | 4 | 1000 | 1 | TYPE_LIMIT | TIF_GTC | | 142 143 # Then forward enough to cause them both to distribute, the fees are instead sent as two separate distributions 144 Then the network moves ahead "7" blocks 145 And the following transfers should happen: 146 | from | to | from account | to account | market id | amount | asset | 147 | market | lp1 | ACCOUNT_TYPE_FEES_LIQUIDITY | ACCOUNT_TYPE_LP_LIQUIDITY_FEES | ETH/MAR22 | 27 | USD | 148 | market | lp2 | ACCOUNT_TYPE_FEES_LIQUIDITY | ACCOUNT_TYPE_LP_LIQUIDITY_FEES | ETH/MAR22 | 18 | USD | 149 | market | lp1 | ACCOUNT_TYPE_FEES_LIQUIDITY | ACCOUNT_TYPE_LP_LIQUIDITY_FEES | ETH/MAR22 | 48 | USD | 150 | market | lp2 | ACCOUNT_TYPE_FEES_LIQUIDITY | ACCOUNT_TYPE_LP_LIQUIDITY_FEES | ETH/MAR22 | 32 | USD | 151 152 @Now 153 Scenario: 001b: lp1 and lp2 on the market ETH/MAR22, 0044-LIME-062 with ELS fee share fraction set to 0.5 154 Given the parties deposit on asset's general account the following amount: 155 | party | asset | amount | 156 | lp1 | USD | 100000 | 157 | lp2 | USD | 100000 | 158 | party1 | USD | 1000000 | 159 | party2 | USD | 1000000 | 160 And the following network parameters are set: 161 | name | value | 162 | market.liquidity.equityLikeShareFeeFraction | 0.5 | 163 164 And the network moves ahead "1" blocks 165 And the parties submit the following liquidity provision: 166 | id | party | market id | commitment amount | fee | lp type | 167 | lp_1 | lp1 | ETH/MAR22 | 6000 | 0.02 | submission | 168 | lp_2 | lp2 | ETH/MAR22 | 4000 | 0.015 | submission | 169 170 Then the parties place the following orders: 171 | party | market id | side | volume | price | resulting trades | type | tif | reference | 172 | party1 | ETH/MAR22 | buy | 10 | 900 | 0 | TYPE_LIMIT | TIF_GTC | | 173 | party1 | ETH/MAR22 | buy | 1 | 1000 | 0 | TYPE_LIMIT | TIF_GTC | | 174 | party2 | ETH/MAR22 | sell | 10 | 1100 | 0 | TYPE_LIMIT | TIF_GTC | | 175 | party2 | ETH/MAR22 | sell | 1 | 1000 | 0 | TYPE_LIMIT | TIF_GTC | | 176 | lp1 | ETH/MAR22 | buy | 10 | 950 | 0 | TYPE_LIMIT | TIF_GTC | lp1-b | 177 | lp2 | ETH/MAR22 | buy | 10 | 970 | 0 | TYPE_LIMIT | TIF_GTC | lp2-b | 178 | lp2 | ETH/MAR22 | sell | 10 | 1020 | 0 | TYPE_LIMIT | TIF_GTC | lp2-s | 179 | lp1 | ETH/MAR22 | sell | 10 | 1050 | 0 | TYPE_LIMIT | TIF_GTC | lp1-s | 180 181 Then the opening auction period ends for market "ETH/MAR22" 182 And the following trades should be executed: 183 | buyer | price | size | seller | 184 | party1 | 1000 | 1 | party2 | 185 186 When the network moves ahead "4" blocks 187 And the market data for the market "ETH/MAR22" should be: 188 | mark price | trading mode | horizon | min bound | max bound | target stake | supplied stake | open interest | 189 | 1000 | TRADING_MODE_CONTINUOUS | 3600 | 973 | 1027 | 3556 | 10000 | 1 | 190 191 192 Then the network moves ahead "1" epochs 193 Then the following network parameters are set: 194 | name | value | 195 | market.liquidity.providersFeeCalculationTimeStep | 3s | 196 197 # As we are still within the epoch, the change to 3s distributions should not occur yet, so we make a trade 198 And the parties place the following orders: 199 | party | market id | side | volume | price | resulting trades | type | tif | reference | 200 | party1 | ETH/MAR22 | sell | 2 | 1000 | 0 | TYPE_LIMIT | TIF_GTC | | 201 | party2 | ETH/MAR22 | buy | 2 | 1000 | 1 | TYPE_LIMIT | TIF_GTC | | 202 203 # Then forward enough blocks that the 3s setting would have caused a distribution and place another trade 204 Then the network moves ahead "4" blocks 205 And the parties place the following orders: 206 | party | market id | side | volume | price | resulting trades | type | tif | reference | 207 | party1 | ETH/MAR22 | buy | 2 | 1000 | 0 | TYPE_LIMIT | TIF_GTC | | 208 | party2 | ETH/MAR22 | sell | 2 | 1000 | 1 | TYPE_LIMIT | TIF_GTC | | 209 210 Then the network moves ahead "8" blocks 211 212 # Now forward enough that a distribution does occur at the original 10s frequency and see one took place with the 213 # volume from both orders in one transfer, implying nothing happened between the two orders 214 Then the following transfers should happen: 215 | from | to | from account | to account | market id | amount | asset | 216 | market | lp1 | ACCOUNT_TYPE_FEES_LIQUIDITY | ACCOUNT_TYPE_LP_LIQUIDITY_FEES | ETH/MAR22 | 33 | USD | 217 | market | lp2 | ACCOUNT_TYPE_FEES_LIQUIDITY | ACCOUNT_TYPE_LP_LIQUIDITY_FEES | ETH/MAR22 | 27 | USD | 218 219 # We are now nearly at the epoch boundary, so place an order just before 220 Then the parties place the following orders: 221 | party | market id | side | volume | price | resulting trades | type | tif | reference | 222 | party1 | ETH/MAR22 | sell | 2 | 1000 | 0 | TYPE_LIMIT | TIF_GTC | | 223 | party2 | ETH/MAR22 | buy | 2 | 1000 | 1 | TYPE_LIMIT | TIF_GTC | | 224 225 Then the network moves ahead "1" epochs 226 # And once we pass the epoch, this is distributed to the fee accounts at the new frequency 227 And the following transfers should happen: 228 | from | to | from account | to account | market id | amount | asset | 229 | market | lp1 | ACCOUNT_TYPE_FEES_LIQUIDITY | ACCOUNT_TYPE_LP_LIQUIDITY_FEES | ETH/MAR22 | 16 | USD | 230 | market | lp2 | ACCOUNT_TYPE_FEES_LIQUIDITY | ACCOUNT_TYPE_LP_LIQUIDITY_FEES | ETH/MAR22 | 13 | USD | 231 232 # So now if we place a new trade 233 Then the parties place the following orders: 234 | party | market id | side | volume | price | resulting trades | type | tif | reference | 235 | party1 | ETH/MAR22 | buy | 3 | 1000 | 0 | TYPE_LIMIT | TIF_GTC | | 236 | party2 | ETH/MAR22 | sell | 3 | 1000 | 1 | TYPE_LIMIT | TIF_GTC | | 237 Then the network moves ahead "4" blocks 238 # Forward past the distribution frequency cutoff and place another 239 Then the parties place the following orders: 240 | party | market id | side | volume | price | resulting trades | type | tif | reference | 241 | party1 | ETH/MAR22 | sell | 4 | 1000 | 0 | TYPE_LIMIT | TIF_GTC | | 242 | party2 | ETH/MAR22 | buy | 4 | 1000 | 1 | TYPE_LIMIT | TIF_GTC | | 243 244 # Then forward enough to cause them both to distribute, the fees are instead sent as two separate distributions 245 Then the network moves ahead "7" blocks 246 And the following transfers should happen: 247 | from | to | from account | to account | market id | amount | asset | 248 | market | lp1 | ACCOUNT_TYPE_FEES_LIQUIDITY | ACCOUNT_TYPE_LP_LIQUIDITY_FEES | ETH/MAR22 | 25 | USD | 249 | market | lp1 | ACCOUNT_TYPE_FEES_LIQUIDITY | ACCOUNT_TYPE_LP_LIQUIDITY_FEES | ETH/MAR22 | 44 | USD | 250 | market | lp2 | ACCOUNT_TYPE_FEES_LIQUIDITY | ACCOUNT_TYPE_LP_LIQUIDITY_FEES | ETH/MAR22 | 20 | USD | 251 | market | lp2 | ACCOUNT_TYPE_FEES_LIQUIDITY | ACCOUNT_TYPE_LP_LIQUIDITY_FEES | ETH/MAR22 | 36 | USD |