code.vegaprotocol.io/vega@v0.79.0/core/integration/features/amm/0042-LIQF-108.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-108: A vAMM which was active on the market with an average of `10000` liquidity units (`price * volume`) provided across the epoch, and where the `market.liquidity.stakeToCcyVolume` value is `100`, will have an implied commitment of `100`. 87 Then the parties submit the following AMM: 88 | party | market id | amount | slippage | base | lower bound | upper bound | proposed fee | 89 | vamm1 | ETH/MAR22 | 10000 | 0.05 | 100 | 98 | 102 | 0.03 | 90 Then the AMM pool status should be: 91 | party | market id | amount | status | base | lower bound | upper bound | 92 | vamm1 | ETH/MAR22 | 10000 | STATUS_ACTIVE | 100 | 98 | 102 | 93 94 And set the following AMM sub account aliases: 95 | party | market id | alias | 96 | vamm1 | ETH/MAR22 | vamm-party | 97 98 # Then the network moves ahead "1" blocks 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 following trades should be executed: 105 | buyer | price | size | seller | 106 | party1 | 100 | 10 | party2 | 107 108 Then the network moves ahead "1" epochs 109 And the current epoch is "2" 110 111 And the following transfers should happen: 112 | type | from | to | from account | to account | market id | amount | asset | 113 | TRANSFER_TYPE_LIQUIDITY_FEE_ALLOCATE | market | 137112507e25d3845a56c47db15d8ced0f28daa8498a0fd52648969c4b296aba | ACCOUNT_TYPE_FEES_LIQUIDITY | ACCOUNT_TYPE_LP_LIQUIDITY_FEES | ETH/MAR22 | 3 | USD | 114 | TRANSFER_TYPE_LIQUIDITY_FEE_ALLOCATE | market | lp1 | ACCOUNT_TYPE_FEES_LIQUIDITY | ACCOUNT_TYPE_LP_LIQUIDITY_FEES | ETH/MAR22 | 8 | USD | 115 | TRANSFER_TYPE_LIQUIDITY_FEE_ALLOCATE | market | lp2 | ACCOUNT_TYPE_FEES_LIQUIDITY | ACCOUNT_TYPE_LP_LIQUIDITY_FEES | ETH/MAR22 | 8 | USD | 116 | TRANSFER_TYPE_SLA_PERFORMANCE_BONUS_DISTRIBUTE | market | 137112507e25d3845a56c47db15d8ced0f28daa8498a0fd52648969c4b296aba | ACCOUNT_TYPE_LIQUIDITY_FEES_BONUS_DISTRIBUTION | ACCOUNT_TYPE_GENERAL | ETH/MAR22 | 16 | USD | 117 | TRANSFER_TYPE_LIQUIDITY_FEE_UNPAID_COLLECT | lp1 | market | ACCOUNT_TYPE_LP_LIQUIDITY_FEES | ACCOUNT_TYPE_LIQUIDITY_FEES_BONUS_DISTRIBUTION | ETH/MAR22 | 8 | USD | 118 | TRANSFER_TYPE_LIQUIDITY_FEE_UNPAID_COLLECT | lp2 | market | ACCOUNT_TYPE_LP_LIQUIDITY_FEES | ACCOUNT_TYPE_LIQUIDITY_FEES_BONUS_DISTRIBUTION | ETH/MAR22 | 8 | USD | 119 120 And the liquidity provider fee shares for the market "ETH/MAR22" should be: 121 | party | equity like share | virtual stake | average entry valuation | 122 | 137112507e25d3845a56c47db15d8ced0f28daa8498a0fd52648969c4b296aba | 0 | 4669.0000000000000000 | 24669 | 123 124 @VAMM 125 Scenario: 0042-LIQF-110: A vAMM which was active on the market with an average of `10000` liquidity units (`price * volume`) provided for half the epoch, because it was submitted half way through an epoch, and where the `market.liquidity.stakeToCcyVolume` value is `100`, will have an implied commitment of `50`. 126 127 # move ahead half an epoch then submit the AMM 128 Then the network moves ahead "5" blocks 129 Then the parties submit the following AMM: 130 | party | market id | amount | slippage | base | lower bound | upper bound | proposed fee | 131 | vamm1 | ETH/MAR22 | 10000 | 0.05 | 100 | 98 | 102 | 0.03 | 132 Then the AMM pool status should be: 133 | party | market id | amount | status | base | lower bound | upper bound | 134 | vamm1 | ETH/MAR22 | 10000 | STATUS_ACTIVE | 100 | 98 | 102 | 135 136 137 And the parties place the following orders: 138 | party | market id | side | volume | price | resulting trades | type | tif | reference | 139 | party1 | ETH/MAR22 | buy | 10 | 100 | 0 | TYPE_LIMIT | TIF_GTC | lp1-b | 140 | party2 | ETH/MAR22 | sell | 10 | 100 | 1 | TYPE_LIMIT | TIF_GTC | | 141 142 # epoch ends and AMM should get fewer fees than the above test because its ELS is less 143 Then the network moves ahead "7" blocks 144 And the following transfers should happen: 145 | type | from | to | from account | to account | market id | amount | asset | 146 | TRANSFER_TYPE_LIQUIDITY_FEE_ALLOCATE | market | 137112507e25d3845a56c47db15d8ced0f28daa8498a0fd52648969c4b296aba | ACCOUNT_TYPE_FEES_LIQUIDITY | ACCOUNT_TYPE_LP_LIQUIDITY_FEES | ETH/MAR22 | 0 | USD | 147 | TRANSFER_TYPE_LIQUIDITY_FEE_ALLOCATE | market | lp1 | ACCOUNT_TYPE_FEES_LIQUIDITY | ACCOUNT_TYPE_LP_LIQUIDITY_FEES | ETH/MAR22 | 9 | USD | 148 | TRANSFER_TYPE_LIQUIDITY_FEE_ALLOCATE | market | lp2 | ACCOUNT_TYPE_FEES_LIQUIDITY | ACCOUNT_TYPE_LP_LIQUIDITY_FEES | ETH/MAR22 | 9 | USD | 149 150 # virtual stake is HALF what it was in the above test since the AMM was only active for half the epoch 151 And the liquidity provider fee shares for the market "ETH/MAR22" should be: 152 | party | equity like share | virtual stake | average entry valuation | 153 | 137112507e25d3845a56c47db15d8ced0f28daa8498a0fd52648969c4b296aba | 0 | 2334.0000000000000000 | 22334 | 154 155 156 @VAMM 157 Scenario: LP fee for AMM based solely on liquidity score 158 159 And the following network parameters are set: 160 | name | value | 161 | market.liquidity.equityLikeShareFeeFraction | 0 | 162 163 164 # submit an AMM 165 Then the parties submit the following AMM: 166 | party | market id | amount | slippage | base | lower bound | upper bound | proposed fee | 167 | vamm1 | ETH/MAR22 | 10000 | 0.05 | 100 | 98 | 102 | 0.03 | 168 Then the AMM pool status should be: 169 | party | market id | amount | status | base | lower bound | upper bound | 170 | vamm1 | ETH/MAR22 | 10000 | STATUS_ACTIVE | 100 | 98 | 102 | 171 172 Then the network moves ahead "1" blocks 173 174 And the parties place the following orders: 175 | party | market id | side | volume | price | resulting trades | type | tif | reference | 176 | party1 | ETH/MAR22 | buy | 10 | 100 | 0 | TYPE_LIMIT | TIF_GTC | lp1-b | 177 | party2 | ETH/MAR22 | sell | 10 | 100 | 1 | TYPE_LIMIT | TIF_GTC | | 178 179 Then the network moves ahead "1" epochs 180 And the following transfers should happen: 181 | type | from | to | from account | to account | market id | amount | asset | 182 | TRANSFER_TYPE_LIQUIDITY_FEE_ALLOCATE | market | 137112507e25d3845a56c47db15d8ced0f28daa8498a0fd52648969c4b296aba | ACCOUNT_TYPE_FEES_LIQUIDITY | ACCOUNT_TYPE_LP_LIQUIDITY_FEES | ETH/MAR22 | 6 | USD | 183 | TRANSFER_TYPE_LIQUIDITY_FEE_ALLOCATE | market | lp1 | ACCOUNT_TYPE_FEES_LIQUIDITY | ACCOUNT_TYPE_LP_LIQUIDITY_FEES | ETH/MAR22 | 6 | USD | 184 | TRANSFER_TYPE_LIQUIDITY_FEE_ALLOCATE | market | lp2 | ACCOUNT_TYPE_FEES_LIQUIDITY | ACCOUNT_TYPE_LP_LIQUIDITY_FEES | ETH/MAR22 | 6 | USD | 185 186 187 @VAMM 188 Scenario: LP fee for AMM based solely on liquidity score when AMM cancels half way through an epoch 189 190 And the following network parameters are set: 191 | name | value | 192 | market.liquidity.equityLikeShareFeeFraction | 0 | 193 194 # submit an AMM 195 Then the parties submit the following AMM: 196 | party | market id | amount | slippage | base | lower bound | upper bound | proposed fee | 197 | vamm1 | ETH/MAR22 | 10000 | 0.05 | 100 | 98 | 102 | 0.03 | 198 Then the AMM pool status should be: 199 | party | market id | amount | status | base | lower bound | upper bound | 200 | vamm1 | ETH/MAR22 | 10000 | STATUS_ACTIVE | 100 | 98 | 102 | 201 202 Then the network moves ahead "5" blocks 203 When the parties cancel the following AMM: 204 | party | market id | method | 205 | vamm1 | ETH/MAR22 | METHOD_IMMEDIATE | 206 207 And the parties place the following orders: 208 | party | market id | side | volume | price | resulting trades | type | tif | reference | 209 | party1 | ETH/MAR22 | buy | 10 | 100 | 0 | TYPE_LIMIT | TIF_GTC | lp1-b | 210 | party2 | ETH/MAR22 | sell | 10 | 100 | 1 | TYPE_LIMIT | TIF_GTC | | 211 212 # epoch ends and AMM should get fewer fees than the above test because its ELS is less 213 Then the network moves ahead "7" blocks 214 And the following transfers should happen: 215 | type | from | to | from account | to account | market id | amount | asset | 216 | TRANSFER_TYPE_LIQUIDITY_FEE_ALLOCATE | market | 137112507e25d3845a56c47db15d8ced0f28daa8498a0fd52648969c4b296aba | ACCOUNT_TYPE_FEES_LIQUIDITY | ACCOUNT_TYPE_LP_LIQUIDITY_FEES | ETH/MAR22 | 5 | USD | 217 | TRANSFER_TYPE_LIQUIDITY_FEE_ALLOCATE | market | lp1 | ACCOUNT_TYPE_FEES_LIQUIDITY | ACCOUNT_TYPE_LP_LIQUIDITY_FEES | ETH/MAR22 | 7 | USD | 218 | TRANSFER_TYPE_LIQUIDITY_FEE_ALLOCATE | market | lp2 | ACCOUNT_TYPE_FEES_LIQUIDITY | ACCOUNT_TYPE_LP_LIQUIDITY_FEES | ETH/MAR22 | 7 | USD | 219 220 # and at the next epoch it should be 0 fees because its fully cancelled 221 And the parties place the following orders: 222 | party | market id | side | volume | price | resulting trades | type | tif | reference | 223 | party1 | ETH/MAR22 | buy | 10 | 100 | 0 | TYPE_LIMIT | TIF_GTC | lp1-b | 224 | party2 | ETH/MAR22 | sell | 10 | 100 | 1 | TYPE_LIMIT | TIF_GTC | | 225 226 Then the network moves ahead "1" epochs 227 And the following transfers should happen: 228 | type | from | to | from account | to account | market id | amount | asset | 229 | TRANSFER_TYPE_LIQUIDITY_FEE_ALLOCATE | market | lp1 | ACCOUNT_TYPE_FEES_LIQUIDITY | ACCOUNT_TYPE_LP_LIQUIDITY_FEES | ETH/MAR22 | 10 | USD | 230 | TRANSFER_TYPE_LIQUIDITY_FEE_ALLOCATE | market | lp2 | ACCOUNT_TYPE_FEES_LIQUIDITY | ACCOUNT_TYPE_LP_LIQUIDITY_FEES | ETH/MAR22 | 10 | USD |