code.vegaprotocol.io/vega@v0.79.0/core/integration/features/amm/amend-amm-single-side.feature (about) 1 Feature: vAMM amend single-sided commitments 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 #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 43 And the liquidity sla params named "SLA-22": 44 | price range | commitment min time fraction | performance hysteresis epochs | sla competition factor | 45 | 0.5 | 0.6 | 1 | 1.0 | 46 47 And the markets: 48 | 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 | 49 | 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 | 50 | ETH/MAR23 | 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 # Setting up the accounts and vAMM submission now is part of the background, because we'll be running scenarios 0090-VAMM-006 through 0090-VAMM-014 on this setup 53 Given the parties deposit on asset's general account the following amount: 54 | party | asset | amount | 55 | lp1 | USD | 1000000 | 56 | lp2 | USD | 1000000 | 57 | lp3 | USD | 1000000 | 58 | party1 | USD | 1000000 | 59 | party2 | USD | 1000000 | 60 | party3 | USD | 1000000 | 61 | party4 | USD | 1000000 | 62 | party5 | USD | 1000000 | 63 | vamm1 | USD | 1000000 | 64 | vamm2 | USD | 1000000 | 65 66 When the parties submit the following liquidity provision: 67 | id | party | market id | commitment amount | fee | lp type | 68 | lp_1 | lp1 | ETH/MAR22 | 10000 | 0.02 | submission | 69 | lp_2 | lp2 | ETH/MAR23 | 10000 | 0.02 | submission | 70 71 And the parties place the following orders: 72 | party | market id | side | volume | price | resulting trades | type | tif | reference | 73 | lp1 | ETH/MAR22 | buy | 20 | 40 | 0 | TYPE_LIMIT | TIF_GTC | lp1-b | 74 | lp2 | ETH/MAR23 | buy | 20 | 40 | 0 | TYPE_LIMIT | TIF_GTC | lp2-b | 75 | party1 | ETH/MAR22 | buy | 1 | 100 | 0 | TYPE_LIMIT | TIF_GTC | | 76 | party3 | ETH/MAR23 | buy | 1 | 100 | 0 | TYPE_LIMIT | TIF_GTC | | 77 | party2 | ETH/MAR22 | sell | 1 | 100 | 0 | TYPE_LIMIT | TIF_GTC | | 78 | party4 | ETH/MAR23 | sell | 1 | 100 | 0 | TYPE_LIMIT | TIF_GTC | | 79 | lp1 | ETH/MAR22 | sell | 10 | 160 | 0 | TYPE_LIMIT | TIF_GTC | lp1-s | 80 | lp2 | ETH/MAR23 | sell | 10 | 160 | 0 | TYPE_LIMIT | TIF_GTC | lp2-s | 81 82 # End opening auction for both markets. 83 When the network moves ahead "3" blocks 84 Then the following trades should be executed: 85 | buyer | price | size | seller | 86 | party1 | 100 | 1 | party2 | 87 | party3 | 100 | 1 | party4 | 88 89 Then the network moves ahead "1" epochs 90 And the current epoch is "1" 91 92 Then the parties submit the following AMM: 93 | party | market id | amount | slippage | base | upper bound | proposed fee | 94 | vamm1 | ETH/MAR22 | 100000 | 0.05 | 100 | 110 | 0.03 | 95 And the parties submit the following AMM: 96 | party | market id | amount | slippage | base | lower bound | upper bound | proposed fee | 97 | vamm2 | ETH/MAR23 | 100000 | 0.05 | 100 | 90 | 110 | 0.03 | 98 Then the AMM pool status should be: 99 | party | market id | amount | status | base | upper bound | lower bound | 100 | vamm1 | ETH/MAR22 | 100000 | STATUS_ACTIVE | 100 | 110 | | 101 | vamm2 | ETH/MAR23 | 100000 | STATUS_ACTIVE | 100 | 110 | 90 | 102 And set the following AMM sub account aliases: 103 | party | market id | alias | 104 | vamm1 | ETH/MAR22 | vamm1-id | 105 | vamm2 | ETH/MAR23 | vamm2-id | 106 107 108 @VAMM 109 Scenario: vAMM is amended from BUY to SELL side 110 When the parties place the following orders: 111 | party | market id | side | volume | price | resulting trades | type | tif | 112 | party3 | ETH/MAR22 | buy | 1 | 99 | 0 | TYPE_LIMIT | TIF_GTC | 113 Then the order book should have the following volumes for market "ETH/MAR22": 114 | side | price | volume | 115 | buy | 40 | 20 | 116 | buy | 99 | 1 | 117 | sell | 160 | 10 | 118 And the parties amend the following AMM: 119 | party | market id | slippage | base | lower bound | 120 | vamm1 | ETH/MAR22 | 0.05 | 100 | 90 | 121 Then the AMM pool status should be: 122 | party | market id | amount | status | base | lower bound | upper bound | 123 | vamm1 | ETH/MAR22 | 100000 | STATUS_ACTIVE | 100 | 90 | | 124 # Make sure nothing changes when we move to the next block 125 When the network moves ahead "1" blocks 126 And the parties amend the following AMM: 127 | party | market id | slippage | base | lower bound | 128 | vamm1 | ETH/MAR22 | 0.05 | 100 | 90 | 129 Then the AMM pool status should be: 130 | party | market id | amount | status | base | lower bound | upper bound | 131 | vamm1 | ETH/MAR22 | 100000 | STATUS_ACTIVE | 100 | 90 | | 132 And the order book should have the following volumes for market "ETH/MAR22": 133 | side | price | volume | 134 | buy | 40 | 20 | 135 | buy | 99 | 1 | 136 | sell | 160 | 10 | 137 138 When the parties place the following orders: 139 | party | market id | side | volume | price | resulting trades | type | tif | 140 | party3 | ETH/MAR22 | sell | 1 | 101 | 0 | TYPE_LIMIT | TIF_GTC | 141 Then the AMM pool status should be: 142 | party | market id | amount | status | base | lower bound | upper bound | 143 | vamm1 | ETH/MAR22 | 100000 | STATUS_ACTIVE | 100 | 90 | | 144 And the order book should have the following volumes for market "ETH/MAR22": 145 | side | price | volume | 146 | buy | 40 | 20 | 147 | buy | 99 | 1 | 148 | sell | 101 | 1 | 149 | sell | 160 | 10 | 150 When the network moves ahead "1" blocks 151 Then the AMM pool status should be: 152 | party | market id | amount | status | base | lower bound | upper bound | 153 | vamm1 | ETH/MAR22 | 100000 | STATUS_ACTIVE | 100 | 90 | | 154 And the order book should have the following volumes for market "ETH/MAR22": 155 | side | price | volume | 156 | buy | 40 | 20 | 157 | buy | 99 | 1 | 158 | sell | 101 | 1 | 159 | sell | 160 | 10 | 160 161 @VAMM 162 Scenario: vAMM is amended from having a lower and upper bound to just lower or upper bound. The vAMM does not hold any positions. 163 When the parties amend the following AMM: 164 | party | market id | slippage | base | upper bound | 165 | vamm2 | ETH/MAR23 | 0.05 | 100 | 110 | 166 # No trades because the sell vAMM places no sell orders. 167 Then the parties place the following orders: 168 | party | market id | side | volume | price | resulting trades | type | tif | 169 | party3 | ETH/MAR23 | buy | 1 | 99 | 0 | TYPE_LIMIT | TIF_GTC | 170 And the AMM pool status should be: 171 | party | market id | amount | status | base | upper bound | lower bound | 172 | vamm2 | ETH/MAR23 | 100000 | STATUS_ACTIVE | 100 | 110 | | 173 174 When the network moves ahead "1" blocks 175 And the parties amend the following AMM: 176 | party | market id | slippage | base | lower bound | 177 | vamm2 | ETH/MAR23 | 0.05 | 100 | 90 | 178 Then the AMM pool status should be: 179 | party | market id | amount | status | base | lower bound | upper bound | 180 | vamm2 | ETH/MAR23 | 100000 | STATUS_ACTIVE | 100 | 90 | | 181 And the order book should have the following volumes for market "ETH/MAR23": 182 | side | price | volume | 183 | buy | 40 | 20 | 184 | buy | 99 | 1 | 185 | sell | 160 | 10 | 186 187 When the parties place the following orders: 188 | party | market id | side | volume | price | resulting trades | type | tif | 189 | party4 | ETH/MAR23 | sell | 1 | 101 | 0 | TYPE_LIMIT | TIF_GTC | 190 Then the AMM pool status should be: 191 | party | market id | amount | status | base | lower bound | upper bound | 192 | vamm2 | ETH/MAR23 | 100000 | STATUS_ACTIVE | 100 | 90 | | 193 And the order book should have the following volumes for market "ETH/MAR23": 194 | side | price | volume | 195 | buy | 40 | 20 | 196 | buy | 99 | 1 | 197 | sell | 101 | 1 | 198 | sell | 160 | 10 | 199 When the network moves ahead "1" blocks 200 Then the AMM pool status should be: 201 | party | market id | amount | status | base | lower bound | upper bound | 202 | vamm2 | ETH/MAR23 | 100000 | STATUS_ACTIVE | 100 | 90 | | 203 And the order book should have the following volumes for market "ETH/MAR23": 204 | side | price | volume | 205 | buy | 40 | 20 | 206 | buy | 99 | 1 | 207 | sell | 101 | 1 | 208 | sell | 160 | 10 | 209 210 @VAMM 211 Scenario: vAMM can't amended from having a lower and upper bound to just lower or upper bound when the vAMM holds a long position. 212 Then the parties place the following orders: 213 | party | market id | side | volume | price | resulting trades | type | tif | 214 | party3 | ETH/MAR23 | buy | 1 | 101 | 1 | TYPE_LIMIT | TIF_GTC | 215 When the parties amend the following AMM: 216 | party | market id | slippage | base | upper bound | 217 | vamm2 | ETH/MAR23 | 0.05 | 100 | 110 | 218 And the AMM pool status should be: 219 | party | market id | amount | status | base | upper bound | lower bound | 220 | vamm2 | ETH/MAR23 | 100000 | STATUS_ACTIVE | 100 | 110 | | 221 222 When the network moves ahead "1" blocks 223 Then the parties amend the following AMM: 224 | party | market id | slippage | base | lower bound | error | 225 | vamm2 | ETH/MAR23 | 0.05 | 100 | 90 | cannot remove upper bound when AMM is short | 226 And the AMM pool status should be: 227 | party | market id | amount | status | base | upper bound | lower bound | 228 | vamm2 | ETH/MAR23 | 100000 | STATUS_ACTIVE | 100 | 110 | | 229 230 @VAMM 231 Scenario: vAMM can't amended from having a lower and upper bound to just lower or upper bound when the vAMM holds a short position. 232 When the parties place the following orders: 233 | party | market id | side | volume | price | resulting trades | type | tif | 234 | party4 | ETH/MAR23 | sell | 1 | 99 | 1 | TYPE_LIMIT | TIF_GTC | 235 Then the parties amend the following AMM: 236 | party | market id | slippage | base | lower bound | 237 | vamm2 | ETH/MAR23 | 0.05 | 100 | 90 | 238 And the AMM pool status should be: 239 | party | market id | amount | status | base | upper bound | lower bound | 240 | vamm2 | ETH/MAR23 | 100000 | STATUS_ACTIVE | 100 | | 90 | 241 242 When the network moves ahead "1" blocks 243 Then the parties amend the following AMM: 244 | party | market id | slippage | base | upper bound | error | 245 | vamm2 | ETH/MAR23 | 0.05 | 100 | 110 | cannot remove lower bound when AMM is long | 246 And the AMM pool status should be: 247 | party | market id | amount | status | base | upper bound | lower bound | 248 | vamm2 | ETH/MAR23 | 100000 | STATUS_ACTIVE | 100 | | 90 | 249 250 @VAMM 251 Scenario: vAMM can't amended from having a single bound to the other side, when the vAMM holds a long position. 252 Then the parties place the following orders: 253 | party | market id | side | volume | price | resulting trades | type | tif | 254 | party1 | ETH/MAR22 | buy | 1 | 101 | 1 | TYPE_LIMIT | TIF_GTC | 255 And the AMM pool status should be: 256 | party | market id | amount | status | base | upper bound | lower bound | 257 | vamm1 | ETH/MAR22 | 100000 | STATUS_ACTIVE | 100 | 110 | | 258 259 When the network moves ahead "1" blocks 260 Then the parties amend the following AMM: 261 | party | market id | slippage | base | lower bound | error | 262 | vamm1 | ETH/MAR22 | 0.05 | 100 | 90 | cannot remove upper bound when AMM is short | 263 And the AMM pool status should be: 264 | party | market id | amount | status | base | upper bound | lower bound | 265 | vamm1 | ETH/MAR22 | 100000 | STATUS_ACTIVE | 100 | 110 | | 266 267 @VAMM 268 Scenario: vAMM can't amended from having a single bound to the other side, when the vAMM holds a short position. 269 When the parties amend the following AMM: 270 | party | market id | slippage | base | lower bound | 271 | vamm1 | ETH/MAR22 | 0.05 | 100 | 90 | 272 Then the parties place the following orders: 273 | party | market id | side | volume | price | resulting trades | type | tif | 274 | party2 | ETH/MAR22 | sell | 1 | 99 | 1 | TYPE_LIMIT | TIF_GTC | 275 And the AMM pool status should be: 276 | party | market id | amount | status | base | upper bound | lower bound | 277 | vamm1 | ETH/MAR22 | 100000 | STATUS_ACTIVE | 100 | | 90 | 278 279 When the network moves ahead "1" blocks 280 Then the parties amend the following AMM: 281 | party | market id | slippage | base | upper bound | error | 282 | vamm1 | ETH/MAR22 | 0.05 | 100 | 110 | cannot remove lower bound when AMM is long | 283 And the AMM pool status should be: 284 | party | market id | amount | status | base | upper bound | lower bound | 285 | vamm1 | ETH/MAR22 | 100000 | STATUS_ACTIVE | 100 | | 90 |