code.vegaprotocol.io/vega@v0.79.0/core/integration/features/amm/0090-VAMM-oracle-base.feature (about) 1 Feature: vAMM with oracle driven base price 2 3 Background: 4 Background: 5 Given the following assets are registered: 6 | id | decimal places | 7 | ETH | 5 | 8 | USD | 0 | 9 And the perpetual oracles from "0xCAFECAFE1": 10 | name | asset | settlement property | settlement type | schedule property | schedule type | margin funding factor | interest rate | clamp lower bound | clamp upper bound | quote name | settlement decimals | source weights | source staleness tolerance | spec id | 11 | perp-oracle | ETH | perp.ETH.value | TYPE_INTEGER | perp.funding.cue | TYPE_TIMESTAMP | 0 | 0 | 0 | 0 | ETH | 5 | 1,0,0,0 | 100s,0s,0s,0s | 1234 | 12 And the liquidity sla params named "SLA": 13 | price range | commitment min time fraction | performance hysteresis epochs | sla competition factor | 14 | 1.0 | 0.5 | 1 | 1.0 | 15 And the liquidity monitoring parameters: 16 | name | triggering ratio | time window | scaling factor | 17 | lqm-params | 0.01 | 10s | 5 | 18 19 And the markets: 20 | id | quote name | asset | liquidity monitoring | risk model | margin calculator | auction duration | fees | price monitoring | data source config | linear slippage factor | quadratic slippage factor | decimal places | position decimal places | market type | sla params | tick size | 21 | ETH/MAR22 | ETH | ETH | lqm-params | default-st-risk-model | default-margin-calculator | 1 | default-none | default-none | perp-oracle | 0.1 | 0 | 0 | 5 | perp | SLA | 1 | 22 And the following network parameters are set: 23 | name | value | 24 | network.markPriceUpdateMaximumFrequency | 0s | 25 | market.auction.minimumDuration | 1 | 26 | market.fee.factors.infrastructureFee | 0.001 | 27 | market.fee.factors.makerFee | 0.004 | 28 | market.value.windowLength | 60s | 29 | market.liquidity.bondPenaltyParameter | 0.1 | 30 | validators.epoch.length | 5s | 31 | limits.markets.maxPeggedOrders | 2 | 32 | market.liquidity.providersFeeCalculationTimeStep | 5s | 33 | market.liquidity.stakeToCcyVolume | 1 | 34 35 And the average block duration is "1" 36 # 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 37 Given the parties deposit on asset's general account the following amount: 38 | party | asset | amount | 39 | lp1 | ETH | 100000000000 | 40 | lp2 | ETH | 100000000000 | 41 | lp3 | ETH | 100000000000 | 42 | party1 | ETH | 100000000000 | 43 | party2 | ETH | 100000000000 | 44 | party3 | ETH | 100000000000 | 45 | party4 | ETH | 100000000000 | 46 | party5 | ETH | 100000000000 | 47 | vamm1 | ETH | 100000000000 | 48 | vamm2 | ETH | 100000000000 | 49 | vamm3 | ETH | 100000000000 | 50 51 52 And the parties place the following orders: 53 | party | market id | side | volume | price | resulting trades | type | tif | reference | 54 | party1 | ETH/MAR22 | buy | 1 | 100 | 0 | TYPE_LIMIT | TIF_GTC | | 55 | party2 | ETH/MAR22 | sell | 1 | 100 | 0 | TYPE_LIMIT | TIF_GTC | | 56 When the opening auction period ends for market "ETH/MAR22" 57 Then the following trades should be executed: 58 | buyer | price | size | seller | 59 | party1 | 100 | 1 | party2 | 60 61 62 @VAMM 63 Scenario: 0090-VAMM-038 It's possible to setup the vAMM so that it uses one of the oracles already available for the market in which it operates for its `base price`. In that case the deployment attempt should be deferred until the next value is received from the oracle. 64 65 Then the parties submit the following AMM: 66 | party | market id | amount | slippage | base | lower bound | upper bound | proposed fee | data source id | 67 | vamm1 | ETH/MAR22 | 100000 | 0.05 | 0 | 95 | 105 | 0.03 | 1234 | 68 Then the AMM pool status should be: 69 | party | market id | amount | status | base | lower bound | upper bound | 70 | vamm1 | ETH/MAR22 | 100000 | STATUS_PENDING | 0 | 95 | 105 | 71 72 And set the following AMM sub account aliases: 73 | party | market id | alias | 74 | vamm1 | ETH/MAR22 | vamm1-id | 75 76 And the market data for the market "ETH/MAR22" should be: 77 | mark price | trading mode | best bid price | best offer price | best bid volume | best offer volume | 78 | 100 | TRADING_MODE_CONTINUOUS | 0 | 0 | 0 | 0 | 79 80 # now oracle data comes in for the perp and it drives the AMM's base price 81 When the oracles broadcast data with block time signed with "0xCAFECAFE1": 82 | name | value | time offset | 83 | perp.ETH.value | 10000000 | -2s | 84 85 Then the AMM pool status should be: 86 | party | market id | amount | status | base | lower bound | upper bound | 87 | vamm1 | ETH/MAR22 | 100000 | STATUS_ACTIVE | 100 | 95 | 105 | 88 89 Then the market data for the market "ETH/MAR22" should be: 90 | mark price | trading mode | best bid price | best offer price | best bid volume | best offer volume | 91 | 100 | TRADING_MODE_CONTINUOUS | 99 | 101 | 976 | 931 | 92 93 # now oracle data comes in for a price that is outside of the lower bound the AMM doesn't get updated 94 When the oracles broadcast data with block time signed with "0xCAFECAFE1": 95 | name | value | time offset | 96 | perp.ETH.value | 9000000 | -1s | 97 98 Then the market data for the market "ETH/MAR22" should be: 99 | mark price | trading mode | best bid price | best offer price | best bid volume | best offer volume | 100 | 100 | TRADING_MODE_CONTINUOUS | 99 | 101 | 976 | 931 | 101 102 # now oracle data comes in for a price that is outside of the upper bound the AMM doesn't get updated 103 When the oracles broadcast data with block time signed with "0xCAFECAFE1": 104 | name | value | time offset | 105 | perp.ETH.value | 20000000 | 0s | 106 107 Then the market data for the market "ETH/MAR22" should be: 108 | mark price | trading mode | best bid price | best offer price | best bid volume | best offer volume | 109 | 100 | TRADING_MODE_CONTINUOUS | 99 | 101 | 976 | 931 | 110 111 # now oracle data comes in for a price that is outside of the upper bound the AMM doesn't get updated 112 When the oracles broadcast data with block time signed with "0xCAFECAFE1": 113 | name | value | time offset | 114 | perp.ETH.value | 9900000 | 1s | 115 116 Then the market data for the market "ETH/MAR22" should be: 117 | mark price | trading mode | best bid price | best offer price | best bid volume | best offer volume | 118 | 100 | TRADING_MODE_CONTINUOUS | 98 | 100 | 1260 | 764 | 119 120 @VAMM 121 Scenario: 0090-VAMM-039 AMM has a static base price and amends itself to a oracle drive base price 122 Then the parties submit the following AMM: 123 | party | market id | amount | slippage | base | lower bound | upper bound | proposed fee | 124 | vamm1 | ETH/MAR22 | 100000 | 0.05 | 100 | 95 | 105 | 0.03 | 125 Then the AMM pool status should be: 126 | party | market id | amount | status | base | lower bound | upper bound | 127 | vamm1 | ETH/MAR22 | 100000 | STATUS_ACTIVE | 100 | 95 | 105 | 128 129 And set the following AMM sub account aliases: 130 | party | market id | alias | 131 | vamm1 | ETH/MAR22 | vamm1-id | 132 133 And the market data for the market "ETH/MAR22" should be: 134 | mark price | trading mode | best bid price | best offer price | best bid volume | best offer volume | 135 | 100 | TRADING_MODE_CONTINUOUS | 99 | 101 | 976 | 931 | 136 137 # now oracle data comes in nothing changes on the AMM 138 When the oracles broadcast data with block time signed with "0xCAFECAFE1": 139 | name | value | time offset | 140 | perp.ETH.value | 10000000 | -2s | 141 142 And the market data for the market "ETH/MAR22" should be: 143 | mark price | trading mode | best bid price | best offer price | best bid volume | best offer volume | 144 | 100 | TRADING_MODE_CONTINUOUS | 99 | 101 | 976 | 931 | 145 146 # the base price is inherited from the old AMM 147 Then the parties amend the following AMM: 148 | party | market id | amount | slippage | base | lower bound | upper bound | proposed fee | data source id | 149 | vamm1 | ETH/MAR22 | 100000 | 0.05 | 0 | 95 | 105 | 0.03 | 1234 | 150 Then the AMM pool status should be: 151 | party | market id | amount | status | base | lower bound | upper bound | 152 | vamm1 | ETH/MAR22 | 100000 | STATUS_ACTIVE | 100 | 95 | 105 | 153 154 And the market data for the market "ETH/MAR22" should be: 155 | mark price | trading mode | best bid price | best offer price | best bid volume | best offer volume | 156 | 100 | TRADING_MODE_CONTINUOUS | 99 | 101 | 976 | 931 | 157 158 # now it can get updated 159 When the oracles broadcast data with block time signed with "0xCAFECAFE1": 160 | name | value | time offset | 161 | perp.ETH.value | 9900000 | -1s | 162 163 Then the market data for the market "ETH/MAR22" should be: 164 | mark price | trading mode | best bid price | best offer price | best bid volume | best offer volume | 165 | 100 | TRADING_MODE_CONTINUOUS | 98 | 100 | 1260 | 764 | 166 167 @VAMM 168 Scenario: AMM has a static base price and amends itself to a oracle drive base price where old base it out of range 169 Then the parties submit the following AMM: 170 | party | market id | amount | slippage | base | lower bound | upper bound | proposed fee | 171 | vamm1 | ETH/MAR22 | 100000 | 0.05 | 100 | 95 | 105 | 0.03 | 172 Then the AMM pool status should be: 173 | party | market id | amount | status | base | lower bound | upper bound | 174 | vamm1 | ETH/MAR22 | 100000 | STATUS_ACTIVE | 100 | 95 | 105 | 175 176 And set the following AMM sub account aliases: 177 | party | market id | alias | 178 | vamm1 | ETH/MAR22 | vamm1-id | 179 180 And the market data for the market "ETH/MAR22" should be: 181 | mark price | trading mode | best bid price | best offer price | best bid volume | best offer volume | 182 | 100 | TRADING_MODE_CONTINUOUS | 99 | 101 | 976 | 931 | 183 184 # the base price is inherited from the old AMM 185 Then the parties amend the following AMM: 186 | party | market id | amount | slippage | base | lower bound | upper bound | proposed fee | data source id | 187 | vamm1 | ETH/MAR22 | 1000000 | 0.05 | 0 | 200 | 210 | 0.03 | 1234 | 188 Then the AMM pool status should be: 189 | party | market id | amount | status | base | lower bound | upper bound | 190 | vamm1 | ETH/MAR22 | 1000000 | STATUS_PENDING | 0 | 200 | 210 | 191 192 And the market data for the market "ETH/MAR22" should be: 193 | mark price | trading mode | best bid price | best offer price | best bid volume | best offer volume | 194 | 100 | TRADING_MODE_CONTINUOUS | 0 | 0 | 0 | 0 | 195 196 # now it can get updated 197 When the oracles broadcast data with block time signed with "0xCAFECAFE1": 198 | name | value | time offset | 199 | perp.ETH.value | 20500000 | -1s | 200 201 Then the market data for the market "ETH/MAR22" should be: 202 | mark price | trading mode | best bid price | best offer price | best bid volume | best offer volume | 203 | 100 | TRADING_MODE_CONTINUOUS | 204 | 206 | 5037 | 4871 | 204 205 206 @VAMM 207 Scenario: 0090-VAMM-040, 0090-VAMM-041 base only gets update if difference in price is less that minimum price change trigger 208 Then the parties submit the following AMM: 209 | party | market id | amount | slippage | base | lower bound | upper bound | proposed fee | data source id | minimum price change trigger | 210 | vamm1 | ETH/MAR22 | 100000 | 0.05 | 0 | 95 | 105 | 0.03 | 1234 | 0.02 | 211 Then the AMM pool status should be: 212 | party | market id | amount | status | base | lower bound | upper bound | 213 | vamm1 | ETH/MAR22 | 100000 | STATUS_PENDING | 0 | 95 | 105 | 214 215 And set the following AMM sub account aliases: 216 | party | market id | alias | 217 | vamm1 | ETH/MAR22 | vamm1-id | 218 219 And the market data for the market "ETH/MAR22" should be: 220 | mark price | trading mode | best bid price | best offer price | best bid volume | best offer volume | 221 | 100 | TRADING_MODE_CONTINUOUS | 0 | 0 | 0 | 0 | 222 223 # now oracle data comes in and update base price, the AMM is pending so will take anything 224 When the oracles broadcast data with block time signed with "0xCAFECAFE1": 225 | name | value | time offset | 226 | perp.ETH.value | 10000000 | -2s | 227 228 And the market data for the market "ETH/MAR22" should be: 229 | mark price | trading mode | best bid price | best offer price | best bid volume | best offer volume | 230 | 100 | TRADING_MODE_CONTINUOUS | 99 | 101 | 976 | 931 | 231 232 233 Then the network moves ahead "1" blocks 234 # oracle data too close in price, no update 235 When the oracles broadcast data with block time signed with "0xCAFECAFE1": 236 | name | value | time offset | 237 | perp.ETH.value | 10100000 | -1s | 238 239 And the market data for the market "ETH/MAR22" should be: 240 | mark price | trading mode | best bid price | best offer price | best bid volume | best offer volume | 241 | 100 | TRADING_MODE_CONTINUOUS | 99 | 101 | 976 | 931 | 242 243 244 # oracle data shifts the base price more than the minimum, update happens 245 When the oracles broadcast data with block time signed with "0xCAFECAFE1": 246 | name | value | time offset | 247 | perp.ETH.value | 10300000 | 0s | 248 249 And the market data for the market "ETH/MAR22" should be: 250 | mark price | trading mode | best bid price | best offer price | best bid volume | best offer volume | 251 | 100 | TRADING_MODE_CONTINUOUS | 102 | 104 | 556 | 2447 | 252 253 254 @VAMM 255 Scenario: 0090-VAMM-042 updated base price is good, but slippage to rebase prevents it 256 257 Then the parties submit the following AMM: 258 | party | market id | amount | slippage | base | lower bound | upper bound | proposed fee | data source id | 259 | vamm1 | ETH/MAR22 | 100000 | 0.02 | 0 | 80 | 120 | 0.03 | 1234 | 260 Then the AMM pool status should be: 261 | party | market id | amount | status | base | lower bound | upper bound | 262 | vamm1 | ETH/MAR22 | 100000 | STATUS_PENDING | 0 | 80 | 120 | 263 264 # now oracle data comes in for the perp and it drives the AMM's base price 265 When the oracles broadcast data with block time signed with "0xCAFECAFE1": 266 | name | value | time offset | 267 | perp.ETH.value | 10000000 | -2s | 268 269 Then the AMM pool status should be: 270 | party | market id | amount | status | base | lower bound | upper bound | 271 | vamm1 | ETH/MAR22 | 100000 | STATUS_ACTIVE | 100 | 80 | 120 | 272 273 # now we place a big order that doesn't cross 274 When the parties place the following orders: 275 | party | market id | side | volume | price | resulting trades | type | tif | reference | 276 | party1 | ETH/MAR22 | sell | 200 | 101 | 0 | TYPE_LIMIT | TIF_GTC | | 277 278 279 Then the market data for the market "ETH/MAR22" should be: 280 | mark price | trading mode | best bid price | best offer price | best bid volume | best offer volume | 281 | 100 | TRADING_MODE_CONTINUOUS | 99 | 101 | 177 | 373 | 282 283 284 # now oracle data comes in for the perp and it drives the AMM's base price 285 When the oracles broadcast data with block time signed with "0xCAFECAFE1": 286 | name | value | time offset | 287 | perp.ETH.value | 11500000 | -1s | 288 289 Then the market data for the market "ETH/MAR22" should be: 290 | mark price | trading mode | best bid price | best offer price | best bid volume | best offer volume | 291 | 100 | TRADING_MODE_CONTINUOUS | 99 | 101 | 177 | 373 | 292 293 # now oracle data comes in for the perp and it drives the AMM's base price 294 When the oracles broadcast data with block time signed with "0xCAFECAFE1": 295 | name | value | time offset | 296 | perp.ETH.value | 10200000 | 0s | 297 298 Then the AMM pool status should be: 299 | party | market id | amount | status | base | lower bound | upper bound | 300 | vamm1 | ETH/MAR22 | 100000 | STATUS_ACTIVE | 102 | 80 | 120 | 301 302 Then the market data for the market "ETH/MAR22" should be: 303 | mark price | trading mode | best bid price | best offer price | best bid volume | best offer volume | 304 | 100 | TRADING_MODE_CONTINUOUS | 100 | 101 | 155 | 47 | 305 306 307 @VAMM 308 Scenario: 0090-VAMM-043 AMM amendment uses slippage straight away 309 Then the parties submit the following AMM: 310 | party | market id | amount | slippage | base | lower bound | upper bound | proposed fee | 311 | vamm1 | ETH/MAR22 | 100000 | 0.01 | 100 | 80 | 120 | 0.03 | 312 Then the AMM pool status should be: 313 | party | market id | amount | status | base | lower bound | upper bound | 314 | vamm1 | ETH/MAR22 | 100000 | STATUS_ACTIVE | 100 | 80 | 120 | 315 316 317 And the market data for the market "ETH/MAR22" should be: 318 | mark price | trading mode | best bid price | best offer price | best bid volume | best offer volume | 319 | 100 | TRADING_MODE_CONTINUOUS | 99 | 101 | 177 | 173 | 320 321 # the base price is inherited from the old AMM 322 Then the parties amend the following AMM: 323 | party | market id | amount | slippage | base | lower bound | upper bound | proposed fee | data source id | 324 | vamm1 | ETH/MAR22 | 100000 | 0.05 | 0 | 80 | 120 | 0.03 | 1234 | 325 Then the AMM pool status should be: 326 | party | market id | amount | status | base | lower bound | upper bound | 327 | vamm1 | ETH/MAR22 | 100000 | STATUS_ACTIVE | 100 | 80 | 120 | 328 329 330 # now we place a big order that doesn't cross 331 When the parties place the following orders: 332 | party | market id | side | volume | price | resulting trades | type | tif | reference | 333 | party1 | ETH/MAR22 | sell | 700 | 102 | 0 | TYPE_LIMIT | TIF_GTC | | 334 335 336 And the market data for the market "ETH/MAR22" should be: 337 | mark price | trading mode | best bid price | best offer price | best bid volume | best offer volume | 338 | 100 | TRADING_MODE_CONTINUOUS | 99 | 101 | 177 | 173 | 339 340 # now it can get updated 341 When the oracles broadcast data with block time signed with "0xCAFECAFE1": 342 | name | value | time offset | 343 | perp.ETH.value | 11500000 | -1s | 344 345 # base price update only happened because the slippage was increased in the amend that set the new oracle value 346 Then the AMM pool status should be: 347 | party | market id | amount | status | base | lower bound | upper bound | 348 | vamm1 | ETH/MAR22 | 100000 | STATUS_ACTIVE | 115 | 80 | 120 |