code.vegaprotocol.io/vega@v0.79.0/core/integration/features/orders/stoporders.feature (about) 1 Feature: stop orders 2 3 Background: 4 Given the markets: 5 | id | quote name | asset | risk model | margin calculator | auction duration | fees | price monitoring | data source config | linear slippage factor | quadratic slippage factor | sla params | 6 | ETH/DEC19 | BTC | BTC | default-simple-risk-model-3 | default-margin-calculator | 1 | default-none | default-none | default-eth-for-future | 0.25 | 0 | default-futures | 7 | ETH/DEC20 | BTC | BTC | default-log-normal-risk-model | default-margin-calculator | 1 | default-none | default-basic | default-eth-for-future | 1e-3 | 0 | default-futures | 8 And the following network parameters are set: 9 | name | value | 10 | market.auction.minimumDuration | 1 | 11 | network.markPriceUpdateMaximumFrequency | 0s | 12 | limits.markets.maxPeggedOrders | 1500 | 13 | spam.protection.max.stopOrdersPerMarket | 5 | 14 15 Scenario: A stop order placed by a key with a zero position and no open orders will be rejected. (0014-ORDT-042) 16 # setup accounts 17 Given the parties deposit on asset's general account the following amount: 18 | party | asset | amount | 19 | party1 | BTC | 10000 | 20 | party2 | BTC | 10000 | 21 | aux | BTC | 100000 | 22 | aux2 | BTC | 100000 | 23 | lpprov | BTC | 90000000 | 24 25 When the parties submit the following liquidity provision: 26 | id | party | market id | commitment amount | fee | lp type | 27 | lp1 | lpprov | ETH/DEC19 | 90000000 | 0.1 | submission | 28 | lp1 | lpprov | ETH/DEC19 | 90000000 | 0.1 | submission | 29 And the parties place the following pegged iceberg orders: 30 | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | 31 | lpprov | ETH/DEC19 | 2 | 1 | buy | BID | 50 | 100 | 32 | lpprov | ETH/DEC19 | 2 | 1 | sell | ASK | 50 | 100 | 33 34 # place auxiliary orders so we always have best bid and best offer as to not trigger the liquidity auction 35 When the parties place the following orders: 36 | party | market id | side | volume | price | resulting trades | type | tif | 37 | aux | ETH/DEC19 | buy | 1 | 1 | 0 | TYPE_LIMIT | TIF_GTC | 38 | aux | ETH/DEC19 | sell | 1 | 10001 | 0 | TYPE_LIMIT | TIF_GTC | 39 | aux2 | ETH/DEC19 | buy | 1 | 50 | 0 | TYPE_LIMIT | TIF_GTC | 40 | aux | ETH/DEC19 | sell | 1 | 50 | 0 | TYPE_LIMIT | TIF_GTC | 41 42 Then the opening auction period ends for market "ETH/DEC19" 43 And the trading mode should be "TRADING_MODE_CONTINUOUS" for the market "ETH/DEC19" 44 45 When the parties place the following orders: 46 | party | market id | side | volume | price | resulting trades | type | tif | only | fb price trigger | error | 47 | party1 | ETH/DEC19 | buy | 1 | 0 | 0 | TYPE_MARKET | TIF_GTC | reduce | 47 | stop order submission not allowed without existing position | 48 49 Scenario: A stop order placed by a key with a zero position but open orders will be accepted. (0014-ORDT-043) 50 51 # setup accounts 52 Given the parties deposit on asset's general account the following amount: 53 | party | asset | amount | 54 | party1 | BTC | 10000 | 55 | party2 | BTC | 10000 | 56 | aux | BTC | 100000 | 57 | aux2 | BTC | 100000 | 58 | lpprov | BTC | 90000000 | 59 60 When the parties submit the following liquidity provision: 61 | id | party | market id | commitment amount | fee | lp type | 62 | lp1 | lpprov | ETH/DEC19 | 90000000 | 0.1 | submission | 63 | lp1 | lpprov | ETH/DEC19 | 90000000 | 0.1 | submission | 64 And the parties place the following pegged iceberg orders: 65 | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | 66 | lpprov | ETH/DEC19 | 2 | 1 | buy | BID | 50 | 100 | 67 | lpprov | ETH/DEC19 | 2 | 1 | sell | ASK | 50 | 100 | 68 69 # place auxiliary orders so we always have best bid and best offer as to not trigger the liquidity auction 70 When the parties place the following orders: 71 | party | market id | side | volume | price | resulting trades | type | tif | 72 | aux | ETH/DEC19 | buy | 1 | 1 | 0 | TYPE_LIMIT | TIF_GTC | 73 | aux | ETH/DEC19 | sell | 1 | 10001 | 0 | TYPE_LIMIT | TIF_GTC | 74 | aux2 | ETH/DEC19 | buy | 1 | 50 | 0 | TYPE_LIMIT | TIF_GTC | 75 | aux | ETH/DEC19 | sell | 1 | 50 | 0 | TYPE_LIMIT | TIF_GTC | 76 77 Then the opening auction period ends for market "ETH/DEC19" 78 And the trading mode should be "TRADING_MODE_CONTINUOUS" for the market "ETH/DEC19" 79 80 When the parties place the following orders: 81 | party | market id | side | volume | price | resulting trades | type | tif | only | fb price trigger | error | 82 | party1 | ETH/DEC19 | sell | 10 | 60 | 0 | TYPE_LIMIT | TIF_GTC | | | | 83 | party1 | ETH/DEC19 | buy | 10 | 0 | 0 | TYPE_MARKET | TIF_GTC | reduce | 47 | | 84 85 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-044) 86 87 # setup accounts 88 Given the parties deposit on asset's general account the following amount: 89 | party | asset | amount | 90 | party1 | BTC | 10000 | 91 | party2 | BTC | 10000 | 92 | aux | BTC | 100000 | 93 | aux2 | BTC | 100000 | 94 | lpprov | BTC | 90000000 | 95 96 When the parties submit the following liquidity provision: 97 | id | party | market id | commitment amount | fee | lp type | 98 | lp1 | lpprov | ETH/DEC19 | 90000000 | 0.1 | submission | 99 | lp1 | lpprov | ETH/DEC19 | 90000000 | 0.1 | submission | 100 And the parties place the following pegged iceberg orders: 101 | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | 102 | lpprov | ETH/DEC19 | 2 | 1 | buy | BID | 50 | 100 | 103 | lpprov | ETH/DEC19 | 2 | 1 | sell | ASK | 50 | 100 | 104 105 # place auxiliary orders so we always have best bid and best offer as to not trigger the liquidity auction 106 When the parties place the following orders: 107 | party | market id | side | volume | price | resulting trades | type | tif | 108 | aux | ETH/DEC19 | buy | 1 | 1 | 0 | TYPE_LIMIT | TIF_GTC | 109 | aux | ETH/DEC19 | sell | 1 | 10001 | 0 | TYPE_LIMIT | TIF_GTC | 110 | aux2 | ETH/DEC19 | buy | 1 | 50 | 0 | TYPE_LIMIT | TIF_GTC | 111 | aux | ETH/DEC19 | sell | 1 | 50 | 0 | TYPE_LIMIT | TIF_GTC | 112 113 Then the opening auction period ends for market "ETH/DEC19" 114 And the trading mode should be "TRADING_MODE_CONTINUOUS" for the market "ETH/DEC19" 115 116 When the parties place the following orders: 117 | party | market id | side | volume | price | resulting trades | type | tif | only | fb price trigger | error | 118 | party1 | ETH/DEC19 | sell | 10 | 60 | 0 | TYPE_LIMIT | TIF_GTC | | | | 119 | party1 | ETH/DEC19 | buy | 10 | 0 | 0 | TYPE_MARKET | TIF_GTC | reduce | 47 | | 120 | party1 | ETH/DEC19 | buy | 10 | 0 | 0 | TYPE_MARKET | TIF_GTC | reduce | 47 | | 121 | party1 | ETH/DEC19 | buy | 10 | 0 | 0 | TYPE_MARKET | TIF_GTC | reduce | 47 | | 122 | party1 | ETH/DEC19 | buy | 10 | 0 | 0 | TYPE_MARKET | TIF_GTC | reduce | 47 | | 123 | party1 | ETH/DEC19 | buy | 10 | 0 | 0 | TYPE_MARKET | TIF_GTC | reduce | 47 | | 124 # this next one goes over the top 125 | party1 | ETH/DEC19 | buy | 10 | 0 | 0 | TYPE_MARKET | TIF_GTC | reduce | 47 | max stop orders per party reached | 126 127 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-045) 128 129 # setup accounts 130 Given the parties deposit on asset's general account the following amount: 131 | party | asset | amount | 132 | party1 | BTC | 1000000 | 133 | party2 | BTC | 1000000 | 134 | party3 | BTC | 1000000 | 135 | aux | BTC | 1000000 | 136 | aux2 | BTC | 1000000 | 137 | lpprov | BTC | 90000000 | 138 139 When the parties submit the following liquidity provision: 140 | id | party | market id | commitment amount | fee | lp type | 141 | lp1 | lpprov | ETH/DEC19 | 900000 | 0.1 | submission | 142 | lp1 | lpprov | ETH/DEC19 | 900000 | 0.1 | submission | 143 And the parties place the following pegged iceberg orders: 144 | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | 145 | lpprov | ETH/DEC19 | 2 | 1 | buy | BID | 50 | 100 | 146 | lpprov | ETH/DEC19 | 2 | 1 | sell | ASK | 50 | 100 | 147 # place auxiliary orders so we always have best bid and best offer as to not trigger the liquidity auction 148 When the parties place the following orders: 149 | party | market id | side | volume | price | resulting trades | type | tif | 150 | aux | ETH/DEC19 | buy | 1 | 1 | 0 | TYPE_LIMIT | TIF_GTC | 151 | aux | ETH/DEC19 | sell | 1 | 10001 | 0 | TYPE_LIMIT | TIF_GTC | 152 | aux2 | ETH/DEC19 | buy | 1 | 50 | 0 | TYPE_LIMIT | TIF_GTC | 153 | aux | ETH/DEC19 | sell | 1 | 50 | 0 | TYPE_LIMIT | TIF_GTC | 154 155 Then the opening auction period ends for market "ETH/DEC19" 156 And the trading mode should be "TRADING_MODE_CONTINUOUS" for the market "ETH/DEC19" 157 158 # setup party1 position, open a 10 short position 159 Given the parties place the following orders: 160 | party | market id | side | volume | price | resulting trades | type | tif | 161 | party1 | ETH/DEC19 | sell | 10 | 50 | 0 | TYPE_LIMIT | TIF_GTC | 162 | party2 | ETH/DEC19 | buy | 10 | 50 | 1 | TYPE_LIMIT | TIF_GTC | 163 # place an order to match with the limit order then check the stop is filled 164 And the parties place the following orders: 165 | party | market id | side | volume | price | resulting trades | type | tif | 166 | party3 | ETH/DEC19 | sell | 10 | 80 | 0 | TYPE_LIMIT | TIF_GTC | 167 # create party1 stop order 168 And the parties place the following orders: 169 | party | market id | side | volume | price | resulting trades | type | tif | only | ra price trigger | error | reference | 170 | party1 | ETH/DEC19 | buy | 5 | 80 | 0 | TYPE_LIMIT | TIF_IOC | reduce | 75 | | stop1 | 171 172 # now we trade at 75, this will breach the trigger 173 When the parties place the following orders: 174 | party | market id | side | volume | price | resulting trades | type | tif | 175 | party3 | ETH/DEC19 | buy | 10 | 75 | 0 | TYPE_LIMIT | TIF_GTC | 176 | party2 | ETH/DEC19 | sell | 10 | 75 | 1 | TYPE_LIMIT | TIF_GTC | 177 178 # check that the order was triggered 179 Then the stop orders should have the following states 180 | party | market id | status | reference | 181 | party1 | ETH/DEC19 | STATUS_TRIGGERED | stop1 | 182 And the orders should have the following states: 183 | party | market id | side | volume | remaining | price | status | reference | 184 | party1 | ETH/DEC19 | buy | 5 | 0 | 80 | STATUS_FILLED | stop1 | 185 186 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-047) (0014-ORDT-046) 187 188 # setup accounts 189 Given the parties deposit on asset's general account the following amount: 190 | party | asset | amount | 191 | party1 | BTC | 10000 | 192 | party2 | BTC | 10000 | 193 | party3 | BTC | 10000 | 194 | aux | BTC | 100000 | 195 | aux2 | BTC | 100000 | 196 | lpprov | BTC | 90000000 | 197 198 When the parties submit the following liquidity provision: 199 | id | party | market id | commitment amount | fee | lp type | 200 | lp1 | lpprov | ETH/DEC19 | 90000000 | 0.1 | submission | 201 | lp1 | lpprov | ETH/DEC19 | 90000000 | 0.1 | submission | 202 And the parties place the following pegged iceberg orders: 203 | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | 204 | lpprov | ETH/DEC19 | 2 | 1 | buy | BID | 50 | 100 | 205 | lpprov | ETH/DEC19 | 2 | 1 | sell | ASK | 50 | 100 | 206 # place auxiliary orders so we always have best bid and best offer as to not trigger the liquidity auction 207 When the parties place the following orders: 208 | party | market id | side | volume | price | resulting trades | type | tif | 209 | aux | ETH/DEC19 | buy | 1 | 1 | 0 | TYPE_LIMIT | TIF_GTC | 210 | aux | ETH/DEC19 | sell | 1 | 10001 | 0 | TYPE_LIMIT | TIF_GTC | 211 | aux2 | ETH/DEC19 | buy | 5 | 50 | 0 | TYPE_LIMIT | TIF_GTC | 212 | aux | ETH/DEC19 | sell | 5 | 50 | 0 | TYPE_LIMIT | TIF_GTC | 213 214 Then the opening auction period ends for market "ETH/DEC19" 215 And the trading mode should be "TRADING_MODE_CONTINUOUS" for the market "ETH/DEC19" 216 217 # setup party1 position, open a 10 short position 218 When the parties place the following orders: 219 | party | market id | side | volume | price | resulting trades | type | tif | 220 | party1 | ETH/DEC19 | sell | 10 | 50 | 0 | TYPE_LIMIT | TIF_GTC | 221 | party2 | ETH/DEC19 | buy | 10 | 50 | 1 | TYPE_LIMIT | TIF_GTC | 222 223 # create party1 stop order 224 When the parties place the following orders: 225 | party | market id | side | volume | price | resulting trades | type | tif | only | ra price trigger | error | reference | 226 | party1 | ETH/DEC19 | buy | 10 | 0 | 0 | TYPE_MARKET | TIF_IOC | reduce | 75 | | stop1 | 227 228 # volume for the stop trade 229 When the parties place the following orders: 230 | party | market id | side | volume | price | resulting trades | type | tif | 231 | party3 | ETH/DEC19 | sell | 20 | 80 | 0 | TYPE_LIMIT | TIF_GTC | 232 233 234 # now we trade at 75, this will breach the trigger 235 When the parties place the following orders: 236 | party | market id | side | volume | price | resulting trades | type | tif | 237 | party3 | ETH/DEC19 | buy | 10 | 75 | 0 | TYPE_LIMIT | TIF_GTC | 238 | party2 | ETH/DEC19 | sell | 10 | 75 | 1 | TYPE_LIMIT | TIF_GTC | 239 240 # check that the order got submitted 241 Then the orders should have the following states: 242 | party | market id | side | volume | remaining | price | status | reference | 243 | party1 | ETH/DEC19 | buy | 10 | 0 | 0 | STATUS_FILLED | stop1 | 244 245 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-048) 246 247 # setup accounts 248 Given the parties deposit on asset's general account the following amount: 249 | party | asset | amount | 250 | party1 | BTC | 10000 | 251 | party2 | BTC | 10000 | 252 | party3 | BTC | 10000 | 253 | aux | BTC | 100000 | 254 | aux2 | BTC | 100000 | 255 | lpprov | BTC | 90000000 | 256 257 When the parties submit the following liquidity provision: 258 | id | party | market id | commitment amount | fee | lp type | 259 | lp1 | lpprov | ETH/DEC19 | 90000000 | 0.1 | submission | 260 | lp1 | lpprov | ETH/DEC19 | 90000000 | 0.1 | submission | 261 And the parties place the following pegged iceberg orders: 262 | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | 263 | lpprov | ETH/DEC19 | 2 | 1 | buy | BID | 50 | 100 | 264 | lpprov | ETH/DEC19 | 2 | 1 | sell | ASK | 50 | 100 | 265 # place auxiliary orders so we always have best bid and best offer as to not trigger the liquidity auction 266 When the parties place the following orders: 267 | party | market id | side | volume | price | resulting trades | type | tif | 268 | aux | ETH/DEC19 | buy | 1 | 1 | 0 | TYPE_LIMIT | TIF_GTC | 269 | aux | ETH/DEC19 | sell | 1 | 10001 | 0 | TYPE_LIMIT | TIF_GTC | 270 | aux2 | ETH/DEC19 | buy | 5 | 50 | 0 | TYPE_LIMIT | TIF_GTC | 271 | aux | ETH/DEC19 | sell | 5 | 50 | 0 | TYPE_LIMIT | TIF_GTC | 272 273 Then the opening auction period ends for market "ETH/DEC19" 274 And the trading mode should be "TRADING_MODE_CONTINUOUS" for the market "ETH/DEC19" 275 276 # setup party1 position, open a 10 long position 277 When the parties place the following orders: 278 | party | market id | side | volume | price | resulting trades | type | tif | 279 | party1 | ETH/DEC19 | buy | 10 | 50 | 0 | TYPE_LIMIT | TIF_GTC | 280 | party2 | ETH/DEC19 | sell | 10 | 50 | 1 | TYPE_LIMIT | TIF_GTC | 281 282 # volume for the stop trade 283 When the parties place the following orders: 284 | party | market id | side | volume | price | resulting trades | type | tif | 285 | party3 | ETH/DEC19 | buy | 10 | 50 | 0 | TYPE_LIMIT | TIF_GTC | 286 287 288 # create party1 stop order, results in a trade 289 When the parties place the following orders: 290 | party | market id | side | volume | price | resulting trades | type | tif | only | ra price trigger | error | reference | 291 | party1 | ETH/DEC19 | sell | 10 | 0 | 1 | TYPE_MARKET | TIF_IOC | reduce | 25 | | stop1 | 292 293 294 # check that the order got submitted 295 Then the orders should have the following states: 296 | party | market id | side | volume | remaining | price | status | reference | 297 | party1 | ETH/DEC19 | sell | 10 | 0 | 0 | STATUS_FILLED | stop1 | 298 299 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-049) 300 301 # setup accounts 302 Given the parties deposit on asset's general account the following amount: 303 | party | asset | amount | 304 | party1 | BTC | 10000 | 305 | party2 | BTC | 10000 | 306 | party3 | BTC | 10000 | 307 | aux | BTC | 100000 | 308 | aux2 | BTC | 100000 | 309 | lpprov | BTC | 90000000 | 310 311 When the parties submit the following liquidity provision: 312 | id | party | market id | commitment amount | fee | lp type | 313 | lp1 | lpprov | ETH/DEC19 | 90000000 | 0.1 | submission | 314 | lp1 | lpprov | ETH/DEC19 | 90000000 | 0.1 | submission | 315 And the parties place the following pegged iceberg orders: 316 | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | 317 | lpprov | ETH/DEC19 | 2 | 1 | buy | BID | 50 | 100 | 318 | lpprov | ETH/DEC19 | 2 | 1 | sell | ASK | 50 | 100 | 319 # place auxiliary orders so we always have best bid and best offer as to not trigger the liquidity auction 320 When the parties place the following orders: 321 | party | market id | side | volume | price | resulting trades | type | tif | 322 | aux | ETH/DEC19 | buy | 1 | 1 | 0 | TYPE_LIMIT | TIF_GTC | 323 | aux | ETH/DEC19 | sell | 1 | 10001 | 0 | TYPE_LIMIT | TIF_GTC | 324 | aux2 | ETH/DEC19 | buy | 5 | 50 | 0 | TYPE_LIMIT | TIF_GTC | 325 | aux | ETH/DEC19 | sell | 5 | 50 | 0 | TYPE_LIMIT | TIF_GTC | 326 327 Then the opening auction period ends for market "ETH/DEC19" 328 And the trading mode should be "TRADING_MODE_CONTINUOUS" for the market "ETH/DEC19" 329 330 # setup party1 position, open a 10 short position 331 When the parties place the following orders: 332 | party | market id | side | volume | price | resulting trades | type | tif | 333 | party1 | ETH/DEC19 | buy | 10 | 50 | 0 | TYPE_LIMIT | TIF_GTC | 334 | party2 | ETH/DEC19 | sell | 10 | 50 | 1 | TYPE_LIMIT | TIF_GTC | 335 336 337 # create party1 stop order, results in a trade 338 When the parties place the following orders: 339 | party | market id | side | volume | price | resulting trades | type | tif | only | fb price trigger | error | reference | 340 | party1 | ETH/DEC19 | sell | 10 | 0 | 0 | TYPE_MARKET | TIF_IOC | reduce | 25 | | stop1 | 341 342 # volume for the stop trade 343 When the parties place the following orders: 344 | party | market id | side | volume | price | resulting trades | type | tif | 345 | party3 | ETH/DEC19 | buy | 10 | 20 | 0 | TYPE_LIMIT | TIF_GTC | 346 347 # now we trade at 75, this will breach the trigger 348 When the parties place the following orders: 349 | party | market id | side | volume | price | resulting trades | type | tif | 350 | party3 | ETH/DEC19 | sell | 10 | 25 | 0 | TYPE_LIMIT | TIF_GTC | 351 | party2 | ETH/DEC19 | buy | 10 | 25 | 1 | TYPE_LIMIT | TIF_GTC | 352 353 # check that the order got submitted 354 Then the orders should have the following states: 355 | party | market id | side | volume | remaining | price | status | reference | 356 | party1 | ETH/DEC19 | sell | 10 | 0 | 0 | STATUS_FILLED | stop1 | 357 358 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-050) 359 360 # setup accounts 361 Given the parties deposit on asset's general account the following amount: 362 | party | asset | amount | 363 | party1 | BTC | 10000 | 364 | party2 | BTC | 10000 | 365 | party3 | BTC | 10000 | 366 | aux | BTC | 100000 | 367 | aux2 | BTC | 100000 | 368 | lpprov | BTC | 90000000 | 369 370 When the parties submit the following liquidity provision: 371 | id | party | market id | commitment amount | fee | lp type | 372 | lp1 | lpprov | ETH/DEC19 | 90000000 | 0.1 | submission | 373 | lp1 | lpprov | ETH/DEC19 | 90000000 | 0.1 | submission | 374 And the parties place the following pegged iceberg orders: 375 | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | 376 | lpprov | ETH/DEC19 | 2 | 1 | buy | BID | 50 | 100 | 377 | lpprov | ETH/DEC19 | 2 | 1 | sell | ASK | 50 | 100 | 378 379 # place auxiliary orders so we always have best bid and best offer as to not trigger the liquidity auction 380 When the parties place the following orders: 381 | party | market id | side | volume | price | resulting trades | type | tif | 382 | aux | ETH/DEC19 | buy | 5 | 1 | 0 | TYPE_LIMIT | TIF_GTC | 383 | aux | ETH/DEC19 | sell | 5 | 10001 | 0 | TYPE_LIMIT | TIF_GTC | 384 | aux2 | ETH/DEC19 | buy | 5 | 50 | 0 | TYPE_LIMIT | TIF_GTC | 385 | aux | ETH/DEC19 | sell | 5 | 50 | 0 | TYPE_LIMIT | TIF_GTC | 386 387 Then the opening auction period ends for market "ETH/DEC19" 388 And the trading mode should be "TRADING_MODE_CONTINUOUS" for the market "ETH/DEC19" 389 390 # setup party1 position, open a 10 long position 391 When the parties place the following orders: 392 | party | market id | side | volume | price | resulting trades | type | tif | 393 | party1 | ETH/DEC19 | sell | 10 | 50 | 0 | TYPE_LIMIT | TIF_GTC | 394 | party2 | ETH/DEC19 | buy | 10 | 50 | 1 | TYPE_LIMIT | TIF_GTC | 395 396 # volume for the stop trade 397 When the parties place the following orders: 398 | party | market id | side | volume | price | resulting trades | type | tif | 399 | party3 | ETH/DEC19 | sell | 10 | 50 | 0 | TYPE_LIMIT | TIF_GTC | 400 401 402 # create party1 stop order, results in a trade 403 When the parties place the following orders: 404 | party | market id | side | volume | price | resulting trades | type | tif | only | fb price trigger | error | reference | 405 | party1 | ETH/DEC19 | buy | 10 | 0 | 1 | TYPE_MARKET | TIF_IOC | reduce | 75 | | stop1 | 406 407 408 # check that the order got submitted 409 Then the orders should have the following states: 410 | party | market id | side | volume | remaining | price | status | reference | 411 | party1 | ETH/DEC19 | buy | 10 | 0 | 0 | STATUS_FILLED | stop1 | 412 413 @Liquidation 414 Scenario: With a last traded price at 50, a stop order placed with any trigger price which does not trigger immediately will trigger as soon as a trade occurs at a trigger price, and will not wait until the next mark price update to trigger. (0014-ORDT-051) 415 # setup network parameters 416 Given the following network parameters are set: 417 | name | value | 418 | network.markPriceUpdateMaximumFrequency | 1s | 419 And the average block duration is "1" 420 421 # setup accounts 422 Given the parties deposit on asset's general account the following amount: 423 | party | asset | amount | 424 | party1 | BTC | 10000 | 425 | party2 | BTC | 10000 | 426 | party3 | BTC | 10000 | 427 | aux | BTC | 100000 | 428 | aux2 | BTC | 100000 | 429 | lpprov | BTC | 90000000 | 430 431 When the parties submit the following liquidity provision: 432 | id | party | market id | commitment amount | fee | lp type | 433 | lp1 | lpprov | ETH/DEC19 | 90000 | 0.1 | submission | 434 | lp1 | lpprov | ETH/DEC19 | 90000 | 0.1 | submission | 435 And the parties place the following pegged iceberg orders: 436 | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | 437 | lpprov | ETH/DEC19 | 2 | 1 | buy | BID | 50 | 100 | 438 | lpprov | ETH/DEC19 | 2 | 1 | sell | ASK | 50 | 100 | 439 440 # place auxiliary orders so we always have best bid and best offer as to not trigger the liquidity auction 441 When the parties place the following orders: 442 | party | market id | side | volume | price | resulting trades | type | tif | 443 | aux | ETH/DEC19 | buy | 1 | 1 | 0 | TYPE_LIMIT | TIF_GTC | 444 | aux | ETH/DEC19 | sell | 1 | 10001 | 0 | TYPE_LIMIT | TIF_GTC | 445 | aux2 | ETH/DEC19 | buy | 5 | 50 | 0 | TYPE_LIMIT | TIF_GTC | 446 | aux | ETH/DEC19 | sell | 5 | 50 | 0 | TYPE_LIMIT | TIF_GTC | 447 448 Then the opening auction period ends for market "ETH/DEC19" 449 And the trading mode should be "TRADING_MODE_CONTINUOUS" for the market "ETH/DEC19" 450 451 # setup party1 position, open a 10 long position 452 Given the parties place the following orders: 453 | party | market id | side | volume | price | resulting trades | type | tif | 454 | party1 | ETH/DEC19 | buy | 10 | 50 | 0 | TYPE_LIMIT | TIF_GTC | 455 | party2 | ETH/DEC19 | sell | 10 | 50 | 1 | TYPE_LIMIT | TIF_GTC | 456 457 # place volume to trade with stop order 458 Given the parties place the following orders: 459 | party | market id | side | volume | price | resulting trades | type | tif | 460 | party3 | ETH/DEC19 | buy | 10 | 20 | 0 | TYPE_LIMIT | TIF_GTC | 461 # place stop order 462 And the parties place the following orders: 463 | party | market id | side | volume | price | resulting trades | type | tif | only | fb price trigger | error | reference | 464 | party1 | ETH/DEC19 | sell | 10 | 0 | 0 | TYPE_MARKET | TIF_IOC | reduce | 25 | | stop1 | 465 # trigger stop order 466 When the parties place the following orders: 467 | party | market id | side | volume | price | resulting trades | type | tif | 468 | party2 | ETH/DEC19 | buy | 10 | 24 | 0 | TYPE_LIMIT | TIF_GTC | 469 | party3 | ETH/DEC19 | sell | 10 | 24 | 1 | TYPE_LIMIT | TIF_GTC | 470 # check that the stop order was triggered despite the mark price not updating 471 Then the mark price should be "50" for the market "ETH/DEC19" 472 Then the orders should have the following states: 473 | party | market id | side | volume | remaining | price | status | reference | 474 | party1 | ETH/DEC19 | sell | 10 | 0 | 0 | STATUS_FILLED | stop1 | 475 476 # check the mark price is later updated correctly 477 When the network moves ahead "2" blocks 478 Then the mark price should be "20" for the market "ETH/DEC19" 479 480 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-052) 481 482 # setup accounts 483 Given time is updated to "2019-11-30T00:00:00Z" 484 Given the parties deposit on asset's general account the following amount: 485 | party | asset | amount | 486 | party1 | BTC | 10000 | 487 | party2 | BTC | 10000 | 488 | party3 | BTC | 10000 | 489 | aux | BTC | 100000 | 490 | aux2 | BTC | 100000 | 491 | lpprov | BTC | 90000000 | 492 493 When the parties submit the following liquidity provision: 494 | id | party | market id | commitment amount | fee | lp type | 495 | lp1 | lpprov | ETH/DEC19 | 90000000 | 0.1 | submission | 496 | lp1 | lpprov | ETH/DEC19 | 90000000 | 0.1 | submission | 497 And the parties place the following pegged iceberg orders: 498 | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | 499 | lpprov | ETH/DEC19 | 2 | 1 | buy | BID | 50 | 100 | 500 | lpprov | ETH/DEC19 | 2 | 1 | sell | ASK | 50 | 100 | 501 502 # place auxiliary orders so we always have best bid and best offer as to not trigger the liquidity auction 503 When the parties place the following orders: 504 | party | market id | side | volume | price | resulting trades | type | tif | 505 | aux | ETH/DEC19 | buy | 1 | 1 | 0 | TYPE_LIMIT | TIF_GTC | 506 | aux | ETH/DEC19 | sell | 1 | 10001 | 0 | TYPE_LIMIT | TIF_GTC | 507 | aux2 | ETH/DEC19 | buy | 5 | 50 | 0 | TYPE_LIMIT | TIF_GTC | 508 | aux | ETH/DEC19 | sell | 5 | 50 | 0 | TYPE_LIMIT | TIF_GTC | 509 510 Then the opening auction period ends for market "ETH/DEC19" 511 And the trading mode should be "TRADING_MODE_CONTINUOUS" for the market "ETH/DEC19" 512 513 # setup party1 position, open a 10 long position 514 When the parties place the following orders: 515 | party | market id | side | volume | price | resulting trades | type | tif | 516 | party1 | ETH/DEC19 | sell | 10 | 50 | 0 | TYPE_LIMIT | TIF_GTC | 517 | party2 | ETH/DEC19 | buy | 10 | 50 | 1 | TYPE_LIMIT | TIF_GTC | 518 519 # volume for the stop trade 520 When the parties place the following orders: 521 | party | market id | side | volume | price | resulting trades | type | tif | 522 | party3 | ETH/DEC19 | sell | 10 | 50 | 0 | TYPE_LIMIT | TIF_GTC | 523 524 When time is updated to "2019-11-30T00:00:10Z" 525 # create party1 stop order, no trade resulting, expires in 10 secs 526 When the parties place the following orders: 527 | party | market id | side | volume | price | resulting trades | type | tif | only | ra price trigger | error | reference | ra expires in | ra expiry strategy | 528 | party1 | ETH/DEC19 | buy | 10 | 0 | 0 | TYPE_MARKET | TIF_IOC | reduce | 75 | | stop1 | 10 | EXPIRY_STRATEGY_CANCELS | 529 530 # add 20 secs, should expire 531 When time is updated to "2019-11-30T00:00:30Z" 532 533 Then the stop orders should have the following states 534 | party | market id | status | reference | 535 | party1 | ETH/DEC19 | STATUS_EXPIRED | stop1 | 536 537 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-053) 538 539 # setup accounts 540 Given time is updated to "2019-11-30T00:00:00Z" 541 Given the parties deposit on asset's general account the following amount: 542 | party | asset | amount | 543 | party1 | BTC | 10000 | 544 | party2 | BTC | 10000 | 545 | party3 | BTC | 10000 | 546 | aux | BTC | 100000 | 547 | aux2 | BTC | 100000 | 548 | aux3 | BTC | 100000 | 549 | lpprov | BTC | 90000000 | 550 551 When the parties submit the following liquidity provision: 552 | id | party | market id | commitment amount | fee | lp type | 553 | lp1 | lpprov | ETH/DEC19 | 90000000 | 0.1 | submission | 554 | lp1 | lpprov | ETH/DEC19 | 90000000 | 0.1 | submission | 555 And the parties place the following pegged iceberg orders: 556 | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | 557 | lpprov | ETH/DEC19 | 2 | 1 | buy | BID | 50 | 100 | 558 | lpprov | ETH/DEC19 | 2 | 1 | sell | ASK | 50 | 100 | 559 560 # place auxiliary orders so we always have best bid and best offer as to not trigger the liquidity auction 561 When the parties place the following orders: 562 | party | market id | side | volume | price | resulting trades | type | tif | 563 | aux | ETH/DEC19 | buy | 1 | 1 | 0 | TYPE_LIMIT | TIF_GTC | 564 | aux | ETH/DEC19 | sell | 1 | 10001 | 0 | TYPE_LIMIT | TIF_GTC | 565 | aux2 | ETH/DEC19 | buy | 5 | 50 | 0 | TYPE_LIMIT | TIF_GTC | 566 | aux3 | ETH/DEC19 | sell | 5 | 50 | 0 | TYPE_LIMIT | TIF_GTC | 567 568 Then the opening auction period ends for market "ETH/DEC19" 569 And the trading mode should be "TRADING_MODE_CONTINUOUS" for the market "ETH/DEC19" 570 571 # setup party1 position, open a 10 long position 572 When the parties place the following orders: 573 | party | market id | side | volume | price | resulting trades | type | tif | 574 | party1 | ETH/DEC19 | sell | 10 | 50 | 0 | TYPE_LIMIT | TIF_GTC | 575 | party2 | ETH/DEC19 | buy | 10 | 50 | 1 | TYPE_LIMIT | TIF_GTC | 576 577 # volume for the stop trade 578 When the parties place the following orders: 579 | party | market id | side | volume | price | resulting trades | type | tif | 580 | party3 | ETH/DEC19 | sell | 10 | 50 | 0 | TYPE_LIMIT | TIF_GTC | 581 582 583 When time is updated to "2019-11-30T00:00:10Z" 584 # create party1 stop order, no trade resulting, expires in 10 secs 585 When the parties place the following orders: 586 | party | market id | side | volume | price | resulting trades | type | tif | only | ra price trigger | error | reference | ra expires in | ra expiry strategy | 587 | party1 | ETH/DEC19 | buy | 10 | 0 | 0 | TYPE_MARKET | TIF_IOC | reduce | 75 | | stop1 | 10 | EXPIRY_STRATEGY_SUBMIT | 588 589 # add 20 secs, should expire 590 When time is updated to "2019-11-30T00:00:30Z" 591 592 Then the stop orders should have the following states 593 | party | market id | status | reference | 594 | party1 | ETH/DEC19 | STATUS_EXPIRED | stop1 | 595 596 # check that the order got submitted 597 Then the orders should have the following states: 598 | party | market id | side | volume | remaining | price | status | reference | 599 | party1 | ETH/DEC19 | buy | 10 | 0 | 0 | STATUS_FILLED | stop1 | 600 601 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-054) (0014-ORDT-041) 602 603 # setup accounts 604 Given time is updated to "2019-11-30T00:00:00Z" 605 Given the parties deposit on asset's general account the following amount: 606 | party | asset | amount | 607 | party1 | BTC | 1000000 | 608 | party2 | BTC | 1000000 | 609 | party3 | BTC | 1000000 | 610 | aux | BTC | 1000000 | 611 | aux2 | BTC | 1000000 | 612 | aux3 | BTC | 1000000 | 613 | lpprov | BTC | 90000000 | 614 615 When the parties submit the following liquidity provision: 616 | id | party | market id | commitment amount | fee | lp type | 617 | lp1 | lpprov | ETH/DEC19 | 900000 | 0.1 | submission | 618 | lp1 | lpprov | ETH/DEC19 | 900000 | 0.1 | submission | 619 And the parties place the following pegged iceberg orders: 620 | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | 621 | lpprov | ETH/DEC19 | 2 | 1 | buy | BID | 50 | 100 | 622 | lpprov | ETH/DEC19 | 2 | 1 | sell | ASK | 50 | 100 | 623 624 # place auxiliary orders so we always have best bid and best offer as to not trigger the liquidity auction 625 When the parties place the following orders: 626 | party | market id | side | volume | price | resulting trades | type | tif | 627 | aux | ETH/DEC19 | buy | 1 | 1 | 0 | TYPE_LIMIT | TIF_GTC | 628 | aux | ETH/DEC19 | sell | 1 | 10001 | 0 | TYPE_LIMIT | TIF_GTC | 629 | aux2 | ETH/DEC19 | buy | 5 | 50 | 0 | TYPE_LIMIT | TIF_GTC | 630 | aux3 | ETH/DEC19 | sell | 5 | 50 | 0 | TYPE_LIMIT | TIF_GTC | 631 632 Then the opening auction period ends for market "ETH/DEC19" 633 And the trading mode should be "TRADING_MODE_CONTINUOUS" for the market "ETH/DEC19" 634 635 Given time is updated to "2019-11-30T00:00:10Z" 636 # setup party1 position, open a 10 long position 637 And the parties place the following orders: 638 | party | market id | side | volume | price | resulting trades | type | tif | 639 | party1 | ETH/DEC19 | buy | 20 | 50 | 0 | TYPE_LIMIT | TIF_GTC | 640 | party2 | ETH/DEC19 | sell | 20 | 50 | 1 | TYPE_LIMIT | TIF_GTC | 641 # volume for the stop trade 642 And the parties place the following orders: 643 | party | market id | side | volume | price | resulting trades | type | tif | 644 | party3 | ETH/DEC19 | buy | 20 | 20 | 0 | TYPE_LIMIT | TIF_GTC | 645 # create party1 stop order, no trade resulting, expires in 10 secs 646 And the parties place the following orders: 647 | party | market id | side | volume | price | resulting trades | type | tif | only | fb price trigger | error | reference | fb expires in | fb expiry strategy | 648 | party1 | ETH/DEC19 | sell | 10 | 0 | 0 | TYPE_MARKET | TIF_IOC | reduce | 25 | | stop1 | 10 | EXPIRY_STRATEGY_SUBMIT | 649 650 # trigger the stop order 651 When the parties place the following orders: 652 | party | market id | side | volume | price | resulting trades | type | tif | 653 | party2 | ETH/DEC19 | buy | 1 | 24 | 0 | TYPE_LIMIT | TIF_GTC | 654 | party3 | ETH/DEC19 | sell | 1 | 24 | 1 | TYPE_LIMIT | TIF_GTC | 655 # check the stop order is filled 656 Then the stop orders should have the following states 657 | party | market id | status | reference | 658 | party1 | ETH/DEC19 | STATUS_TRIGGERED | stop1 | 659 660 # add 20 secs, should expire 661 Given time is updated to "2019-11-30T00:00:30Z" 662 # check the stop order was not triggered a second at time T 663 Then the parties should have the following profit and loss: 664 | party | volume | unrealised pnl | realised pnl | 665 | party1 | 10 | -300 | -300 | 666 667 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-055) 668 669 # setup accounts 670 Given the parties deposit on asset's general account the following amount: 671 | party | asset | amount | 672 | party1 | BTC | 10000000 | 673 | party2 | BTC | 10000000 | 674 | party3 | BTC | 10000000 | 675 | aux | BTC | 10000000 | 676 | aux2 | BTC | 10000000 | 677 | aux3 | BTC | 10000000 | 678 | lpprov | BTC | 90000000 | 679 680 When the parties submit the following liquidity provision: 681 | id | party | market id | commitment amount | fee | lp type | 682 | lp1 | lpprov | ETH/DEC19 | 90000000 | 0.1 | submission | 683 | lp1 | lpprov | ETH/DEC19 | 90000000 | 0.1 | submission | 684 And the parties place the following pegged iceberg orders: 685 | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | 686 | lpprov | ETH/DEC19 | 2 | 1 | buy | BID | 50 | 100 | 687 | lpprov | ETH/DEC19 | 2 | 1 | sell | ASK | 50 | 100 | 688 689 # place auxiliary orders so we always have best bid and best offer as to not trigger the liquidity auction 690 When the parties place the following orders: 691 | party | market id | side | volume | price | resulting trades | type | tif | 692 | aux | ETH/DEC19 | buy | 1 | 1 | 0 | TYPE_LIMIT | TIF_GTC | 693 | aux | ETH/DEC19 | sell | 1 | 10001 | 0 | TYPE_LIMIT | TIF_GTC | 694 | aux2 | ETH/DEC19 | buy | 1 | 50 | 0 | TYPE_LIMIT | TIF_GTC | 695 | aux3 | ETH/DEC19 | sell | 1 | 50 | 0 | TYPE_LIMIT | TIF_GTC | 696 697 Then the opening auction period ends for market "ETH/DEC19" 698 And the trading mode should be "TRADING_MODE_CONTINUOUS" for the market "ETH/DEC19" 699 700 # setup party1 position, open a 10 short position 701 When the parties place the following orders: 702 | party | market id | side | volume | price | resulting trades | type | tif | 703 | party1 | ETH/DEC19 | buy | 1 | 50 | 0 | TYPE_LIMIT | TIF_GTC | 704 | party2 | ETH/DEC19 | sell | 1 | 50 | 1 | TYPE_LIMIT | TIF_GTC | 705 706 707 Then the network moves ahead "1" blocks 708 And the trading mode should be "TRADING_MODE_CONTINUOUS" for the market "ETH/DEC19" 709 710 # before, we check the volum for the party 711 Then the parties should have the following profit and loss: 712 | party | volume | unrealised pnl | realised pnl | 713 | party1 | 1 | 0 | 0 | 714 715 # create party1 stop order, results in a trade 716 When the parties place the following orders: 717 | party | market id | side | volume | price | resulting trades | type | tif | only | fb price trigger | error | reference | 718 | party1 | ETH/DEC19 | sell | 1 | 0 | 0 | TYPE_MARKET | TIF_IOC | reduce | 25 | | stop1 | 719 720 # volume for the stop trade 721 When the parties place the following orders: 722 | party | market id | side | volume | price | resulting trades | type | tif | 723 | party3 | ETH/DEC19 | buy | 10 | 20 | 0 | TYPE_LIMIT | TIF_GTC | 724 725 # now we trade at 25, this will breach the trigger 726 When the parties place the following orders: 727 | party | market id | side | volume | price | resulting trades | type | tif | 728 | party3 | ETH/DEC19 | sell | 10 | 25 | 0 | TYPE_LIMIT | TIF_GTC | 729 | party2 | ETH/DEC19 | buy | 10 | 25 | 1 | TYPE_LIMIT | TIF_GTC | 730 731 # check that the order got submitted 732 Then the orders should have the following states: 733 | party | market id | side | volume | remaining | price | status | reference | 734 | party1 | ETH/DEC19 | sell | 1 | 0 | 0 | STATUS_FILLED | stop1 | 735 736 Then the network moves ahead "1" blocks 737 And the trading mode should be "TRADING_MODE_CONTINUOUS" for the market "ETH/DEC19" 738 739 # after the volume has been reduced 740 Then the parties should have the following profit and loss: 741 | party | volume | unrealised pnl | realised pnl | 742 | party1 | 0 | 0 | -30 | 743 744 Scenario: If a pair of stop orders are specified as OCO, one being triggered also removes the other from the book. (0014-ORDT-056) 745 746 747 # setup accounts 748 Given the parties deposit on asset's general account the following amount: 749 | party | asset | amount | 750 | party1 | BTC | 10000 | 751 | party2 | BTC | 10000 | 752 | party3 | BTC | 10000 | 753 | aux | BTC | 100000 | 754 | aux2 | BTC | 100000 | 755 | lpprov | BTC | 90000000 | 756 757 When the parties submit the following liquidity provision: 758 | id | party | market id | commitment amount | fee | lp type | 759 | lp1 | lpprov | ETH/DEC19 | 90000000 | 0.1 | submission | 760 | lp1 | lpprov | ETH/DEC19 | 90000000 | 0.1 | submission | 761 And the parties place the following pegged iceberg orders: 762 | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | 763 | lpprov | ETH/DEC19 | 2 | 1 | buy | BID | 50 | 100 | 764 | lpprov | ETH/DEC19 | 2 | 1 | sell | ASK | 50 | 100 | 765 # place auxiliary orders so we always have best bid and best offer as to not trigger the liquidity auction 766 When the parties place the following orders: 767 | party | market id | side | volume | price | resulting trades | type | tif | 768 | aux | ETH/DEC19 | buy | 1 | 1 | 0 | TYPE_LIMIT | TIF_GTC | 769 | aux | ETH/DEC19 | sell | 1 | 10001 | 0 | TYPE_LIMIT | TIF_GTC | 770 | aux2 | ETH/DEC19 | buy | 5 | 50 | 0 | TYPE_LIMIT | TIF_GTC | 771 | aux | ETH/DEC19 | sell | 5 | 50 | 0 | TYPE_LIMIT | TIF_GTC | 772 773 Then the opening auction period ends for market "ETH/DEC19" 774 And the trading mode should be "TRADING_MODE_CONTINUOUS" for the market "ETH/DEC19" 775 776 # setup party1 position, open a 10 short position 777 When the parties place the following orders: 778 | party | market id | side | volume | price | resulting trades | type | tif | 779 | party1 | ETH/DEC19 | buy | 10 | 50 | 0 | TYPE_LIMIT | TIF_GTC | 780 | party2 | ETH/DEC19 | sell | 10 | 50 | 1 | TYPE_LIMIT | TIF_GTC | 781 782 783 # create party1 stop order, results in a trade 784 When the parties place the following orders: 785 | party | market id | side | volume | price | resulting trades | type | tif | only | fb price trigger | ra price trigger | error | reference | 786 | party1 | ETH/DEC19 | sell | 10 | 0 | 0 | TYPE_MARKET | TIF_IOC | reduce | 25 | 75 | | stop1 | 787 788 # volume for the stop trade 789 When the parties place the following orders: 790 | party | market id | side | volume | price | resulting trades | type | tif | 791 | party3 | ETH/DEC19 | buy | 10 | 20 | 0 | TYPE_LIMIT | TIF_GTC | 792 793 # now we trade at 75, this will breach the trigger 794 When the parties place the following orders: 795 | party | market id | side | volume | price | resulting trades | type | tif | 796 | party3 | ETH/DEC19 | sell | 10 | 25 | 0 | TYPE_LIMIT | TIF_GTC | 797 | party2 | ETH/DEC19 | buy | 10 | 25 | 1 | TYPE_LIMIT | TIF_GTC | 798 799 # check that the order got submitted 800 Then the orders should have the following states: 801 | party | market id | side | volume | remaining | price | status | reference | 802 | party1 | ETH/DEC19 | sell | 10 | 0 | 0 | STATUS_FILLED | stop1-1 | 803 804 Then the stop orders should have the following states 805 | party | market id | status | reference | 806 | party1 | ETH/DEC19 | STATUS_TRIGGERED | stop1-1 | 807 | party1 | ETH/DEC19 | STATUS_STOPPED | stop1-2 | 808 809 @Liquidation 810 Scenario: If a pair of stop orders are specified as OCO and one triggers but is invalid at time of triggering (e.g. a buy when the trader is already long) the other will still be cancelled. (0014-ORDT-058) 811 # setup accounts 812 Given the parties deposit on asset's general account the following amount: 813 | party | asset | amount | 814 | party1 | BTC | 10000000 | 815 | party2 | BTC | 10000000 | 816 | party3 | BTC | 900000000 | 817 | aux | BTC | 10000000 | 818 | aux2 | BTC | 10000000 | 819 | aux3 | BTC | 10000000 | 820 | lpprov | BTC | 90000000 | 821 822 When the parties submit the following liquidity provision: 823 | id | party | market id | commitment amount | fee | lp type | 824 | lp1 | lpprov | ETH/DEC19 | 90000000 | 0.1 | submission | 825 | lp1 | lpprov | ETH/DEC19 | 90000000 | 0.1 | submission | 826 And the parties place the following pegged iceberg orders: 827 | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | 828 | lpprov | ETH/DEC19 | 2 | 1 | buy | BID | 50 | 100 | 829 | lpprov | ETH/DEC19 | 2 | 1 | sell | ASK | 50 | 100 | 830 831 # place auxiliary orders so we always have best bid and best offer as to not trigger the liquidity auction 832 When the parties place the following orders: 833 | party | market id | side | volume | price | resulting trades | type | tif | 834 | aux | ETH/DEC19 | buy | 1 | 1 | 0 | TYPE_LIMIT | TIF_GTC | 835 | aux | ETH/DEC19 | sell | 1 | 10001 | 0 | TYPE_LIMIT | TIF_GTC | 836 | aux2 | ETH/DEC19 | buy | 1 | 50 | 0 | TYPE_LIMIT | TIF_GTC | 837 | aux3 | ETH/DEC19 | sell | 1 | 50 | 0 | TYPE_LIMIT | TIF_GTC | 838 839 Then the opening auction period ends for market "ETH/DEC19" 840 And the trading mode should be "TRADING_MODE_CONTINUOUS" for the market "ETH/DEC19" 841 842 # setup party1 position, open a 10 short position 843 When the parties place the following orders: 844 | party | market id | side | volume | price | resulting trades | type | tif | 845 | party1 | ETH/DEC19 | buy | 1 | 50 | 0 | TYPE_LIMIT | TIF_GTC | 846 | party2 | ETH/DEC19 | sell | 1 | 50 | 1 | TYPE_LIMIT | TIF_GTC | 847 848 849 Then the network moves ahead "1" blocks 850 And the trading mode should be "TRADING_MODE_CONTINUOUS" for the market "ETH/DEC19" 851 852 # before, we check the volum for the party 853 Then the parties should have the following profit and loss: 854 | party | volume | unrealised pnl | realised pnl | 855 | party1 | 1 | 0 | 0 | 856 857 # create party1 stop order, results in a trade 858 When the parties place the following orders: 859 | party | market id | side | volume | price | resulting trades | type | tif | only | fb price trigger | ra price trigger | error | reference | 860 | party1 | ETH/DEC19 | sell | 1 | 0 | 0 | TYPE_MARKET | TIF_IOC | reduce | 25 | 100 | | stop1 | 861 862 863 # close party1 position 864 When the parties place the following orders: 865 | party | market id | side | volume | price | resulting trades | type | tif | 866 | party3 | ETH/DEC19 | buy | 2 | 50 | 0 | TYPE_LIMIT | TIF_GTC | 867 | party1 | ETH/DEC19 | sell | 2 | 50 | 1 | TYPE_LIMIT | TIF_GTC | 868 869 Then the network moves ahead "1" blocks 870 And the trading mode should be "TRADING_MODE_CONTINUOUS" for the market "ETH/DEC19" 871 872 # after the volume has been reduced 873 Then the parties should have the following profit and loss: 874 | party | volume | unrealised pnl | realised pnl | 875 | party1 | -1 | 0 | 0 | 876 877 # now we trade at 25, this will breach the trigger 878 When the parties place the following orders: 879 | party | market id | side | volume | price | resulting trades | type | tif | reference | 880 | party3 | ETH/DEC19 | sell | 1 | 25 | 0 | TYPE_LIMIT | TIF_GTC | p3-ord | 881 | party2 | ETH/DEC19 | buy | 1 | 25 | 1 | TYPE_LIMIT | TIF_GTC | p2-ord | 882 883 884 # check that the order got submitted and stopped as would not reduce the position 885 Then the orders should have the following states: 886 | party | market id | side | volume | remaining | price | status | reference | 887 | party1 | ETH/DEC19 | sell | 1 | 1 | 0 | STATUS_STOPPED | stop1-1 | 888 889 Then the stop orders should have the following states 890 | party | market id | status | reference | 891 | party1 | ETH/DEC19 | STATUS_TRIGGERED | stop1-1 | 892 | party1 | ETH/DEC19 | STATUS_STOPPED | stop1-2 | 893 894 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-059), Not be triggered by a fall to 58. (0014-ORDT-060) 895 896 # setup accounts 897 Given the parties deposit on asset's general account the following amount: 898 | party | asset | amount | 899 | party1 | BTC | 10000000000 | 900 | party2 | BTC | 10000000000 | 901 | party3 | BTC | 10000000000 | 902 | aux | BTC | 10000000000 | 903 | aux2 | BTC | 10000000000 | 904 | lpprov | BTC | 9000000000 | 905 906 When the parties submit the following liquidity provision: 907 | id | party | market id | commitment amount | fee | lp type | 908 | lp1 | lpprov | ETH/DEC19 | 90000000 | 0.1 | submission | 909 | lp1 | lpprov | ETH/DEC19 | 90000000 | 0.1 | submission | 910 And the parties place the following pegged iceberg orders: 911 | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | 912 | lpprov | ETH/DEC19 | 2 | 1 | buy | BID | 50 | 100 | 913 | lpprov | ETH/DEC19 | 2 | 1 | sell | ASK | 50 | 100 | 914 915 # place auxiliary orders so we always have best bid and best offer as to not trigger the liquidity auction 916 When the parties place the following orders: 917 | party | market id | side | volume | price | resulting trades | type | tif | 918 | aux | ETH/DEC19 | buy | 1 | 1 | 0 | TYPE_LIMIT | TIF_GTC | 919 | aux | ETH/DEC19 | sell | 1 | 10001 | 0 | TYPE_LIMIT | TIF_GTC | 920 | aux2 | ETH/DEC19 | buy | 1 | 50 | 0 | TYPE_LIMIT | TIF_GTC | 921 | aux | ETH/DEC19 | sell | 1 | 50 | 0 | TYPE_LIMIT | TIF_GTC | 922 923 Then the opening auction period ends for market "ETH/DEC19" 924 And the trading mode should be "TRADING_MODE_CONTINUOUS" for the market "ETH/DEC19" 925 926 # setup party1 position, open a 10 long position 927 When the parties place the following orders: 928 | party | market id | side | volume | price | resulting trades | type | tif | 929 | party1 | ETH/DEC19 | buy | 1 | 50 | 0 | TYPE_LIMIT | TIF_GTC | 930 | party2 | ETH/DEC19 | sell | 1 | 50 | 1 | TYPE_LIMIT | TIF_GTC | 931 932 # create party1 stop order, results in a trade 933 When the parties place the following orders: 934 | party | market id | side | volume | price | resulting trades | type | tif | only | fb trailing | error | reference | 935 | party1 | ETH/DEC19 | sell | 1 | 0 | 0 | TYPE_MARKET | TIF_IOC | reduce | 0.05 | | stop1 | 936 937 # create volume to close party 1 938 # high price sell so it doesn't trade 939 When the parties place the following orders: 940 | party | market id | side | volume | price | resulting trades | type | tif | 941 | aux | ETH/DEC19 | buy | 1 | 20 | 0 | TYPE_LIMIT | TIF_GTC | 942 943 944 # move prive to 60, nothing happen 945 When the parties place the following orders: 946 | party | market id | side | volume | price | resulting trades | type | tif | 947 | aux2 | ETH/DEC19 | buy | 1 | 60 | 0 | TYPE_LIMIT | TIF_GTC | 948 | aux | ETH/DEC19 | sell | 1 | 60 | 1 | TYPE_LIMIT | TIF_GTC | 949 950 Then the network moves ahead "1" blocks 951 And the trading mode should be "TRADING_MODE_CONTINUOUS" for the market "ETH/DEC19" 952 953 # check the volum as not reduced 954 Then the parties should have the following profit and loss: 955 | party | volume | unrealised pnl | realised pnl | 956 | party1 | 1 | 10 | 0 | 957 958 # move first to 58, nothing happen 959 When the parties place the following orders: 960 | party | market id | side | volume | price | resulting trades | type | tif | 961 | aux2 | ETH/DEC19 | buy | 1 | 58 | 0 | TYPE_LIMIT | TIF_GTC | 962 | aux | ETH/DEC19 | sell | 1 | 58 | 1 | TYPE_LIMIT | TIF_GTC | 963 964 Then the network moves ahead "1" blocks 965 And the trading mode should be "TRADING_MODE_CONTINUOUS" for the market "ETH/DEC19" 966 967 # check the volum as not reduced 968 Then the parties should have the following profit and loss: 969 | party | volume | unrealised pnl | realised pnl | 970 | party1 | 1 | 8 | 0 | 971 972 # move first to 57, nothing happen 973 When the parties place the following orders: 974 | party | market id | side | volume | price | resulting trades | type | tif | 975 | aux2 | ETH/DEC19 | buy | 1 | 57 | 0 | TYPE_LIMIT | TIF_GTC | 976 | aux | ETH/DEC19 | sell | 1 | 57 | 1 | TYPE_LIMIT | TIF_GTC | 977 978 # check that the order got submitted 979 Then the orders should have the following states: 980 | party | market id | side | volume | remaining | price | status | reference | 981 | party1 | ETH/DEC19 | sell | 1 | 0 | 0 | STATUS_FILLED | stop1 | 982 983 Then the stop orders should have the following states 984 | party | market id | status | reference | 985 | party1 | ETH/DEC19 | STATUS_TRIGGERED | stop1 | 986 987 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-061), Not be triggered by a rise to 41. (0014-ORDT-062) 988 989 # setup accounts 990 Given the parties deposit on asset's general account the following amount: 991 | party | asset | amount | 992 | party1 | BTC | 10000000000 | 993 | party2 | BTC | 10000000000 | 994 | party3 | BTC | 10000000000 | 995 | aux | BTC | 10000000000 | 996 | aux2 | BTC | 10000000000 | 997 | lpprov | BTC | 9000000000 | 998 999 When the parties submit the following liquidity provision: 1000 | id | party | market id | commitment amount | fee | lp type | 1001 | lp1 | lpprov | ETH/DEC19 | 90000000 | 0.1 | submission | 1002 | lp1 | lpprov | ETH/DEC19 | 90000000 | 0.1 | submission | 1003 And the parties place the following pegged iceberg orders: 1004 | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | 1005 | lpprov | ETH/DEC19 | 2 | 1 | buy | BID | 50 | 100 | 1006 | lpprov | ETH/DEC19 | 2 | 1 | sell | ASK | 50 | 100 | 1007 1008 # place auxiliary orders so we always have best bid and best offer as to not trigger the liquidity auction 1009 When the parties place the following orders: 1010 | party | market id | side | volume | price | resulting trades | type | tif | 1011 | aux | ETH/DEC19 | buy | 1 | 1 | 0 | TYPE_LIMIT | TIF_GTC | 1012 | aux | ETH/DEC19 | sell | 1 | 10001 | 0 | TYPE_LIMIT | TIF_GTC | 1013 | aux2 | ETH/DEC19 | buy | 1 | 50 | 0 | TYPE_LIMIT | TIF_GTC | 1014 | aux | ETH/DEC19 | sell | 1 | 50 | 0 | TYPE_LIMIT | TIF_GTC | 1015 1016 Then the opening auction period ends for market "ETH/DEC19" 1017 And the trading mode should be "TRADING_MODE_CONTINUOUS" for the market "ETH/DEC19" 1018 1019 # setup party1 position, open a 10 short position 1020 When the parties place the following orders: 1021 | party | market id | side | volume | price | resulting trades | type | tif | 1022 | party1 | ETH/DEC19 | sell | 1 | 50 | 0 | TYPE_LIMIT | TIF_GTC | 1023 | party2 | ETH/DEC19 | buy | 1 | 50 | 1 | TYPE_LIMIT | TIF_GTC | 1024 1025 # create party1 stop order, results in a trade 1026 When the parties place the following orders: 1027 | party | market id | side | volume | price | resulting trades | type | tif | only | ra trailing | error | reference | 1028 | party1 | ETH/DEC19 | buy | 1 | 0 | 0 | TYPE_MARKET | TIF_IOC | reduce | 0.05 | | stop1 | 1029 1030 # create volume to close party 1 1031 # high price sell so it doesn't trade 1032 When the parties place the following orders: 1033 | party | market id | side | volume | price | resulting trades | type | tif | 1034 | aux | ETH/DEC19 | sell | 1 | 70 | 0 | TYPE_LIMIT | TIF_GTC | 1035 1036 1037 # move prive to 60, nothing happen 1038 When the parties place the following orders: 1039 | party | market id | side | volume | price | resulting trades | type | tif | 1040 | aux2 | ETH/DEC19 | buy | 1 | 40 | 0 | TYPE_LIMIT | TIF_GTC | 1041 | aux | ETH/DEC19 | sell | 1 | 40 | 1 | TYPE_LIMIT | TIF_GTC | 1042 1043 Then the network moves ahead "1" blocks 1044 And the trading mode should be "TRADING_MODE_CONTINUOUS" for the market "ETH/DEC19" 1045 1046 # check the volum as not reduced 1047 Then the parties should have the following profit and loss: 1048 | party | volume | unrealised pnl | realised pnl | 1049 | party1 | -1 | 10 | 0 | 1050 1051 # move first to 58, nothing happen 1052 When the parties place the following orders: 1053 | party | market id | side | volume | price | resulting trades | type | tif | 1054 | aux2 | ETH/DEC19 | buy | 1 | 41 | 0 | TYPE_LIMIT | TIF_GTC | 1055 | aux | ETH/DEC19 | sell | 1 | 41 | 1 | TYPE_LIMIT | TIF_GTC | 1056 1057 Then the network moves ahead "1" blocks 1058 And the trading mode should be "TRADING_MODE_CONTINUOUS" for the market "ETH/DEC19" 1059 1060 # check the volum as not reduced 1061 Then the parties should have the following profit and loss: 1062 | party | volume | unrealised pnl | realised pnl | 1063 | party1 | -1 | 9 | 0 | 1064 1065 # move first to 57, nothing happen 1066 When the parties place the following orders: 1067 | party | market id | side | volume | price | resulting trades | type | tif | 1068 | aux2 | ETH/DEC19 | buy | 1 | 42 | 0 | TYPE_LIMIT | TIF_GTC | 1069 | aux | ETH/DEC19 | sell | 1 | 42 | 1 | TYPE_LIMIT | TIF_GTC | 1070 1071 # check that the order got submitted 1072 Then the orders should have the following states: 1073 | party | market id | side | volume | remaining | price | status | reference | 1074 | party1 | ETH/DEC19 | buy | 1 | 0 | 0 | STATUS_FILLED | stop1 | 1075 1076 Then the stop orders should have the following states 1077 | party | market id | status | reference | 1078 | party1 | ETH/DEC19 | STATUS_TRIGGERED | stop1 | 1079 1080 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-063), Not be triggered by a fall to 46. (0014-ORDT-064) 1081 1082 # setup accounts 1083 Given the parties deposit on asset's general account the following amount: 1084 | party | asset | amount | 1085 | party1 | BTC | 10000000000 | 1086 | party2 | BTC | 10000000000 | 1087 | party3 | BTC | 10000000000 | 1088 | aux | BTC | 10000000000 | 1089 | aux2 | BTC | 10000000000 | 1090 | lpprov | BTC | 9000000000 | 1091 1092 When the parties submit the following liquidity provision: 1093 | id | party | market id | commitment amount | fee | lp type | 1094 | lp1 | lpprov | ETH/DEC19 | 90000000 | 0.1 | submission | 1095 | lp1 | lpprov | ETH/DEC19 | 90000000 | 0.1 | submission | 1096 And the parties place the following pegged iceberg orders: 1097 | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | 1098 | lpprov | ETH/DEC19 | 2 | 1 | buy | BID | 50 | 100 | 1099 | lpprov | ETH/DEC19 | 2 | 1 | sell | ASK | 50 | 100 | 1100 1101 # place auxiliary orders so we always have best bid and best offer as to not trigger the liquidity auction 1102 When the parties place the following orders: 1103 | party | market id | side | volume | price | resulting trades | type | tif | 1104 | aux | ETH/DEC19 | buy | 1 | 1 | 0 | TYPE_LIMIT | TIF_GTC | 1105 | aux | ETH/DEC19 | sell | 1 | 10001 | 0 | TYPE_LIMIT | TIF_GTC | 1106 | aux2 | ETH/DEC19 | buy | 1 | 50 | 0 | TYPE_LIMIT | TIF_GTC | 1107 | aux | ETH/DEC19 | sell | 1 | 50 | 0 | TYPE_LIMIT | TIF_GTC | 1108 1109 Then the opening auction period ends for market "ETH/DEC19" 1110 And the trading mode should be "TRADING_MODE_CONTINUOUS" for the market "ETH/DEC19" 1111 1112 # setup party1 position, open a 10 long position 1113 When the parties place the following orders: 1114 | party | market id | side | volume | price | resulting trades | type | tif | 1115 | party1 | ETH/DEC19 | buy | 1 | 50 | 0 | TYPE_LIMIT | TIF_GTC | 1116 | party2 | ETH/DEC19 | sell | 1 | 50 | 1 | TYPE_LIMIT | TIF_GTC | 1117 1118 # create party1 stop order, results in a trade 1119 When the parties place the following orders: 1120 | party | market id | side | volume | price | resulting trades | type | tif | only | fb trailing | error | reference | 1121 | party1 | ETH/DEC19 | sell | 1 | 0 | 0 | TYPE_MARKET | TIF_IOC | reduce | 0.25 | | stop1 | 1122 1123 # create volume to close party 1 1124 # high price sell so it doesn't trade 1125 When the parties place the following orders: 1126 | party | market id | side | volume | price | resulting trades | type | tif | 1127 | aux | ETH/DEC19 | buy | 1 | 20 | 0 | TYPE_LIMIT | TIF_GTC | 1128 1129 1130 # move prive to 60, nothing happen 1131 When the parties place the following orders: 1132 | party | market id | side | volume | price | resulting trades | type | tif | 1133 | aux2 | ETH/DEC19 | buy | 1 | 60 | 0 | TYPE_LIMIT | TIF_GTC | 1134 | aux | ETH/DEC19 | sell | 1 | 60 | 1 | TYPE_LIMIT | TIF_GTC | 1135 1136 Then the network moves ahead "1" blocks 1137 And the trading mode should be "TRADING_MODE_CONTINUOUS" for the market "ETH/DEC19" 1138 1139 # check the volum as not reduced 1140 Then the parties should have the following profit and loss: 1141 | party | volume | unrealised pnl | realised pnl | 1142 | party1 | 1 | 10 | 0 | 1143 1144 # move first to 58, nothing happen 1145 When the parties place the following orders: 1146 | party | market id | side | volume | price | resulting trades | type | tif | 1147 | aux2 | ETH/DEC19 | buy | 1 | 50 | 0 | TYPE_LIMIT | TIF_GTC | 1148 | aux | ETH/DEC19 | sell | 1 | 50 | 1 | TYPE_LIMIT | TIF_GTC | 1149 1150 Then the network moves ahead "1" blocks 1151 And the trading mode should be "TRADING_MODE_CONTINUOUS" for the market "ETH/DEC19" 1152 1153 # check the volum as not reduced 1154 Then the parties should have the following profit and loss: 1155 | party | volume | unrealised pnl | realised pnl | 1156 | party1 | 1 | 0 | 0 | 1157 1158 # move first to 57, nothing happen 1159 When the parties place the following orders: 1160 | party | market id | side | volume | price | resulting trades | type | tif | 1161 | aux2 | ETH/DEC19 | buy | 1 | 57 | 0 | TYPE_LIMIT | TIF_GTC | 1162 | aux | ETH/DEC19 | sell | 1 | 57 | 1 | TYPE_LIMIT | TIF_GTC | 1163 1164 Then the network moves ahead "1" blocks 1165 And the trading mode should be "TRADING_MODE_CONTINUOUS" for the market "ETH/DEC19" 1166 1167 # check the volum as not reduced 1168 Then the parties should have the following profit and loss: 1169 | party | volume | unrealised pnl | realised pnl | 1170 | party1 | 1 | 7 | 0 | 1171 1172 # move first to 46, nothing happen 1173 When the parties place the following orders: 1174 | party | market id | side | volume | price | resulting trades | type | tif | 1175 | aux2 | ETH/DEC19 | buy | 1 | 46 | 0 | TYPE_LIMIT | TIF_GTC | 1176 | aux | ETH/DEC19 | sell | 1 | 46 | 1 | TYPE_LIMIT | TIF_GTC | 1177 1178 Then the network moves ahead "1" blocks 1179 And the trading mode should be "TRADING_MODE_CONTINUOUS" for the market "ETH/DEC19" 1180 1181 # check the volum as not reduced 1182 Then the parties should have the following profit and loss: 1183 | party | volume | unrealised pnl | realised pnl | 1184 | party1 | 1 | -4 | 0 | 1185 1186 1187 # move first to 46, nothing happen 1188 When the parties place the following orders: 1189 | party | market id | side | volume | price | resulting trades | type | tif | 1190 | aux2 | ETH/DEC19 | buy | 1 | 45 | 0 | TYPE_LIMIT | TIF_GTC | 1191 | aux | ETH/DEC19 | sell | 1 | 45 | 1 | TYPE_LIMIT | TIF_GTC | 1192 1193 1194 # check that the order got submitted 1195 Then the orders should have the following states: 1196 | party | market id | side | volume | remaining | price | status | reference | 1197 | party1 | ETH/DEC19 | sell | 1 | 0 | 0 | STATUS_FILLED | stop1 | 1198 1199 Then the stop orders should have the following states 1200 | party | market id | status | reference | 1201 | party1 | ETH/DEC19 | STATUS_TRIGGERED | stop1 | 1202 1203 1204 Scenario: If a trader has open stop orders and their position moves to zero whilst they still have open limit orders their stop orders will remain active. (0014-ORDT-067) 1205 1206 # setup accounts 1207 Given the parties deposit on asset's general account the following amount: 1208 | party | asset | amount | 1209 | party1 | BTC | 100000000 | 1210 | party2 | BTC | 100000000 | 1211 | party3 | BTC | 100000000 | 1212 | aux | BTC | 100000000 | 1213 | aux2 | BTC | 100000000 | 1214 | lpprov | BTC | 900000000 | 1215 1216 When the parties submit the following liquidity provision: 1217 | id | party | market id | commitment amount | fee | lp type | 1218 | lp1 | lpprov | ETH/DEC19 | 900000 | 0.1 | submission | 1219 | lp1 | lpprov | ETH/DEC19 | 900000 | 0.1 | submission | 1220 And the parties place the following pegged iceberg orders: 1221 | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | 1222 | lpprov | ETH/DEC19 | 2 | 1 | buy | BID | 50 | 100 | 1223 | lpprov | ETH/DEC19 | 2 | 1 | sell | ASK | 50 | 100 | 1224 1225 # place auxiliary orders so we always have best bid and best offer as to not trigger the liquidity auction 1226 When the parties place the following orders: 1227 | party | market id | side | volume | price | resulting trades | type | tif | 1228 | aux | ETH/DEC19 | buy | 1 | 1 | 0 | TYPE_LIMIT | TIF_GTC | 1229 | aux | ETH/DEC19 | sell | 1 | 10001 | 0 | TYPE_LIMIT | TIF_GTC | 1230 | aux2 | ETH/DEC19 | buy | 1 | 50 | 0 | TYPE_LIMIT | TIF_GTC | 1231 | aux | ETH/DEC19 | sell | 1 | 50 | 0 | TYPE_LIMIT | TIF_GTC | 1232 1233 Then the opening auction period ends for market "ETH/DEC19" 1234 And the trading mode should be "TRADING_MODE_CONTINUOUS" for the market "ETH/DEC19" 1235 1236 # open position 1237 Given the parties place the following orders: 1238 | party | market id | side | volume | price | resulting trades | type | tif | 1239 | party1 | ETH/DEC19 | buy | 1 | 50 | 0 | TYPE_LIMIT | TIF_GTC | 1240 | party2 | ETH/DEC19 | sell | 1 | 50 | 1 | TYPE_LIMIT | TIF_GTC | 1241 # create party1 stop order 1242 And the parties place the following orders: 1243 | party | market id | side | volume | price | resulting trades | type | tif | only | fb price trigger | error | reference | 1244 | party1 | ETH/DEC19 | sell | 1 | 0 | 0 | TYPE_MARKET | TIF_IOC | reduce | 25 | | stop1 | 1245 # create party1 limit orders 1246 And the parties place the following orders: 1247 | party | market id | side | volume | price | resulting trades | type | tif | 1248 | party1 | ETH/DEC19 | sell | 1 | 51 | 0 | TYPE_LIMIT | TIF_GTC | 1249 1250 # close position 1251 When the parties place the following orders: 1252 | party | market id | side | volume | price | resulting trades | type | tif | 1253 | party1 | ETH/DEC19 | sell | 1 | 50 | 0 | TYPE_LIMIT | TIF_GTC | 1254 | party2 | ETH/DEC19 | buy | 1 | 50 | 1 | TYPE_LIMIT | TIF_GTC | 1255 And the network moves ahead "1" blocks 1256 1257 # check stop orders have not been cancelled and are still pending 1258 Then the stop orders should have the following states 1259 | party | market id | status | reference | 1260 | party1 | ETH/DEC19 | STATUS_PENDING | stop1 | 1261 1262 Scenario: If a trader has open stop orders and their position moves to zero with no open limit orders their stop orders are cancelled. (0014-ORDT-068) 1263 1264 # setup accounts 1265 Given the parties deposit on asset's general account the following amount: 1266 | party | asset | amount | 1267 | party1 | BTC | 100000000 | 1268 | party2 | BTC | 100000000 | 1269 | party3 | BTC | 100000000 | 1270 | aux | BTC | 100000000 | 1271 | aux2 | BTC | 100000000 | 1272 | lpprov | BTC | 900000000 | 1273 1274 When the parties submit the following liquidity provision: 1275 | id | party | market id | commitment amount | fee | lp type | 1276 | lp1 | lpprov | ETH/DEC19 | 90000000 | 0.1 | submission | 1277 | lp1 | lpprov | ETH/DEC19 | 90000000 | 0.1 | submission | 1278 And the parties place the following pegged iceberg orders: 1279 | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | 1280 | lpprov | ETH/DEC19 | 2 | 1 | buy | BID | 50 | 100 | 1281 | lpprov | ETH/DEC19 | 2 | 1 | sell | ASK | 50 | 100 | 1282 1283 # place auxiliary orders so we always have best bid and best offer as to not trigger the liquidity auction 1284 When the parties place the following orders: 1285 | party | market id | side | volume | price | resulting trades | type | tif | 1286 | aux | ETH/DEC19 | buy | 1 | 1 | 0 | TYPE_LIMIT | TIF_GTC | 1287 | aux | ETH/DEC19 | sell | 1 | 10001 | 0 | TYPE_LIMIT | TIF_GTC | 1288 | aux2 | ETH/DEC19 | buy | 1 | 50 | 0 | TYPE_LIMIT | TIF_GTC | 1289 | aux | ETH/DEC19 | sell | 1 | 50 | 0 | TYPE_LIMIT | TIF_GTC | 1290 1291 Then the opening auction period ends for market "ETH/DEC19" 1292 And the trading mode should be "TRADING_MODE_CONTINUOUS" for the market "ETH/DEC19" 1293 1294 # open position 1295 When the parties place the following orders: 1296 | party | market id | side | volume | price | resulting trades | type | tif | 1297 | party1 | ETH/DEC19 | buy | 1 | 50 | 0 | TYPE_LIMIT | TIF_GTC | 1298 | party2 | ETH/DEC19 | sell | 1 | 50 | 1 | TYPE_LIMIT | TIF_GTC | 1299 1300 # create party1 stop order 1301 When the parties place the following orders: 1302 | party | market id | side | volume | price | resulting trades | type | tif | only | fb price trigger | error | reference | 1303 | party1 | ETH/DEC19 | sell | 1 | 0 | 0 | TYPE_MARKET | TIF_IOC | reduce | 25 | | stop1 | 1304 1305 1306 # close position 1307 When the parties place the following orders: 1308 | party | market id | side | volume | price | resulting trades | type | tif | 1309 | party1 | ETH/DEC19 | sell | 1 | 50 | 0 | TYPE_LIMIT | TIF_GTC | 1310 | party2 | ETH/DEC19 | buy | 1 | 50 | 1 | TYPE_LIMIT | TIF_GTC | 1311 1312 Then the network moves ahead "1" blocks 1313 And the trading mode should be "TRADING_MODE_CONTINUOUS" for the market "ETH/DEC19" 1314 1315 Then the stop orders should have the following states 1316 | party | market id | status | reference | 1317 | party1 | ETH/DEC19 | STATUS_CANCELLED | stop1 | 1318 1319 1320 Scenario: A Stop order that hasn't been triggered can be cancelled. (0014-ORDT-071) 1321 1322 # setup accounts 1323 Given the parties deposit on asset's general account the following amount: 1324 | party | asset | amount | 1325 | party1 | BTC | 10000 | 1326 | party2 | BTC | 10000 | 1327 | aux | BTC | 100000 | 1328 | aux2 | BTC | 100000 | 1329 | lpprov | BTC | 90000000 | 1330 1331 When the parties submit the following liquidity provision: 1332 | id | party | market id | commitment amount | fee | lp type | 1333 | lp1 | lpprov | ETH/DEC19 | 90000000 | 0.1 | submission | 1334 | lp1 | lpprov | ETH/DEC19 | 90000000 | 0.1 | submission | 1335 And the parties place the following pegged iceberg orders: 1336 | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | 1337 | lpprov | ETH/DEC19 | 2 | 1 | buy | BID | 50 | 100 | 1338 | lpprov | ETH/DEC19 | 2 | 1 | sell | ASK | 50 | 100 | 1339 1340 # place auxiliary orders so we always have best bid and best offer as to not trigger the liquidity auction 1341 When the parties place the following orders: 1342 | party | market id | side | volume | price | resulting trades | type | tif | 1343 | aux | ETH/DEC19 | buy | 1 | 1 | 0 | TYPE_LIMIT | TIF_GTC | 1344 | aux | ETH/DEC19 | sell | 1 | 10001 | 0 | TYPE_LIMIT | TIF_GTC | 1345 | aux2 | ETH/DEC19 | buy | 1 | 50 | 0 | TYPE_LIMIT | TIF_GTC | 1346 | aux | ETH/DEC19 | sell | 1 | 50 | 0 | TYPE_LIMIT | TIF_GTC | 1347 1348 Then the opening auction period ends for market "ETH/DEC19" 1349 And the trading mode should be "TRADING_MODE_CONTINUOUS" for the market "ETH/DEC19" 1350 1351 When the parties place the following orders: 1352 | party | market id | side | volume | price | resulting trades | type | tif | only | fb price trigger | error | reference | 1353 | party1 | ETH/DEC19 | sell | 10 | 60 | 0 | TYPE_LIMIT | TIF_GTC | | | | | 1354 | party1 | ETH/DEC19 | buy | 10 | 0 | 0 | TYPE_MARKET | TIF_GTC | reduce | 47 | | stop1 | 1355 1356 Then the parties cancel the following stop orders: 1357 | party | reference | 1358 | party1 | stop1 | 1359 1360 Then the stop orders should have the following states 1361 | party | market id | status | reference | 1362 | party1 | ETH/DEC19 | STATUS_CANCELLED | stop1 | 1363 1364 @SLABug 1365 Scenario: All stop orders for a specific party can be cancelled by a single stop order cancellation. (0014-ORDT-072) 1366 1367 # setup accounts 1368 Given the parties deposit on asset's general account the following amount: 1369 | party | asset | amount | 1370 | party1 | BTC | 1000000 | 1371 | party2 | BTC | 1000000 | 1372 | aux | BTC | 1000000 | 1373 | aux2 | BTC | 1000000 | 1374 | lpprov | BTC | 900000000 | 1375 1376 When the parties submit the following liquidity provision: 1377 | id | party | market id | commitment amount | fee | lp type | 1378 | lp1 | lpprov | ETH/DEC19 | 900000 | 0.1 | submission | 1379 | lp1 | lpprov | ETH/DEC19 | 900000 | 0.1 | submission | 1380 | lp2 | lpprov | ETH/DEC20 | 900000 | 0.1 | submission | 1381 | lp2 | lpprov | ETH/DEC20 | 900000 | 0.1 | submission | 1382 And the parties place the following pegged iceberg orders: 1383 | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | 1384 | lpprov | ETH/DEC19 | 2 | 1 | buy | BID | 50 | 100 | 1385 | lpprov | ETH/DEC19 | 2 | 1 | sell | ASK | 50 | 100 | 1386 | lpprov | ETH/DEC20 | 2 | 1 | buy | BID | 50 | 100 | 1387 | lpprov | ETH/DEC20 | 2 | 1 | sell | ASK | 50 | 100 | 1388 1389 # place auxiliary orders so we always have best bid and best offer as to not trigger the liquidity auction 1390 When the parties place the following orders: 1391 | party | market id | side | volume | price | resulting trades | type | tif | 1392 | aux | ETH/DEC19 | buy | 1 | 1 | 0 | TYPE_LIMIT | TIF_GTC | 1393 | aux | ETH/DEC19 | sell | 1 | 10001 | 0 | TYPE_LIMIT | TIF_GTC | 1394 | aux2 | ETH/DEC19 | buy | 1 | 50 | 0 | TYPE_LIMIT | TIF_GTC | 1395 | aux | ETH/DEC19 | sell | 1 | 50 | 0 | TYPE_LIMIT | TIF_GTC | 1396 | aux | ETH/DEC20 | buy | 1 | 1 | 0 | TYPE_LIMIT | TIF_GTC | 1397 | aux | ETH/DEC20 | sell | 1 | 10001 | 0 | TYPE_LIMIT | TIF_GTC | 1398 | aux2 | ETH/DEC20 | buy | 1 | 50 | 0 | TYPE_LIMIT | TIF_GTC | 1399 | aux | ETH/DEC20 | sell | 1 | 50 | 0 | TYPE_LIMIT | TIF_GTC | 1400 1401 When the network moves ahead "2" blocks 1402 Then the trading mode should be "TRADING_MODE_CONTINUOUS" for the market "ETH/DEC19" 1403 And the trading mode should be "TRADING_MODE_CONTINUOUS" for the market "ETH/DEC20" 1404 1405 When the parties place the following orders: 1406 | party | market id | side | volume | price | resulting trades | type | tif | only | fb price trigger | error | reference | 1407 | party1 | ETH/DEC19 | sell | 10 | 60 | 0 | TYPE_LIMIT | TIF_GTC | | | | | 1408 | party1 | ETH/DEC19 | buy | 2 | 0 | 0 | TYPE_MARKET | TIF_GTC | reduce | 47 | | stop1 | 1409 | party1 | ETH/DEC19 | buy | 2 | 0 | 0 | TYPE_MARKET | TIF_GTC | reduce | 48 | | stop2 | 1410 | party1 | ETH/DEC20 | sell | 10 | 60 | 0 | TYPE_LIMIT | TIF_GTC | | | | | 1411 | party1 | ETH/DEC20 | buy | 2 | 0 | 0 | TYPE_MARKET | TIF_GTC | reduce | 49 | | stop3 | 1412 | party1 | ETH/DEC20 | buy | 2 | 0 | 0 | TYPE_MARKET | TIF_GTC | reduce | 49 | | stop4 | 1413 1414 Then the party "party1" cancels all their stop orders 1415 1416 Then the stop orders should have the following states 1417 | party | market id | status | reference | 1418 | party1 | ETH/DEC19 | STATUS_CANCELLED | stop1 | 1419 | party1 | ETH/DEC19 | STATUS_CANCELLED | stop2 | 1420 | party1 | ETH/DEC20 | STATUS_CANCELLED | stop3 | 1421 | party1 | ETH/DEC20 | STATUS_CANCELLED | stop4 | 1422 1423 @SLABug 1424 Scenario: All stop orders for a specific party for a specific market can be cancelled by a single stop order cancellation. (0014-ORDT-073) 1425 1426 # setup accounts 1427 Given the parties deposit on asset's general account the following amount: 1428 | party | asset | amount | 1429 | party1 | BTC | 1000000 | 1430 | party2 | BTC | 1000000 | 1431 | aux | BTC | 1000000 | 1432 | aux2 | BTC | 1000000 | 1433 | lpprov | BTC | 900000000 | 1434 1435 When the parties submit the following liquidity provision: 1436 | id | party | market id | commitment amount | fee | lp type | 1437 | lp1 | lpprov | ETH/DEC19 | 900000 | 0.1 | submission | 1438 | lp1 | lpprov | ETH/DEC19 | 900000 | 0.1 | submission | 1439 | lp2 | lpprov | ETH/DEC20 | 900000 | 0.1 | submission | 1440 | lp2 | lpprov | ETH/DEC20 | 900000 | 0.1 | submission | 1441 And the parties place the following pegged iceberg orders: 1442 | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | 1443 | lpprov | ETH/DEC19 | 2 | 1 | buy | BID | 50 | 100 | 1444 | lpprov | ETH/DEC19 | 2 | 1 | sell | ASK | 50 | 100 | 1445 | lpprov | ETH/DEC20 | 2 | 1 | buy | BID | 50 | 100 | 1446 | lpprov | ETH/DEC20 | 2 | 1 | sell | ASK | 50 | 100 | 1447 1448 # place auxiliary orders so we always have best bid and best offer as to not trigger the liquidity auction 1449 When the parties place the following orders: 1450 | party | market id | side | volume | price | resulting trades | type | tif | 1451 | aux | ETH/DEC19 | buy | 1 | 1 | 0 | TYPE_LIMIT | TIF_GTC | 1452 | aux | ETH/DEC19 | sell | 1 | 10001 | 0 | TYPE_LIMIT | TIF_GTC | 1453 | aux2 | ETH/DEC19 | buy | 1 | 50 | 0 | TYPE_LIMIT | TIF_GTC | 1454 | aux | ETH/DEC19 | sell | 1 | 50 | 0 | TYPE_LIMIT | TIF_GTC | 1455 | aux | ETH/DEC20 | buy | 1 | 1 | 0 | TYPE_LIMIT | TIF_GTC | 1456 | aux | ETH/DEC20 | sell | 1 | 10001 | 0 | TYPE_LIMIT | TIF_GTC | 1457 | aux2 | ETH/DEC20 | buy | 1 | 50 | 0 | TYPE_LIMIT | TIF_GTC | 1458 | aux | ETH/DEC20 | sell | 1 | 50 | 0 | TYPE_LIMIT | TIF_GTC | 1459 1460 When the network moves ahead "2" blocks 1461 Then the trading mode should be "TRADING_MODE_CONTINUOUS" for the market "ETH/DEC19" 1462 And the trading mode should be "TRADING_MODE_CONTINUOUS" for the market "ETH/DEC20" 1463 1464 When the parties place the following orders: 1465 | party | market id | side | volume | price | resulting trades | type | tif | only | fb price trigger | error | reference | 1466 | party1 | ETH/DEC19 | sell | 10 | 60 | 0 | TYPE_LIMIT | TIF_GTC | | | | | 1467 | party1 | ETH/DEC19 | buy | 2 | 0 | 0 | TYPE_MARKET | TIF_GTC | reduce | 47 | | stop1 | 1468 | party1 | ETH/DEC19 | buy | 2 | 0 | 0 | TYPE_MARKET | TIF_GTC | reduce | 48 | | stop2 | 1469 | party1 | ETH/DEC20 | sell | 10 | 60 | 0 | TYPE_LIMIT | TIF_GTC | | | | | 1470 | party1 | ETH/DEC20 | buy | 2 | 0 | 0 | TYPE_MARKET | TIF_GTC | reduce | 49 | | stop3 | 1471 | party1 | ETH/DEC20 | buy | 2 | 0 | 0 | TYPE_MARKET | TIF_GTC | reduce | 49 | | stop4 | 1472 1473 Then the party "party1" cancels all their stop orders for the market "ETH/DEC19" 1474 1475 Then the stop orders should have the following states 1476 | party | market id | status | reference | 1477 | party1 | ETH/DEC19 | STATUS_CANCELLED | stop1 | 1478 | party1 | ETH/DEC19 | STATUS_CANCELLED | stop2 | 1479 | party1 | ETH/DEC20 | STATUS_PENDING | stop3 | 1480 | party1 | ETH/DEC20 | STATUS_PENDING | stop4 | 1481 1482 Scenario: A stop order cannot be triggered by orders crossing during an auction. (WIP TEST CASE 2) 1483 1484 # setup accounts 1485 Given the parties deposit on asset's general account the following amount: 1486 | party | asset | amount | 1487 | party1 | BTC | 1000000000 | 1488 | party2 | BTC | 1000000000 | 1489 | party3 | BTC | 1000000000 | 1490 | aux | BTC | 1000000000 | 1491 | aux2 | BTC | 1000000000 | 1492 | lpprov | BTC | 9000000000 | 1493 1494 When the parties submit the following liquidity provision: 1495 | id | party | market id | commitment amount | fee | lp type | 1496 | lp2 | lpprov | ETH/DEC20 | 900000 | 0.1 | submission | 1497 | lp2 | lpprov | ETH/DEC20 | 900000 | 0.1 | submission | 1498 And the parties place the following pegged iceberg orders: 1499 | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | 1500 | lpprov | ETH/DEC20 | 2 | 1 | buy | BID | 50 | 100 | 1501 | lpprov | ETH/DEC20 | 2 | 1 | sell | ASK | 50 | 100 | 1502 1503 # place auxiliary orders so we always have best bid and best offer as to not trigger the liquidity auction 1504 When the parties place the following orders: 1505 | party | market id | side | volume | price | resulting trades | type | tif | 1506 | aux | ETH/DEC20 | buy | 100 | 1 | 0 | TYPE_LIMIT | TIF_GTC | 1507 | aux | ETH/DEC20 | sell | 100 | 10001 | 0 | TYPE_LIMIT | TIF_GTC | 1508 | aux2 | ETH/DEC20 | buy | 1 | 5000 | 0 | TYPE_LIMIT | TIF_GTC | 1509 | aux | ETH/DEC20 | sell | 1 | 5000 | 0 | TYPE_LIMIT | TIF_GTC | 1510 1511 When the opening auction period ends for market "ETH/DEC20" 1512 Then the market data for the market "ETH/DEC20" should be: 1513 | mark price | trading mode | auction trigger | horizon | min bound | max bound | 1514 | 5000 | TRADING_MODE_CONTINUOUS | AUCTION_TRIGGER_UNSPECIFIED | 5 | 4993 | 5007 | 1515 | 5000 | TRADING_MODE_CONTINUOUS | AUCTION_TRIGGER_UNSPECIFIED | 10 | 4986 | 5014 | 1516 1517 # Open a position for party1 1518 Given the parties place the following orders: 1519 | party | market id | side | volume | price | resulting trades | type | tif | 1520 | party1 | ETH/DEC20 | buy | 1 | 5000 | 0 | TYPE_LIMIT | TIF_GTC | 1521 | party2 | ETH/DEC20 | sell | 1 | 5000 | 1 | TYPE_LIMIT | TIF_GTC | 1522 # Place a stop order 1523 And the parties place the following orders: 1524 | party | market id | side | volume | price | resulting trades | type | tif | only | ra price trigger | error | reference | 1525 | party1 | ETH/DEC20 | sell | 1 | 0 | 0 | TYPE_MARKET | TIF_IOC | reduce | 5001 | | stop | 1526 # Trigger a price-monitoring auction 1527 When the parties place the following orders: 1528 | party | market id | side | volume | price | resulting trades | type | tif | 1529 | party2 | ETH/DEC20 | buy | 1 | 5010 | 0 | TYPE_LIMIT | TIF_GTC | 1530 | party3 | ETH/DEC20 | sell | 1 | 5010 | 0 | TYPE_LIMIT | TIF_GTC | 1531 Then the market data for the market "ETH/DEC20" should be: 1532 | mark price | trading mode | auction trigger | horizon | min bound | max bound | 1533 | 5000 | TRADING_MODE_MONITORING_AUCTION | AUCTION_TRIGGER_PRICE | 10 | 4986 | 5014 | 1534 # Check the stop order was not triggered 1535 And the stop orders should have the following states 1536 | party | market id | status | reference | 1537 | party1 | ETH/DEC20 | STATUS_PENDING | stop | 1538 1539 # Update the indicative uncrossing price 1540 When the parties place the following orders: 1541 | party | market id | side | volume | price | resulting trades | type | tif | 1542 | party2 | ETH/DEC20 | buy | 1 | 5011 | 0 | TYPE_LIMIT | TIF_GTC | 1543 | party3 | ETH/DEC20 | sell | 1 | 5011 | 0 | TYPE_LIMIT | TIF_GTC | 1544 # Check the stop order was not triggered 1545 And the stop orders should have the following states 1546 | party | market id | status | reference | 1547 | party1 | ETH/DEC20 | STATUS_PENDING | stop | 1548 1549 Scenario: A stop order cannot be triggered by a stop order expiring during an auction. (WIP TEST CASE 2) 1550 1551 # setup accounts 1552 Given time is updated to "2019-11-30T00:00:00Z" 1553 And the parties deposit on asset's general account the following amount: 1554 | party | asset | amount | 1555 | party1 | BTC | 10000 | 1556 | party2 | BTC | 10000 | 1557 | party3 | BTC | 10000 | 1558 | aux | BTC | 100000 | 1559 | aux2 | BTC | 100000 | 1560 | lpprov | BTC | 90000000 | 1561 And the parties submit the following liquidity provision: 1562 | id | party | market id | commitment amount | fee | lp type | 1563 | lp1 | lpprov | ETH/DEC20 | 90000000 | 0.1 | submission | 1564 | lp1 | lpprov | ETH/DEC20 | 90000000 | 0.1 | submission | 1565 And the parties place the following pegged iceberg orders: 1566 | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | 1567 | lpprov | ETH/DEC20 | 2 | 1 | buy | BID | 50 | 100 | 1568 | lpprov | ETH/DEC20 | 2 | 1 | sell | ASK | 50 | 100 | 1569 And the parties place the following orders: 1570 | party | market id | side | volume | price | resulting trades | type | tif | 1571 | aux | ETH/DEC20 | buy | 1 | 1 | 0 | TYPE_LIMIT | TIF_GTC | 1572 | aux | ETH/DEC20 | sell | 1 | 10001 | 0 | TYPE_LIMIT | TIF_GTC | 1573 | aux2 | ETH/DEC20 | buy | 5 | 5000 | 0 | TYPE_LIMIT | TIF_GTC | 1574 | aux | ETH/DEC20 | sell | 5 | 5000 | 0 | TYPE_LIMIT | TIF_GTC | 1575 When the opening auction period ends for market "ETH/DEC20" 1576 Then the market data for the market "ETH/DEC20" should be: 1577 | mark price | trading mode | auction trigger | horizon | min bound | max bound | 1578 | 5000 | TRADING_MODE_CONTINUOUS | AUCTION_TRIGGER_UNSPECIFIED | 5 | 4993 | 5007 | 1579 | 5000 | TRADING_MODE_CONTINUOUS | AUCTION_TRIGGER_UNSPECIFIED | 10 | 4986 | 5014 | 1580 1581 # Open a position for party1 1582 Given the parties place the following orders: 1583 | party | market id | side | volume | price | resulting trades | type | tif | 1584 | party1 | ETH/DEC20 | buy | 1 | 5000 | 0 | TYPE_LIMIT | TIF_GTC | 1585 | party2 | ETH/DEC20 | sell | 1 | 5000 | 1 | TYPE_LIMIT | TIF_GTC | 1586 # Place a stop order which will expire during the auction 1587 And the parties place the following orders: 1588 | party | market id | side | volume | price | resulting trades | type | tif | only | ra price trigger | error | ra expires in | ra expiry strategy | reference | 1589 | party1 | ETH/DEC20 | sell | 1 | 0 | 0 | TYPE_MARKET | TIF_IOC | reduce | 5020 | | 5 | EXPIRY_STRATEGY_SUBMIT | stop | 1590 # Trigger a price-monitoring auction 1591 When the parties place the following orders: 1592 | party | market id | side | volume | price | resulting trades | type | tif | 1593 | party2 | ETH/DEC20 | buy | 1 | 5010 | 0 | TYPE_LIMIT | TIF_GTC | 1594 | party3 | ETH/DEC20 | sell | 1 | 5010 | 0 | TYPE_LIMIT | TIF_GTC | 1595 # Check we have entered an auction 1596 Then the market data for the market "ETH/DEC20" should be: 1597 | mark price | trading mode | auction trigger | horizon | min bound | max bound | 1598 | 5000 | TRADING_MODE_MONITORING_AUCTION | AUCTION_TRIGGER_PRICE | 10 | 4986 | 5014 | 1599 # Check the stop order was not triggered 1600 And the stop orders should have the following states 1601 | party | market id | status | reference | 1602 | party1 | ETH/DEC20 | STATUS_PENDING | stop | 1603 1604 # Update the time to expire the stop order 1605 When time is updated to "2019-11-30T00:00:03Z" 1606 Then the market data for the market "ETH/DEC20" should be: 1607 | mark price | trading mode | auction trigger | horizon | min bound | max bound | 1608 | 5000 | TRADING_MODE_MONITORING_AUCTION | AUCTION_TRIGGER_PRICE | 10 | 4986 | 5014 | 1609 And the stop orders should have the following states 1610 | party | market id | status | reference | 1611 | party1 | ETH/DEC20 | STATUS_PENDING | stop | 1612 1613 # Update the time to the end of the auction 1614 When time is updated to "2019-11-30T00:00:10Z" 1615 Then the market data for the market "ETH/DEC20" should be: 1616 | mark price | trading mode | auction trigger | horizon | min bound | max bound | 1617 | 5010 | TRADING_MODE_CONTINUOUS | AUCTION_TRIGGER_UNSPECIFIED | 10 | 4996 | 5024 | 1618 And the stop orders should have the following states 1619 | party | market id | status | reference | 1620 | party1 | ETH/DEC20 | STATUS_EXPIRED | stop | 1621 # The stop order did not trigger an order as stop expired during an auction 1622 Then the parties should have the following profit and loss: 1623 | party | volume | unrealised pnl | realised pnl | 1624 | party1 | 1 | 10 | 0 | 1625 1626 1627 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-054) (0014-ORDT-041) 1628 1629 # setup accounts 1630 Given time is updated to "2019-11-30T00:00:00Z" 1631 Given the parties deposit on asset's general account the following amount: 1632 | party | asset | amount | 1633 | party1 | BTC | 1000000 | 1634 | party2 | BTC | 1000000 | 1635 | party3 | BTC | 1000000 | 1636 | aux | BTC | 1000000 | 1637 | aux2 | BTC | 1000000 | 1638 | aux3 | BTC | 1000000 | 1639 | lpprov | BTC | 90000000 | 1640 1641 When the parties submit the following liquidity provision: 1642 | id | party | market id | commitment amount | fee | lp type | 1643 | lp1 | lpprov | ETH/DEC19 | 900000 | 0.1 | submission | 1644 | lp1 | lpprov | ETH/DEC19 | 900000 | 0.1 | submission | 1645 And the parties place the following pegged iceberg orders: 1646 | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | 1647 | lpprov | ETH/DEC19 | 2 | 1 | buy | BID | 50 | 100 | 1648 | lpprov | ETH/DEC19 | 2 | 1 | sell | ASK | 50 | 100 | 1649 1650 # place auxiliary orders so we always have best bid and best offer as to not trigger the liquidity auction 1651 When the parties place the following orders: 1652 | party | market id | side | volume | price | resulting trades | type | tif | 1653 | aux | ETH/DEC19 | buy | 1 | 1 | 0 | TYPE_LIMIT | TIF_GTC | 1654 | aux | ETH/DEC19 | sell | 1 | 10001 | 0 | TYPE_LIMIT | TIF_GTC | 1655 | aux2 | ETH/DEC19 | buy | 5 | 50 | 0 | TYPE_LIMIT | TIF_GTC | 1656 | aux3 | ETH/DEC19 | sell | 5 | 50 | 0 | TYPE_LIMIT | TIF_GTC | 1657 1658 Then the opening auction period ends for market "ETH/DEC19" 1659 And the trading mode should be "TRADING_MODE_CONTINUOUS" for the market "ETH/DEC19" 1660 1661 Given time is updated to "2019-11-30T00:00:10Z" 1662 # setup party1 position, open a 10 long position 1663 And the parties place the following orders: 1664 | party | market id | side | volume | price | resulting trades | type | tif | 1665 | party1 | ETH/DEC19 | buy | 20 | 50 | 0 | TYPE_LIMIT | TIF_GTC | 1666 | party2 | ETH/DEC19 | sell | 20 | 50 | 1 | TYPE_LIMIT | TIF_GTC | 1667 # volume for the stop trade 1668 And the parties place the following orders: 1669 | party | market id | side | volume | price | resulting trades | type | tif | 1670 | party3 | ETH/DEC19 | buy | 20 | 20 | 0 | TYPE_LIMIT | TIF_GTC | 1671 # create party1 stop order, no trade resulting, expires in 10 secs 1672 And the parties place the following orders: 1673 | party | market id | side | volume | price | resulting trades | type | tif | only | fb price trigger | ra price trigger | error | reference | fb expires in | fb expiry strategy | 1674 | party1 | ETH/DEC19 | sell | 10 | 0 | 0 | TYPE_MARKET | TIF_IOC | reduce | 25 | 100 | | stop1 | 10 | EXPIRY_STRATEGY_SUBMIT | 1675 1676 # trigger the stop order 1677 When the parties place the following orders: 1678 | party | market id | side | volume | price | resulting trades | type | tif | 1679 | party2 | ETH/DEC19 | buy | 1 | 24 | 0 | TYPE_LIMIT | TIF_GTC | 1680 | party3 | ETH/DEC19 | sell | 1 | 24 | 1 | TYPE_LIMIT | TIF_GTC | 1681 # check the stop order is filled 1682 Then the stop orders should have the following states 1683 | party | market id | status | reference | 1684 | party1 | ETH/DEC19 | STATUS_TRIGGERED | stop1-1 | 1685 | party1 | ETH/DEC19 | STATUS_STOPPED | stop1-2 | 1686 1687 # add 20 secs, should expire 1688 Given time is updated to "2019-11-30T00:00:30Z" 1689 # check the stop order was not triggered a second at time T 1690 Then the parties should have the following profit and loss: 1691 | party | volume | unrealised pnl | realised pnl | 1692 | party1 | 10 | -300 | -300 | 1693 1694 1695 Scenario: A stop order expiring in the past is rejected 1696 1697 # setup accounts 1698 Given time is updated to "2019-11-30T00:00:00Z" 1699 Given the parties deposit on asset's general account the following amount: 1700 | party | asset | amount | 1701 | party1 | BTC | 10000 | 1702 | party2 | BTC | 10000 | 1703 | party3 | BTC | 10000 | 1704 | aux | BTC | 100000 | 1705 | aux2 | BTC | 100000 | 1706 | aux3 | BTC | 100000 | 1707 | lpprov | BTC | 90000000 | 1708 1709 When the parties submit the following liquidity provision: 1710 | id | party | market id | commitment amount | fee | lp type | 1711 | lp1 | lpprov | ETH/DEC19 | 90000000 | 0.1 | submission | 1712 | lp1 | lpprov | ETH/DEC19 | 90000000 | 0.1 | submission | 1713 And the parties place the following pegged iceberg orders: 1714 | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | 1715 | lpprov | ETH/DEC19 | 2 | 1 | buy | BID | 50 | 100 | 1716 | lpprov | ETH/DEC19 | 2 | 1 | sell | ASK | 50 | 100 | 1717 1718 # place auxiliary orders so we always have best bid and best offer as to not trigger the liquidity auction 1719 When the parties place the following orders: 1720 | party | market id | side | volume | price | resulting trades | type | tif | 1721 | aux | ETH/DEC19 | buy | 1 | 1 | 0 | TYPE_LIMIT | TIF_GTC | 1722 | aux | ETH/DEC19 | sell | 1 | 10001 | 0 | TYPE_LIMIT | TIF_GTC | 1723 | aux2 | ETH/DEC19 | buy | 5 | 50 | 0 | TYPE_LIMIT | TIF_GTC | 1724 | aux3 | ETH/DEC19 | sell | 5 | 50 | 0 | TYPE_LIMIT | TIF_GTC | 1725 1726 Then the opening auction period ends for market "ETH/DEC19" 1727 And the trading mode should be "TRADING_MODE_CONTINUOUS" for the market "ETH/DEC19" 1728 1729 # setup party1 position, open a 10 long position 1730 When the parties place the following orders: 1731 | party | market id | side | volume | price | resulting trades | type | tif | 1732 | party1 | ETH/DEC19 | sell | 10 | 50 | 0 | TYPE_LIMIT | TIF_GTC | 1733 | party2 | ETH/DEC19 | buy | 10 | 50 | 1 | TYPE_LIMIT | TIF_GTC | 1734 1735 # volume for the stop trade 1736 When the parties place the following orders: 1737 | party | market id | side | volume | price | resulting trades | type | tif | 1738 | party3 | ETH/DEC19 | sell | 10 | 50 | 0 | TYPE_LIMIT | TIF_GTC | 1739 1740 1741 When time is updated to "2019-11-30T00:00:10Z" 1742 # create party1 stop order, no trade resulting, expires in 10 secs 1743 When the parties place the following orders: 1744 | party | market id | side | volume | price | resulting trades | type | tif | only | ra price trigger | error | reference | ra expires in | ra expiry strategy | 1745 | party1 | ETH/DEC19 | buy | 10 | 0 | 0 | TYPE_MARKET | TIF_IOC | reduce | 75 | stop order expiry in the past | stop1 | -10 | EXPIRY_STRATEGY_SUBMIT | 1746 1747 Then the stop orders should have the following states 1748 | party | market id | status | reference | 1749 | party1 | ETH/DEC19 | STATUS_REJECTED | stop1 | 1750 1751 1752 1753 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-130) 1754 1755 # setup accounts 1756 Given time is updated to "2019-11-30T00:00:00Z" 1757 Given the parties deposit on asset's general account the following amount: 1758 | party | asset | amount | 1759 | party1 | BTC | 10000 | 1760 | party2 | BTC | 10000 | 1761 | party3 | BTC | 10000 | 1762 | aux | BTC | 100000 | 1763 | aux2 | BTC | 100000 | 1764 | aux3 | BTC | 100000 | 1765 | lpprov | BTC | 90000000 | 1766 1767 When the parties submit the following liquidity provision: 1768 | id | party | market id | commitment amount | fee | lp type | 1769 | lp1 | lpprov | ETH/DEC19 | 90000000 | 0.1 | submission | 1770 | lp1 | lpprov | ETH/DEC19 | 90000000 | 0.1 | submission | 1771 And the parties place the following pegged iceberg orders: 1772 | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | 1773 | lpprov | ETH/DEC19 | 2 | 1 | buy | BID | 50 | 100 | 1774 | lpprov | ETH/DEC19 | 2 | 1 | sell | ASK | 50 | 100 | 1775 1776 # place auxiliary orders so we always have best bid and best offer as to not trigger the liquidity auction 1777 When the parties place the following orders: 1778 | party | market id | side | volume | price | resulting trades | type | tif | 1779 | aux | ETH/DEC19 | buy | 1 | 1 | 0 | TYPE_LIMIT | TIF_GTC | 1780 | aux | ETH/DEC19 | sell | 1 | 10001 | 0 | TYPE_LIMIT | TIF_GTC | 1781 | aux2 | ETH/DEC19 | buy | 5 | 50 | 0 | TYPE_LIMIT | TIF_GTC | 1782 | aux3 | ETH/DEC19 | sell | 5 | 50 | 0 | TYPE_LIMIT | TIF_GTC | 1783 1784 Then the opening auction period ends for market "ETH/DEC19" 1785 And the trading mode should be "TRADING_MODE_CONTINUOUS" for the market "ETH/DEC19" 1786 1787 When the parties place the following orders: 1788 | party | market id | side | volume | price | resulting trades | type | tif | 1789 | party1 | ETH/DEC19 | sell | 10 | 50 | 0 | TYPE_LIMIT | TIF_GTC | 1790 | party2 | ETH/DEC19 | buy | 10 | 50 | 1 | TYPE_LIMIT | TIF_GTC | 1791 1792 # volume for the stop trade 1793 When the parties place the following orders: 1794 | party | market id | side | volume | price | resulting trades | type | tif | 1795 | party3 | ETH/DEC19 | sell | 10 | 50 | 0 | TYPE_LIMIT | TIF_GTC | 1796 1797 1798 When time is updated to "2019-11-30T00:00:10Z" 1799 When the parties place the following orders: 1800 | 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 | 1801 | party1 | ETH/DEC19 | 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 | 1802 1803 1804 Scenario: An OCO stop order with expiration time T with one side set to execute at that time will execute at time T 1805 # if reached without being triggered, with the specified side triggering and the other side cancelling. (0014-ORDT-131) 1806 1807 # setup accounts 1808 Given time is updated to "2019-11-30T00:00:00Z" 1809 Given the parties deposit on asset's general account the following amount: 1810 | party | asset | amount | 1811 | party1 | BTC | 10000000 | 1812 | party2 | BTC | 10000000 | 1813 | party3 | BTC | 10000000 | 1814 | aux | BTC | 10000000 | 1815 | aux2 | BTC | 10000000 | 1816 | aux3 | BTC | 100000 | 1817 | lpprov | BTC | 90000000 | 1818 1819 When the parties submit the following liquidity provision: 1820 | id | party | market id | commitment amount | fee | lp type | 1821 | lp1 | lpprov | ETH/DEC19 | 90000000 | 0.1 | submission | 1822 | lp1 | lpprov | ETH/DEC19 | 90000000 | 0.1 | submission | 1823 And the parties place the following pegged iceberg orders: 1824 | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | 1825 | lpprov | ETH/DEC19 | 2 | 1 | buy | BID | 50 | 100 | 1826 | lpprov | ETH/DEC19 | 2 | 1 | sell | ASK | 50 | 100 | 1827 1828 # place auxiliary orders so we always have best bid and best offer as to not trigger the liquidity auction 1829 When the parties place the following orders: 1830 | party | market id | side | volume | price | resulting trades | type | tif | 1831 | aux | ETH/DEC19 | buy | 100 | 1 | 0 | TYPE_LIMIT | TIF_GTC | 1832 | aux | ETH/DEC19 | sell | 100 | 10001 | 0 | TYPE_LIMIT | TIF_GTC | 1833 | aux2 | ETH/DEC19 | buy | 5 | 50 | 0 | TYPE_LIMIT | TIF_GTC | 1834 | aux3 | ETH/DEC19 | sell | 5 | 50 | 0 | TYPE_LIMIT | TIF_GTC | 1835 1836 Then the opening auction period ends for market "ETH/DEC19" 1837 And the trading mode should be "TRADING_MODE_CONTINUOUS" for the market "ETH/DEC19" 1838 1839 When the parties place the following orders: 1840 | party | market id | side | volume | price | resulting trades | type | tif | 1841 | party1 | ETH/DEC19 | sell | 10 | 50 | 0 | TYPE_LIMIT | TIF_GTC | 1842 | party2 | ETH/DEC19 | buy | 10 | 50 | 1 | TYPE_LIMIT | TIF_GTC | 1843 1844 # volume for the stop trade 1845 When the parties place the following orders: 1846 | party | market id | side | volume | price | resulting trades | type | tif | 1847 | party3 | ETH/DEC19 | sell | 10 | 50 | 0 | TYPE_LIMIT | TIF_GTC | 1848 | party3 | ETH/DEC19 | buy | 10 | 51 | 0 | TYPE_LIMIT | TIF_GTC | 1849 1850 1851 When time is updated to "2019-11-30T00:00:10Z" 1852 When the parties place the following orders: 1853 | 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 | 1854 | party1 | ETH/DEC19 | buy | 10 | 0 | 0 | TYPE_MARKET | TIF_IOC | reduce | 75 | 25 | stop | 10 | EXPIRY_STRATEGY_SUBMIT | 15 | EXPIRY_STRATEGY_SUBMIT | 1855 1856 Then the stop orders should have the following states 1857 | party | market id | status | reference | 1858 | party1 | ETH/DEC19 | STATUS_PENDING | stop-1 | 1859 | party1 | ETH/DEC19 | STATUS_PENDING | stop-2 | 1860 1861 Then clear all events 1862 When time is updated to "2019-11-30T00:00:20Z" 1863 1864 Then the stop orders should have the following states 1865 | party | market id | status | reference | 1866 | party1 | ETH/DEC19 | STATUS_STOPPED | stop-1 | 1867 | party1 | ETH/DEC19 | STATUS_EXPIRED | stop-2 | 1868 1869 # Now perform the same test but from the other side 1870 When the parties place the following orders: 1871 | 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 | 1872 | party2 | ETH/DEC19 | sell | 10 | 0 | 0 | TYPE_MARKET | TIF_IOC | reduce | 75 | 25 | stop2 | 15 | EXPIRY_STRATEGY_SUBMIT | 10 | EXPIRY_STRATEGY_SUBMIT | 1873 1874 Then the stop orders should have the following states 1875 | party | market id | status | reference | 1876 | party2 | ETH/DEC19 | STATUS_PENDING | stop2-1 | 1877 | party2 | ETH/DEC19 | STATUS_PENDING | stop2-2 | 1878 1879 Then clear all events 1880 When time is updated to "2019-11-30T00:00:30Z" 1881 1882 Then the stop orders should have the following states 1883 | party | market id | status | reference | 1884 | party2 | ETH/DEC19 | STATUS_STOPPED | stop2-2 | 1885 | party2 | ETH/DEC19 | STATUS_EXPIRED | stop2-1 | 1886 1887 1888 Scenario: A party with a long or short position CAN increase their position with stop orders. (0014-ORDT-137) 1889 1890 # setup accounts 1891 Given time is updated to "2019-11-30T00:00:00Z" 1892 Given the parties deposit on asset's general account the following amount: 1893 | party | asset | amount | 1894 | party1 | BTC | 10000000 | 1895 | party2 | BTC | 10000000 | 1896 | party3 | BTC | 10000000 | 1897 | aux | BTC | 10000000 | 1898 | aux2 | BTC | 10000000 | 1899 | aux3 | BTC | 100000 | 1900 | lpprov | BTC | 90000000 | 1901 1902 When the parties submit the following liquidity provision: 1903 | id | party | market id | commitment amount | fee | lp type | 1904 | lp1 | lpprov | ETH/DEC19 | 90000000 | 0.1 | submission | 1905 | lp1 | lpprov | ETH/DEC19 | 90000000 | 0.1 | submission | 1906 And the parties place the following pegged iceberg orders: 1907 | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | 1908 | lpprov | ETH/DEC19 | 2 | 1 | buy | BID | 50 | 100 | 1909 | lpprov | ETH/DEC19 | 2 | 1 | sell | ASK | 50 | 100 | 1910 1911 # place auxiliary orders so we always have best bid and best offer as to not trigger the liquidity auction 1912 When the parties place the following orders: 1913 | party | market id | side | volume | price | resulting trades | type | tif | 1914 | aux | ETH/DEC19 | buy | 100 | 1 | 0 | TYPE_LIMIT | TIF_GTC | 1915 | aux | ETH/DEC19 | sell | 100 | 10001 | 0 | TYPE_LIMIT | TIF_GTC | 1916 | aux2 | ETH/DEC19 | buy | 5 | 50 | 0 | TYPE_LIMIT | TIF_GTC | 1917 | aux3 | ETH/DEC19 | sell | 5 | 50 | 0 | TYPE_LIMIT | TIF_GTC | 1918 1919 Then the opening auction period ends for market "ETH/DEC19" 1920 And the trading mode should be "TRADING_MODE_CONTINUOUS" for the market "ETH/DEC19" 1921 1922 When the parties place the following orders: 1923 | party | market id | side | volume | price | resulting trades | type | tif | 1924 | party1 | ETH/DEC19 | sell | 10 | 50 | 0 | TYPE_LIMIT | TIF_GTC | 1925 | party2 | ETH/DEC19 | buy | 10 | 50 | 1 | TYPE_LIMIT | TIF_GTC | 1926 1927 # volume for the stop trade 1928 When the parties place the following orders: 1929 | party | market id | side | volume | price | resulting trades | type | tif | 1930 | party3 | ETH/DEC19 | sell | 10 | 50 | 0 | TYPE_LIMIT | TIF_GTC | 1931 | party3 | ETH/DEC19 | buy | 10 | 51 | 0 | TYPE_LIMIT | TIF_GTC | 1932 1933 # We should not be able to place a but stop order for party2 as they have a long position and it would make it more long 1934 When the parties place the following orders: 1935 | party | market id | side | volume | price | resulting trades | type | tif | only | ra price trigger | fb price trigger | reference | error | 1936 | party2 | ETH/DEC19 | buy | 1 | 0 | 0 | TYPE_MARKET | TIF_IOC | reduce | 75 | 25 | stop | | 1937 1938 # We should not be able to place a sell stop order for party1 as they have a short position and it would make it more short 1939 When the parties place the following orders: 1940 | party | market id | side | volume | price | resulting trades | type | tif | only | ra price trigger | fb price trigger | reference | error | 1941 | party1 | ETH/DEC19 | sell | 1 | 0 | 0 | TYPE_MARKET | TIF_IOC | reduce | 75 | 25 | stop | | 1942 1943 Scenario: A party with a long position cannot flip to short by placing a stop order. 1944 Given time is updated to "2019-11-30T00:00:00Z" 1945 And the parties deposit on asset's general account the following amount: 1946 | party | asset | amount | 1947 | party1 | BTC | 10000000 | 1948 | party2 | BTC | 10000000 | 1949 | party3 | BTC | 10000000 | 1950 | aux | BTC | 10000000 | 1951 | aux2 | BTC | 10000000 | 1952 | aux3 | BTC | 100000 | 1953 | lpprov | BTC | 90000000 | 1954 1955 And the parties submit the following liquidity provision: 1956 | id | party | market id | commitment amount | fee | lp type | 1957 | lp1 | lpprov | ETH/DEC19 | 90000000 | 0.1 | submission | 1958 | lp1 | lpprov | ETH/DEC19 | 90000000 | 0.1 | submission | 1959 And the parties place the following pegged iceberg orders: 1960 | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | 1961 | lpprov | ETH/DEC19 | 2 | 1 | buy | BID | 50 | 100 | 1962 | lpprov | ETH/DEC19 | 2 | 1 | sell | ASK | 50 | 100 | 1963 1964 # place auxiliary orders so we always have best bid and best offer as to not trigger the liquidity auction 1965 And the parties place the following orders: 1966 | party | market id | side | volume | price | resulting trades | type | tif | 1967 | aux | ETH/DEC19 | buy | 100 | 1 | 0 | TYPE_LIMIT | TIF_GTC | 1968 | aux | ETH/DEC19 | sell | 100 | 10001 | 0 | TYPE_LIMIT | TIF_GTC | 1969 | aux2 | ETH/DEC19 | buy | 5 | 50 | 0 | TYPE_LIMIT | TIF_GTC | 1970 | aux3 | ETH/DEC19 | sell | 5 | 50 | 0 | TYPE_LIMIT | TIF_GTC | 1971 1972 When the opening auction period ends for market "ETH/DEC19" 1973 Then the trading mode should be "TRADING_MODE_CONTINUOUS" for the market "ETH/DEC19" 1974 1975 When the parties place the following orders: 1976 | party | market id | side | volume | price | resulting trades | type | tif | 1977 | party1 | ETH/DEC19 | sell | 10 | 50 | 0 | TYPE_LIMIT | TIF_GTC | 1978 | party2 | ETH/DEC19 | buy | 10 | 50 | 1 | TYPE_LIMIT | TIF_GTC | 1979 Then the following trades should be executed: 1980 | buyer | seller | price | size | 1981 | party2 | party1 | 50 | 10 | 1982 1983 When the parties place the following orders: 1984 | party | market id | side | volume | price | resulting trades | type | tif | 1985 | party1 | ETH/DEC19 | sell | 1 | 75 | 0 | TYPE_LIMIT | TIF_GTC | 1986 | party3 | ETH/DEC19 | buy | 50 | 75 | 1 | TYPE_LIMIT | TIF_GTC | 1987 And the network moves ahead "1" blocks 1988 Then the following trades should be executed: 1989 | buyer | seller | price | size | 1990 | party3 | party1 | 75 | 1 | 1991 1992 When the parties place the following orders: 1993 | party | market id | side | volume | price | resulting trades | type | tif | only | ra price trigger | fb price trigger | reference | error | 1994 | party2 | ETH/DEC19 | sell | 20 | 0 | 1 | TYPE_MARKET | TIF_IOC | reduce | 75 | 25 | stop | | 1995 Then the following trades should be executed: 1996 | buyer | seller | price | size | 1997 | party3 | party2 | 75 | 10 | 1998 1999 # Ensure the party has closed its position, despite the stop order being for a larger volume than their open position. 2000 When the network moves ahead "1" blocks 2001 Then the parties should have the following profit and loss: 2002 | party | volume | unrealised pnl | realised pnl | 2003 | party1 | -11 | -250 | 0 | 2004 | party2 | 0 | 0 | 250 | 2005 | party3 | 11 | 0 | 0 | 2006 2007 Scenario: If a stop order is placed with a position_fraction equal to 0.5 and the position 2008 size is 5 then the rounding should be equal to 3 (0014-ORDT-138) 2009 2010 # setup accounts 2011 Given time is updated to "2019-11-30T00:00:00Z" 2012 Given the parties deposit on asset's general account the following amount: 2013 | party | asset | amount | 2014 | party1 | BTC | 10000000 | 2015 | party2 | BTC | 10000000 | 2016 | party3 | BTC | 10000000 | 2017 | aux | BTC | 10000000 | 2018 | aux2 | BTC | 10000000 | 2019 | aux3 | BTC | 100000 | 2020 | lpprov | BTC | 90000000 | 2021 2022 When the parties submit the following liquidity provision: 2023 | id | party | market id | commitment amount | fee | lp type | 2024 | lp1 | lpprov | ETH/DEC19 | 90000000 | 0.1 | submission | 2025 | lp1 | lpprov | ETH/DEC19 | 90000000 | 0.1 | submission | 2026 And the parties place the following pegged iceberg orders: 2027 | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | 2028 | lpprov | ETH/DEC19 | 2 | 1 | buy | BID | 50 | 100 | 2029 | lpprov | ETH/DEC19 | 2 | 1 | sell | ASK | 50 | 100 | 2030 2031 # place auxiliary orders so we always have best bid and best offer as to not trigger the liquidity auction 2032 When the parties place the following orders: 2033 | party | market id | side | volume | price | resulting trades | type | tif | 2034 | aux | ETH/DEC19 | buy | 100 | 1 | 0 | TYPE_LIMIT | TIF_GTC | 2035 | aux | ETH/DEC19 | sell | 100 | 10001 | 0 | TYPE_LIMIT | TIF_GTC | 2036 | aux2 | ETH/DEC19 | buy | 5 | 50 | 0 | TYPE_LIMIT | TIF_GTC | 2037 | aux3 | ETH/DEC19 | sell | 5 | 50 | 0 | TYPE_LIMIT | TIF_GTC | 2038 2039 Then the opening auction period ends for market "ETH/DEC19" 2040 And the trading mode should be "TRADING_MODE_CONTINUOUS" for the market "ETH/DEC19" 2041 2042 When the parties place the following orders: 2043 | party | market id | side | volume | price | resulting trades | type | tif | 2044 | party1 | ETH/DEC19 | sell | 5 | 50 | 0 | TYPE_LIMIT | TIF_GTC | 2045 | party2 | ETH/DEC19 | buy | 5 | 50 | 1 | TYPE_LIMIT | TIF_GTC | 2046 2047 # volume for the stop trade 2048 When the parties place the following orders: 2049 | party | market id | side | volume | price | resulting trades | type | tif | 2050 | party3 | ETH/DEC19 | sell | 10 | 50 | 0 | TYPE_LIMIT | TIF_GTC | 2051 | party3 | ETH/DEC19 | buy | 10 | 51 | 0 | TYPE_LIMIT | TIF_GTC | 2052 2053 When time is updated to "2019-11-30T00:00:10Z" 2054 When the parties place the following orders: 2055 | 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 | 2056 | party1 | ETH/DEC19 | buy | 10 | 0 | 0 | TYPE_MARKET | TIF_IOC | reduce | 75 | 25 | stop | 10 | EXPIRY_STRATEGY_SUBMIT | 15 | EXPIRY_STRATEGY_SUBMIT | POSITION | 0.5 | 2057 2058 Then the stop orders should have the following states 2059 | party | market id | status | reference | 2060 | party1 | ETH/DEC19 | STATUS_PENDING | stop-1 | 2061 | party1 | ETH/DEC19 | STATUS_PENDING | stop-2 | 2062 2063 Then clear all events 2064 When time is updated to "2019-11-30T00:00:20Z" 2065 2066 Then the stop orders should have the following states 2067 | party | market id | status | reference | 2068 | party1 | ETH/DEC19 | STATUS_STOPPED | stop-1 | 2069 | party1 | ETH/DEC19 | STATUS_EXPIRED | stop-2 | 2070 2071 # Now we check that the order size was 3 as the position was 5 and the were scaling by 0.5 (5*0.5)==3, we round up 2072 And the following trades should be executed: 2073 | buyer | price | size | seller | 2074 | party1 | 50 | 3 | party3 | 2075 2076 2077 Scenario: If a stop order is placed with a position_fraction equal to 0 the order should be rejected. (0014-ORDT-139) 2078 2079 # setup accounts 2080 Given time is updated to "2019-11-30T00:00:00Z" 2081 Given the parties deposit on asset's general account the following amount: 2082 | party | asset | amount | 2083 | party1 | BTC | 10000000 | 2084 | party2 | BTC | 10000000 | 2085 | party3 | BTC | 10000000 | 2086 | aux | BTC | 10000000 | 2087 | aux2 | BTC | 10000000 | 2088 | aux3 | BTC | 100000 | 2089 | lpprov | BTC | 90000000 | 2090 2091 When the parties submit the following liquidity provision: 2092 | id | party | market id | commitment amount | fee | lp type | 2093 | lp1 | lpprov | ETH/DEC19 | 90000000 | 0.1 | submission | 2094 | lp1 | lpprov | ETH/DEC19 | 90000000 | 0.1 | submission | 2095 And the parties place the following pegged iceberg orders: 2096 | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | 2097 | lpprov | ETH/DEC19 | 2 | 1 | buy | BID | 50 | 100 | 2098 | lpprov | ETH/DEC19 | 2 | 1 | sell | ASK | 50 | 100 | 2099 2100 # place auxiliary orders so we always have best bid and best offer as to not trigger the liquidity auction 2101 When the parties place the following orders: 2102 | party | market id | side | volume | price | resulting trades | type | tif | 2103 | aux | ETH/DEC19 | buy | 100 | 1 | 0 | TYPE_LIMIT | TIF_GTC | 2104 | aux | ETH/DEC19 | sell | 100 | 10001 | 0 | TYPE_LIMIT | TIF_GTC | 2105 | aux2 | ETH/DEC19 | buy | 5 | 50 | 0 | TYPE_LIMIT | TIF_GTC | 2106 | aux3 | ETH/DEC19 | sell | 5 | 50 | 0 | TYPE_LIMIT | TIF_GTC | 2107 2108 Then the opening auction period ends for market "ETH/DEC19" 2109 And the trading mode should be "TRADING_MODE_CONTINUOUS" for the market "ETH/DEC19" 2110 2111 When the parties place the following orders: 2112 | party | market id | side | volume | price | resulting trades | type | tif | 2113 | party1 | ETH/DEC19 | sell | 5 | 50 | 0 | TYPE_LIMIT | TIF_GTC | 2114 | party2 | ETH/DEC19 | buy | 5 | 50 | 1 | TYPE_LIMIT | TIF_GTC | 2115 2116 # volume for the stop trade 2117 When the parties place the following orders: 2118 | party | market id | side | volume | price | resulting trades | type | tif | 2119 | party3 | ETH/DEC19 | sell | 10 | 50 | 0 | TYPE_LIMIT | TIF_GTC | 2120 | party3 | ETH/DEC19 | buy | 10 | 51 | 0 | TYPE_LIMIT | TIF_GTC | 2121 2122 When time is updated to "2019-11-30T00:00:10Z" 2123 When the parties place the following orders: 2124 | party | market id | side | volume | price | resulting trades | type | tif | only | ra price trigger | reference | ra expires in | ra expiry strategy | ra size override setting | ra size override percentage | error | 2125 | party1 | ETH/DEC19 | buy | 10 | 0 | 0 | TYPE_MARKET | TIF_IOC | reduce | 75 | stop | 10 | EXPIRY_STRATEGY_SUBMIT | POSITION | 0.0 | stop order size override percentage value is invalid | 2126 2127