code.vegaprotocol.io/vega@v0.79.0/core/integration/features/amm/0042-LIQF-109.feature (about) 1 Feature: Test vAMM implied commitment is working as expected 2 3 Background: 4 Given the average block duration is "1" 5 And the margin calculator named "margin-calculator-1": 6 | search factor | initial factor | release factor | 7 | 1.2 | 1.5 | 1.7 | 8 And the log normal risk model named "log-normal-risk-model": 9 | risk aversion | tau | mu | r | sigma | 10 | 0.001 | 0.0011407711613050422 | 0 | 0.9 | 3.0 | 11 And the liquidity monitoring parameters: 12 | name | triggering ratio | time window | scaling factor | 13 | lqm-params | 1.00 | 20s | 1 | 14 15 And the following network parameters are set: 16 | name | value | 17 | market.value.windowLength | 60s | 18 | network.markPriceUpdateMaximumFrequency | 0s | 19 | limits.markets.maxPeggedOrders | 6 | 20 | market.auction.minimumDuration | 1 | 21 | market.fee.factors.infrastructureFee | 0.001 | 22 | market.fee.factors.makerFee | 0.004 | 23 | spam.protection.max.stopOrdersPerMarket | 5 | 24 | market.liquidity.equityLikeShareFeeFraction | 1 | 25 | market.amm.minCommitmentQuantum | 1 | 26 | market.liquidity.bondPenaltyParameter | 0.2 | 27 | market.liquidity.stakeToCcyVolume | 1 | 28 | market.liquidity.successorLaunchWindowLength | 1h | 29 | market.liquidity.sla.nonPerformanceBondPenaltySlope | 0 | 30 | market.liquidity.sla.nonPerformanceBondPenaltyMax | 0.6 | 31 | validators.epoch.length | 10s | 32 | market.liquidity.earlyExitPenalty | 0.25 | 33 | market.liquidity.maximumLiquidityFeeFactorLevel | 0.25 | 34 | market.liquidity.providersFeeCalculationTimeStep | 9s | 35 #risk factor short:3.5569036 36 #risk factor long:0.801225765 37 And the following assets are registered: 38 | id | decimal places | 39 | USD | 0 | 40 And the fees configuration named "fees-config-1": 41 | maker fee | infrastructure fee | 42 | 0.0004 | 0.001 | 43 44 And the liquidity sla params named "SLA-22": 45 | price range | commitment min time fraction | performance hysteresis epochs | sla competition factor | 46 | 0.05 | 1 | 1 | 1.0 | 47 48 And the markets: 49 | 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 | 50 | ETH/MAR22 | USD | USD | lqm-params | log-normal-risk-model | margin-calculator-1 | 2 | fees-config-1 | default-none | default-eth-for-future | 1e0 | 0 | SLA-22 | 51 52 Given the parties deposit on asset's general account the following amount: 53 | party | asset | amount | 54 | lp1 | USD | 1000000 | 55 | lp2 | USD | 1000000 | 56 | lp3 | USD | 1000000 | 57 | party1 | USD | 1000000 | 58 | party2 | USD | 1000000 | 59 | party3 | USD | 1000000 | 60 | party4 | USD | 1000000 | 61 | party5 | USD | 1000000 | 62 | vamm1 | USD | 1000000 | 63 | vamm2 | USD | 1000000 | 64 65 When the parties submit the following liquidity provision: 66 | id | party | market id | commitment amount | fee | lp type | 67 | lp_1 | lp1 | ETH/MAR22 | 10000 | 0.02 | submission | 68 | lp_2 | lp2 | ETH/MAR22 | 10000 | 0.02 | submission | 69 70 And the parties place the following orders: 71 | party | market id | side | volume | price | resulting trades | type | tif | reference | 72 | lp1 | ETH/MAR22 | buy | 20 | 40 | 0 | TYPE_LIMIT | TIF_GTC | lp1-b | 73 | party1 | ETH/MAR22 | buy | 1 | 100 | 0 | TYPE_LIMIT | TIF_GTC | | 74 | party2 | ETH/MAR22 | sell | 1 | 100 | 0 | TYPE_LIMIT | TIF_GTC | | 75 | lp1 | ETH/MAR22 | sell | 20 | 160 | 0 | TYPE_LIMIT | TIF_GTC | lp1-s | 76 77 When the opening auction period ends for market "ETH/MAR22" 78 Then the following trades should be executed: 79 | buyer | price | size | seller | 80 | party1 | 100 | 1 | party2 | 81 82 Then the network moves ahead "1" epochs 83 And the current epoch is "1" 84 85 @VAMM 86 Scenario: 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 `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`. 87 #first check the virtual stake if vamm1 provide AMM within SLA range for the whole epoch 88 Then the parties submit the following AMM: 89 | party | market id | amount | slippage | base | lower bound | upper bound | proposed fee | 90 | vamm1 | ETH/MAR22 | 10000 | 0.05 | 100 | 98 | 102 | 0.03 | 91 Then the AMM pool status should be: 92 | party | market id | amount | status | base | lower bound | upper bound | 93 | vamm1 | ETH/MAR22 | 10000 | STATUS_ACTIVE | 100 | 98 | 102 | 94 95 And set the following AMM sub account aliases: 96 | party | market id | alias | 97 | vamm1 | ETH/MAR22 | vamm-party | 98 99 And the parties place the following orders: 100 | party | market id | side | volume | price | resulting trades | type | tif | reference | 101 | party1 | ETH/MAR22 | buy | 10 | 100 | 0 | TYPE_LIMIT | TIF_GTC | lp1-b | 102 | party2 | ETH/MAR22 | sell | 10 | 100 | 1 | TYPE_LIMIT | TIF_GTC | | 103 104 Then the network moves ahead "1" epochs 105 106 And the liquidity provider fee shares for the market "ETH/MAR22" should be: 107 | party | equity like share | virtual stake | average entry valuation | 108 | 137112507e25d3845a56c47db15d8ced0f28daa8498a0fd52648969c4b296aba | 0 | 4669.0000000000000000 | 24669 | 109 110 Scenario: 0042-LIQF-109 111 #now check the virtual stake if vamm1 only provide AMM within SLA range for the first half of the epoch, and second half is lower AMM only 112 Then the parties submit the following AMM: 113 | party | market id | amount | slippage | base | lower bound | upper bound | proposed fee | 114 | vamm1 | ETH/MAR22 | 10000 | 0.05 | 100 | 98 | 102 | 0.03 | 115 Then the AMM pool status should be: 116 | party | market id | amount | status | base | lower bound | upper bound | 117 | vamm1 | ETH/MAR22 | 10000 | STATUS_ACTIVE | 100 | 98 | 102 | 118 119 And set the following AMM sub account aliases: 120 | party | market id | alias | 121 | vamm1 | ETH/MAR22 | vamm-party | 122 123 And the parties place the following orders: 124 | party | market id | side | volume | price | resulting trades | type | tif | reference | 125 | party1 | ETH/MAR22 | buy | 10 | 100 | 0 | TYPE_LIMIT | TIF_GTC | lp1-b | 126 | party2 | ETH/MAR22 | sell | 10 | 100 | 1 | TYPE_LIMIT | TIF_GTC | | 127 128 Then the network moves ahead "5" blocks 129 130 When the parties amend the following AMM: 131 | party | market id | slippage | base | lower bound | upper bound | lower leverage | upper leverage | 132 | vamm1 | ETH/MAR22 | 0.1 | 100 | 90 | | 0.25 | 0.25 | 133 Then the AMM pool status should be: 134 | party | market id | amount | status | base | lower bound | upper bound | lower leverage | upper leverage | 135 | vamm1 | ETH/MAR22 | 10000 | STATUS_ACTIVE | 100 | 90 | | 0.25 | 0.25 | 136 137 Then the network moves ahead "7" blocks 138 139 And the liquidity provider fee shares for the market "ETH/MAR22" should be: 140 | party | equity like share | virtual stake | average entry valuation | 141 | 137112507e25d3845a56c47db15d8ced0f28daa8498a0fd52648969c4b296aba | 0 | 2334.0000000000000000 | 22334 | 142 143 @VAMM 144 Scenario: 0042-LIQF-109 145 #now check the virtual stake if vamm1 only provide AMM within SLA range for the first half of the epoch, and second half is outside SLA range 146 Then the parties submit the following AMM: 147 | party | market id | amount | slippage | base | lower bound | upper bound | proposed fee | 148 | vamm1 | ETH/MAR22 | 10000 | 0.05 | 100 | 98 | 102 | 0.03 | 149 Then the AMM pool status should be: 150 | party | market id | amount | status | base | lower bound | upper bound | 151 | vamm1 | ETH/MAR22 | 10000 | STATUS_ACTIVE | 100 | 98 | 102 | 152 153 And set the following AMM sub account aliases: 154 | party | market id | alias | 155 | vamm1 | ETH/MAR22 | vamm-party | 156 157 And the parties place the following orders: 158 | party | market id | side | volume | price | resulting trades | type | tif | reference | 159 | party1 | ETH/MAR22 | buy | 10 | 100 | 0 | TYPE_LIMIT | TIF_GTC | lp1-b | 160 | party2 | ETH/MAR22 | sell | 10 | 100 | 1 | TYPE_LIMIT | TIF_GTC | | 161 162 Then the network moves ahead "5" blocks 163 164 When the parties amend the following AMM: 165 | party | market id | slippage | base | lower bound | upper bound | lower leverage | upper leverage | 166 | vamm1 | ETH/MAR22 | 0.1 | 100 | 80 | 115 | 0.25 | 0.25 | 167 Then the AMM pool status should be: 168 | party | market id | amount | status | base | lower bound | upper bound | lower leverage | upper leverage | 169 | vamm1 | ETH/MAR22 | 10000 | STATUS_ACTIVE | 100 | 80 | 115 | 0.25 | 0.25 | 170 171 Then the network moves ahead "7" blocks 172 173 And the liquidity provider fee shares for the market "ETH/MAR22" should be: 174 | party | equity like share | virtual stake | average entry valuation | 175 | 137112507e25d3845a56c47db15d8ced0f28daa8498a0fd52648969c4b296aba | 0 | 2625.0000000000000000 | 22625 | 176 177 @VAMM 178 Scenario: 0042-LIQF-111: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`. 179 Then the parties submit the following AMM: 180 | party | market id | amount | slippage | base | lower bound | upper bound | proposed fee | 181 | vamm1 | ETH/MAR22 | 10000 | 0.05 | 100 | 98 | 102 | 0.03 | 182 Then the AMM pool status should be: 183 | party | market id | amount | status | base | lower bound | upper bound | 184 | vamm1 | ETH/MAR22 | 10000 | STATUS_ACTIVE | 100 | 98 | 102 | 185 186 And set the following AMM sub account aliases: 187 | party | market id | alias | 188 | vamm1 | ETH/MAR22 | vamm-party | 189 190 And the parties place the following orders: 191 | party | market id | side | volume | price | resulting trades | type | tif | reference | 192 | party1 | ETH/MAR22 | buy | 10 | 100 | 0 | TYPE_LIMIT | TIF_GTC | lp1-b | 193 | party2 | ETH/MAR22 | sell | 10 | 100 | 1 | TYPE_LIMIT | TIF_GTC | | 194 195 Then the network moves ahead "5" blocks 196 197 When the parties amend the following AMM: 198 | party | market id | amount | slippage | base | lower bound | upper bound | 199 | vamm1 | ETH/MAR22 | 5000 | 0.05 | 100 | 98 | 102 | 200 Then the AMM pool status should be: 201 | party | market id | amount | status | base | lower bound | upper bound | 202 | vamm1 | ETH/MAR22 | 5000 | STATUS_ACTIVE | 100 | 98 | 102 | 203 204 Then the network moves ahead "7" blocks 205 206 #virtual stake is 75% * 4669 = 3501 207 And the liquidity provider fee shares for the market "ETH/MAR22" should be: 208 | party | equity like share | virtual stake | average entry valuation | 209 | 137112507e25d3845a56c47db15d8ced0f28daa8498a0fd52648969c4b296aba | 0 | 3502.0000000000000000 | 23502 | 210 211