code.vegaprotocol.io/vega@v0.79.0/core/integration/features/price_monitoring/end-long-auction-with-trigger-change.feature (about) 1 Feature: Confirm return to continuous trading during significant mark price change can be sped up with trigger modification mid-auction 2 Background: 3 Given the following network parameters are set: 4 | name | value | 5 | network.markPriceUpdateMaximumFrequency | 1s | 6 | limits.markets.maxPeggedOrders | 2 | 7 And the liquidity monitoring parameters: 8 | name | triggering ratio | time window | scaling factor | 9 | lqm-params | 0.00 | 24h | 1e-9 | 10 And the price monitoring named "my-price-monitoring-1": 11 | horizon | probability | auction extension | 12 | 60 | 0.95 | 5 | 13 | 60 | 0.95 | 5 | 14 | 60 | 0.95 | 5 | 15 | 60 | 0.95 | 5 | 16 | 60 | 0.95 | 5 | 17 And the log normal risk model named "my-log-normal-risk-model": 18 | risk aversion | tau | mu | r | sigma | 19 | 0.000001 | 0.00011407711613050422 | 0 | 0.016 | 2.0 | 20 And the composite price oracles from "0xCAFECAFE1": 21 | name | price property | price type | price decimals | 22 | oracle1 | prices.ETH.value | TYPE_INTEGER | 0 | 23 And the markets: 24 | 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 | price type | decay weight | decay power | cash amount | source weights | source staleness tolerance | oracle1 | market type | 25 | ETH/FEB23 | ETH | USD | lqm-params | my-log-normal-risk-model | default-margin-calculator | 5 | default-none | my-price-monitoring-1 | default-eth-for-future | 0.25 | 0 | default-futures | weight | 0.1 | 0.5 | 500000 | 0,0,1,0 | 0s,0s,0h0m120s,0s | oracle1 | future | 26 27 When the parties deposit on asset's general account the following amount: 28 | party | asset | amount | 29 | party1 | USD | 100000000000 | 30 | party2 | USD | 100000000000 | 31 And the parties place the following orders with ticks: 32 | party | market id | side | volume | price | resulting trades | type | tif | 33 | party1 | ETH/FEB23 | buy | 1 | 1000 | 0 | TYPE_LIMIT | TIF_GTC | 34 | party2 | ETH/FEB23 | sell | 1 | 1000 | 0 | TYPE_LIMIT | TIF_GTC | 35 And the oracles broadcast data with block time signed with "0xCAFECAFE1": 36 | name | value | time offset | 37 | prices.ETH.value | 1000 | -1s | 38 And the network moves ahead "6" blocks 39 Then the market data for the market "ETH/FEB23" should be: 40 | mark price | trading mode | auction trigger | horizon | ref price | min bound | max bound | 41 | 1000 | TRADING_MODE_CONTINUOUS | AUCTION_TRIGGER_UNSPECIFIED | 60 | 1000 | 995 | 1005 | 42 43 Scenario: Mark price update without any intervention, book stuck at old price 44 45 When the oracles broadcast data with block time signed with "0xCAFECAFE1": 46 | name | value | time offset | 47 | prices.ETH.value | 2000 | -1s | 48 And the network moves ahead "2" blocks 49 Then the market data for the market "ETH/FEB23" should be: 50 | mark price | trading mode | auction trigger | horizon | ref price | min bound | max bound | 51 | 1000 | TRADING_MODE_MONITORING_AUCTION | AUCTION_TRIGGER_PRICE | 60 | 1000 | 995 | 1005 | 52 53 When the network moves ahead "100" blocks 54 Then the market data for the market "ETH/FEB23" should be: 55 | mark price | trading mode | auction trigger | horizon | ref price | min bound | max bound | 56 | 1000 | TRADING_MODE_MONITORING_AUCTION | AUCTION_TRIGGER_PRICE | 60 | 1000 | 995 | 1005 | 57 58 When the oracles broadcast data with block time signed with "0xCAFECAFE1": 59 | name | value | time offset | 60 | prices.ETH.value | 2000 | -1s | 61 And the network moves ahead "25" blocks 62 Then the market data for the market "ETH/FEB23" should be: 63 | mark price | trading mode | auction trigger | horizon | ref price | min bound | max bound | 64 | 1000 | TRADING_MODE_MONITORING_AUCTION | AUCTION_TRIGGER_PRICE | 60 | 1000 | 995 | 1005 | 65 66 # In this scenario market will only leave the auction once the latest oracle-based mark-price candidate becomes stale 67 When the network moves ahead "96" blocks 68 Then the market data for the market "ETH/FEB23" should be: 69 | mark price | trading mode | auction trigger | horizon | ref price | min bound | max bound | 70 | 1000 | TRADING_MODE_CONTINUOUS | AUCTION_TRIGGER_UNSPECIFIED | 60 | 1000 | 995 | 1005 | 71 72 Scenario: Mark price update, followed by uncrossing trade near the new price 73 74 When the oracles broadcast data with block time signed with "0xCAFECAFE1": 75 | name | value | time offset | 76 | prices.ETH.value | 2000 | -1s | 77 And the network moves ahead "2" blocks 78 Then the market data for the market "ETH/FEB23" should be: 79 | mark price | trading mode | auction trigger | horizon | ref price | min bound | max bound | 80 | 1000 | TRADING_MODE_MONITORING_AUCTION | AUCTION_TRIGGER_PRICE | 60 | 1000 | 995 | 1005 | 81 82 When the parties place the following orders with ticks: 83 | party | market id | side | volume | price | resulting trades | type | tif | 84 | party1 | ETH/FEB23 | buy | 1 | 2004 | 0 | TYPE_LIMIT | TIF_GTC | 85 | party2 | ETH/FEB23 | sell | 1 | 2004 | 0 | TYPE_LIMIT | TIF_GTC | 86 And the network moves ahead "5" blocks 87 Then the market data for the market "ETH/FEB23" should be: 88 | mark price | trading mode | auction trigger | 89 | 1000 | TRADING_MODE_MONITORING_AUCTION | AUCTION_TRIGGER_PRICE | 90 91 # auction ends once auction extensions for all triggers elapse 92 When the network moves ahead "21" blocks 93 Then the market data for the market "ETH/FEB23" should be: 94 | mark price | trading mode | auction trigger | last traded price | horizon | ref price | min bound | max bound | 95 | 2000 | TRADING_MODE_CONTINUOUS | AUCTION_TRIGGER_UNSPECIFIED | 2004 | 60 | 2002 | 1992 | 2012 | 96 97 Scenario: Mark price update, followed by trigger update 98 99 When the oracles broadcast data with block time signed with "0xCAFECAFE1": 100 | name | value | time offset | 101 | prices.ETH.value | 2000 | -1s | 102 And the network moves ahead "2" blocks 103 Then the market data for the market "ETH/FEB23" should be: 104 | mark price | trading mode | auction trigger | horizon | ref price | min bound | max bound | auction end | 105 | 1000 | TRADING_MODE_MONITORING_AUCTION | AUCTION_TRIGGER_PRICE | 60 | 1000 | 995 | 1005 | 5 | 106 107 And the price monitoring named "my-price-monitoring-2": 108 | horizon | probability | auction extension | 109 | 30 | 0.95 | 1 | 110 111 # update trigger here so that there's only one 112 When the markets are updated: 113 | id | price monitoring | price type | source weights | source staleness tolerance | 114 | ETH/FEB23 | my-price-monitoring-2 | weight | 0,0,1,0 | 0s,0s,0h0m120s,0s | 115 # first we get bounds based on default factors, once the state variable engine finishes its calculation we get the proper values 116 Then the market data for the market "ETH/FEB23" should be: 117 | mark price | trading mode | auction trigger | 118 | 1000 | TRADING_MODE_MONITORING_AUCTION | AUCTION_TRIGGER_PRICE | 119 120 # the last second of the original extensions 121 And the network moves ahead "3" blocks 122 Then the market data for the market "ETH/FEB23" should be: 123 | mark price | trading mode | auction trigger | 124 | 1000 | TRADING_MODE_MONITORING_AUCTION | AUCTION_TRIGGER_PRICE | 125 126 # the updated extension triggered, no triggers left as they've all been switched off since update took place during auction 127 And the network moves ahead "1" blocks 128 Then the market data for the market "ETH/FEB23" should be: 129 | mark price | trading mode | auction trigger | 130 | 1000 | TRADING_MODE_MONITORING_AUCTION | AUCTION_TRIGGER_PRICE | 131 132 # market leaves the auction 133 # mark price doesn't update as there weren't any trades so the reference price for price monitoring engine is still the last value it had (1000) 134 # which results in bounds that the mark price candidate (2000) is outside of 135 And the network moves ahead "1" blocks 136 Then the market data for the market "ETH/FEB23" should be: 137 | mark price | trading mode | auction trigger | last traded price | horizon | ref price | min bound | max bound | 138 | 1000 | TRADING_MODE_CONTINUOUS | AUCTION_TRIGGER_UNSPECIFIED | 1000 | 30 | 1000 | 997 | 1003 | 139 140 # update trigger here so that there's only one 141 When the markets are updated: 142 | id | price monitoring | price type | source weights | source staleness tolerance | 143 | ETH/FEB23 | my-price-monitoring-1 | weight | 0,0,1,0 | 0s,0s,0h0m120s,0s | 144 145 # first we get bounds based on default factors, once the state variable engine finishes its calculation we get the proper values 146 Then the market data for the market "ETH/FEB23" should be: 147 | mark price | trading mode | auction trigger | last traded price | horizon | ref price | min bound | max bound | 148 | 1000 | TRADING_MODE_CONTINUOUS | AUCTION_TRIGGER_UNSPECIFIED | 1000 | 60 | 1000 | 900 | 1100 | 149 150 When the network moves ahead "1" blocks 151 Then the market data for the market "ETH/FEB23" should be: 152 | mark price | trading mode | auction trigger | last traded price | horizon | ref price | min bound | max bound | 153 | 1000 | TRADING_MODE_CONTINUOUS | AUCTION_TRIGGER_UNSPECIFIED | 1000 | 60 | 1000 | 995 | 1005 | 154 155 Scenario: Mark price update, followed by trigger update (+ trade in auction, after market update) 156 157 When the oracles broadcast data with block time signed with "0xCAFECAFE1": 158 | name | value | time offset | 159 | prices.ETH.value | 2000 | -1s | 160 And the network moves ahead "2" blocks 161 Then the market data for the market "ETH/FEB23" should be: 162 | mark price | trading mode | auction trigger | horizon | ref price | min bound | max bound | auction end | 163 | 1000 | TRADING_MODE_MONITORING_AUCTION | AUCTION_TRIGGER_PRICE | 60 | 1000 | 995 | 1005 | 5 | 164 165 And the price monitoring named "my-price-monitoring-2": 166 | horizon | probability | auction extension | 167 | 30 | 0.95 | 1 | 168 169 # update trigger here so that there's only one 170 When the markets are updated: 171 | id | price monitoring | price type | source weights | source staleness tolerance | 172 | ETH/FEB23 | my-price-monitoring-2 | weight | 0,0,1,0 | 0s,0s,0h0m120s,0s | 173 174 # the last second of the original extensions 175 And the network moves ahead "3" blocks 176 Then the market data for the market "ETH/FEB23" should be: 177 | mark price | trading mode | auction trigger | 178 | 1000 | TRADING_MODE_MONITORING_AUCTION | AUCTION_TRIGGER_PRICE | 179 180 When the parties place the following orders with ticks: 181 | party | market id | side | volume | price | resulting trades | type | tif | 182 | party1 | ETH/FEB23 | buy | 1 | 2004 | 0 | TYPE_LIMIT | TIF_GTC | 183 | party2 | ETH/FEB23 | sell | 1 | 2004 | 0 | TYPE_LIMIT | TIF_GTC | 184 185 # the updated extension triggered, no triggers left as they've all been switched off since update took place during auction 186 And the network moves ahead "1" blocks 187 Then the market data for the market "ETH/FEB23" should be: 188 | mark price | trading mode | auction trigger | 189 | 1000 | TRADING_MODE_MONITORING_AUCTION | AUCTION_TRIGGER_PRICE | 190 191 # market leaves the auction 192 # All values received from oracle but not yet accepted as valid mark price get lost during the market update 193 And the network moves ahead "2" blocks 194 Then the market data for the market "ETH/FEB23" should be: 195 | mark price | trading mode | auction trigger | last traded price | horizon | ref price | min bound | max bound | 196 | 1000 | TRADING_MODE_CONTINUOUS | AUCTION_TRIGGER_UNSPECIFIED | 2004 | 30 | 2004 | 1997 | 2011 | 197 198 Scenario: Mark price update, followed by trigger update (+ oracle value gets resubmitted after the market update) 199 200 When the oracles broadcast data with block time signed with "0xCAFECAFE1": 201 | name | value | time offset | 202 | prices.ETH.value | 2000 | -1s | 203 And the network moves ahead "2" blocks 204 Then the market data for the market "ETH/FEB23" should be: 205 | mark price | trading mode | auction trigger | horizon | ref price | min bound | max bound | auction end | 206 | 1000 | TRADING_MODE_MONITORING_AUCTION | AUCTION_TRIGGER_PRICE | 60 | 1000 | 995 | 1005 | 5 | 207 208 And the price monitoring named "my-price-monitoring-2": 209 | horizon | probability | auction extension | 210 | 30 | 0.95 | 1 | 211 212 # update trigger here so that there's only one 213 When the markets are updated: 214 | id | price monitoring | price type | source weights | source staleness tolerance | 215 | ETH/FEB23 | my-price-monitoring-2 | weight | 0,0,1,0 | 0s,0s,0h0m120s,0s | 216 217 # the last second of the original extensions 218 And the network moves ahead "3" blocks 219 Then the market data for the market "ETH/FEB23" should be: 220 | mark price | trading mode | auction trigger | 221 | 1000 | TRADING_MODE_MONITORING_AUCTION | AUCTION_TRIGGER_PRICE | 222 223 When the oracles broadcast data with block time signed with "0xCAFECAFE1": 224 | name | value | time offset | 225 | prices.ETH.value | 2000 | -1s | 226 227 # the updated extension triggered, no triggers left as they've all been switched off since update took place during auction 228 And the network moves ahead "1" blocks 229 Then the market data for the market "ETH/FEB23" should be: 230 | mark price | trading mode | auction trigger | 231 | 1000 | TRADING_MODE_MONITORING_AUCTION | AUCTION_TRIGGER_PRICE | 232 233 # market leaves the auction 234 # now we get stuck in an series of auctions (with uncrossing trades in between) until the mark price becomes stale 235 When the parties place the following orders with ticks: 236 | party | market id | side | volume | price | resulting trades | type | tif | 237 | party1 | ETH/FEB23 | buy | 1 | 1002 | 0 | TYPE_LIMIT | TIF_GTC | 238 | party2 | ETH/FEB23 | sell | 1 | 1002 | 0 | TYPE_LIMIT | TIF_GTC | 239 And the network moves ahead "1" blocks 240 Then the market data for the market "ETH/FEB23" should be: 241 | mark price | trading mode | auction trigger | last traded price | 242 | 1000 | TRADING_MODE_MONITORING_AUCTION | AUCTION_TRIGGER_PRICE | 1002 | 243 244 When the parties place the following orders with ticks: 245 | party | market id | side | volume | price | resulting trades | type | tif | 246 | party1 | ETH/FEB23 | buy | 1 | 1003 | 0 | TYPE_LIMIT | TIF_GTC | 247 | party2 | ETH/FEB23 | sell | 1 | 1003 | 0 | TYPE_LIMIT | TIF_GTC | 248 And the network moves ahead "2" blocks 249 Then the market data for the market "ETH/FEB23" should be: 250 | mark price | trading mode | auction trigger | last traded price | 251 | 1000 | TRADING_MODE_MONITORING_AUCTION | AUCTION_TRIGGER_PRICE | 1003 | 252 253 And the network moves ahead "118" blocks 254 Then the market data for the market "ETH/FEB23" should be: 255 | mark price | trading mode | auction trigger | last traded price | horizon | ref price | min bound | max bound | 256 | 1000 | TRADING_MODE_CONTINUOUS | AUCTION_TRIGGER_UNSPECIFIED | 1003 | 30 | 1003 | 1000 | 1006 | 257 258 Scenario: Verify that trigger update in continuous trading works as expected 259 260 When the network moves ahead "2" blocks 261 Then the market data for the market "ETH/FEB23" should be: 262 | mark price | trading mode | horizon | ref price | min bound | max bound | 263 | 1000 | TRADING_MODE_CONTINUOUS | 60 | 1000 | 995 | 1005 | 264 265 And the price monitoring named "my-price-monitoring-2": 266 | horizon | probability | auction extension | 267 | 30 | 0.95 | 1 | 268 269 # update trigger here so that there's only one 270 When the markets are updated: 271 | id | price monitoring | price type | source weights | source staleness tolerance | 272 | ETH/FEB23 | my-price-monitoring-2 | weight | 0,0,1,0 | 0s,0s,0h0m120s,0s | 273 274 # the last second of the original extensions 275 And the network moves ahead "3" blocks 276 Then the market data for the market "ETH/FEB23" should be: 277 | mark price | trading mode | horizon | ref price | min bound | max bound | 278 | 1000 | TRADING_MODE_CONTINUOUS | 30 | 1000 | 997 | 1003 |