code.vegaprotocol.io/vega@v0.79.0/core/integration/features/orders/stoporders_spot.feature (about) 1 Feature: stop orders 2 3 Background: 4 Given the spot markets: 5 | id | name | base asset | quote asset | risk model | auction duration | fees | price monitoring | sla params | 6 | BTC/ETH | BTC/ETH | BTC | ETH | default-simple-risk-model-3 | 1 | default-none | default-none | default-futures | 7 | USDT/ETH | USDT/ETH | USDT | ETH | default-log-normal-risk-model | 1 | default-none | default-basic | default-futures | 8 9 And the following network parameters are set: 10 | name | value | 11 | market.auction.minimumDuration | 1 | 12 | network.markPriceUpdateMaximumFrequency | 0s | 13 | limits.markets.maxPeggedOrders | 1500 | 14 | spam.protection.max.stopOrdersPerMarket | 5 | 15 16 @NoPerp 17 Scenario: If the order is triggered before reaching time T, the order will have been removed and will not trigger at time T. (0014-ORDT-175) (0014-ORDT-124) 18 Given time is updated to "2019-11-30T00:00:00Z" 19 Given the parties deposit on asset's general account the following amount: 20 | party | asset | amount | 21 | party1 | BTC | 1000000 | 22 | party2 | BTC | 1000000 | 23 | party3 | BTC | 1000000 | 24 | aux | BTC | 1000000 | 25 | aux2 | BTC | 1000000 | 26 | aux3 | BTC | 1000000 | 27 | lpprov | BTC | 90000000 | 28 | party1 | ETH | 1000000 | 29 | party2 | ETH | 1000000 | 30 | party3 | ETH | 1000000 | 31 | aux | ETH | 1000000 | 32 | aux2 | ETH | 1000000 | 33 | aux3 | ETH | 1000000 | 34 | lpprov | ETH | 90000000 | 35 36 When the parties submit the following liquidity provision: 37 | id | party | market id | commitment amount | fee | lp type | 38 | lp1 | lpprov | BTC/ETH | 900000 | 0.1 | submission | 39 | lp1 | lpprov | BTC/ETH | 900000 | 0.1 | submission | 40 And the parties place the following pegged iceberg orders: 41 | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | 42 | lpprov | BTC/ETH | 2 | 1 | buy | BID | 50 | 100 | 43 | lpprov | BTC/ETH | 2 | 1 | sell | ASK | 50 | 100 | 44 45 When the parties place the following orders: 46 | party | market id | side | volume | price | resulting trades | type | tif | 47 | aux | BTC/ETH | buy | 1 | 1 | 0 | TYPE_LIMIT | TIF_GTC | 48 | aux | BTC/ETH | sell | 1 | 10001 | 0 | TYPE_LIMIT | TIF_GTC | 49 | aux2 | BTC/ETH | buy | 5 | 50 | 0 | TYPE_LIMIT | TIF_GTC | 50 | aux3 | BTC/ETH | sell | 5 | 50 | 0 | TYPE_LIMIT | TIF_GTC | 51 52 Then the opening auction period ends for market "BTC/ETH" 53 And the trading mode should be "TRADING_MODE_CONTINUOUS" for the market "BTC/ETH" 54 55 Given time is updated to "2019-11-30T00:00:10Z" 56 And the parties place the following orders: 57 | party | market id | side | volume | price | resulting trades | type | tif | 58 | party1 | BTC/ETH | buy | 20 | 50 | 0 | TYPE_LIMIT | TIF_GTC | 59 | party2 | BTC/ETH | sell | 20 | 50 | 1 | TYPE_LIMIT | TIF_GTC | 60 # volume for the stop trade 61 And the parties place the following orders: 62 | party | market id | side | volume | price | resulting trades | type | tif | 63 | party3 | BTC/ETH | buy | 20 | 20 | 0 | TYPE_LIMIT | TIF_GTC | 64 # create party1 stop order, no trade resulting, expires in 10 secs 65 And the parties place the following orders: 66 | party | market id | side | volume | price | resulting trades | type | tif | only | fb price trigger | error | reference | fb expires in | fb expiry strategy | 67 | party1 | BTC/ETH | sell | 10 | 0 | 0 | TYPE_MARKET | TIF_IOC | reduce | 25 | | stop1 | 10 | EXPIRY_STRATEGY_SUBMIT | 68 # trigger the stop order 69 When the parties place the following orders: 70 | party | market id | side | volume | price | resulting trades | type | tif | 71 | party2 | BTC/ETH | buy | 1 | 24 | 0 | TYPE_LIMIT | TIF_GTC | 72 | party3 | BTC/ETH | sell | 1 | 24 | 1 | TYPE_LIMIT | TIF_GTC | 73 # check the stop order is filled 74 Then the stop orders should have the following states 75 | party | market id | status | reference | 76 | party1 | BTC/ETH | STATUS_TRIGGERED | stop1 | 77 78 # add 20 secs, should expire 79 Given time is updated to "2019-11-30T00:00:30Z" 80 # check the stop order was not triggered a second at time T 81 # bought 20, sold 10 with the stop order 82 Then "party1" should have general account balance of "1000010" for asset "BTC" 83 84 Scenario: Attempting to create more stop orders than is allowed by the relevant network parameter will result in the transaction failing to execute. (0014-ORDT-126) 85 Given the parties deposit on asset's general account the following amount: 86 | party | asset | amount | 87 | party1 | BTC | 10000 | 88 | party2 | BTC | 10000 | 89 | aux | BTC | 100000 | 90 | aux2 | BTC | 100000 | 91 | lpprov | BTC | 90000000 | 92 | party1 | ETH | 10000 | 93 | party2 | ETH | 10000 | 94 | aux | ETH | 100000 | 95 | aux2 | ETH | 100000 | 96 | lpprov | ETH | 90000000 | 97 98 When the parties submit the following liquidity provision: 99 | id | party | market id | commitment amount | fee | lp type | 100 | lp1 | lpprov | BTC/ETH | 90000000 | 0.1 | submission | 101 | lp1 | lpprov | BTC/ETH | 90000000 | 0.1 | submission | 102 And the parties place the following pegged iceberg orders: 103 | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | 104 | lpprov | BTC/ETH | 2 | 1 | buy | BID | 50 | 100 | 105 | lpprov | BTC/ETH | 2 | 1 | sell | ASK | 50 | 100 | 106 107 When the parties place the following orders: 108 | party | market id | side | volume | price | resulting trades | type | tif | 109 | aux | BTC/ETH | buy | 1 | 1 | 0 | TYPE_LIMIT | TIF_GTC | 110 | aux | BTC/ETH | sell | 1 | 10001 | 0 | TYPE_LIMIT | TIF_GTC | 111 | aux2 | BTC/ETH | buy | 1 | 50 | 0 | TYPE_LIMIT | TIF_GTC | 112 | aux | BTC/ETH | sell | 1 | 50 | 0 | TYPE_LIMIT | TIF_GTC | 113 114 Then the opening auction period ends for market "BTC/ETH" 115 And the trading mode should be "TRADING_MODE_CONTINUOUS" for the market "BTC/ETH" 116 117 When the parties place the following orders: 118 | party | market id | side | volume | price | resulting trades | type | tif | only | fb price trigger | error | 119 | party1 | BTC/ETH | sell | 10 | 60 | 0 | TYPE_LIMIT | TIF_GTC | | | | 120 | party1 | BTC/ETH | buy | 10 | 0 | 0 | TYPE_MARKET | TIF_GTC | reduce | 47 | | 121 | party1 | BTC/ETH | buy | 10 | 0 | 0 | TYPE_MARKET | TIF_GTC | reduce | 47 | | 122 | party1 | BTC/ETH | buy | 10 | 0 | 0 | TYPE_MARKET | TIF_GTC | reduce | 47 | | 123 | party1 | BTC/ETH | buy | 10 | 0 | 0 | TYPE_MARKET | TIF_GTC | reduce | 47 | | 124 | party1 | BTC/ETH | buy | 10 | 0 | 0 | TYPE_MARKET | TIF_GTC | reduce | 47 | | 125 # this next one goes over the top 126 | party1 | BTC/ETH | buy | 10 | 0 | 0 | TYPE_MARKET | TIF_GTC | reduce | 47 | max stop orders per party reached | 127 128 Scenario: An OCO stop order with expiration time T with one side set to execute at that time will execute at time T (0014-ORDT-165) 129 Given time is updated to "2019-11-30T00:00:00Z" 130 Given the parties deposit on asset's general account the following amount: 131 | party | asset | amount | 132 | party1 | BTC | 10000000 | 133 | party2 | BTC | 10000000 | 134 | party3 | BTC | 10000000 | 135 | aux | BTC | 10000000 | 136 | aux2 | BTC | 10000000 | 137 | aux3 | BTC | 100000 | 138 | lpprov | BTC | 90000000 | 139 | party1 | ETH | 10000000 | 140 | party2 | ETH | 10000000 | 141 | party3 | ETH | 10000000 | 142 | aux | ETH | 10000000 | 143 | aux2 | ETH | 10000000 | 144 | aux3 | ETH | 100000 | 145 | lpprov | ETH | 90000000 | 146 147 When the parties submit the following liquidity provision: 148 | id | party | market id | commitment amount | fee | lp type | 149 | lp1 | lpprov | BTC/ETH | 90000000 | 0.1 | submission | 150 | lp1 | lpprov | BTC/ETH | 90000000 | 0.1 | submission | 151 And the parties place the following pegged iceberg orders: 152 | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | 153 | lpprov | BTC/ETH | 2 | 1 | buy | BID | 50 | 100 | 154 | lpprov | BTC/ETH | 2 | 1 | sell | ASK | 50 | 100 | 155 When the parties place the following orders: 156 | party | market id | side | volume | price | resulting trades | type | tif | 157 | aux | BTC/ETH | buy | 100 | 1 | 0 | TYPE_LIMIT | TIF_GTC | 158 | aux | BTC/ETH | sell | 100 | 10001 | 0 | TYPE_LIMIT | TIF_GTC | 159 | aux2 | BTC/ETH | buy | 5 | 50 | 0 | TYPE_LIMIT | TIF_GTC | 160 | aux3 | BTC/ETH | sell | 5 | 50 | 0 | TYPE_LIMIT | TIF_GTC | 161 162 Then the opening auction period ends for market "BTC/ETH" 163 And the trading mode should be "TRADING_MODE_CONTINUOUS" for the market "BTC/ETH" 164 165 When the parties place the following orders: 166 | party | market id | side | volume | price | resulting trades | type | tif | 167 | party1 | BTC/ETH | sell | 10 | 50 | 0 | TYPE_LIMIT | TIF_GTC | 168 | party2 | BTC/ETH | buy | 10 | 50 | 1 | TYPE_LIMIT | TIF_GTC | 169 170 When the parties place the following orders: 171 | party | market id | side | volume | price | resulting trades | type | tif | 172 | party3 | BTC/ETH | sell | 10 | 50 | 0 | TYPE_LIMIT | TIF_GTC | 173 | party3 | BTC/ETH | buy | 10 | 51 | 0 | TYPE_LIMIT | TIF_GTC | 174 175 When time is updated to "2019-11-30T00:00:10Z" 176 When the parties place the following orders: 177 | party | market id | side | volume | price | resulting trades | type | tif | only | ra price trigger | fb price trigger | reference | ra expires in | ra expiry strategy | fb expires in | fb expiry strategy | 178 | party1 | BTC/ETH | buy | 10 | 0 | 0 | TYPE_MARKET | TIF_IOC | reduce | 75 | 25 | stop | 10 | EXPIRY_STRATEGY_SUBMIT | 15 | EXPIRY_STRATEGY_SUBMIT | 179 180 Then the stop orders should have the following states 181 | party | market id | status | reference | 182 | party1 | BTC/ETH | STATUS_PENDING | stop-1 | 183 | party1 | BTC/ETH | STATUS_PENDING | stop-2 | 184 185 Then clear all events 186 When time is updated to "2019-11-30T00:00:20Z" 187 188 Then the stop orders should have the following states 189 | party | market id | status | reference | 190 | party1 | BTC/ETH | STATUS_STOPPED | stop-1 | 191 | party1 | BTC/ETH | STATUS_EXPIRED | stop-2 | 192 193 # Now perform the same test but from the other side 194 When the parties place the following orders: 195 | party | market id | side | volume | price | resulting trades | type | tif | only | ra price trigger | fb price trigger | reference | ra expires in | ra expiry strategy | fb expires in | fb expiry strategy | 196 | party2 | BTC/ETH | sell | 10 | 0 | 0 | TYPE_MARKET | TIF_IOC | reduce | 75 | 25 | stop2 | 15 | EXPIRY_STRATEGY_SUBMIT | 10 | EXPIRY_STRATEGY_SUBMIT | 197 198 Then the stop orders should have the following states 199 | party | market id | status | reference | 200 | party2 | BTC/ETH | STATUS_PENDING | stop2-1 | 201 | party2 | BTC/ETH | STATUS_PENDING | stop2-2 | 202 203 Then clear all events 204 When time is updated to "2019-11-30T00:00:30Z" 205 206 Then the stop orders should have the following states 207 | party | market id | status | reference | 208 | party2 | BTC/ETH | STATUS_STOPPED | stop2-2 | 209 | party2 | BTC/ETH | STATUS_EXPIRED | stop2-1 | 210 211 Scenario: If a pair of stop orders are specified as OCO, one being triggered also removes the other from the book. (0014-ORDT-166) 212 Given the parties deposit on asset's general account the following amount: 213 | party | asset | amount | 214 | party1 | BTC | 10000 | 215 | party2 | BTC | 10000 | 216 | party3 | BTC | 10000 | 217 | aux | BTC | 100000 | 218 | aux2 | BTC | 100000 | 219 | lpprov | BTC | 90000000 | 220 | party1 | ETH | 10000 | 221 | party2 | ETH | 10000 | 222 | party3 | ETH | 10000 | 223 | aux | ETH | 100000 | 224 | aux2 | ETH | 100000 | 225 | lpprov | ETH | 90000000 | 226 227 When the parties submit the following liquidity provision: 228 | id | party | market id | commitment amount | fee | lp type | 229 | lp1 | lpprov | BTC/ETH | 90000000 | 0.1 | submission | 230 | lp1 | lpprov | BTC/ETH | 90000000 | 0.1 | submission | 231 And the parties place the following pegged iceberg orders: 232 | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | 233 | lpprov | BTC/ETH | 2 | 1 | buy | BID | 50 | 100 | 234 | lpprov | BTC/ETH | 2 | 1 | sell | ASK | 50 | 100 | 235 When the parties place the following orders: 236 | party | market id | side | volume | price | resulting trades | type | tif | 237 | aux | BTC/ETH | buy | 1 | 1 | 0 | TYPE_LIMIT | TIF_GTC | 238 | aux | BTC/ETH | sell | 1 | 10001 | 0 | TYPE_LIMIT | TIF_GTC | 239 | aux2 | BTC/ETH | buy | 5 | 50 | 0 | TYPE_LIMIT | TIF_GTC | 240 | aux | BTC/ETH | sell | 5 | 50 | 0 | TYPE_LIMIT | TIF_GTC | 241 242 Then the opening auction period ends for market "BTC/ETH" 243 And the trading mode should be "TRADING_MODE_CONTINUOUS" for the market "BTC/ETH" 244 245 When the parties place the following orders: 246 | party | market id | side | volume | price | resulting trades | type | tif | 247 | party1 | BTC/ETH | buy | 10 | 50 | 0 | TYPE_LIMIT | TIF_GTC | 248 | party2 | BTC/ETH | sell | 10 | 50 | 1 | TYPE_LIMIT | TIF_GTC | 249 250 # create party1 stop order, results in a trade 251 When the parties place the following orders: 252 | party | market id | side | volume | price | resulting trades | type | tif | only | fb price trigger | ra price trigger | error | reference | 253 | party1 | BTC/ETH | sell | 10 | 0 | 0 | TYPE_MARKET | TIF_IOC | reduce | 25 | 75 | | stop1 | 254 255 # volume for the stop trade 256 When the parties place the following orders: 257 | party | market id | side | volume | price | resulting trades | type | tif | 258 | party3 | BTC/ETH | buy | 10 | 20 | 0 | TYPE_LIMIT | TIF_GTC | 259 260 # now we trade at 75, this will breach the trigger 261 When the parties place the following orders: 262 | party | market id | side | volume | price | resulting trades | type | tif | 263 | party3 | BTC/ETH | sell | 10 | 25 | 0 | TYPE_LIMIT | TIF_GTC | 264 | party2 | BTC/ETH | buy | 10 | 25 | 1 | TYPE_LIMIT | TIF_GTC | 265 266 # check that the order got submitted 267 Then the orders should have the following states: 268 | party | market id | side | volume | remaining | price | status | reference | 269 | party1 | BTC/ETH | sell | 10 | 0 | 0 | STATUS_FILLED | stop1-1 | 270 271 Then the stop orders should have the following states 272 | party | market id | status | reference | 273 | party1 | BTC/ETH | STATUS_TRIGGERED | stop1-1 | 274 | party1 | BTC/ETH | STATUS_STOPPED | stop1-2 | 275 276 Scenario: A stop order wrapping a limit order will, once triggered, place the limit order as if it just arrived as an order without the stop order wrapping. (0014-ORDT-167) 277 Given the parties deposit on asset's general account the following amount: 278 | party | asset | amount | 279 | party1 | BTC | 1000000 | 280 | party2 | BTC | 1000000 | 281 | party3 | BTC | 1000000 | 282 | aux | BTC | 1000000 | 283 | aux2 | BTC | 1000000 | 284 | lpprov | BTC | 90000000 | 285 | party1 | ETH | 1000000 | 286 | party2 | ETH | 1000000 | 287 | party3 | ETH | 1000000 | 288 | aux | ETH | 1000000 | 289 | aux2 | ETH | 1000000 | 290 | lpprov | ETH | 90000000 | 291 292 When the parties submit the following liquidity provision: 293 | id | party | market id | commitment amount | fee | lp type | 294 | lp1 | lpprov | BTC/ETH | 900000 | 0.1 | submission | 295 | lp1 | lpprov | BTC/ETH | 900000 | 0.1 | submission | 296 And the parties place the following pegged iceberg orders: 297 | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | 298 | lpprov | BTC/ETH | 2 | 1 | buy | BID | 50 | 100 | 299 | lpprov | BTC/ETH | 2 | 1 | sell | ASK | 50 | 100 | 300 When the parties place the following orders: 301 | party | market id | side | volume | price | resulting trades | type | tif | 302 | aux | BTC/ETH | buy | 1 | 1 | 0 | TYPE_LIMIT | TIF_GTC | 303 | aux | BTC/ETH | sell | 1 | 10001 | 0 | TYPE_LIMIT | TIF_GTC | 304 | aux2 | BTC/ETH | buy | 1 | 50 | 0 | TYPE_LIMIT | TIF_GTC | 305 | aux | BTC/ETH | sell | 1 | 50 | 0 | TYPE_LIMIT | TIF_GTC | 306 307 Then the opening auction period ends for market "BTC/ETH" 308 And the trading mode should be "TRADING_MODE_CONTINUOUS" for the market "BTC/ETH" 309 310 # setup party1 position, open a 10 short position 311 Given the parties place the following orders: 312 | party | market id | side | volume | price | resulting trades | type | tif | 313 | party1 | BTC/ETH | sell | 10 | 50 | 0 | TYPE_LIMIT | TIF_GTC | 314 | party2 | BTC/ETH | buy | 10 | 50 | 1 | TYPE_LIMIT | TIF_GTC | 315 # place an order to match with the limit order then check the stop is filled 316 And the parties place the following orders: 317 | party | market id | side | volume | price | resulting trades | type | tif | 318 | party3 | BTC/ETH | sell | 10 | 80 | 0 | TYPE_LIMIT | TIF_GTC | 319 # create party1 stop order 320 And the parties place the following orders: 321 | party | market id | side | volume | price | resulting trades | type | tif | only | ra price trigger | error | reference | 322 | party1 | BTC/ETH | buy | 5 | 80 | 0 | TYPE_LIMIT | TIF_IOC | reduce | 75 | | stop1 | 323 324 # now we trade at 75, this will breach the trigger 325 When the parties place the following orders: 326 | party | market id | side | volume | price | resulting trades | type | tif | 327 | party3 | BTC/ETH | buy | 10 | 75 | 0 | TYPE_LIMIT | TIF_GTC | 328 | party2 | BTC/ETH | sell | 10 | 75 | 1 | TYPE_LIMIT | TIF_GTC | 329 330 # check that the order was triggered 331 Then the stop orders should have the following states 332 | party | market id | status | reference | 333 | party1 | BTC/ETH | STATUS_TRIGGERED | stop1 | 334 And the orders should have the following states: 335 | party | market id | side | volume | remaining | price | status | reference | 336 | party1 | BTC/ETH | buy | 5 | 0 | 80 | STATUS_FILLED | stop1 | 337 338 Scenario: With a last traded price at 50, a stop order placed with Rises Above setting at 75 will be triggered by any trade at price 75 or higher. (0014-ORDT-168) (0014-ORDT-169) 339 Given the parties deposit on asset's general account the following amount: 340 | party | asset | amount | 341 | party1 | BTC | 10000 | 342 | party2 | BTC | 10000 | 343 | party3 | BTC | 10000 | 344 | aux | BTC | 100000 | 345 | aux2 | BTC | 100000 | 346 | lpprov | BTC | 90000000 | 347 | party1 | ETH | 10000 | 348 | party2 | ETH | 10000 | 349 | party3 | ETH | 10000 | 350 | aux | ETH | 100000 | 351 | aux2 | ETH | 100000 | 352 | lpprov | ETH | 90000000 | 353 354 When the parties submit the following liquidity provision: 355 | id | party | market id | commitment amount | fee | lp type | 356 | lp1 | lpprov | BTC/ETH | 90000000 | 0.1 | submission | 357 | lp1 | lpprov | BTC/ETH | 90000000 | 0.1 | submission | 358 And the parties place the following pegged iceberg orders: 359 | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | 360 | lpprov | BTC/ETH | 2 | 1 | buy | BID | 50 | 100 | 361 | lpprov | BTC/ETH | 2 | 1 | sell | ASK | 50 | 100 | 362 When the parties place the following orders: 363 | party | market id | side | volume | price | resulting trades | type | tif | 364 | aux | BTC/ETH | buy | 1 | 1 | 0 | TYPE_LIMIT | TIF_GTC | 365 | aux | BTC/ETH | sell | 1 | 10001 | 0 | TYPE_LIMIT | TIF_GTC | 366 | aux2 | BTC/ETH | buy | 5 | 50 | 0 | TYPE_LIMIT | TIF_GTC | 367 | aux | BTC/ETH | sell | 5 | 50 | 0 | TYPE_LIMIT | TIF_GTC | 368 369 Then the opening auction period ends for market "BTC/ETH" 370 And the trading mode should be "TRADING_MODE_CONTINUOUS" for the market "BTC/ETH" 371 372 # setup party1 position, open a 10 short position 373 When the parties place the following orders: 374 | party | market id | side | volume | price | resulting trades | type | tif | 375 | party1 | BTC/ETH | sell | 10 | 50 | 0 | TYPE_LIMIT | TIF_GTC | 376 | party2 | BTC/ETH | buy | 10 | 50 | 1 | TYPE_LIMIT | TIF_GTC | 377 378 # create party1 stop order 379 When the parties place the following orders: 380 | party | market id | side | volume | price | resulting trades | type | tif | only | ra price trigger | error | reference | 381 | party1 | BTC/ETH | buy | 10 | 0 | 0 | TYPE_MARKET | TIF_IOC | reduce | 75 | | stop1 | 382 383 # volume for the stop trade 384 When the parties place the following orders: 385 | party | market id | side | volume | price | resulting trades | type | tif | 386 | party3 | BTC/ETH | sell | 20 | 80 | 0 | TYPE_LIMIT | TIF_GTC | 387 388 389 # now we trade at 75, this will breach the trigger 390 When the parties place the following orders: 391 | party | market id | side | volume | price | resulting trades | type | tif | 392 | party3 | BTC/ETH | buy | 10 | 75 | 0 | TYPE_LIMIT | TIF_GTC | 393 | party2 | BTC/ETH | sell | 10 | 75 | 1 | TYPE_LIMIT | TIF_GTC | 394 395 # check that the order got submitted 396 Then the orders should have the following states: 397 | party | market id | side | volume | remaining | price | status | reference | 398 | party1 | BTC/ETH | buy | 10 | 0 | 0 | STATUS_FILLED | stop1 | 399 400 Scenario: With a last traded price at 50, a stop order placed with Rises Above setting at 25 will be triggered immediately (before another trade is even necessary). (0014-ORDT-170) 401 Given the parties deposit on asset's general account the following amount: 402 | party | asset | amount | 403 | party1 | BTC | 10000 | 404 | party2 | BTC | 10000 | 405 | party3 | BTC | 10000 | 406 | aux | BTC | 100000 | 407 | aux2 | BTC | 100000 | 408 | lpprov | BTC | 90000000 | 409 | party1 | ETH | 10000 | 410 | party2 | ETH | 10000 | 411 | party3 | ETH | 10000 | 412 | aux | ETH | 100000 | 413 | aux2 | ETH | 100000 | 414 | lpprov | ETH | 90000000 | 415 416 When the parties submit the following liquidity provision: 417 | id | party | market id | commitment amount | fee | lp type | 418 | lp1 | lpprov | BTC/ETH | 90000000 | 0.1 | submission | 419 | lp1 | lpprov | BTC/ETH | 90000000 | 0.1 | submission | 420 And the parties place the following pegged iceberg orders: 421 | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | 422 | lpprov | BTC/ETH | 2 | 1 | buy | BID | 50 | 100 | 423 | lpprov | BTC/ETH | 2 | 1 | sell | ASK | 50 | 100 | 424 When the parties place the following orders: 425 | party | market id | side | volume | price | resulting trades | type | tif | 426 | aux | BTC/ETH | buy | 1 | 1 | 0 | TYPE_LIMIT | TIF_GTC | 427 | aux | BTC/ETH | sell | 1 | 10001 | 0 | TYPE_LIMIT | TIF_GTC | 428 | aux2 | BTC/ETH | buy | 5 | 50 | 0 | TYPE_LIMIT | TIF_GTC | 429 | aux | BTC/ETH | sell | 5 | 50 | 0 | TYPE_LIMIT | TIF_GTC | 430 431 Then the opening auction period ends for market "BTC/ETH" 432 And the trading mode should be "TRADING_MODE_CONTINUOUS" for the market "BTC/ETH" 433 434 # setup party1 position, open a 10 long position 435 When the parties place the following orders: 436 | party | market id | side | volume | price | resulting trades | type | tif | 437 | party1 | BTC/ETH | buy | 10 | 50 | 0 | TYPE_LIMIT | TIF_GTC | 438 | party2 | BTC/ETH | sell | 10 | 50 | 1 | TYPE_LIMIT | TIF_GTC | 439 440 # volume for the stop trade 441 When the parties place the following orders: 442 | party | market id | side | volume | price | resulting trades | type | tif | 443 | party3 | BTC/ETH | buy | 10 | 50 | 0 | TYPE_LIMIT | TIF_GTC | 444 445 446 # create party1 stop order, results in a trade 447 When the parties place the following orders: 448 | party | market id | side | volume | price | resulting trades | type | tif | only | ra price trigger | error | reference | 449 | party1 | BTC/ETH | sell | 10 | 0 | 1 | TYPE_MARKET | TIF_IOC | reduce | 25 | | stop1 | 450 451 452 # check that the order got submitted 453 Then the orders should have the following states: 454 | party | market id | side | volume | remaining | price | status | reference | 455 | party1 | BTC/ETH | sell | 10 | 0 | 0 | STATUS_FILLED | stop1 | 456 457 Scenario: With a last traded price at 50, a stop order placed with Falls Below setting at 25 will be triggered by any trade at price 25 or lower. (0014-ORDT-171) 458 Given the parties deposit on asset's general account the following amount: 459 | party | asset | amount | 460 | party1 | BTC | 10000 | 461 | party2 | BTC | 10000 | 462 | party3 | BTC | 10000 | 463 | aux | BTC | 100000 | 464 | aux2 | BTC | 100000 | 465 | lpprov | BTC | 90000000 | 466 | party1 | ETH | 10000 | 467 | party2 | ETH | 10000 | 468 | party3 | ETH | 10000 | 469 | aux | ETH | 100000 | 470 | aux2 | ETH | 100000 | 471 | lpprov | ETH | 90000000 | 472 473 When the parties submit the following liquidity provision: 474 | id | party | market id | commitment amount | fee | lp type | 475 | lp1 | lpprov | BTC/ETH | 90000000 | 0.1 | submission | 476 | lp1 | lpprov | BTC/ETH | 90000000 | 0.1 | submission | 477 And the parties place the following pegged iceberg orders: 478 | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | 479 | lpprov | BTC/ETH | 2 | 1 | buy | BID | 50 | 100 | 480 | lpprov | BTC/ETH | 2 | 1 | sell | ASK | 50 | 100 | 481 When the parties place the following orders: 482 | party | market id | side | volume | price | resulting trades | type | tif | 483 | aux | BTC/ETH | buy | 1 | 1 | 0 | TYPE_LIMIT | TIF_GTC | 484 | aux | BTC/ETH | sell | 1 | 10001 | 0 | TYPE_LIMIT | TIF_GTC | 485 | aux2 | BTC/ETH | buy | 5 | 50 | 0 | TYPE_LIMIT | TIF_GTC | 486 | aux | BTC/ETH | sell | 5 | 50 | 0 | TYPE_LIMIT | TIF_GTC | 487 488 Then the opening auction period ends for market "BTC/ETH" 489 And the trading mode should be "TRADING_MODE_CONTINUOUS" for the market "BTC/ETH" 490 491 # setup party1 position, open a 10 short position 492 When the parties place the following orders: 493 | party | market id | side | volume | price | resulting trades | type | tif | 494 | party1 | BTC/ETH | buy | 10 | 50 | 0 | TYPE_LIMIT | TIF_GTC | 495 | party2 | BTC/ETH | sell | 10 | 50 | 1 | TYPE_LIMIT | TIF_GTC | 496 497 # create party1 stop order, results in a trade 498 When the parties place the following orders: 499 | party | market id | side | volume | price | resulting trades | type | tif | only | fb price trigger | error | reference | 500 | party1 | BTC/ETH | sell | 10 | 0 | 0 | TYPE_MARKET | TIF_IOC | reduce | 25 | | stop1 | 501 502 # volume for the stop trade 503 When the parties place the following orders: 504 | party | market id | side | volume | price | resulting trades | type | tif | 505 | party3 | BTC/ETH | buy | 10 | 20 | 0 | TYPE_LIMIT | TIF_GTC | 506 507 # now we trade at 75, this will breach the trigger 508 When the parties place the following orders: 509 | party | market id | side | volume | price | resulting trades | type | tif | 510 | party3 | BTC/ETH | sell | 10 | 25 | 0 | TYPE_LIMIT | TIF_GTC | 511 | party2 | BTC/ETH | buy | 10 | 25 | 1 | TYPE_LIMIT | TIF_GTC | 512 513 # check that the order got submitted 514 Then the orders should have the following states: 515 | party | market id | side | volume | remaining | price | status | reference | 516 | party1 | BTC/ETH | sell | 10 | 0 | 0 | STATUS_FILLED | stop1 | 517 518 Scenario: With a last traded price at 50, a stop order placed with Falls Below setting at 75 will be triggered immediately (before another trade is even necessary). (0014-ORDT-172) 519 Given the parties deposit on asset's general account the following amount: 520 | party | asset | amount | 521 | party1 | BTC | 10000 | 522 | party2 | BTC | 10000 | 523 | party3 | BTC | 10000 | 524 | aux | BTC | 100000 | 525 | aux2 | BTC | 100000 | 526 | lpprov | BTC | 90000000 | 527 | party1 | ETH | 10000 | 528 | party2 | ETH | 10000 | 529 | party3 | ETH | 10000 | 530 | aux | ETH | 100000 | 531 | aux2 | ETH | 100000 | 532 | lpprov | ETH | 90000000 | 533 534 When the parties submit the following liquidity provision: 535 | id | party | market id | commitment amount | fee | lp type | 536 | lp1 | lpprov | BTC/ETH | 90000000 | 0.1 | submission | 537 | lp1 | lpprov | BTC/ETH | 90000000 | 0.1 | submission | 538 And the parties place the following pegged iceberg orders: 539 | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | 540 | lpprov | BTC/ETH | 2 | 1 | buy | BID | 50 | 100 | 541 | lpprov | BTC/ETH | 2 | 1 | sell | ASK | 50 | 100 | 542 543 When the parties place the following orders: 544 | party | market id | side | volume | price | resulting trades | type | tif | 545 | aux | BTC/ETH | buy | 5 | 1 | 0 | TYPE_LIMIT | TIF_GTC | 546 | aux | BTC/ETH | sell | 5 | 10001 | 0 | TYPE_LIMIT | TIF_GTC | 547 | aux2 | BTC/ETH | buy | 5 | 50 | 0 | TYPE_LIMIT | TIF_GTC | 548 | aux | BTC/ETH | sell | 5 | 50 | 0 | TYPE_LIMIT | TIF_GTC | 549 550 Then the opening auction period ends for market "BTC/ETH" 551 And the trading mode should be "TRADING_MODE_CONTINUOUS" for the market "BTC/ETH" 552 553 # setup party1 position, open a 10 long position 554 When the parties place the following orders: 555 | party | market id | side | volume | price | resulting trades | type | tif | 556 | party1 | BTC/ETH | sell | 10 | 50 | 0 | TYPE_LIMIT | TIF_GTC | 557 | party2 | BTC/ETH | buy | 10 | 50 | 1 | TYPE_LIMIT | TIF_GTC | 558 559 # volume for the stop trade 560 When the parties place the following orders: 561 | party | market id | side | volume | price | resulting trades | type | tif | 562 | party3 | BTC/ETH | sell | 10 | 50 | 0 | TYPE_LIMIT | TIF_GTC | 563 564 565 # create party1 stop order, results in a trade 566 When the parties place the following orders: 567 | party | market id | side | volume | price | resulting trades | type | tif | only | fb price trigger | error | reference | 568 | party1 | BTC/ETH | buy | 10 | 0 | 1 | TYPE_MARKET | TIF_IOC | reduce | 75 | | stop1 | 569 570 571 # check that the order got submitted 572 Then the orders should have the following states: 573 | party | market id | side | volume | remaining | price | status | reference | 574 | party1 | BTC/ETH | buy | 10 | 0 | 0 | STATUS_FILLED | stop1 | 575 576 Scenario: A stop order with expiration time T set to expire at that time will expire at time T if reached without being triggered. (0014-ORDT-173) 577 Given time is updated to "2019-11-30T00:00:00Z" 578 Given the parties deposit on asset's general account the following amount: 579 | party | asset | amount | 580 | party1 | BTC | 10000 | 581 | party2 | BTC | 10000 | 582 | party3 | BTC | 10000 | 583 | aux | BTC | 100000 | 584 | aux2 | BTC | 100000 | 585 | lpprov | BTC | 90000000 | 586 | party1 | ETH | 10000 | 587 | party2 | ETH | 10000 | 588 | party3 | ETH | 10000 | 589 | aux | ETH | 100000 | 590 | aux2 | ETH | 100000 | 591 | lpprov | ETH | 90000000 | 592 593 When the parties submit the following liquidity provision: 594 | id | party | market id | commitment amount | fee | lp type | 595 | lp1 | lpprov | BTC/ETH | 90000000 | 0.1 | submission | 596 | lp1 | lpprov | BTC/ETH | 90000000 | 0.1 | submission | 597 And the parties place the following pegged iceberg orders: 598 | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | 599 | lpprov | BTC/ETH | 2 | 1 | buy | BID | 50 | 100 | 600 | lpprov | BTC/ETH | 2 | 1 | sell | ASK | 50 | 100 | 601 602 When the parties place the following orders: 603 | party | market id | side | volume | price | resulting trades | type | tif | 604 | aux | BTC/ETH | buy | 1 | 1 | 0 | TYPE_LIMIT | TIF_GTC | 605 | aux | BTC/ETH | sell | 1 | 10001 | 0 | TYPE_LIMIT | TIF_GTC | 606 | aux2 | BTC/ETH | buy | 5 | 50 | 0 | TYPE_LIMIT | TIF_GTC | 607 | aux | BTC/ETH | sell | 5 | 50 | 0 | TYPE_LIMIT | TIF_GTC | 608 609 Then the opening auction period ends for market "BTC/ETH" 610 And the trading mode should be "TRADING_MODE_CONTINUOUS" for the market "BTC/ETH" 611 612 # setup party1 position, open a 10 long position 613 When the parties place the following orders: 614 | party | market id | side | volume | price | resulting trades | type | tif | 615 | party1 | BTC/ETH | sell | 10 | 50 | 0 | TYPE_LIMIT | TIF_GTC | 616 | party2 | BTC/ETH | buy | 10 | 50 | 1 | TYPE_LIMIT | TIF_GTC | 617 618 # volume for the stop trade 619 When the parties place the following orders: 620 | party | market id | side | volume | price | resulting trades | type | tif | 621 | party3 | BTC/ETH | sell | 10 | 50 | 0 | TYPE_LIMIT | TIF_GTC | 622 623 When time is updated to "2019-11-30T00:00:10Z" 624 # create party1 stop order, no trade resulting, expires in 10 secs 625 When the parties place the following orders: 626 | party | market id | side | volume | price | resulting trades | type | tif | only | ra price trigger | error | reference | ra expires in | ra expiry strategy | 627 | party1 | BTC/ETH | buy | 10 | 0 | 0 | TYPE_MARKET | TIF_IOC | reduce | 75 | | stop1 | 10 | EXPIRY_STRATEGY_CANCELS | 628 629 # add 20 secs, should expire 630 When time is updated to "2019-11-30T00:00:30Z" 631 632 Then the stop orders should have the following states 633 | party | market id | status | reference | 634 | party1 | BTC/ETH | STATUS_EXPIRED | stop1 | 635 636 Scenario: A stop order with expiration time T set to execute at that time will execute at time T if reached without being triggered. (0014-ORDT-174) 637 Given time is updated to "2019-11-30T00:00:00Z" 638 Given the parties deposit on asset's general account the following amount: 639 | party | asset | amount | 640 | party1 | BTC | 10000 | 641 | party2 | BTC | 10000 | 642 | party3 | BTC | 10000 | 643 | aux | BTC | 100000 | 644 | aux2 | BTC | 100000 | 645 | aux3 | BTC | 100000 | 646 | lpprov | BTC | 90000000 | 647 | party1 | ETH | 10000 | 648 | party2 | ETH | 10000 | 649 | party3 | ETH | 10000 | 650 | aux | ETH | 100000 | 651 | aux2 | ETH | 100000 | 652 | aux3 | ETH | 100000 | 653 | lpprov | ETH | 90000000 | 654 655 When the parties submit the following liquidity provision: 656 | id | party | market id | commitment amount | fee | lp type | 657 | lp1 | lpprov | BTC/ETH | 90000000 | 0.1 | submission | 658 | lp1 | lpprov | BTC/ETH | 90000000 | 0.1 | submission | 659 And the parties place the following pegged iceberg orders: 660 | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | 661 | lpprov | BTC/ETH | 2 | 1 | buy | BID | 50 | 100 | 662 | lpprov | BTC/ETH | 2 | 1 | sell | ASK | 50 | 100 | 663 664 When the parties place the following orders: 665 | party | market id | side | volume | price | resulting trades | type | tif | 666 | aux | BTC/ETH | buy | 1 | 1 | 0 | TYPE_LIMIT | TIF_GTC | 667 | aux | BTC/ETH | sell | 1 | 10001 | 0 | TYPE_LIMIT | TIF_GTC | 668 | aux2 | BTC/ETH | buy | 5 | 50 | 0 | TYPE_LIMIT | TIF_GTC | 669 | aux3 | BTC/ETH | sell | 5 | 50 | 0 | TYPE_LIMIT | TIF_GTC | 670 671 Then the opening auction period ends for market "BTC/ETH" 672 And the trading mode should be "TRADING_MODE_CONTINUOUS" for the market "BTC/ETH" 673 674 # setup party1 position, open a 10 long position 675 When the parties place the following orders: 676 | party | market id | side | volume | price | resulting trades | type | tif | 677 | party1 | BTC/ETH | sell | 10 | 50 | 0 | TYPE_LIMIT | TIF_GTC | 678 | party2 | BTC/ETH | buy | 10 | 50 | 1 | TYPE_LIMIT | TIF_GTC | 679 680 # volume for the stop trade 681 When the parties place the following orders: 682 | party | market id | side | volume | price | resulting trades | type | tif | 683 | party3 | BTC/ETH | sell | 10 | 50 | 0 | TYPE_LIMIT | TIF_GTC | 684 685 686 When time is updated to "2019-11-30T00:00:10Z" 687 # create party1 stop order, no trade resulting, expires in 10 secs 688 When the parties place the following orders: 689 | party | market id | side | volume | price | resulting trades | type | tif | only | ra price trigger | error | reference | ra expires in | ra expiry strategy | 690 | party1 | BTC/ETH | buy | 10 | 0 | 0 | TYPE_MARKET | TIF_IOC | reduce | 75 | | stop1 | 10 | EXPIRY_STRATEGY_SUBMIT | 691 692 # add 20 secs, should expire 693 When time is updated to "2019-11-30T00:00:30Z" 694 695 Then the stop orders should have the following states 696 | party | market id | status | reference | 697 | party1 | BTC/ETH | STATUS_EXPIRED | stop1 | 698 699 # check that the order got submitted 700 Then the orders should have the following states: 701 | party | market id | side | volume | remaining | price | status | reference | 702 | party1 | BTC/ETH | buy | 10 | 0 | 0 | STATUS_FILLED | stop1 | 703 704 Scenario: A stop order set to trade volume x with a trigger set to Rises Above at a given price will trigger at the first trade at or above that price. At this time the order will be placed on the book if and only if it would reduce the trader's absolute position (buying if they are short or selling if they are long) if executed (i.e. will execute as a reduce-only order). (0014-ORDT-177) 705 Given the parties deposit on asset's general account the following amount: 706 | party | asset | amount | 707 | party1 | BTC | 10000000 | 708 | party2 | BTC | 10000000 | 709 | party3 | BTC | 10000000 | 710 | aux | BTC | 10000000 | 711 | aux2 | BTC | 10000000 | 712 | aux3 | BTC | 10000000 | 713 | lpprov | BTC | 90000000 | 714 | party1 | ETH | 10000000 | 715 | party2 | ETH | 10000000 | 716 | party3 | ETH | 10000000 | 717 | aux | ETH | 10000000 | 718 | aux2 | ETH | 10000000 | 719 | aux3 | ETH | 10000000 | 720 | lpprov | ETH | 90000000 | 721 722 When the parties submit the following liquidity provision: 723 | id | party | market id | commitment amount | fee | lp type | 724 | lp1 | lpprov | BTC/ETH | 90000000 | 0.1 | submission | 725 | lp1 | lpprov | BTC/ETH | 90000000 | 0.1 | submission | 726 And the parties place the following pegged iceberg orders: 727 | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | 728 | lpprov | BTC/ETH | 2 | 1 | buy | BID | 50 | 100 | 729 | lpprov | BTC/ETH | 2 | 1 | sell | ASK | 50 | 100 | 730 731 When the parties place the following orders: 732 | party | market id | side | volume | price | resulting trades | type | tif | 733 | aux | BTC/ETH | buy | 1 | 1 | 0 | TYPE_LIMIT | TIF_GTC | 734 | aux | BTC/ETH | sell | 1 | 10001 | 0 | TYPE_LIMIT | TIF_GTC | 735 | aux2 | BTC/ETH | buy | 1 | 50 | 0 | TYPE_LIMIT | TIF_GTC | 736 | aux3 | BTC/ETH | sell | 1 | 50 | 0 | TYPE_LIMIT | TIF_GTC | 737 738 Then the opening auction period ends for market "BTC/ETH" 739 And the trading mode should be "TRADING_MODE_CONTINUOUS" for the market "BTC/ETH" 740 741 # setup party1 position, open a 10 short position 742 When the parties place the following orders: 743 | party | market id | side | volume | price | resulting trades | type | tif | 744 | party1 | BTC/ETH | buy | 1 | 50 | 0 | TYPE_LIMIT | TIF_GTC | 745 | party2 | BTC/ETH | sell | 1 | 50 | 1 | TYPE_LIMIT | TIF_GTC | 746 747 Then the network moves ahead "1" blocks 748 And the trading mode should be "TRADING_MODE_CONTINUOUS" for the market "BTC/ETH" 749 750 Then "party1" should have general account balance of "10000001" for asset "BTC" 751 752 # create party1 stop order, results in a trade 753 When the parties place the following orders: 754 | party | market id | side | volume | price | resulting trades | type | tif | only | fb price trigger | error | reference | 755 | party1 | BTC/ETH | sell | 1 | 0 | 0 | TYPE_MARKET | TIF_IOC | reduce | 25 | | stop1 | 756 757 # volume for the stop trade 758 When the parties place the following orders: 759 | party | market id | side | volume | price | resulting trades | type | tif | 760 | party3 | BTC/ETH | buy | 10 | 20 | 0 | TYPE_LIMIT | TIF_GTC | 761 762 # now we trade at 25, this will breach the trigger 763 When the parties place the following orders: 764 | party | market id | side | volume | price | resulting trades | type | tif | 765 | party3 | BTC/ETH | sell | 10 | 25 | 0 | TYPE_LIMIT | TIF_GTC | 766 | party2 | BTC/ETH | buy | 10 | 25 | 1 | TYPE_LIMIT | TIF_GTC | 767 768 # check that the order got submitted 769 Then the orders should have the following states: 770 | party | market id | side | volume | remaining | price | status | reference | 771 | party1 | BTC/ETH | sell | 1 | 0 | 0 | STATUS_FILLED | stop1 | 772 773 Then the network moves ahead "1" blocks 774 And the trading mode should be "TRADING_MODE_CONTINUOUS" for the market "BTC/ETH" 775 776 # after the volume has been reduced 777 Then "party1" should have general account balance of "10000000" for asset "BTC" 778 779 Scenario: A trailing stop order for a 5% drop placed when the price is 50, followed by a price rise to 60 will, Be triggered by a fall to 57. (0014-ORDT-141), Not be triggered by a fall to 58. (0014-ORDT-142) 780 Given the parties deposit on asset's general account the following amount: 781 | party | asset | amount | 782 | party1 | BTC | 10000000000 | 783 | party2 | BTC | 10000000000 | 784 | party3 | BTC | 10000000000 | 785 | aux | BTC | 10000000000 | 786 | aux2 | BTC | 10000000000 | 787 | lpprov | BTC | 9000000000 | 788 | party1 | ETH | 10000000000 | 789 | party2 | ETH | 10000000000 | 790 | party3 | ETH | 10000000000 | 791 | aux | ETH | 10000000000 | 792 | aux2 | ETH | 10000000000 | 793 | lpprov | ETH | 9000000000 | 794 795 When the parties submit the following liquidity provision: 796 | id | party | market id | commitment amount | fee | lp type | 797 | lp1 | lpprov | BTC/ETH | 90000000 | 0.1 | submission | 798 | lp1 | lpprov | BTC/ETH | 90000000 | 0.1 | submission | 799 And the parties place the following pegged iceberg orders: 800 | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | 801 | lpprov | BTC/ETH | 2 | 1 | buy | BID | 50 | 100 | 802 | lpprov | BTC/ETH | 2 | 1 | sell | ASK | 50 | 100 | 803 804 When the parties place the following orders: 805 | party | market id | side | volume | price | resulting trades | type | tif | 806 | aux | BTC/ETH | buy | 1 | 1 | 0 | TYPE_LIMIT | TIF_GTC | 807 | aux | BTC/ETH | sell | 1 | 10001 | 0 | TYPE_LIMIT | TIF_GTC | 808 | aux2 | BTC/ETH | buy | 1 | 50 | 0 | TYPE_LIMIT | TIF_GTC | 809 | aux | BTC/ETH | sell | 1 | 50 | 0 | TYPE_LIMIT | TIF_GTC | 810 811 Then the opening auction period ends for market "BTC/ETH" 812 And the trading mode should be "TRADING_MODE_CONTINUOUS" for the market "BTC/ETH" 813 814 # setup party1 position, open a 10 long position 815 When the parties place the following orders: 816 | party | market id | side | volume | price | resulting trades | type | tif | 817 | party1 | BTC/ETH | buy | 1 | 50 | 0 | TYPE_LIMIT | TIF_GTC | 818 | party2 | BTC/ETH | sell | 1 | 50 | 1 | TYPE_LIMIT | TIF_GTC | 819 820 # create party1 stop order, results in a trade 821 When the parties place the following orders: 822 | party | market id | side | volume | price | resulting trades | type | tif | only | fb trailing | error | reference | 823 | party1 | BTC/ETH | sell | 1 | 0 | 0 | TYPE_MARKET | TIF_IOC | reduce | 0.05 | | stop1 | 824 825 # create volume to close party 1 826 # high price sell so it doesn't trade 827 When the parties place the following orders: 828 | party | market id | side | volume | price | resulting trades | type | tif | 829 | aux | BTC/ETH | buy | 1 | 20 | 0 | TYPE_LIMIT | TIF_GTC | 830 831 832 # move prive to 60, nothing happen 833 When the parties place the following orders: 834 | party | market id | side | volume | price | resulting trades | type | tif | 835 | aux2 | BTC/ETH | buy | 1 | 60 | 0 | TYPE_LIMIT | TIF_GTC | 836 | aux | BTC/ETH | sell | 1 | 60 | 1 | TYPE_LIMIT | TIF_GTC | 837 838 Then the network moves ahead "1" blocks 839 And the trading mode should be "TRADING_MODE_CONTINUOUS" for the market "BTC/ETH" 840 841 # check the volum as not reduced 842 Then "party1" should have general account balance of "10000000001" for asset "BTC" 843 844 # move first to 58, nothing happen 845 When the parties place the following orders: 846 | party | market id | side | volume | price | resulting trades | type | tif | 847 | aux2 | BTC/ETH | buy | 1 | 58 | 0 | TYPE_LIMIT | TIF_GTC | 848 | aux | BTC/ETH | sell | 1 | 58 | 1 | TYPE_LIMIT | TIF_GTC | 849 850 Then the network moves ahead "1" blocks 851 And the trading mode should be "TRADING_MODE_CONTINUOUS" for the market "BTC/ETH" 852 853 # check the volum as not reduced 854 Then "party1" should have general account balance of "10000000001" for asset "BTC" 855 856 # move first to 57, nothing happen 857 When the parties place the following orders: 858 | party | market id | side | volume | price | resulting trades | type | tif | 859 | aux2 | BTC/ETH | buy | 1 | 57 | 0 | TYPE_LIMIT | TIF_GTC | 860 | aux | BTC/ETH | sell | 1 | 57 | 1 | TYPE_LIMIT | TIF_GTC | 861 862 # check that the order got submitted 863 Then the orders should have the following states: 864 | party | market id | side | volume | remaining | price | status | reference | 865 | party1 | BTC/ETH | sell | 1 | 0 | 0 | STATUS_FILLED | stop1 | 866 867 Then the stop orders should have the following states 868 | party | market id | status | reference | 869 | party1 | BTC/ETH | STATUS_TRIGGERED | stop1 | 870 871 Then "party1" should have general account balance of "10000000000" for asset "BTC" 872 873 Scenario: A trailing stop order for a 5% rise placed when the price is 50, followed by a drop to 40 will, Be triggered by a rise to 42. (0014-ORDT-143), Not be triggered by a rise to 41. (0014-ORDT-144) 874 Given the parties deposit on asset's general account the following amount: 875 | party | asset | amount | 876 | party1 | BTC | 10000000000 | 877 | party2 | BTC | 10000000000 | 878 | party3 | BTC | 10000000000 | 879 | aux | BTC | 10000000000 | 880 | aux2 | BTC | 10000000000 | 881 | lpprov | BTC | 9000000000 | 882 | party1 | ETH | 10000000000 | 883 | party2 | ETH | 10000000000 | 884 | party3 | ETH | 10000000000 | 885 | aux | ETH | 10000000000 | 886 | aux2 | ETH | 10000000000 | 887 | lpprov | ETH | 9000000000 | 888 889 When the parties submit the following liquidity provision: 890 | id | party | market id | commitment amount | fee | lp type | 891 | lp1 | lpprov | BTC/ETH | 90000000 | 0.1 | submission | 892 | lp1 | lpprov | BTC/ETH | 90000000 | 0.1 | submission | 893 And the parties place the following pegged iceberg orders: 894 | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | 895 | lpprov | BTC/ETH | 2 | 1 | buy | BID | 50 | 100 | 896 | lpprov | BTC/ETH | 2 | 1 | sell | ASK | 50 | 100 | 897 898 When the parties place the following orders: 899 | party | market id | side | volume | price | resulting trades | type | tif | 900 | aux | BTC/ETH | buy | 1 | 1 | 0 | TYPE_LIMIT | TIF_GTC | 901 | aux | BTC/ETH | sell | 1 | 10001 | 0 | TYPE_LIMIT | TIF_GTC | 902 | aux2 | BTC/ETH | buy | 1 | 50 | 0 | TYPE_LIMIT | TIF_GTC | 903 | aux | BTC/ETH | sell | 1 | 50 | 0 | TYPE_LIMIT | TIF_GTC | 904 905 Then the opening auction period ends for market "BTC/ETH" 906 And the trading mode should be "TRADING_MODE_CONTINUOUS" for the market "BTC/ETH" 907 908 # setup party1 position, open a 10 short position 909 When the parties place the following orders: 910 | party | market id | side | volume | price | resulting trades | type | tif | 911 | party1 | BTC/ETH | sell | 1 | 50 | 0 | TYPE_LIMIT | TIF_GTC | 912 | party2 | BTC/ETH | buy | 1 | 50 | 1 | TYPE_LIMIT | TIF_GTC | 913 914 # create party1 stop order, results in a trade 915 When the parties place the following orders: 916 | party | market id | side | volume | price | resulting trades | type | tif | only | ra trailing | error | reference | 917 | party1 | BTC/ETH | buy | 1 | 0 | 0 | TYPE_MARKET | TIF_IOC | reduce | 0.05 | | stop1 | 918 919 # create volume to close party 1 920 # high price sell so it doesn't trade 921 When the parties place the following orders: 922 | party | market id | side | volume | price | resulting trades | type | tif | 923 | aux | BTC/ETH | sell | 1 | 70 | 0 | TYPE_LIMIT | TIF_GTC | 924 925 926 # move prive to 60, nothing happen 927 When the parties place the following orders: 928 | party | market id | side | volume | price | resulting trades | type | tif | 929 | aux2 | BTC/ETH | buy | 1 | 40 | 0 | TYPE_LIMIT | TIF_GTC | 930 | aux | BTC/ETH | sell | 1 | 40 | 1 | TYPE_LIMIT | TIF_GTC | 931 932 Then the network moves ahead "1" blocks 933 And the trading mode should be "TRADING_MODE_CONTINUOUS" for the market "BTC/ETH" 934 935 # check the volum as not reduced 936 Then "party1" should have general account balance of "9999999999" for asset "BTC" 937 938 # move first to 58, nothing happen 939 When the parties place the following orders: 940 | party | market id | side | volume | price | resulting trades | type | tif | 941 | aux2 | BTC/ETH | buy | 1 | 41 | 0 | TYPE_LIMIT | TIF_GTC | 942 | aux | BTC/ETH | sell | 1 | 41 | 1 | TYPE_LIMIT | TIF_GTC | 943 944 Then the network moves ahead "1" blocks 945 And the trading mode should be "TRADING_MODE_CONTINUOUS" for the market "BTC/ETH" 946 947 # check the volum as not reduced 948 Then "party1" should have general account balance of "9999999999" for asset "BTC" 949 950 # move first to 57, nothing happen 951 When the parties place the following orders: 952 | party | market id | side | volume | price | resulting trades | type | tif | 953 | aux2 | BTC/ETH | buy | 1 | 42 | 0 | TYPE_LIMIT | TIF_GTC | 954 | aux | BTC/ETH | sell | 1 | 42 | 1 | TYPE_LIMIT | TIF_GTC | 955 956 # check that the order got submitted 957 Then the orders should have the following states: 958 | party | market id | side | volume | remaining | price | status | reference | 959 | party1 | BTC/ETH | buy | 1 | 0 | 0 | STATUS_FILLED | stop1 | 960 961 Then the stop orders should have the following states 962 | party | market id | status | reference | 963 | party1 | BTC/ETH | STATUS_TRIGGERED | stop1 | 964 965 Then "party1" should have general account balance of "10000000000" for asset "BTC" 966 967 Scenario: A trailing stop order for a 25% drop placed when the price is 50, followed by a price rise to 60, then to 50, then another rise to 57 will:, Be triggered by a fall to 45. (0014-ORDT-145), Not be triggered by a fall to 46. (0014-ORDT-146) 968 Given the parties deposit on asset's general account the following amount: 969 | party | asset | amount | 970 | party1 | BTC | 10000000000 | 971 | party2 | BTC | 10000000000 | 972 | party3 | BTC | 10000000000 | 973 | aux | BTC | 10000000000 | 974 | aux2 | BTC | 10000000000 | 975 | lpprov | BTC | 9000000000 | 976 | party1 | ETH | 10000000000 | 977 | party2 | ETH | 10000000000 | 978 | party3 | ETH | 10000000000 | 979 | aux | ETH | 10000000000 | 980 | aux2 | ETH | 10000000000 | 981 | lpprov | ETH | 9000000000 | 982 983 When the parties submit the following liquidity provision: 984 | id | party | market id | commitment amount | fee | lp type | 985 | lp1 | lpprov | BTC/ETH | 90000000 | 0.1 | submission | 986 | lp1 | lpprov | BTC/ETH | 90000000 | 0.1 | submission | 987 And the parties place the following pegged iceberg orders: 988 | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | 989 | lpprov | BTC/ETH | 2 | 1 | buy | BID | 50 | 100 | 990 | lpprov | BTC/ETH | 2 | 1 | sell | ASK | 50 | 100 | 991 992 When the parties place the following orders: 993 | party | market id | side | volume | price | resulting trades | type | tif | 994 | aux | BTC/ETH | buy | 1 | 1 | 0 | TYPE_LIMIT | TIF_GTC | 995 | aux | BTC/ETH | sell | 1 | 10001 | 0 | TYPE_LIMIT | TIF_GTC | 996 | aux2 | BTC/ETH | buy | 1 | 50 | 0 | TYPE_LIMIT | TIF_GTC | 997 | aux | BTC/ETH | sell | 1 | 50 | 0 | TYPE_LIMIT | TIF_GTC | 998 999 Then the opening auction period ends for market "BTC/ETH" 1000 And the trading mode should be "TRADING_MODE_CONTINUOUS" for the market "BTC/ETH" 1001 1002 # setup party1 position, open a 10 long position 1003 When the parties place the following orders: 1004 | party | market id | side | volume | price | resulting trades | type | tif | 1005 | party1 | BTC/ETH | buy | 1 | 50 | 0 | TYPE_LIMIT | TIF_GTC | 1006 | party2 | BTC/ETH | sell | 1 | 50 | 1 | TYPE_LIMIT | TIF_GTC | 1007 1008 # create party1 stop order, results in a trade 1009 When the parties place the following orders: 1010 | party | market id | side | volume | price | resulting trades | type | tif | only | fb trailing | error | reference | 1011 | party1 | BTC/ETH | sell | 1 | 0 | 0 | TYPE_MARKET | TIF_IOC | reduce | 0.25 | | stop1 | 1012 1013 # create volume to close party 1 1014 # high price sell so it doesn't trade 1015 When the parties place the following orders: 1016 | party | market id | side | volume | price | resulting trades | type | tif | 1017 | aux | BTC/ETH | buy | 1 | 20 | 0 | TYPE_LIMIT | TIF_GTC | 1018 1019 1020 # move prive to 60, nothing happen 1021 When the parties place the following orders: 1022 | party | market id | side | volume | price | resulting trades | type | tif | 1023 | aux2 | BTC/ETH | buy | 1 | 60 | 0 | TYPE_LIMIT | TIF_GTC | 1024 | aux | BTC/ETH | sell | 1 | 60 | 1 | TYPE_LIMIT | TIF_GTC | 1025 1026 Then the network moves ahead "1" blocks 1027 And the trading mode should be "TRADING_MODE_CONTINUOUS" for the market "BTC/ETH" 1028 1029 # check the volume has not reduced 1030 Then "party1" should have general account balance of "10000000001" for asset "BTC" 1031 1032 # move first to 58, nothing happen 1033 When the parties place the following orders: 1034 | party | market id | side | volume | price | resulting trades | type | tif | 1035 | aux2 | BTC/ETH | buy | 1 | 50 | 0 | TYPE_LIMIT | TIF_GTC | 1036 | aux | BTC/ETH | sell | 1 | 50 | 1 | TYPE_LIMIT | TIF_GTC | 1037 1038 Then the network moves ahead "1" blocks 1039 And the trading mode should be "TRADING_MODE_CONTINUOUS" for the market "BTC/ETH" 1040 1041 # check the volum as not reduced 1042 Then "party1" should have general account balance of "10000000001" for asset "BTC" 1043 1044 # move first to 57, nothing happen 1045 When the parties place the following orders: 1046 | party | market id | side | volume | price | resulting trades | type | tif | 1047 | aux2 | BTC/ETH | buy | 1 | 57 | 0 | TYPE_LIMIT | TIF_GTC | 1048 | aux | BTC/ETH | sell | 1 | 57 | 1 | TYPE_LIMIT | TIF_GTC | 1049 1050 Then the network moves ahead "1" blocks 1051 And the trading mode should be "TRADING_MODE_CONTINUOUS" for the market "BTC/ETH" 1052 1053 # check the volum as not reduced 1054 Then "party1" should have general account balance of "10000000001" for asset "BTC" 1055 1056 # move first to 46, nothing happen 1057 When the parties place the following orders: 1058 | party | market id | side | volume | price | resulting trades | type | tif | 1059 | aux2 | BTC/ETH | buy | 1 | 46 | 0 | TYPE_LIMIT | TIF_GTC | 1060 | aux | BTC/ETH | sell | 1 | 46 | 1 | TYPE_LIMIT | TIF_GTC | 1061 1062 Then the network moves ahead "1" blocks 1063 And the trading mode should be "TRADING_MODE_CONTINUOUS" for the market "BTC/ETH" 1064 1065 # check the volum as not reduced 1066 Then "party1" should have general account balance of "10000000001" for asset "BTC" 1067 1068 # move first to 46, nothing happen 1069 When the parties place the following orders: 1070 | party | market id | side | volume | price | resulting trades | type | tif | 1071 | aux2 | BTC/ETH | buy | 1 | 45 | 0 | TYPE_LIMIT | TIF_GTC | 1072 | aux | BTC/ETH | sell | 1 | 45 | 1 | TYPE_LIMIT | TIF_GTC | 1073 1074 # check that the order got submitted 1075 Then the orders should have the following states: 1076 | party | market id | side | volume | remaining | price | status | reference | 1077 | party1 | BTC/ETH | sell | 1 | 0 | 0 | STATUS_FILLED | stop1 | 1078 1079 Then the stop orders should have the following states 1080 | party | market id | status | reference | 1081 | party1 | BTC/ETH | STATUS_TRIGGERED | stop1 | 1082 1083 Scenario: A Stop order that hasn't been triggered can be cancelled. (0014-ORDT-154) 1084 Given the parties deposit on asset's general account the following amount: 1085 | party | asset | amount | 1086 | party1 | BTC | 10000 | 1087 | party2 | BTC | 10000 | 1088 | aux | BTC | 100000 | 1089 | aux2 | BTC | 100000 | 1090 | lpprov | BTC | 90000000 | 1091 | party1 | ETH | 10000 | 1092 | party2 | ETH | 10000 | 1093 | aux | ETH | 100000 | 1094 | aux2 | ETH | 100000 | 1095 | lpprov | ETH | 90000000 | 1096 1097 When the parties submit the following liquidity provision: 1098 | id | party | market id | commitment amount | fee | lp type | 1099 | lp1 | lpprov | BTC/ETH | 90000000 | 0.1 | submission | 1100 | lp1 | lpprov | BTC/ETH | 90000000 | 0.1 | submission | 1101 And the parties place the following pegged iceberg orders: 1102 | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | 1103 | lpprov | BTC/ETH | 2 | 1 | buy | BID | 50 | 100 | 1104 | lpprov | BTC/ETH | 2 | 1 | sell | ASK | 50 | 100 | 1105 1106 When the parties place the following orders: 1107 | party | market id | side | volume | price | resulting trades | type | tif | 1108 | aux | BTC/ETH | buy | 1 | 1 | 0 | TYPE_LIMIT | TIF_GTC | 1109 | aux | BTC/ETH | sell | 1 | 10001 | 0 | TYPE_LIMIT | TIF_GTC | 1110 | aux2 | BTC/ETH | buy | 1 | 50 | 0 | TYPE_LIMIT | TIF_GTC | 1111 | aux | BTC/ETH | sell | 1 | 50 | 0 | TYPE_LIMIT | TIF_GTC | 1112 1113 Then the opening auction period ends for market "BTC/ETH" 1114 And the trading mode should be "TRADING_MODE_CONTINUOUS" for the market "BTC/ETH" 1115 1116 When the parties place the following orders: 1117 | party | market id | side | volume | price | resulting trades | type | tif | only | fb price trigger | error | reference | 1118 | party1 | BTC/ETH | sell | 10 | 60 | 0 | TYPE_LIMIT | TIF_GTC | | | | | 1119 | party1 | BTC/ETH | buy | 10 | 0 | 0 | TYPE_MARKET | TIF_GTC | reduce | 47 | | stop1 | 1120 1121 Then the parties cancel the following stop orders: 1122 | party | reference | 1123 | party1 | stop1 | 1124 1125 Then the stop orders should have the following states 1126 | party | market id | status | reference | 1127 | party1 | BTC/ETH | STATUS_CANCELLED | stop1 | 1128 1129 @SLABug 1130 Scenario: All stop orders for a specific party can be cancelled by a single stop order cancellation. (0014-ORDT-155) 1131 Given the parties deposit on asset's general account the following amount: 1132 | party | asset | amount | 1133 | party1 | BTC | 1000000 | 1134 | party2 | BTC | 1000000 | 1135 | aux | BTC | 1000000 | 1136 | aux2 | BTC | 1000000 | 1137 | lpprov | BTC | 900000000 | 1138 | party1 | ETH | 1000000 | 1139 | party2 | ETH | 1000000 | 1140 | aux | ETH | 1000000 | 1141 | aux2 | ETH | 1000000 | 1142 | lpprov | ETH | 900000000 | 1143 | party1 | USDT | 1000000 | 1144 | party2 | USDT | 1000000 | 1145 | aux | USDT | 1000000 | 1146 | aux2 | USDT | 1000000 | 1147 | lpprov | USDT | 900000000 | 1148 1149 When the parties submit the following liquidity provision: 1150 | id | party | market id | commitment amount | fee | lp type | 1151 | lp1 | lpprov | BTC/ETH | 900000 | 0.1 | submission | 1152 | lp1 | lpprov | BTC/ETH | 900000 | 0.1 | submission | 1153 | lp2 | lpprov | USDT/ETH | 900000 | 0.1 | submission | 1154 | lp2 | lpprov | USDT/ETH | 900000 | 0.1 | submission | 1155 And the parties place the following pegged iceberg orders: 1156 | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | 1157 | lpprov | BTC/ETH | 2 | 1 | buy | BID | 50 | 100 | 1158 | lpprov | BTC/ETH | 2 | 1 | sell | ASK | 50 | 100 | 1159 | lpprov | USDT/ETH | 2 | 1 | buy | BID | 50 | 100 | 1160 | lpprov | USDT/ETH | 2 | 1 | sell | ASK | 50 | 100 | 1161 1162 When the parties place the following orders: 1163 | party | market id | side | volume | price | resulting trades | type | tif | 1164 | aux | BTC/ETH | buy | 1 | 1 | 0 | TYPE_LIMIT | TIF_GTC | 1165 | aux | BTC/ETH | sell | 1 | 10001 | 0 | TYPE_LIMIT | TIF_GTC | 1166 | aux2 | BTC/ETH | buy | 1 | 50 | 0 | TYPE_LIMIT | TIF_GTC | 1167 | aux | BTC/ETH | sell | 1 | 50 | 0 | TYPE_LIMIT | TIF_GTC | 1168 | aux | USDT/ETH | buy | 1 | 1 | 0 | TYPE_LIMIT | TIF_GTC | 1169 | aux | USDT/ETH | sell | 1 | 10001 | 0 | TYPE_LIMIT | TIF_GTC | 1170 | aux2 | USDT/ETH | buy | 1 | 50 | 0 | TYPE_LIMIT | TIF_GTC | 1171 | aux | USDT/ETH | sell | 1 | 50 | 0 | TYPE_LIMIT | TIF_GTC | 1172 1173 When the network moves ahead "2" blocks 1174 Then the trading mode should be "TRADING_MODE_CONTINUOUS" for the market "BTC/ETH" 1175 And the trading mode should be "TRADING_MODE_CONTINUOUS" for the market "USDT/ETH" 1176 1177 When the parties place the following orders: 1178 | party | market id | side | volume | price | resulting trades | type | tif | only | fb price trigger | error | reference | 1179 | party1 | BTC/ETH | sell | 10 | 60 | 0 | TYPE_LIMIT | TIF_GTC | | | | | 1180 | party1 | BTC/ETH | buy | 2 | 0 | 0 | TYPE_MARKET | TIF_GTC | reduce | 47 | | stop1 | 1181 | party1 | BTC/ETH | buy | 2 | 0 | 0 | TYPE_MARKET | TIF_GTC | reduce | 48 | | stop2 | 1182 | party1 | USDT/ETH | sell | 10 | 60 | 0 | TYPE_LIMIT | TIF_GTC | | | | | 1183 | party1 | USDT/ETH | buy | 2 | 0 | 0 | TYPE_MARKET | TIF_GTC | reduce | 49 | | stop3 | 1184 | party1 | USDT/ETH | buy | 2 | 0 | 0 | TYPE_MARKET | TIF_GTC | reduce | 49 | | stop4 | 1185 1186 Then the party "party1" cancels all their stop orders 1187 1188 Then the stop orders should have the following states 1189 | party | market id | status | reference | 1190 | party1 | BTC/ETH | STATUS_CANCELLED | stop1 | 1191 | party1 | BTC/ETH | STATUS_CANCELLED | stop2 | 1192 | party1 | USDT/ETH | STATUS_CANCELLED | stop3 | 1193 | party1 | USDT/ETH | STATUS_CANCELLED | stop4 | 1194 1195 @SLABug 1196 Scenario: All stop orders for a specific party for a specific market can be cancelled by a single stop order cancellation. (0014-ORDT-156) 1197 Given the parties deposit on asset's general account the following amount: 1198 | party | asset | amount | 1199 | party1 | BTC | 1000000 | 1200 | party2 | BTC | 1000000 | 1201 | aux | BTC | 1000000 | 1202 | aux2 | BTC | 1000000 | 1203 | lpprov | BTC | 900000000 | 1204 | party1 | ETH | 1000000 | 1205 | party2 | ETH | 1000000 | 1206 | aux | ETH | 1000000 | 1207 | aux2 | ETH | 1000000 | 1208 | lpprov | ETH | 900000000 | 1209 | party1 | USDT | 1000000 | 1210 | party2 | USDT | 1000000 | 1211 | aux | USDT | 1000000 | 1212 | aux2 | USDT | 1000000 | 1213 | lpprov | USDT | 900000000 | 1214 1215 When the parties submit the following liquidity provision: 1216 | id | party | market id | commitment amount | fee | lp type | 1217 | lp1 | lpprov | BTC/ETH | 900000 | 0.1 | submission | 1218 | lp1 | lpprov | BTC/ETH | 900000 | 0.1 | submission | 1219 | lp2 | lpprov | USDT/ETH | 900000 | 0.1 | submission | 1220 | lp2 | lpprov | USDT/ETH | 900000 | 0.1 | submission | 1221 And the parties place the following pegged iceberg orders: 1222 | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | 1223 | lpprov | BTC/ETH | 2 | 1 | buy | BID | 50 | 100 | 1224 | lpprov | BTC/ETH | 2 | 1 | sell | ASK | 50 | 100 | 1225 | lpprov | USDT/ETH | 2 | 1 | buy | BID | 50 | 100 | 1226 | lpprov | USDT/ETH | 2 | 1 | sell | ASK | 50 | 100 | 1227 1228 When the parties place the following orders: 1229 | party | market id | side | volume | price | resulting trades | type | tif | 1230 | aux | BTC/ETH | buy | 1 | 1 | 0 | TYPE_LIMIT | TIF_GTC | 1231 | aux | BTC/ETH | sell | 1 | 10001 | 0 | TYPE_LIMIT | TIF_GTC | 1232 | aux2 | BTC/ETH | buy | 1 | 50 | 0 | TYPE_LIMIT | TIF_GTC | 1233 | aux | BTC/ETH | sell | 1 | 50 | 0 | TYPE_LIMIT | TIF_GTC | 1234 | aux | USDT/ETH | buy | 1 | 1 | 0 | TYPE_LIMIT | TIF_GTC | 1235 | aux | USDT/ETH | sell | 1 | 10001 | 0 | TYPE_LIMIT | TIF_GTC | 1236 | aux2 | USDT/ETH | buy | 1 | 50 | 0 | TYPE_LIMIT | TIF_GTC | 1237 | aux | USDT/ETH | sell | 1 | 50 | 0 | TYPE_LIMIT | TIF_GTC | 1238 1239 When the network moves ahead "2" blocks 1240 Then the trading mode should be "TRADING_MODE_CONTINUOUS" for the market "BTC/ETH" 1241 And the trading mode should be "TRADING_MODE_CONTINUOUS" for the market "USDT/ETH" 1242 1243 When the parties place the following orders: 1244 | party | market id | side | volume | price | resulting trades | type | tif | only | fb price trigger | error | reference | 1245 | party1 | BTC/ETH | sell | 10 | 60 | 0 | TYPE_LIMIT | TIF_GTC | | | | | 1246 | party1 | BTC/ETH | buy | 2 | 0 | 0 | TYPE_MARKET | TIF_GTC | reduce | 47 | | stop1 | 1247 | party1 | BTC/ETH | buy | 2 | 0 | 0 | TYPE_MARKET | TIF_GTC | reduce | 48 | | stop2 | 1248 | party1 | USDT/ETH | sell | 10 | 60 | 0 | TYPE_LIMIT | TIF_GTC | | | | | 1249 | party1 | USDT/ETH | buy | 2 | 0 | 0 | TYPE_MARKET | TIF_GTC | reduce | 49 | | stop3 | 1250 | party1 | USDT/ETH | buy | 2 | 0 | 0 | TYPE_MARKET | TIF_GTC | reduce | 49 | | stop4 | 1251 1252 Then the party "party1" cancels all their stop orders for the market "BTC/ETH" 1253 1254 Then the stop orders should have the following states 1255 | party | market id | status | reference | 1256 | party1 | BTC/ETH | STATUS_CANCELLED | stop1 | 1257 | party1 | BTC/ETH | STATUS_CANCELLED | stop2 | 1258 | party1 | USDT/ETH | STATUS_PENDING | stop3 | 1259 | party1 | USDT/ETH | STATUS_PENDING | stop4 | 1260 1261 Scenario: An OCO stop order with expiration time T with both sides set to execute at that time will be rejected on submission (0014-ORDT-176) 1262 # setup accounts 1263 Given time is updated to "2019-11-30T00:00:00Z" 1264 Given the parties deposit on asset's general account the following amount: 1265 | party | asset | amount | 1266 | party1 | BTC | 10000 | 1267 | party2 | BTC | 10000 | 1268 | party3 | BTC | 10000 | 1269 | aux | BTC | 100000 | 1270 | aux2 | BTC | 100000 | 1271 | aux3 | BTC | 100000 | 1272 | lpprov | BTC | 90000000 | 1273 | party1 | ETH | 10000 | 1274 | party2 | ETH | 10000 | 1275 | party3 | ETH | 10000 | 1276 | aux | ETH | 100000 | 1277 | aux2 | ETH | 100000 | 1278 | aux3 | ETH | 100000 | 1279 | lpprov | ETH | 90000000 | 1280 1281 When the parties submit the following liquidity provision: 1282 | id | party | market id | commitment amount | fee | lp type | 1283 | lp1 | lpprov | BTC/ETH | 90000000 | 0.1 | submission | 1284 | lp1 | lpprov | BTC/ETH | 90000000 | 0.1 | submission | 1285 And the parties place the following pegged iceberg orders: 1286 | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | 1287 | lpprov | BTC/ETH | 2 | 1 | buy | BID | 50 | 100 | 1288 | lpprov | BTC/ETH | 2 | 1 | sell | ASK | 50 | 100 | 1289 1290 # place auxiliary orders so we always have best bid and best offer as to not trigger the liquidity auction 1291 When the parties place the following orders: 1292 | party | market id | side | volume | price | resulting trades | type | tif | 1293 | aux | BTC/ETH | buy | 1 | 1 | 0 | TYPE_LIMIT | TIF_GTC | 1294 | aux | BTC/ETH | sell | 1 | 10001 | 0 | TYPE_LIMIT | TIF_GTC | 1295 | aux2 | BTC/ETH | buy | 5 | 50 | 0 | TYPE_LIMIT | TIF_GTC | 1296 | aux3 | BTC/ETH | sell | 5 | 50 | 0 | TYPE_LIMIT | TIF_GTC | 1297 1298 Then the opening auction period ends for market "BTC/ETH" 1299 And the trading mode should be "TRADING_MODE_CONTINUOUS" for the market "BTC/ETH" 1300 1301 When the parties place the following orders: 1302 | party | market id | side | volume | price | resulting trades | type | tif | 1303 | party1 | BTC/ETH | sell | 10 | 50 | 0 | TYPE_LIMIT | TIF_GTC | 1304 | party2 | BTC/ETH | buy | 10 | 50 | 1 | TYPE_LIMIT | TIF_GTC | 1305 1306 # volume for the stop trade 1307 When the parties place the following orders: 1308 | party | market id | side | volume | price | resulting trades | type | tif | 1309 | party3 | BTC/ETH | sell | 10 | 50 | 0 | TYPE_LIMIT | TIF_GTC | 1310 1311 1312 When time is updated to "2019-11-30T00:00:10Z" 1313 When the parties place the following orders: 1314 | party | market id | side | volume | price | resulting trades | type | tif | only | ra price trigger | fb price trigger | reference | ra expires in | ra expiry strategy | fb expires in | fb expiry strategy | error | 1315 | party1 | BTC/ETH | buy | 10 | 0 | 0 | TYPE_MARKET | TIF_IOC | reduce | 75 | 25 | stop1 | 10 | EXPIRY_STRATEGY_SUBMIT | 10 | EXPIRY_STRATEGY_SUBMIT | stop order OCOs must not have the same expiry time | 1316 1317 1318 Scenario: An OCO stop order with expiration time T with one side set to execute at that time will execute at time T if reached without being triggered, with the specified side triggering and the other side cancelling. (0014-ORDT-131) 1319 Given time is updated to "2019-11-30T00:00:00Z" 1320 Given the parties deposit on asset's general account the following amount: 1321 | party | asset | amount | 1322 | party1 | BTC | 10000000 | 1323 | party2 | BTC | 10000000 | 1324 | party3 | BTC | 10000000 | 1325 | aux | BTC | 10000000 | 1326 | aux2 | BTC | 10000000 | 1327 | aux3 | BTC | 100000 | 1328 | lpprov | BTC | 90000000 | 1329 | party1 | ETH | 10000000 | 1330 | party2 | ETH | 10000000 | 1331 | party3 | ETH | 10000000 | 1332 | aux | ETH | 10000000 | 1333 | aux2 | ETH | 10000000 | 1334 | aux3 | ETH | 100000 | 1335 | lpprov | ETH | 90000000 | 1336 1337 When the parties submit the following liquidity provision: 1338 | id | party | market id | commitment amount | fee | lp type | 1339 | lp1 | lpprov | BTC/ETH | 90000000 | 0.1 | submission | 1340 | lp1 | lpprov | BTC/ETH | 90000000 | 0.1 | submission | 1341 And the parties place the following pegged iceberg orders: 1342 | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | 1343 | lpprov | BTC/ETH | 2 | 1 | buy | BID | 50 | 100 | 1344 | lpprov | BTC/ETH | 2 | 1 | sell | ASK | 50 | 100 | 1345 1346 # place auxiliary orders so we always have best bid and best offer as to not trigger the liquidity auction 1347 When the parties place the following orders: 1348 | party | market id | side | volume | price | resulting trades | type | tif | 1349 | aux | BTC/ETH | buy | 100 | 1 | 0 | TYPE_LIMIT | TIF_GTC | 1350 | aux | BTC/ETH | sell | 100 | 10001 | 0 | TYPE_LIMIT | TIF_GTC | 1351 | aux2 | BTC/ETH | buy | 5 | 50 | 0 | TYPE_LIMIT | TIF_GTC | 1352 | aux3 | BTC/ETH | sell | 5 | 50 | 0 | TYPE_LIMIT | TIF_GTC | 1353 1354 Then the opening auction period ends for market "BTC/ETH" 1355 And the trading mode should be "TRADING_MODE_CONTINUOUS" for the market "BTC/ETH" 1356 1357 When the parties place the following orders: 1358 | party | market id | side | volume | price | resulting trades | type | tif | 1359 | party1 | BTC/ETH | sell | 10 | 50 | 0 | TYPE_LIMIT | TIF_GTC | 1360 | party2 | BTC/ETH | buy | 10 | 50 | 1 | TYPE_LIMIT | TIF_GTC | 1361 1362 # volume for the stop trade 1363 When the parties place the following orders: 1364 | party | market id | side | volume | price | resulting trades | type | tif | 1365 | party3 | BTC/ETH | sell | 10 | 50 | 0 | TYPE_LIMIT | TIF_GTC | 1366 | party3 | BTC/ETH | buy | 10 | 51 | 0 | TYPE_LIMIT | TIF_GTC | 1367 1368 When time is updated to "2019-11-30T00:00:10Z" 1369 When the parties place the following orders: 1370 | party | market id | side | volume | price | resulting trades | type | tif | only | ra price trigger | fb price trigger | reference | ra expires in | ra expiry strategy | fb expires in | fb expiry strategy | 1371 | party1 | BTC/ETH | buy | 10 | 0 | 0 | TYPE_MARKET | TIF_IOC | reduce | 75 | 25 | stop | 10 | EXPIRY_STRATEGY_SUBMIT | 15 | EXPIRY_STRATEGY_SUBMIT | 1372 1373 Then the stop orders should have the following states 1374 | party | market id | status | reference | 1375 | party1 | BTC/ETH | STATUS_PENDING | stop-1 | 1376 | party1 | BTC/ETH | STATUS_PENDING | stop-2 | 1377 1378 Then clear all events 1379 When time is updated to "2019-11-30T00:00:20Z" 1380 1381 Then the stop orders should have the following states 1382 | party | market id | status | reference | 1383 | party1 | BTC/ETH | STATUS_STOPPED | stop-1 | 1384 | party1 | BTC/ETH | STATUS_EXPIRED | stop-2 | 1385 1386 # Now perform the same test but from the other side 1387 When the parties place the following orders: 1388 | party | market id | side | volume | price | resulting trades | type | tif | only | ra price trigger | fb price trigger | reference | ra expires in | ra expiry strategy | fb expires in | fb expiry strategy | 1389 | party2 | BTC/ETH | sell | 10 | 0 | 0 | TYPE_MARKET | TIF_IOC | reduce | 75 | 25 | stop2 | 15 | EXPIRY_STRATEGY_SUBMIT | 10 | EXPIRY_STRATEGY_SUBMIT | 1390 1391 Then the stop orders should have the following states 1392 | party | market id | status | reference | 1393 | party2 | BTC/ETH | STATUS_PENDING | stop2-1 | 1394 | party2 | BTC/ETH | STATUS_PENDING | stop2-2 | 1395 1396 Then clear all events 1397 When time is updated to "2019-11-30T00:00:30Z" 1398 1399 Then the stop orders should have the following states 1400 | party | market id | status | reference | 1401 | party2 | BTC/ETH | STATUS_STOPPED | stop2-2 | 1402 | party2 | BTC/ETH | STATUS_EXPIRED | stop2-1 | 1403 1404 1405 Scenario: A stop order placed by a key with a zero position but open orders will be accepted. (0014-ORDT-125) 1406 Given the parties deposit on asset's general account the following amount: 1407 | party | asset | amount | 1408 | party1 | BTC | 10000 | 1409 | party2 | BTC | 10000 | 1410 | aux | BTC | 100000 | 1411 | aux2 | BTC | 100000 | 1412 | lpprov | BTC | 90000000 | 1413 | party1 | ETH | 10000 | 1414 | party2 | ETH | 10000 | 1415 | aux | ETH | 100000 | 1416 | aux2 | ETH | 100000 | 1417 | lpprov | ETH | 90000000 | 1418 1419 When the parties submit the following liquidity provision: 1420 | id | party | market id | commitment amount | fee | lp type | 1421 | lp1 | lpprov | BTC/ETH | 90000000 | 0.1 | submission | 1422 | lp1 | lpprov | BTC/ETH | 90000000 | 0.1 | submission | 1423 And the parties place the following pegged iceberg orders: 1424 | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | 1425 | lpprov | BTC/ETH | 2 | 1 | buy | BID | 50 | 100 | 1426 | lpprov | BTC/ETH | 2 | 1 | sell | ASK | 50 | 100 | 1427 1428 # place auxiliary orders so we always have best bid and best offer as to not trigger the liquidity auction 1429 When the parties place the following orders: 1430 | party | market id | side | volume | price | resulting trades | type | tif | 1431 | aux | BTC/ETH | buy | 1 | 1 | 0 | TYPE_LIMIT | TIF_GTC | 1432 | aux | BTC/ETH | sell | 1 | 10001 | 0 | TYPE_LIMIT | TIF_GTC | 1433 | aux2 | BTC/ETH | buy | 1 | 50 | 0 | TYPE_LIMIT | TIF_GTC | 1434 | aux | BTC/ETH | sell | 1 | 50 | 0 | TYPE_LIMIT | TIF_GTC | 1435 1436 Then the opening auction period ends for market "BTC/ETH" 1437 And the trading mode should be "TRADING_MODE_CONTINUOUS" for the market "BTC/ETH" 1438 1439 When the parties place the following orders: 1440 | party | market id | side | volume | price | resulting trades | type | tif | only | fb price trigger | error | 1441 | party1 | BTC/ETH | buy | 10 | 0 | 0 | TYPE_MARKET | TIF_GTC | reduce | 47 | | 1442 1443 Scenario: Given a spot market, a stop order with a position size override will be rejected (0014-ORDT-162) 1444 1445 # setup accounts 1446 Given time is updated to "2019-11-30T00:00:00Z" 1447 Given the parties deposit on asset's general account the following amount: 1448 | party | asset | amount | 1449 | party1 | BTC | 10000000 | 1450 | party2 | BTC | 10000000 | 1451 | party3 | BTC | 10000000 | 1452 | aux | BTC | 10000000 | 1453 | aux2 | BTC | 10000000 | 1454 | aux3 | BTC | 100000 | 1455 | lpprov | BTC | 90000000 | 1456 | party1 | ETH | 10000000 | 1457 | party2 | ETH | 10000000 | 1458 | party3 | ETH | 10000000 | 1459 | aux | ETH | 10000000 | 1460 | aux2 | ETH | 10000000 | 1461 | aux3 | ETH | 100000 | 1462 | lpprov | ETH | 90000000 | 1463 1464 When the parties submit the following liquidity provision: 1465 | id | party | market id | commitment amount | fee | lp type | 1466 | lp1 | lpprov | BTC/ETH | 90000000 | 0.1 | submission | 1467 | lp1 | lpprov | BTC/ETH | 90000000 | 0.1 | submission | 1468 And the parties place the following pegged iceberg orders: 1469 | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | 1470 | lpprov | BTC/ETH | 2 | 1 | buy | BID | 50 | 100 | 1471 | lpprov | BTC/ETH | 2 | 1 | sell | ASK | 50 | 100 | 1472 1473 # place auxiliary orders so we always have best bid and best offer as to not trigger the liquidity auction 1474 When the parties place the following orders: 1475 | party | market id | side | volume | price | resulting trades | type | tif | 1476 | aux | BTC/ETH | buy | 100 | 1 | 0 | TYPE_LIMIT | TIF_GTC | 1477 | aux | BTC/ETH | sell | 100 | 10001 | 0 | TYPE_LIMIT | TIF_GTC | 1478 | aux2 | BTC/ETH | buy | 5 | 50 | 0 | TYPE_LIMIT | TIF_GTC | 1479 | aux3 | BTC/ETH | sell | 5 | 50 | 0 | TYPE_LIMIT | TIF_GTC | 1480 1481 Then the opening auction period ends for market "BTC/ETH" 1482 And the trading mode should be "TRADING_MODE_CONTINUOUS" for the market "BTC/ETH" 1483 1484 When the parties place the following orders: 1485 | party | market id | side | volume | price | resulting trades | type | tif | 1486 | party1 | BTC/ETH | sell | 5 | 50 | 0 | TYPE_LIMIT | TIF_GTC | 1487 | party2 | BTC/ETH | buy | 5 | 50 | 1 | TYPE_LIMIT | TIF_GTC | 1488 1489 When time is updated to "2019-11-30T00:00:10Z" 1490 When the parties place the following orders: 1491 | party | market id | side | volume | price | resulting trades | type | tif | only | ra price trigger | fb price trigger | reference | ra expires in | ra expiry strategy | fb expires in | fb expiry strategy | ra size override setting | ra size override percentage | error | 1492 | party1 | BTC/ETH | buy | 10 | 0 | 0 | TYPE_MARKET | TIF_IOC | reduce | 75 | 25 | stop | 10 | EXPIRY_STRATEGY_SUBMIT | 15 | EXPIRY_STRATEGY_SUBMIT | POSITION | 0.5 | stop order size override is not supported for spot product | 1493 1494 1495 @SLABug 1496 Scenario: All stop orders for a specific party for a specific market can be cancelled by a single stop order cancellation. (0014-ORDT-156) 1497 1498 # setup accounts 1499 Given the parties deposit on asset's general account the following amount: 1500 | party | asset | amount | 1501 | party1 | BTC | 1000000 | 1502 | party2 | BTC | 1000000 | 1503 | aux | BTC | 1000000 | 1504 | aux2 | BTC | 1000000 | 1505 | lpprov | BTC | 900000000 | 1506 | party1 | ETH | 1000000 | 1507 | party2 | ETH | 1000000 | 1508 | aux | ETH | 1000000 | 1509 | aux2 | ETH | 1000000 | 1510 | lpprov | ETH | 900000000 | 1511 | party1 | USDT | 1000000 | 1512 | party2 | USDT | 1000000 | 1513 | aux | USDT | 1000000 | 1514 | aux2 | USDT | 1000000 | 1515 | lpprov | USDT | 900000000 | 1516 1517 When the parties submit the following liquidity provision: 1518 | id | party | market id | commitment amount | fee | lp type | 1519 | lp1 | lpprov | BTC/ETH | 900000 | 0.1 | submission | 1520 | lp1 | lpprov | BTC/ETH | 900000 | 0.1 | submission | 1521 | lp2 | lpprov | USDT/ETH | 900000 | 0.1 | submission | 1522 | lp2 | lpprov | USDT/ETH | 900000 | 0.1 | submission | 1523 And the parties place the following pegged iceberg orders: 1524 | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | 1525 | lpprov | BTC/ETH | 2 | 1 | buy | BID | 50 | 100 | 1526 | lpprov | BTC/ETH | 2 | 1 | sell | ASK | 50 | 100 | 1527 | lpprov | USDT/ETH | 2 | 1 | buy | BID | 50 | 100 | 1528 | lpprov | USDT/ETH | 2 | 1 | sell | ASK | 50 | 100 | 1529 1530 # place auxiliary orders so we always have best bid and best offer as to not trigger the liquidity auction 1531 When the parties place the following orders: 1532 | party | market id | side | volume | price | resulting trades | type | tif | 1533 | aux | BTC/ETH | buy | 1 | 1 | 0 | TYPE_LIMIT | TIF_GTC | 1534 | aux | BTC/ETH | sell | 1 | 10001 | 0 | TYPE_LIMIT | TIF_GTC | 1535 | aux2 | BTC/ETH | buy | 1 | 50 | 0 | TYPE_LIMIT | TIF_GTC | 1536 | aux | BTC/ETH | sell | 1 | 50 | 0 | TYPE_LIMIT | TIF_GTC | 1537 | aux | USDT/ETH | buy | 1 | 1 | 0 | TYPE_LIMIT | TIF_GTC | 1538 | aux | USDT/ETH | sell | 1 | 10001 | 0 | TYPE_LIMIT | TIF_GTC | 1539 | aux2 | USDT/ETH | buy | 1 | 50 | 0 | TYPE_LIMIT | TIF_GTC | 1540 | aux | USDT/ETH | sell | 1 | 50 | 0 | TYPE_LIMIT | TIF_GTC | 1541 1542 When the network moves ahead "2" blocks 1543 Then the trading mode should be "TRADING_MODE_CONTINUOUS" for the market "BTC/ETH" 1544 And the trading mode should be "TRADING_MODE_CONTINUOUS" for the market "USDT/ETH" 1545 1546 When the parties place the following orders: 1547 | party | market id | side | volume | price | resulting trades | type | tif | only | fb price trigger | error | reference | 1548 | party1 | BTC/ETH | sell | 10 | 60 | 0 | TYPE_LIMIT | TIF_GTC | | | | | 1549 | party1 | BTC/ETH | buy | 2 | 0 | 0 | TYPE_MARKET | TIF_GTC | reduce | 47 | | stop1 | 1550 | party1 | BTC/ETH | buy | 2 | 0 | 0 | TYPE_MARKET | TIF_GTC | reduce | 48 | | stop2 | 1551 | party1 | USDT/ETH | sell | 10 | 60 | 0 | TYPE_LIMIT | TIF_GTC | | | | | 1552 | party1 | USDT/ETH | buy | 2 | 0 | 0 | TYPE_MARKET | TIF_GTC | reduce | 49 | | stop3 | 1553 | party1 | USDT/ETH | buy | 2 | 0 | 0 | TYPE_MARKET | TIF_GTC | reduce | 49 | | stop4 | 1554 1555 Then the party "party1" cancels all their stop orders for the market "BTC/ETH" 1556 1557 Then the stop orders should have the following states 1558 | party | market id | status | reference | 1559 | party1 | BTC/ETH | STATUS_CANCELLED | stop1 | 1560 | party1 | BTC/ETH | STATUS_CANCELLED | stop2 | 1561 | party1 | USDT/ETH | STATUS_PENDING | stop3 | 1562 | party1 | USDT/ETH | STATUS_PENDING | stop4 | 1563 1564 Scenario: Stop orders once triggered can not be cancelled. For spot products (0014-ORDT-161) 1565 Given the parties deposit on asset's general account the following amount: 1566 | party | asset | amount | 1567 | party1 | BTC | 1000000 | 1568 | party2 | BTC | 1000000 | 1569 | party3 | BTC | 1000000 | 1570 | aux | BTC | 1000000 | 1571 | aux2 | BTC | 1000000 | 1572 | lpprov | BTC | 90000000 | 1573 | party1 | ETH | 1000000 | 1574 | party2 | ETH | 1000000 | 1575 | party3 | ETH | 1000000 | 1576 | aux | ETH | 1000000 | 1577 | aux2 | ETH | 1000000 | 1578 | lpprov | ETH | 90000000 | 1579 1580 When the parties submit the following liquidity provision: 1581 | id | party | market id | commitment amount | fee | lp type | 1582 | lp1 | lpprov | BTC/ETH | 900000 | 0.1 | submission | 1583 | lp1 | lpprov | BTC/ETH | 900000 | 0.1 | submission | 1584 And the parties place the following pegged iceberg orders: 1585 | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | 1586 | lpprov | BTC/ETH | 2 | 1 | buy | BID | 50 | 100 | 1587 | lpprov | BTC/ETH | 2 | 1 | sell | ASK | 50 | 100 | 1588 When the parties place the following orders: 1589 | party | market id | side | volume | price | resulting trades | type | tif | 1590 | aux | BTC/ETH | buy | 1 | 1 | 0 | TYPE_LIMIT | TIF_GTC | 1591 | aux | BTC/ETH | sell | 1 | 10001 | 0 | TYPE_LIMIT | TIF_GTC | 1592 | aux2 | BTC/ETH | buy | 1 | 50 | 0 | TYPE_LIMIT | TIF_GTC | 1593 | aux | BTC/ETH | sell | 1 | 50 | 0 | TYPE_LIMIT | TIF_GTC | 1594 1595 Then the opening auction period ends for market "BTC/ETH" 1596 And the trading mode should be "TRADING_MODE_CONTINUOUS" for the market "BTC/ETH" 1597 1598 # setup party1 position, open a 10 short position 1599 Given the parties place the following orders: 1600 | party | market id | side | volume | price | resulting trades | type | tif | 1601 | party1 | BTC/ETH | sell | 10 | 50 | 0 | TYPE_LIMIT | TIF_GTC | 1602 | party2 | BTC/ETH | buy | 10 | 50 | 1 | TYPE_LIMIT | TIF_GTC | 1603 # place an order to match with the limit order then check the stop is filled 1604 And the parties place the following orders: 1605 | party | market id | side | volume | price | resulting trades | type | tif | 1606 | party3 | BTC/ETH | sell | 10 | 80 | 0 | TYPE_LIMIT | TIF_GTC | 1607 # create party1 stop order 1608 And the parties place the following orders: 1609 | party | market id | side | volume | price | resulting trades | type | tif | only | ra price trigger | error | reference | 1610 | party1 | BTC/ETH | buy | 5 | 80 | 0 | TYPE_LIMIT | TIF_IOC | reduce | 75 | | stop1 | 1611 1612 # now we trade at 75, this will breach the trigger 1613 When the parties place the following orders: 1614 | party | market id | side | volume | price | resulting trades | type | tif | 1615 | party3 | BTC/ETH | buy | 10 | 75 | 0 | TYPE_LIMIT | TIF_GTC | 1616 | party2 | BTC/ETH | sell | 10 | 75 | 1 | TYPE_LIMIT | TIF_GTC | 1617 1618 # check that the order was triggered 1619 Then the stop orders should have the following states 1620 | party | market id | status | reference | 1621 | party1 | BTC/ETH | STATUS_TRIGGERED | stop1 | 1622 And the orders should have the following states: 1623 | party | market id | side | volume | remaining | price | status | reference | 1624 | party1 | BTC/ETH | buy | 5 | 0 | 80 | STATUS_FILLED | stop1 | 1625 1626 Then the parties cancel the following stop orders: 1627 | party | reference | error | 1628 | party1 | stop1 | stop order not found | 1629 1630 @SLABug 1631 Scenario: All stop orders for a specific party can be cancelled by a single stop order cancellation. (0014-ORDT-155) 1632 Given the parties deposit on asset's general account the following amount: 1633 | party | asset | amount | 1634 | party1 | BTC | 1000000 | 1635 | party2 | BTC | 1000000 | 1636 | aux | BTC | 1000000 | 1637 | aux2 | BTC | 1000000 | 1638 | lpprov | BTC | 900000000 | 1639 | party1 | ETH | 1000000 | 1640 | party2 | ETH | 1000000 | 1641 | aux | ETH | 1000000 | 1642 | aux2 | ETH | 1000000 | 1643 | lpprov | ETH | 900000000 | 1644 | party1 | USDT | 1000000 | 1645 | party2 | USDT | 1000000 | 1646 | aux | USDT | 1000000 | 1647 | aux2 | USDT | 1000000 | 1648 | lpprov | USDT | 900000000 | 1649 1650 When the parties submit the following liquidity provision: 1651 | id | party | market id | commitment amount | fee | lp type | 1652 | lp1 | lpprov | BTC/ETH | 900000 | 0.1 | submission | 1653 | lp1 | lpprov | BTC/ETH | 900000 | 0.1 | submission | 1654 | lp2 | lpprov | USDT/ETH | 900000 | 0.1 | submission | 1655 | lp2 | lpprov | USDT/ETH | 900000 | 0.1 | submission | 1656 And the parties place the following pegged iceberg orders: 1657 | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | 1658 | lpprov | BTC/ETH | 2 | 1 | buy | BID | 50 | 100 | 1659 | lpprov | BTC/ETH | 2 | 1 | sell | ASK | 50 | 100 | 1660 | lpprov | USDT/ETH | 2 | 1 | buy | BID | 50 | 100 | 1661 | lpprov | USDT/ETH | 2 | 1 | sell | ASK | 50 | 100 | 1662 1663 # place auxiliary orders so we always have best bid and best offer as to not trigger the liquidity auction 1664 When the parties place the following orders: 1665 | party | market id | side | volume | price | resulting trades | type | tif | 1666 | aux | BTC/ETH | buy | 1 | 1 | 0 | TYPE_LIMIT | TIF_GTC | 1667 | aux | BTC/ETH | sell | 1 | 10001 | 0 | TYPE_LIMIT | TIF_GTC | 1668 | aux2 | BTC/ETH | buy | 1 | 50 | 0 | TYPE_LIMIT | TIF_GTC | 1669 | aux | BTC/ETH | sell | 1 | 50 | 0 | TYPE_LIMIT | TIF_GTC | 1670 | aux | USDT/ETH | buy | 1 | 1 | 0 | TYPE_LIMIT | TIF_GTC | 1671 | aux | USDT/ETH | sell | 1 | 10001 | 0 | TYPE_LIMIT | TIF_GTC | 1672 | aux2 | USDT/ETH | buy | 1 | 50 | 0 | TYPE_LIMIT | TIF_GTC | 1673 | aux | USDT/ETH | sell | 1 | 50 | 0 | TYPE_LIMIT | TIF_GTC | 1674 1675 When the network moves ahead "2" blocks 1676 Then the trading mode should be "TRADING_MODE_CONTINUOUS" for the market "BTC/ETH" 1677 And the trading mode should be "TRADING_MODE_CONTINUOUS" for the market "USDT/ETH" 1678 1679 When the parties place the following orders: 1680 | party | market id | side | volume | price | resulting trades | type | tif | only | fb price trigger | error | reference | 1681 | party1 | BTC/ETH | sell | 10 | 60 | 0 | TYPE_LIMIT | TIF_GTC | | | | | 1682 | party1 | BTC/ETH | buy | 2 | 0 | 0 | TYPE_MARKET | TIF_GTC | reduce | 47 | | stop1 | 1683 | party1 | BTC/ETH | buy | 2 | 0 | 0 | TYPE_MARKET | TIF_GTC | reduce | 48 | | stop2 | 1684 | party1 | USDT/ETH | sell | 10 | 60 | 0 | TYPE_LIMIT | TIF_GTC | | | | | 1685 | party1 | USDT/ETH | buy | 2 | 0 | 0 | TYPE_MARKET | TIF_GTC | reduce | 49 | | stop3 | 1686 | party1 | USDT/ETH | buy | 2 | 0 | 0 | TYPE_MARKET | TIF_GTC | reduce | 49 | | stop4 | 1687 1688 Then the party "party1" cancels all their stop orders 1689 1690 Then the stop orders should have the following states 1691 | party | market id | status | reference | 1692 | party1 | BTC/ETH | STATUS_CANCELLED | stop1 | 1693 | party1 | BTC/ETH | STATUS_CANCELLED | stop2 | 1694 | party1 | USDT/ETH | STATUS_CANCELLED | stop3 | 1695 | party1 | USDT/ETH | STATUS_CANCELLED | stop4 |