code.vegaprotocol.io/vega@v0.79.0/core/integration/features/orders/iceberg-orders.feature (about) 1 Feature: Iceberg 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 And the following network parameters are set: 8 | name | value | 9 | market.auction.minimumDuration | 1 | 10 | network.markPriceUpdateMaximumFrequency | 0s | 11 | limits.markets.maxPeggedOrders | 1500 | 12 13 @iceberg 14 Scenario: Iceberg order submission with valid TIF's (0014-ORDT-007) 15 # setup accounts 16 Given the parties deposit on asset's general account the following amount: 17 | party | asset | amount | 18 | party1 | BTC | 10000 | 19 | party2 | BTC | 10000 | 20 | aux | BTC | 100000 | 21 | aux2 | BTC | 100000 | 22 | lpprov | BTC | 90000000 | 23 24 When the parties submit the following liquidity provision: 25 | id | party | market id | commitment amount | fee | lp type | 26 | lp1 | lpprov | ETH/DEC19 | 90000000 | 0.1 | submission | 27 | lp1 | lpprov | ETH/DEC19 | 90000000 | 0.1 | submission | 28 And the parties place the following pegged iceberg orders: 29 | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | 30 | lpprov | ETH/DEC19 | 2 | 1 | buy | BID | 50 | 100 | 31 | lpprov | ETH/DEC19 | 2 | 1 | sell | ASK | 50 | 100 | 32 # place auxiliary orders so we always have best bid and best offer as to not trigger the liquidity auction 33 When the parties place the following orders: 34 | party | market id | side | volume | price | resulting trades | type | tif | 35 | aux | ETH/DEC19 | buy | 1 | 1 | 0 | TYPE_LIMIT | TIF_GTC | 36 | aux | ETH/DEC19 | sell | 1 | 10001 | 0 | TYPE_LIMIT | TIF_GTC | 37 | aux2 | ETH/DEC19 | buy | 1 | 2 | 0 | TYPE_LIMIT | TIF_GTC | 38 | aux | ETH/DEC19 | sell | 1 | 2 | 0 | TYPE_LIMIT | TIF_GTC | 39 Then the opening auction period ends for market "ETH/DEC19" 40 And the trading mode should be "TRADING_MODE_CONTINUOUS" for the market "ETH/DEC19" 41 42 When the parties place the following iceberg orders: 43 | party | market id | side | volume | price | resulting trades | type | tif | peak size | minimum visible size | only | 44 | party1 | ETH/DEC19 | buy | 100 | 10 | 0 | TYPE_LIMIT | TIF_GTC | 10 | 5 | post | 45 46 Then the iceberg orders should have the following states: 47 | party | market id | side | visible volume | price | status | reserved volume | 48 | party1 | ETH/DEC19 | buy | 10 | 10 | STATUS_ACTIVE | 90 | 49 50 When the parties place the following iceberg orders: 51 | party | market id | side | volume | price | resulting trades | type | tif | expires in | peak size | minimum visible size | only | 52 | party2 | ETH/DEC19 | buy | 100 | 10 | 0 | TYPE_LIMIT | TIF_GTT | 3600 | 8 | 4 | post | 53 54 Then the iceberg orders should have the following states: 55 | party | market id | side | visible volume | price | status | reserved volume | 56 | party2 | ETH/DEC19 | buy | 8 | 10 | STATUS_ACTIVE | 92 | 57 58 59 @iceberg 60 Scenario: An iceberg order with either an ordinary or pegged limit price can be submitted (0014-ORDT-008) 61 # setup accounts 62 Given the parties deposit on asset's general account the following amount: 63 | party | asset | amount | 64 | party1 | BTC | 10000 | 65 | party2 | BTC | 10000 | 66 | aux | BTC | 100000 | 67 | aux2 | BTC | 100000 | 68 | lpprov | BTC | 90000000 | 69 70 When the parties submit the following liquidity provision: 71 | id | party | market id | commitment amount | fee | lp type | 72 | lp1 | lpprov | ETH/DEC19 | 90000000 | 0.1 | submission | 73 | lp1 | lpprov | ETH/DEC19 | 90000000 | 0.1 | submission | 74 And the parties place the following pegged iceberg orders: 75 | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | 76 | lpprov | ETH/DEC19 | 2 | 1 | buy | BID | 50 | 100 | 77 | lpprov | ETH/DEC19 | 2 | 1 | sell | ASK | 50 | 100 | 78 # place auxiliary orders so we always have best bid and best offer as to not trigger the liquidity auction 79 When the parties place the following orders: 80 | party | market id | side | volume | price | resulting trades | type | tif | 81 | aux | ETH/DEC19 | buy | 1 | 1 | 0 | TYPE_LIMIT | TIF_GTC | 82 | aux | ETH/DEC19 | sell | 1 | 10001 | 0 | TYPE_LIMIT | TIF_GTC | 83 | aux2 | ETH/DEC19 | buy | 1 | 2 | 0 | TYPE_LIMIT | TIF_GTC | 84 | aux | ETH/DEC19 | sell | 1 | 2 | 0 | TYPE_LIMIT | TIF_GTC | 85 Then the opening auction period ends for market "ETH/DEC19" 86 And the trading mode should be "TRADING_MODE_CONTINUOUS" for the market "ETH/DEC19" 87 88 Given the parties place the following orders: 89 | party | market id | side | volume | price | resulting trades | type | tif | reference | 90 | party2 | ETH/DEC19 | buy | 1 | 10 | 0 | TYPE_LIMIT | TIF_GTC | best-bid | 91 | party2 | ETH/DEC19 | sell | 1 | 20 | 0 | TYPE_LIMIT | TIF_GTC | best-ask | 92 When the parties place the following iceberg orders: 93 | party | market id | side | volume | price | resulting trades | type | tif | peak size | minimum visible size | reference | 94 | party1 | ETH/DEC19 | buy | 10 | 5 | 0 | TYPE_LIMIT | TIF_GTC | 3 | 1 | ordinary-iceberg | 95 And the parties place the following pegged iceberg orders: 96 | party | market id | side | volume | resulting trades | type | tif | peak size | minimum visible size | pegged reference | offset | reference | 97 | party1 | ETH/DEC19 | buy | 10 | 0 | TYPE_LIMIT | TIF_GTC | 2 | 1 | BID | 1 | pegged-iceberg | 98 Then the order book should have the following volumes for market "ETH/DEC19": 99 | side | price | volume | 100 | buy | 5 | 3 | 101 | buy | 9 | 2 | 102 | buy | 10 | 1 | 103 104 # Move best-bid and check pegged iceberg order is re-priced 105 When the parties amend the following orders: 106 | party | reference | price | size delta | tif | 107 | party2 | best-bid | 9 | 0 | TIF_GTC | 108 Then the order book should have the following volumes for market "ETH/DEC19": 109 | side | price | volume | 110 | buy | 5 | 3 | 111 | buy | 8 | 2 | 112 | buy | 9 | 1 | 113 114 115 @iceberg 116 Scenario: Iceberg order margin calculation (0014-ORDT-011) 117 # setup accounts 118 Given the parties deposit on asset's general account the following amount: 119 | party | asset | amount | 120 | party1 | BTC | 10000 | 121 | party2 | BTC | 10000 | 122 | aux | BTC | 100000 | 123 | aux2 | BTC | 100000 | 124 | lpprov | BTC | 90000000 | 125 126 When the parties submit the following liquidity provision: 127 | id | party | market id | commitment amount | fee | lp type | 128 | lp1 | lpprov | ETH/DEC19 | 90000000 | 0.1 | submission | 129 | lp1 | lpprov | ETH/DEC19 | 90000000 | 0.1 | submission | 130 And the parties place the following pegged iceberg orders: 131 | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | 132 | lpprov | ETH/DEC19 | 2 | 1 | buy | BID | 50 | 100 | 133 | lpprov | ETH/DEC19 | 2 | 1 | sell | ASK | 50 | 100 | 134 # place auxiliary orders so we always have best bid and best offer as to not trigger the liquidity auction 135 When the parties place the following orders: 136 | party | market id | side | volume | price | resulting trades | type | tif | 137 | aux | ETH/DEC19 | buy | 1 | 1 | 0 | TYPE_LIMIT | TIF_GTC | 138 | aux | ETH/DEC19 | sell | 1 | 10001 | 0 | TYPE_LIMIT | TIF_GTC | 139 | aux2 | ETH/DEC19 | buy | 1 | 2 | 0 | TYPE_LIMIT | TIF_GTC | 140 | aux | ETH/DEC19 | sell | 1 | 2 | 0 | TYPE_LIMIT | TIF_GTC | 141 Then the opening auction period ends for market "ETH/DEC19" 142 And the trading mode should be "TRADING_MODE_CONTINUOUS" for the market "ETH/DEC19" 143 144 When the parties place the following iceberg orders: 145 | party | market id | side | volume | price | resulting trades | type | tif | peak size | minimum visible size | only | reference | 146 | party1 | ETH/DEC19 | buy | 100 | 10 | 0 | TYPE_LIMIT | TIF_GTC | 10 | 5 | post | iceberg-order-1 | 147 148 Then the iceberg orders should have the following states: 149 | party | market id | side | visible volume | price | status | reserved volume | 150 | party1 | ETH/DEC19 | buy | 10 | 10 | STATUS_ACTIVE | 90 | 151 152 And the parties should have the following account balances: 153 | party | asset | market id | margin | general | 154 | party1 | BTC | ETH/DEC19 | 26 | 9974 | 155 156 # And another party places a normal limit order for the same price and quantity, then the same margin should be taken 157 When the parties place the following orders: 158 | party | market id | side | volume | price | resulting trades | type | tif | reference | 159 | party2 | ETH/DEC19 | buy | 100 | 10 | 0 | TYPE_LIMIT | TIF_GTC | normal-limit-order-1 | 160 161 And the parties should have the following account balances: 162 | party | asset | market id | margin | general | 163 | party2 | BTC | ETH/DEC19 | 26 | 9974 | 164 165 # Now we cancel the iceberg order 166 Then the parties cancel the following orders: 167 | party | reference | 168 | party1 | iceberg-order-1 | 169 170 # And the margin taken for the iceberg order is released 171 And the parties should have the following account balances: 172 | party | asset | market id | margin | general | 173 | party1 | BTC | ETH/DEC19 | 0 | 10000 | 174 175 # Now we cancel the normal limit order 176 Then the parties cancel the following orders: 177 | party | reference | 178 | party2 | normal-limit-order-1 | 179 180 # And the margin taken for the normal limit order is released 181 And the parties should have the following account balances: 182 | party | asset | market id | margin | general | 183 | party2 | BTC | ETH/DEC19 | 0 | 10000 | 184 185 186 @iceberg 187 Scenario: iceberg basic refresh (0014-ORDT-012) 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 | aux | BTC | 100000 | 194 | aux2 | BTC | 100000 | 195 | lpprov | BTC | 90000000 | 196 197 When the parties submit the following liquidity provision: 198 | id | party | market id | commitment amount | fee | lp type | 199 | lp1 | lpprov | ETH/DEC19 | 90000000 | 0.1 | submission | 200 | lp1 | lpprov | ETH/DEC19 | 90000000 | 0.1 | submission | 201 And the parties place the following pegged iceberg orders: 202 | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | 203 | lpprov | ETH/DEC19 | 2 | 1 | buy | BID | 50 | 100 | 204 | lpprov | ETH/DEC19 | 2 | 1 | sell | ASK | 50 | 100 | 205 # place auxiliary orders so we always have best bid and best offer as to not trigger the liquidity auction 206 When the parties place the following orders: 207 | party | market id | side | volume | price | resulting trades | type | tif | 208 | aux | ETH/DEC19 | buy | 1 | 1 | 0 | TYPE_LIMIT | TIF_GTC | 209 | aux | ETH/DEC19 | sell | 1 | 10001 | 0 | TYPE_LIMIT | TIF_GTC | 210 | aux2 | ETH/DEC19 | buy | 1 | 2 | 0 | TYPE_LIMIT | TIF_GTC | 211 | aux | ETH/DEC19 | sell | 1 | 2 | 0 | TYPE_LIMIT | TIF_GTC | 212 Then the opening auction period ends for market "ETH/DEC19" 213 And the trading mode should be "TRADING_MODE_CONTINUOUS" for the market "ETH/DEC19" 214 215 When the parties place the following iceberg orders: 216 | party | market id | side | volume | price | resulting trades | type | tif | peak size | minimum visible size | 217 | party1 | ETH/DEC19 | buy | 100 | 10 | 0 | TYPE_LIMIT | TIF_GTC | 10 | 5 | 218 219 Then the iceberg orders should have the following states: 220 | party | market id | side | visible volume | price | status | reserved volume | 221 | party1 | ETH/DEC19 | buy | 10 | 10 | STATUS_ACTIVE | 90 | 222 223 When the parties place the following orders: 224 | party | market id | side | volume | price | resulting trades | type | tif | 225 | party2 | ETH/DEC19 | sell | 6 | 10 | 1 | TYPE_LIMIT | TIF_GTC | 226 227 Then the iceberg orders should have the following states: 228 | party | market id | side | visible volume | price | status | reserved volume | 229 | party1 | ETH/DEC19 | buy | 10 | 10 | STATUS_ACTIVE | 84 | 230 231 @iceberg 232 Scenario: iceberg refreshes leaving auction 233 # setup accounts 234 Given the parties deposit on asset's general account the following amount: 235 | party | asset | amount | 236 | party1 | BTC | 10000 | 237 | party2 | BTC | 10000 | 238 | aux | BTC | 100000 | 239 | aux2 | BTC | 100000 | 240 | lpprov | BTC | 90000000 | 241 242 When the parties submit the following liquidity provision: 243 | id | party | market id | commitment amount | fee | lp type | 244 | lp1 | lpprov | ETH/DEC19 | 90000000 | 0.1 | submission | 245 | lp1 | lpprov | ETH/DEC19 | 90000000 | 0.1 | submission | 246 And the parties place the following pegged iceberg orders: 247 | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | 248 | lpprov | ETH/DEC19 | 2 | 1 | buy | BID | 50 | 100 | 249 | lpprov | ETH/DEC19 | 2 | 1 | sell | ASK | 50 | 100 | 250 # place an iceberg order that will trade when coming out of auction 251 When the parties place the following iceberg orders: 252 | party | market id | side | volume | price | resulting trades | type | tif | peak size | minimum visible size | 253 | party1 | ETH/DEC19 | buy | 100 | 2 | 0 | TYPE_LIMIT | TIF_GTC | 10 | 10 | 254 255 # place auxiliary orders so we always have best bid and best offer as to not trigger the liquidity auction 256 When the parties place the following orders: 257 | party | market id | side | volume | price | resulting trades | type | tif | 258 | aux | ETH/DEC19 | buy | 1 | 1 | 0 | TYPE_LIMIT | TIF_GTC | 259 | aux | ETH/DEC19 | sell | 1 | 10001 | 0 | TYPE_LIMIT | TIF_GTC | 260 | aux2 | ETH/DEC19 | buy | 1 | 2 | 0 | TYPE_LIMIT | TIF_GTC | 261 | aux | ETH/DEC19 | sell | 1 | 2 | 0 | TYPE_LIMIT | TIF_GTC | 262 Then the opening auction period ends for market "ETH/DEC19" 263 And the trading mode should be "TRADING_MODE_CONTINUOUS" for the market "ETH/DEC19" 264 265 Then the iceberg orders should have the following states: 266 | party | market id | side | visible volume | price | status | reserved volume | 267 | party1 | ETH/DEC19 | buy | 10 | 2 | STATUS_ACTIVE | 89 | 268 269 270 @iceberg 271 Scenario: Iceberg order trading during auction uncrossing (0014-ORDT-013) 272 # setup accounts 273 Given the parties deposit on asset's general account the following amount: 274 | party | asset | amount | 275 | party1 | BTC | 10000 | 276 | party2 | BTC | 10000 | 277 | party3 | BTC | 10000 | 278 | aux | BTC | 100000 | 279 | lpprov | BTC | 90000000 | 280 281 And the parties submit the following liquidity provision: 282 | id | party | market id | commitment amount | fee | lp type | 283 | lp1 | lpprov | ETH/DEC19 | 90000000 | 0.1 | submission | 284 | lp1 | lpprov | ETH/DEC19 | 90000000 | 0.1 | submission | 285 And the parties place the following pegged iceberg orders: 286 | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | 287 | lpprov | ETH/DEC19 | 2 | 1 | buy | BID | 50 | 100 | 288 | lpprov | ETH/DEC19 | 2 | 1 | sell | ASK | 50 | 100 | 289 290 # place auxiliary orders so we always have best bid and best offer as to not trigger the liquidity auction 291 And the parties place the following orders: 292 | party | market id | side | volume | price | resulting trades | type | tif | 293 | aux | ETH/DEC19 | buy | 1 | 1 | 0 | TYPE_LIMIT | TIF_GTC | 294 | aux | ETH/DEC19 | sell | 1 | 10001 | 0 | TYPE_LIMIT | TIF_GTC | 295 296 Given the parties place the following iceberg orders: 297 | party | market id | side | volume | price | resulting trades | type | tif | reference | peak size | minimum visible size | 298 | party1 | ETH/DEC19 | buy | 10 | 2 | 0 | TYPE_LIMIT | TIF_GTC | this-order-1 | 2 | 1 | 299 And the parties place the following orders: 300 | party | market id | side | volume | price | resulting trades | type | tif | 301 | party2 | ETH/DEC19 | buy | 8 | 2 | 0 | TYPE_LIMIT | TIF_GTC | 302 When the parties place the following iceberg orders: 303 | party | market id | side | volume | price | resulting trades | type | tif | reference | peak size | minimum visible size | 304 | party3 | ETH/DEC19 | sell | 10 | 2 | 0 | TYPE_LIMIT | TIF_GTC | this-order-1 | 2 | 1 | 305 And the opening auction period ends for market "ETH/DEC19" 306 Then the trading mode should be "TRADING_MODE_CONTINUOUS" for the market "ETH/DEC19" 307 # Check only the display volume of party1 is filled and is refreshed at the back of the que 308 And the following trades should be executed: 309 | buyer | seller | price | size | 310 | party1 | party3 | 2 | 2 | 311 # Check the remaining volume of party3s iceberg is filled in a single trade with party2 312 And the following trades should be executed: 313 | buyer | seller | price | size | 314 | party2 | party3 | 2 | 8 | 315 316 317 @iceberg 318 @margin 319 Scenario: Iceberg increase size success and not losing position in order book (0014-ORDT-023) 320 # setup accounts 321 Given the parties deposit on asset's general account the following amount: 322 | party | asset | amount | 323 | party1 | BTC | 10000 | 324 | party2 | BTC | 10000 | 325 | party3 | BTC | 10000 | 326 | aux | BTC | 100000 | 327 | aux2 | BTC | 100000 | 328 | lpprov | BTC | 90000000 | 329 330 When the parties submit the following liquidity provision: 331 | id | party | market id | commitment amount | fee | lp type | 332 | lp1 | lpprov | ETH/DEC19 | 90000000 | 0.1 | submission | 333 | lp1 | lpprov | ETH/DEC19 | 90000000 | 0.1 | submission | 334 And the parties place the following pegged iceberg orders: 335 | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | 336 | lpprov | ETH/DEC19 | 2 | 1 | buy | BID | 50 | 100 | 337 | lpprov | ETH/DEC19 | 2 | 1 | sell | ASK | 50 | 100 | 338 # place auxiliary orders so we always have best bid and best offer as to not trigger the liquidity auction 339 When the parties place the following orders: 340 | party | market id | side | volume | price | resulting trades | type | tif | 341 | aux | ETH/DEC19 | buy | 1 | 1 | 0 | TYPE_LIMIT | TIF_GTC | 342 | aux | ETH/DEC19 | sell | 1 | 10001 | 0 | TYPE_LIMIT | TIF_GTC | 343 | aux2 | ETH/DEC19 | buy | 1 | 2 | 0 | TYPE_LIMIT | TIF_GTC | 344 | aux | ETH/DEC19 | sell | 1 | 2 | 0 | TYPE_LIMIT | TIF_GTC | 345 Then the opening auction period ends for market "ETH/DEC19" 346 And the trading mode should be "TRADING_MODE_CONTINUOUS" for the market "ETH/DEC19" 347 348 And the parties place the following iceberg orders: 349 | party | market id | side | volume | price | resulting trades | type | tif | reference | peak size | minimum visible size | 350 | party1 | ETH/DEC19 | sell | 50 | 2 | 0 | TYPE_LIMIT | TIF_GTC | this-order-1 | 2 | 1 | 351 | party2 | ETH/DEC19 | sell | 5 | 2 | 0 | TYPE_LIMIT | TIF_GTC | this-order-2 | 2 | 1 | 352 353 And the parties should have the following account balances: 354 | party | asset | market id | margin | general | 355 | party1 | BTC | ETH/DEC19 | 12 | 9988 | 356 357 # increasing size 358 Then the parties amend the following orders: 359 | party | reference | price | size delta | tif | 360 | party1 | this-order-1 | 2 | 50 | TIF_GTC | 361 362 # the visible is the same and only the reserve amount has increased 363 Then the iceberg orders should have the following states: 364 | party | market id | side | visible volume | price | status | reserved volume | 365 | party1 | ETH/DEC19 | sell | 2 | 2 | STATUS_ACTIVE | 98 | 366 367 And the parties should have the following account balances: 368 | party | asset | market id | margin | general | 369 | party1 | BTC | ETH/DEC19 | 24 | 9976 | 370 371 # matching the order now 372 # this should match with the size 2 order of party1 373 Then the parties place the following orders: 374 | party | market id | side | volume | price | resulting trades | type | tif | reference | 375 | party3 | ETH/DEC19 | buy | 2 | 2 | 1 | TYPE_LIMIT | TIF_GTC | party3 | 376 377 Then the following trades should be executed: 378 | buyer | seller | price | size | 379 | party3 | party1 | 2 | 2 | 380 381 @iceberg 382 Scenario: Iceberg decrease size success and not losing position in order book (0014-ORDT-024) (0014-ORDT-025) 383 # setup accounts 384 Given the parties deposit on asset's general account the following amount: 385 | party | asset | amount | 386 | party1 | BTC | 10000 | 387 | party2 | BTC | 10000 | 388 | party3 | BTC | 10000 | 389 | aux | BTC | 100000 | 390 | aux2 | BTC | 100000 | 391 | lpprov | BTC | 90000000 | 392 393 When the parties submit the following liquidity provision: 394 | id | party | market id | commitment amount | fee | lp type | 395 | lp1 | lpprov | ETH/DEC19 | 90000000 | 0.1 | submission | 396 | lp1 | lpprov | ETH/DEC19 | 90000000 | 0.1 | submission | 397 And the parties place the following pegged iceberg orders: 398 | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | 399 | lpprov | ETH/DEC19 | 2 | 1 | buy | BID | 50 | 100 | 400 | lpprov | ETH/DEC19 | 2 | 1 | sell | ASK | 50 | 100 | 401 # place auxiliary orders so we always have best bid and best offer as to not trigger the liquidity auction 402 When the parties place the following orders: 403 | party | market id | side | volume | price | resulting trades | type | tif | 404 | aux | ETH/DEC19 | buy | 1 | 1 | 0 | TYPE_LIMIT | TIF_GTC | 405 | aux | ETH/DEC19 | sell | 1 | 10001 | 0 | TYPE_LIMIT | TIF_GTC | 406 | aux2 | ETH/DEC19 | buy | 1 | 2 | 0 | TYPE_LIMIT | TIF_GTC | 407 | aux | ETH/DEC19 | sell | 1 | 2 | 0 | TYPE_LIMIT | TIF_GTC | 408 Then the opening auction period ends for market "ETH/DEC19" 409 And the trading mode should be "TRADING_MODE_CONTINUOUS" for the market "ETH/DEC19" 410 411 And the parties place the following iceberg orders: 412 | party | market id | side | volume | price | resulting trades | type | tif | reference | peak size | minimum visible size | 413 | party1 | ETH/DEC19 | sell | 100 | 2 | 0 | TYPE_LIMIT | TIF_GTC | this-order-1 | 2 | 1 | 414 | party2 | ETH/DEC19 | sell | 100 | 2 | 0 | TYPE_LIMIT | TIF_GTC | this-order-2 | 2 | 1 | 415 416 And the parties should have the following account balances: 417 | party | asset | market id | margin | general | 418 | party1 | BTC | ETH/DEC19 | 24 | 9976 | 419 420 # decreasing size 421 Then the parties amend the following orders: 422 | party | reference | price | size delta | tif | 423 | party1 | this-order-1 | 2 | -50 | TIF_GTC | 424 425 # the visible is the same and only the reserve amount has decreased 426 Then the iceberg orders should have the following states: 427 | party | market id | side | visible volume | price | status | reserved volume | 428 | party1 | ETH/DEC19 | sell | 2 | 2 | STATUS_ACTIVE | 48 | 429 430 And the parties should have the following account balances: 431 | party | asset | market id | margin | general | 432 | party1 | BTC | ETH/DEC19 | 12 | 9988 | 433 434 # matching the order now 435 # this should match with the size 2 order of party1 436 Then the parties place the following orders: 437 | party | market id | side | volume | price | resulting trades | type | tif | reference | 438 | party3 | ETH/DEC19 | buy | 2 | 2 | 1 | TYPE_LIMIT | TIF_GTC | party3 | 439 440 Then the following trades should be executed: 441 | buyer | seller | price | size | 442 | party3 | party1 | 2 | 2 | 443 444 @iceberg 445 Scenario: Iceberg amend price reenters aggressively 446 # setup accounts 447 Given the parties deposit on asset's general account the following amount: 448 | party | asset | amount | 449 | party1 | BTC | 10000 | 450 | party2 | BTC | 10000 | 451 | aux | BTC | 100000 | 452 | aux2 | BTC | 100000 | 453 | lpprov | BTC | 90000000 | 454 455 When the parties submit the following liquidity provision: 456 | id | party | market id | commitment amount | fee | lp type | 457 | lp1 | lpprov | ETH/DEC19 | 90000000 | 0.1 | submission | 458 | lp1 | lpprov | ETH/DEC19 | 90000000 | 0.1 | submission | 459 And the parties place the following pegged iceberg orders: 460 | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | 461 | lpprov | ETH/DEC19 | 2 | 1 | buy | BID | 50 | 100 | 462 | lpprov | ETH/DEC19 | 2 | 1 | sell | ASK | 50 | 100 | 463 # place auxiliary orders so we always have best bid and best offer as to not trigger the liquidity auction 464 When the parties place the following orders: 465 | party | market id | side | volume | price | resulting trades | type | tif | 466 | aux | ETH/DEC19 | buy | 1 | 1 | 0 | TYPE_LIMIT | TIF_GTC | 467 | aux | ETH/DEC19 | sell | 1 | 10001 | 0 | TYPE_LIMIT | TIF_GTC | 468 | aux2 | ETH/DEC19 | buy | 1 | 2 | 0 | TYPE_LIMIT | TIF_GTC | 469 | aux | ETH/DEC19 | sell | 1 | 2 | 0 | TYPE_LIMIT | TIF_GTC | 470 Then the opening auction period ends for market "ETH/DEC19" 471 And the trading mode should be "TRADING_MODE_CONTINUOUS" for the market "ETH/DEC19" 472 473 And the parties place the following iceberg orders: 474 | party | market id | side | volume | price | resulting trades | type | tif | reference | peak size | minimum visible size | 475 | party1 | ETH/DEC19 | sell | 16 | 5 | 0 | TYPE_LIMIT | TIF_GTC | this-order-1 | 5 | 1 | 476 | party2 | ETH/DEC19 | buy | 10 | 2 | 0 | TYPE_LIMIT | TIF_GTC | this-order-2 | 2 | 1 | 477 478 # amend the buy order so that it will cross with the other iceberg 479 Then the parties amend the following orders: 480 | party | reference | price | size delta | tif | 481 | party2 | this-order-2 | 5 | 0 | TIF_GTC | 482 483 # the amended iceberg will trade aggressively and be fully consumed 484 Then the iceberg orders should have the following states: 485 | party | market id | side | visible volume | price | status | reserved volume | 486 | party1 | ETH/DEC19 | sell | 5 | 5 | STATUS_ACTIVE | 1 | 487 | party2 | ETH/DEC19 | buy | 0 | 5 | STATUS_FILLED | 0 | 488 489 490 @margin 491 @iceberg 492 Scenario: Cancelling an active iceberg order (0014-ORDT-026) 493 # setup accounts 494 Given the parties deposit on asset's general account the following amount: 495 | party | asset | amount | 496 | party1 | BTC | 10000 | 497 | aux | BTC | 100000 | 498 | aux2 | BTC | 100000 | 499 | lpprov | BTC | 90000000 | 500 501 When the parties submit the following liquidity provision: 502 | id | party | market id | commitment amount | fee | lp type | 503 | lp1 | lpprov | ETH/DEC19 | 90000000 | 0.1 | submission | 504 | lp1 | lpprov | ETH/DEC19 | 90000000 | 0.1 | submission | 505 And the parties place the following pegged iceberg orders: 506 | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | 507 | lpprov | ETH/DEC19 | 2 | 1 | buy | BID | 50 | 100 | 508 | lpprov | ETH/DEC19 | 2 | 1 | sell | ASK | 50 | 100 | 509 # place auxiliary orders so we always have best bid and best offer as to not trigger the liquidity auction 510 When the parties place the following orders: 511 | party | market id | side | volume | price | resulting trades | type | tif | 512 | aux | ETH/DEC19 | buy | 1 | 1 | 0 | TYPE_LIMIT | TIF_GTC | 513 | aux | ETH/DEC19 | sell | 1 | 10001 | 0 | TYPE_LIMIT | TIF_GTC | 514 | aux2 | ETH/DEC19 | buy | 1 | 2 | 0 | TYPE_LIMIT | TIF_GTC | 515 | aux | ETH/DEC19 | sell | 1 | 2 | 0 | TYPE_LIMIT | TIF_GTC | 516 Then the opening auction period ends for market "ETH/DEC19" 517 And the trading mode should be "TRADING_MODE_CONTINUOUS" for the market "ETH/DEC19" 518 519 Given the parties place the following iceberg orders: 520 | party | market id | side | volume | price | resulting trades | type | tif | peak size | minimum visible size | reference | 521 | party1 | ETH/DEC19 | buy | 100 | 5 | 0 | TYPE_LIMIT | TIF_GTC | 2 | 1 | iceberg | 522 And the parties should have the following account balances: 523 | party | asset | market id | margin | general | 524 | party1 | BTC | ETH/DEC19 | 26 | 9974 | 525 And the order book should have the following volumes for market "ETH/DEC19": 526 | side | price | volume | 527 | buy | 5 | 2 | 528 When the parties cancel the following orders: 529 | party | reference | 530 | party1 | iceberg | 531 # The order should be cancelled 532 Then the iceberg orders should have the following states: 533 | party | market id | side | visible volume | price | status | reserved volume | reference | 534 | party1 | ETH/DEC19 | buy | 2 | 5 | STATUS_CANCELLED | 98 | iceberg | 535 # The margin released 536 And the parties should have the following account balances: 537 | party | asset | market id | margin | general | 538 | party1 | BTC | ETH/DEC19 | 0 | 10000 | 539 # And the order book updated 540 And the order book should have the following volumes for market "ETH/DEC19": 541 | side | price | volume | 542 | buy | 5 | 0 | 543 544 545 @iceberg 546 Scenario: An aggressive iceberg order crosses an order with volume > iceberg volume (0014-ORDT-027) 547 # setup accounts 548 Given the parties deposit on asset's general account the following amount: 549 | party | asset | amount | 550 | party1 | BTC | 10000 | 551 | party2 | BTC | 10000 | 552 | aux | BTC | 100000 | 553 | aux2 | BTC | 100000 | 554 | lpprov | BTC | 90000000 | 555 556 When the parties submit the following liquidity provision: 557 | id | party | market id | commitment amount | fee | lp type | 558 | lp1 | lpprov | ETH/DEC19 | 90000000 | 0.1 | submission | 559 | lp1 | lpprov | ETH/DEC19 | 90000000 | 0.1 | submission | 560 And the parties place the following pegged iceberg orders: 561 | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | 562 | lpprov | ETH/DEC19 | 2 | 1 | buy | BID | 50 | 100 | 563 | lpprov | ETH/DEC19 | 2 | 1 | sell | ASK | 50 | 100 | 564 # place auxiliary orders so we always have best bid and best offer as to not trigger the liquidity auction 565 When the parties place the following orders: 566 | party | market id | side | volume | price | resulting trades | type | tif | 567 | aux | ETH/DEC19 | buy | 1 | 1 | 0 | TYPE_LIMIT | TIF_GTC | 568 | aux | ETH/DEC19 | sell | 1 | 10001 | 0 | TYPE_LIMIT | TIF_GTC | 569 | aux2 | ETH/DEC19 | buy | 1 | 2 | 0 | TYPE_LIMIT | TIF_GTC | 570 | aux | ETH/DEC19 | sell | 1 | 2 | 0 | TYPE_LIMIT | TIF_GTC | 571 Then the opening auction period ends for market "ETH/DEC19" 572 And the trading mode should be "TRADING_MODE_CONTINUOUS" for the market "ETH/DEC19" 573 574 Given the parties place the following orders: 575 | party | market id | side | volume | price | resulting trades | type | tif | 576 | party2 | ETH/DEC19 | sell | 15 | 5 | 0 | TYPE_LIMIT | TIF_GTC | 577 When the parties place the following iceberg orders: 578 | party | market id | side | volume | price | resulting trades | type | tif | peak size | minimum visible size | 579 | party1 | ETH/DEC19 | buy | 10 | 5 | 1 | TYPE_LIMIT | TIF_GTC | 2 | 1 | 580 Then the following trades should be executed: 581 | buyer | seller | price | size | 582 | party1 | party2 | 5 | 10 | 583 And the iceberg orders should have the following states: 584 | party | market id | side | visible volume | price | status | reserved volume | 585 | party1 | ETH/DEC19 | buy | 0 | 5 | STATUS_FILLED | 0 | 586 587 588 @iceberg 589 Scenario: An aggressive iceberg order crosses an order with volume < iceberg volume (0014-ORDT-028) 590 # setup accounts 591 Given the parties deposit on asset's general account the following amount: 592 | party | asset | amount | 593 | party1 | BTC | 10000 | 594 | party2 | BTC | 10000 | 595 | aux | BTC | 100000 | 596 | aux2 | BTC | 100000 | 597 | lpprov | BTC | 90000000 | 598 599 When the parties submit the following liquidity provision: 600 | id | party | market id | commitment amount | fee | lp type | 601 | lp1 | lpprov | ETH/DEC19 | 90000000 | 0.1 | submission | 602 | lp1 | lpprov | ETH/DEC19 | 90000000 | 0.1 | submission | 603 And the parties place the following pegged iceberg orders: 604 | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | 605 | lpprov | ETH/DEC19 | 2 | 1 | buy | BID | 50 | 100 | 606 | lpprov | ETH/DEC19 | 2 | 1 | sell | ASK | 50 | 100 | 607 # place auxiliary orders so we always have best bid and best offer as to not trigger the liquidity auction 608 When the parties place the following orders: 609 | party | market id | side | volume | price | resulting trades | type | tif | 610 | aux | ETH/DEC19 | buy | 1 | 1 | 0 | TYPE_LIMIT | TIF_GTC | 611 | aux | ETH/DEC19 | sell | 1 | 10001 | 0 | TYPE_LIMIT | TIF_GTC | 612 | aux2 | ETH/DEC19 | buy | 1 | 2 | 0 | TYPE_LIMIT | TIF_GTC | 613 | aux | ETH/DEC19 | sell | 1 | 2 | 0 | TYPE_LIMIT | TIF_GTC | 614 Then the opening auction period ends for market "ETH/DEC19" 615 And the trading mode should be "TRADING_MODE_CONTINUOUS" for the market "ETH/DEC19" 616 617 Given the parties place the following orders: 618 | party | market id | side | volume | price | resulting trades | type | tif | 619 | party2 | ETH/DEC19 | sell | 10 | 5 | 0 | TYPE_LIMIT | TIF_GTC | 620 When the parties place the following iceberg orders: 621 | party | market id | side | volume | price | resulting trades | type | tif | peak size | minimum visible size | 622 | party1 | ETH/DEC19 | buy | 15 | 5 | 1 | TYPE_LIMIT | TIF_GTC | 2 | 1 | 623 Then the following trades should be executed: 624 | buyer | seller | price | size | 625 | party1 | party2 | 5 | 10 | 626 And the iceberg orders should have the following states: 627 | party | market id | side | visible volume | price | status | reserved volume | 628 | party1 | ETH/DEC19 | buy | 2 | 5 | STATUS_ACTIVE | 3 | 629 630 631 @iceberg 632 Scenario: A passive iceberg order (the only order at the price level) crosses an order with volume > iceberg volume (0014-ORDT-029) 633 # setup accounts 634 Given the parties deposit on asset's general account the following amount: 635 | party | asset | amount | 636 | party1 | BTC | 10000 | 637 | party2 | BTC | 10000 | 638 | aux | BTC | 100000 | 639 | aux2 | BTC | 100000 | 640 | lpprov | BTC | 90000000 | 641 642 When the parties submit the following liquidity provision: 643 | id | party | market id | commitment amount | fee | lp type | 644 | lp1 | lpprov | ETH/DEC19 | 90000000 | 0.1 | submission | 645 | lp1 | lpprov | ETH/DEC19 | 90000000 | 0.1 | submission | 646 And the parties place the following pegged iceberg orders: 647 | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | 648 | lpprov | ETH/DEC19 | 2 | 1 | buy | BID | 50 | 100 | 649 | lpprov | ETH/DEC19 | 2 | 1 | sell | ASK | 50 | 100 | 650 # place auxiliary orders so we always have best bid and best offer as to not trigger the liquidity auction 651 When the parties place the following orders: 652 | party | market id | side | volume | price | resulting trades | type | tif | 653 | aux | ETH/DEC19 | buy | 1 | 1 | 0 | TYPE_LIMIT | TIF_GTC | 654 | aux | ETH/DEC19 | sell | 1 | 10001 | 0 | TYPE_LIMIT | TIF_GTC | 655 | aux2 | ETH/DEC19 | buy | 1 | 2 | 0 | TYPE_LIMIT | TIF_GTC | 656 | aux | ETH/DEC19 | sell | 1 | 2 | 0 | TYPE_LIMIT | TIF_GTC | 657 Then the opening auction period ends for market "ETH/DEC19" 658 And the trading mode should be "TRADING_MODE_CONTINUOUS" for the market "ETH/DEC19" 659 660 Given the parties place the following iceberg orders: 661 | party | market id | side | volume | price | resulting trades | type | tif | peak size | minimum visible size | 662 | party1 | ETH/DEC19 | buy | 10 | 5 | 0 | TYPE_LIMIT | TIF_GTC | 2 | 1 | 663 When the parties place the following orders: 664 | party | market id | side | volume | price | resulting trades | type | tif | 665 | party2 | ETH/DEC19 | sell | 15 | 5 | 1 | TYPE_LIMIT | TIF_GTC | 666 Then the following trades should be executed: 667 | buyer | seller | price | size | 668 | party1 | party2 | 5 | 10 | 669 And the iceberg orders should have the following states: 670 | party | market id | side | visible volume | price | status | reserved volume | 671 | party1 | ETH/DEC19 | buy | 0 | 5 | STATUS_FILLED | 0 | 672 673 674 @iceberg 675 Scenario: A passive iceberg order (one of multiple orders at the price level) crosses an order with volume > iceberg volume (0014-ORDT-030) 676 # setup accounts 677 Given the parties deposit on asset's general account the following amount: 678 | party | asset | amount | 679 | party1 | BTC | 10000 | 680 | party2 | BTC | 10000 | 681 | party3 | BTC | 10000 | 682 | party4 | BTC | 10000 | 683 | aux | BTC | 100000 | 684 | aux2 | BTC | 100000 | 685 | lpprov | BTC | 90000000 | 686 687 When the parties submit the following liquidity provision: 688 | id | party | market id | commitment amount | fee | lp type | 689 | lp1 | lpprov | ETH/DEC19 | 90000000 | 0.1 | submission | 690 | lp1 | lpprov | ETH/DEC19 | 90000000 | 0.1 | submission | 691 And the parties place the following pegged iceberg orders: 692 | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | 693 | lpprov | ETH/DEC19 | 2 | 1 | buy | BID | 50 | 100 | 694 | lpprov | ETH/DEC19 | 2 | 1 | sell | ASK | 50 | 100 | 695 # place auxiliary orders so we always have best bid and best offer as to not trigger the liquidity auction 696 When the parties place the following orders: 697 | party | market id | side | volume | price | resulting trades | type | tif | 698 | aux | ETH/DEC19 | buy | 1 | 1 | 0 | TYPE_LIMIT | TIF_GTC | 699 | aux | ETH/DEC19 | sell | 1 | 10001 | 0 | TYPE_LIMIT | TIF_GTC | 700 | aux2 | ETH/DEC19 | buy | 1 | 2 | 0 | TYPE_LIMIT | TIF_GTC | 701 | aux | ETH/DEC19 | sell | 1 | 2 | 0 | TYPE_LIMIT | TIF_GTC | 702 Then the opening auction period ends for market "ETH/DEC19" 703 And the trading mode should be "TRADING_MODE_CONTINUOUS" for the market "ETH/DEC19" 704 705 Given the parties place the following iceberg orders: 706 | party | market id | side | volume | price | resulting trades | type | tif | peak size | minimum visible size | 707 | party1 | ETH/DEC19 | buy | 10 | 5 | 0 | TYPE_LIMIT | TIF_GTC | 2 | 1 | 708 And the parties place the following orders: 709 | party | market id | side | volume | price | resulting trades | type | tif | 710 | party2 | ETH/DEC19 | buy | 7 | 5 | 0 | TYPE_LIMIT | TIF_GTC | 711 | party3 | ETH/DEC19 | buy | 7 | 5 | 0 | TYPE_LIMIT | TIF_GTC | 712 When the parties place the following orders: 713 | party | market id | side | volume | price | resulting trades | type | tif | 714 | party4 | ETH/DEC19 | sell | 15 | 5 | 3 | TYPE_LIMIT | TIF_GTC | 715 Then the following trades should be executed: 716 | buyer | seller | price | size | 717 | party1 | party4 | 5 | 2 | 718 | party2 | party4 | 5 | 7 | 719 | party3 | party4 | 5 | 6 | 720 And the iceberg orders should have the following states: 721 | party | market id | side | visible volume | price | status | reserved volume | 722 | party1 | ETH/DEC19 | buy | 2 | 5 | STATUS_ACTIVE | 6 | 723 724 725 @iceberg 726 Scenario: An aggressive iceberg order crosses orders where the cumulative volume > iceberg volume (0014-ORDT-031) 727 # setup accounts 728 Given the parties deposit on asset's general account the following amount: 729 | party | asset | amount | 730 | party1 | BTC | 10000 | 731 | party2 | BTC | 10000 | 732 | party3 | BTC | 10000 | 733 | party4 | BTC | 10000 | 734 | aux | BTC | 100000 | 735 | aux2 | BTC | 100000 | 736 | lpprov | BTC | 90000000 | 737 738 When the parties submit the following liquidity provision: 739 | id | party | market id | commitment amount | fee | lp type | 740 | lp1 | lpprov | ETH/DEC19 | 90000000 | 0.1 | submission | 741 | lp1 | lpprov | ETH/DEC19 | 90000000 | 0.1 | submission | 742 And the parties place the following pegged iceberg orders: 743 | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | 744 | lpprov | ETH/DEC19 | 2 | 1 | buy | BID | 50 | 100 | 745 | lpprov | ETH/DEC19 | 2 | 1 | sell | ASK | 50 | 100 | 746 # place auxiliary orders so we always have best bid and best offer as to not trigger the liquidity auction 747 When the parties place the following orders: 748 | party | market id | side | volume | price | resulting trades | type | tif | 749 | aux | ETH/DEC19 | buy | 1 | 1 | 0 | TYPE_LIMIT | TIF_GTC | 750 | aux | ETH/DEC19 | sell | 1 | 10001 | 0 | TYPE_LIMIT | TIF_GTC | 751 | aux2 | ETH/DEC19 | buy | 1 | 2 | 0 | TYPE_LIMIT | TIF_GTC | 752 | aux | ETH/DEC19 | sell | 1 | 2 | 0 | TYPE_LIMIT | TIF_GTC | 753 Then the opening auction period ends for market "ETH/DEC19" 754 And the trading mode should be "TRADING_MODE_CONTINUOUS" for the market "ETH/DEC19" 755 756 Given the parties place the following orders: 757 | party | market id | side | volume | price | resulting trades | type | tif | 758 | party2 | ETH/DEC19 | sell | 30 | 5 | 0 | TYPE_LIMIT | TIF_GTC | 759 | party3 | ETH/DEC19 | sell | 40 | 5 | 0 | TYPE_LIMIT | TIF_GTC | 760 | party4 | ETH/DEC19 | sell | 50 | 5 | 0 | TYPE_LIMIT | TIF_GTC | 761 When the parties place the following iceberg orders: 762 | party | market id | side | volume | price | resulting trades | type | tif | peak size | minimum visible size | 763 | party1 | ETH/DEC19 | buy | 100 | 5 | 3 | TYPE_LIMIT | TIF_GTC | 2 | 1 | 764 Then the following trades should be executed: 765 | buyer | seller | price | size | 766 | party1 | party2 | 5 | 30 | 767 | party1 | party3 | 5 | 40 | 768 | party1 | party4 | 5 | 30 | 769 And the iceberg orders should have the following states: 770 | party | market id | side | visible volume | price | status | reserved volume | 771 | party1 | ETH/DEC19 | buy | 0 | 5 | STATUS_FILLED | 0 | 772 773 774 @iceberg 775 Scenario: An aggressive iceberg order crosses orders where the cumulative volume < iceberg volume (0014-ORDT-032) 776 # setup accounts 777 Given the parties deposit on asset's general account the following amount: 778 | party | asset | amount | 779 | party1 | BTC | 10000 | 780 | party2 | BTC | 10000 | 781 | party3 | BTC | 10000 | 782 | party4 | BTC | 10000 | 783 | aux | BTC | 100000 | 784 | aux2 | BTC | 100000 | 785 | lpprov | BTC | 90000000 | 786 787 When the parties submit the following liquidity provision: 788 | id | party | market id | commitment amount | fee | lp type | 789 | lp1 | lpprov | ETH/DEC19 | 90000000 | 0.1 | submission | 790 | lp1 | lpprov | ETH/DEC19 | 90000000 | 0.1 | submission | 791 And the parties place the following pegged iceberg orders: 792 | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | 793 | lpprov | ETH/DEC19 | 2 | 1 | buy | BID | 50 | 100 | 794 | lpprov | ETH/DEC19 | 2 | 1 | sell | ASK | 50 | 100 | 795 # place auxiliary orders so we always have best bid and best offer as to not trigger the liquidity auction 796 When the parties place the following orders: 797 | party | market id | side | volume | price | resulting trades | type | tif | 798 | aux | ETH/DEC19 | buy | 1 | 1 | 0 | TYPE_LIMIT | TIF_GTC | 799 | aux | ETH/DEC19 | sell | 1 | 10001 | 0 | TYPE_LIMIT | TIF_GTC | 800 | aux2 | ETH/DEC19 | buy | 1 | 2 | 0 | TYPE_LIMIT | TIF_GTC | 801 | aux | ETH/DEC19 | sell | 1 | 2 | 0 | TYPE_LIMIT | TIF_GTC | 802 Then the opening auction period ends for market "ETH/DEC19" 803 And the trading mode should be "TRADING_MODE_CONTINUOUS" for the market "ETH/DEC19" 804 805 Given the parties place the following orders: 806 | party | market id | side | volume | price | resulting trades | type | tif | 807 | party2 | ETH/DEC19 | sell | 30 | 5 | 0 | TYPE_LIMIT | TIF_GTC | 808 | party3 | ETH/DEC19 | sell | 40 | 5 | 0 | TYPE_LIMIT | TIF_GTC | 809 When the parties place the following iceberg orders: 810 | party | market id | side | volume | price | resulting trades | type | tif | peak size | minimum visible size | 811 | party1 | ETH/DEC19 | buy | 100 | 5 | 2 | TYPE_LIMIT | TIF_GTC | 2 | 1 | 812 Then the following trades should be executed: 813 | buyer | seller | price | size | 814 | party1 | party2 | 5 | 30 | 815 | party1 | party3 | 5 | 40 | 816 And the iceberg orders should have the following states: 817 | party | market id | side | visible volume | price | status | reserved volume | 818 | party1 | ETH/DEC19 | buy | 2 | 5 | STATUS_ACTIVE | 28 | 819 820 821 @iceberg 822 Scenario: Amended order trades with iceberg order triggering a refresh (0014-ORDT-033) 823 # setup accounts 824 Given the parties deposit on asset's general account the following amount: 825 | party | asset | amount | 826 | party1 | BTC | 10000 | 827 | party2 | BTC | 10000 | 828 | party3 | BTC | 10000 | 829 | party4 | BTC | 10000 | 830 | aux | BTC | 100000 | 831 | aux2 | BTC | 100000 | 832 | lpprov | BTC | 90000000 | 833 834 When the parties submit the following liquidity provision: 835 | id | party | market id | commitment amount | fee | lp type | 836 | lp1 | lpprov | ETH/DEC19 | 90000000 | 0.1 | submission | 837 | lp1 | lpprov | ETH/DEC19 | 90000000 | 0.1 | submission | 838 And the parties place the following pegged iceberg orders: 839 | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | 840 | lpprov | ETH/DEC19 | 2 | 1 | buy | BID | 50 | 100 | 841 | lpprov | ETH/DEC19 | 2 | 1 | sell | ASK | 50 | 100 | 842 # place auxiliary orders so we always have best bid and best offer as to not trigger the liquidity auction 843 When the parties place the following orders: 844 | party | market id | side | volume | price | resulting trades | type | tif | 845 | aux | ETH/DEC19 | buy | 1 | 1 | 0 | TYPE_LIMIT | TIF_GTC | 846 | aux | ETH/DEC19 | sell | 1 | 10001 | 0 | TYPE_LIMIT | TIF_GTC | 847 | aux2 | ETH/DEC19 | buy | 1 | 2 | 0 | TYPE_LIMIT | TIF_GTC | 848 | aux | ETH/DEC19 | sell | 1 | 2 | 0 | TYPE_LIMIT | TIF_GTC | 849 Then the opening auction period ends for market "ETH/DEC19" 850 And the trading mode should be "TRADING_MODE_CONTINUOUS" for the market "ETH/DEC19" 851 852 Given the parties place the following iceberg orders: 853 | party | market id | side | volume | price | resulting trades | type | tif | peak size | minimum visible size | 854 | party1 | ETH/DEC19 | sell | 10 | 5 | 0 | TYPE_LIMIT | TIF_GTC | 2 | 1 | 855 And the parties place the following orders: 856 | party | market id | side | volume | price | resulting trades | type | tif | reference | 857 | party2 | ETH/DEC19 | buy | 7 | 4 | 0 | TYPE_LIMIT | TIF_GTC | order-to-amend | 858 | party3 | ETH/DEC19 | sell | 5 | 5 | 0 | TYPE_LIMIT | TIF_GTC | | 859 When the parties amend the following orders: 860 | party | reference | price | size delta | tif | 861 | party2 | order-to-amend | 5 | 0 | TIF_GTC | 862 Then the following trades should be executed: 863 | buyer | seller | price | size | 864 | party2 | party1 | 5 | 2 | 865 | party2 | party3 | 5 | 5 | 866 And the iceberg orders should have the following states: 867 | party | market id | side | visible volume | price | status | reserved volume | 868 | party1 | ETH/DEC19 | sell | 2 | 5 | STATUS_ACTIVE | 6 | 869 870 871 @iceberg 872 Scenario: Attempting to wash trade with iceberg orders (0014-ORDT-034) 873 # setup accounts 874 Given the parties deposit on asset's general account the following amount: 875 | party | asset | amount | 876 | party1 | BTC | 10000 | 877 | party2 | BTC | 10000 | 878 | party3 | BTC | 10000 | 879 | party4 | BTC | 10000 | 880 | aux | BTC | 100000 | 881 | aux2 | BTC | 100000 | 882 | lpprov | BTC | 90000000 | 883 884 When the parties submit the following liquidity provision: 885 | id | party | market id | commitment amount | fee | lp type | 886 | lp1 | lpprov | ETH/DEC19 | 90000000 | 0.1 | submission | 887 | lp1 | lpprov | ETH/DEC19 | 90000000 | 0.1 | submission | 888 And the parties place the following pegged iceberg orders: 889 | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | 890 | lpprov | ETH/DEC19 | 2 | 1 | buy | BID | 50 | 100 | 891 | lpprov | ETH/DEC19 | 2 | 1 | sell | ASK | 50 | 100 | 892 # place auxiliary orders so we always have best bid and best offer as to not trigger the liquidity auction 893 When the parties place the following orders: 894 | party | market id | side | volume | price | resulting trades | type | tif | 895 | aux | ETH/DEC19 | buy | 1 | 1 | 0 | TYPE_LIMIT | TIF_GTC | 896 | aux | ETH/DEC19 | sell | 1 | 10001 | 0 | TYPE_LIMIT | TIF_GTC | 897 | aux2 | ETH/DEC19 | buy | 1 | 2 | 0 | TYPE_LIMIT | TIF_GTC | 898 | aux | ETH/DEC19 | sell | 1 | 2 | 0 | TYPE_LIMIT | TIF_GTC | 899 Then the opening auction period ends for market "ETH/DEC19" 900 And the trading mode should be "TRADING_MODE_CONTINUOUS" for the market "ETH/DEC19" 901 902 Given the parties place the following orders: 903 | party | market id | side | volume | price | resulting trades | type | tif | 904 | party2 | ETH/DEC19 | sell | 5 | 5 | 0 | TYPE_LIMIT | TIF_GTC | 905 | party3 | ETH/DEC19 | sell | 5 | 5 | 0 | TYPE_LIMIT | TIF_GTC | 906 And the parties place the following iceberg orders: 907 | party | market id | side | volume | price | resulting trades | type | tif | peak size | minimum visible size | reference | 908 | party1 | ETH/DEC19 | sell | 5 | 5 | 0 | TYPE_LIMIT | TIF_GTC | 2 | 1 | iceberg | 909 When the parties place the following orders: 910 | party | market id | side | volume | price | resulting trades | type | tif | reference | 911 | party1 | ETH/DEC19 | buy | 20 | 5 | 2 | TYPE_LIMIT | TIF_GTC | normal | 912 Then the following trades should be executed: 913 | buyer | seller | price | size | 914 | party1 | party2 | 5 | 5 | 915 | party1 | party3 | 5 | 5 | 916 And the orders should have the following states: 917 | party | market id | reference | side | volume | remaining | price | status | 918 | party1 | ETH/DEC19 | normal | buy | 20 | 10 | 5 | STATUS_PARTIALLY_FILLED | 919 And the iceberg orders should have the following states: 920 | party | market id | reference | side | visible volume | price | status | reserved volume | 921 | party1 | ETH/DEC19 | iceberg | sell | 2 | 5 | STATUS_ACTIVE | 3 | 922 923 @iceberg 924 Scenario: An order matches multiple icebergs at the same level where the order volume < cumulative iceberg display volume (0014-ORDT-037) 925 # setup accounts 926 Given the parties deposit on asset's general account the following amount: 927 | party | asset | amount | 928 | party1 | BTC | 10000 | 929 | party2 | BTC | 10000 | 930 | party3 | BTC | 10000 | 931 | party4 | BTC | 10000 | 932 | aux | BTC | 100000 | 933 | aux2 | BTC | 100000 | 934 | lpprov | BTC | 90000000 | 935 936 When the parties submit the following liquidity provision: 937 | id | party | market id | commitment amount | fee | lp type | 938 | lp1 | lpprov | ETH/DEC19 | 90000000 | 0.1 | submission | 939 | lp1 | lpprov | ETH/DEC19 | 90000000 | 0.1 | submission | 940 And the parties place the following pegged iceberg orders: 941 | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | 942 | lpprov | ETH/DEC19 | 2 | 1 | buy | BID | 50 | 100 | 943 | lpprov | ETH/DEC19 | 2 | 1 | sell | ASK | 50 | 100 | 944 # place auxiliary orders so we always have best bid and best offer as to not trigger the liquidity auction 945 When the parties place the following orders: 946 | party | market id | side | volume | price | resulting trades | type | tif | 947 | aux | ETH/DEC19 | buy | 1 | 1 | 0 | TYPE_LIMIT | TIF_GTC | 948 | aux | ETH/DEC19 | sell | 1 | 10001 | 0 | TYPE_LIMIT | TIF_GTC | 949 | aux2 | ETH/DEC19 | buy | 1 | 2 | 0 | TYPE_LIMIT | TIF_GTC | 950 | aux | ETH/DEC19 | sell | 1 | 2 | 0 | TYPE_LIMIT | TIF_GTC | 951 Then the opening auction period ends for market "ETH/DEC19" 952 And the trading mode should be "TRADING_MODE_CONTINUOUS" for the market "ETH/DEC19" 953 954 Given the parties place the following iceberg orders: 955 | party | market id | side | volume | price | resulting trades | type | tif | peak size | minimum visible size | reference | 956 | party1 | ETH/DEC19 | sell | 200 | 5 | 0 | TYPE_LIMIT | TIF_GTC | 2 | 1 | iceberg | 957 | party2 | ETH/DEC19 | sell | 100 | 5 | 0 | TYPE_LIMIT | TIF_GTC | 2 | 1 | iceberg | 958 | party3 | ETH/DEC19 | sell | 100 | 5 | 0 | TYPE_LIMIT | TIF_GTC | 2 | 1 | iceberg | 959 When the parties place the following orders: 960 | party | market id | side | volume | price | resulting trades | type | tif | 961 | party4 | ETH/DEC19 | buy | 300 | 5 | 3 | TYPE_LIMIT | TIF_GTC | 962 Then the following trades should be executed: 963 | buyer | seller | price | size | 964 | party4 | party1 | 5 | 150 | 965 | party4 | party2 | 5 | 75 | 966 | party4 | party3 | 5 | 75 | 967 And the iceberg orders should have the following states: 968 | party | market id | side | visible volume | price | status | reserved volume | 969 | party1 | ETH/DEC19 | sell | 2 | 5 | STATUS_ACTIVE | 48 | 970 | party2 | ETH/DEC19 | sell | 2 | 5 | STATUS_ACTIVE | 23 | 971 | party3 | ETH/DEC19 | sell | 2 | 5 | STATUS_ACTIVE | 23 | 972 973 974 @iceberg 975 Scenario: An order matches multiple icebergs at the same level where the order volume > cumulative iceberg display volume (0014-ORDT-038) 976 # setup accounts 977 Given the parties deposit on asset's general account the following amount: 978 | party | asset | amount | 979 | party1 | BTC | 10000 | 980 | party2 | BTC | 10000 | 981 | party3 | BTC | 10000 | 982 | party4 | BTC | 10000 | 983 | aux | BTC | 100000 | 984 | aux2 | BTC | 100000 | 985 | lpprov | BTC | 90000000 | 986 987 When the parties submit the following liquidity provision: 988 | id | party | market id | commitment amount | fee | lp type | 989 | lp1 | lpprov | ETH/DEC19 | 90000000 | 0.1 | submission | 990 | lp1 | lpprov | ETH/DEC19 | 90000000 | 0.1 | submission | 991 And the parties place the following pegged iceberg orders: 992 | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | 993 | lpprov | ETH/DEC19 | 2 | 1 | buy | BID | 50 | 100 | 994 | lpprov | ETH/DEC19 | 2 | 1 | sell | ASK | 50 | 100 | 995 # place auxiliary orders so we always have best bid and best offer as to not trigger the liquidity auction 996 When the parties place the following orders: 997 | party | market id | side | volume | price | resulting trades | type | tif | 998 | aux | ETH/DEC19 | buy | 1 | 1 | 0 | TYPE_LIMIT | TIF_GTC | 999 | aux | ETH/DEC19 | sell | 1 | 10001 | 0 | TYPE_LIMIT | TIF_GTC | 1000 | aux2 | ETH/DEC19 | buy | 1 | 2 | 0 | TYPE_LIMIT | TIF_GTC | 1001 | aux | ETH/DEC19 | sell | 1 | 2 | 0 | TYPE_LIMIT | TIF_GTC | 1002 Then the opening auction period ends for market "ETH/DEC19" 1003 And the trading mode should be "TRADING_MODE_CONTINUOUS" for the market "ETH/DEC19" 1004 1005 Given the parties place the following iceberg orders: 1006 | party | market id | side | volume | price | resulting trades | type | tif | peak size | minimum visible size | reference | 1007 | party1 | ETH/DEC19 | sell | 200 | 5 | 0 | TYPE_LIMIT | TIF_GTC | 2 | 1 | iceberg | 1008 | party2 | ETH/DEC19 | sell | 100 | 5 | 0 | TYPE_LIMIT | TIF_GTC | 2 | 1 | iceberg | 1009 | party3 | ETH/DEC19 | sell | 100 | 5 | 0 | TYPE_LIMIT | TIF_GTC | 2 | 1 | iceberg | 1010 When the parties place the following orders: 1011 | party | market id | side | volume | price | resulting trades | type | tif | 1012 | party4 | ETH/DEC19 | buy | 600 | 5 | 3 | TYPE_LIMIT | TIF_GTC | 1013 Then the following trades should be executed: 1014 | buyer | seller | price | size | 1015 | party4 | party1 | 5 | 200 | 1016 | party4 | party2 | 5 | 100 | 1017 | party4 | party3 | 5 | 100 | 1018 1019 1020 @iceberg 1021 Scenario: Pegged orders are not re-priced as price-levels are consumed (0014-ORDT-039) 1022 # setup accounts 1023 Given the parties deposit on asset's general account the following amount: 1024 | party | asset | amount | 1025 | party1 | BTC | 10000 | 1026 | party2 | BTC | 10000 | 1027 | party3 | BTC | 10000 | 1028 | aux | BTC | 100000 | 1029 | aux2 | BTC | 100000 | 1030 | lpprov | BTC | 90000000 | 1031 1032 When the parties submit the following liquidity provision: 1033 | id | party | market id | commitment amount | fee | lp type | 1034 | lp1 | lpprov | ETH/DEC19 | 90000000 | 0.1 | submission | 1035 | lp1 | lpprov | ETH/DEC19 | 90000000 | 0.1 | submission | 1036 And the parties place the following pegged iceberg orders: 1037 | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | 1038 | lpprov | ETH/DEC19 | 2 | 1 | buy | BID | 50 | 100 | 1039 | lpprov | ETH/DEC19 | 2 | 1 | sell | ASK | 50 | 100 | 1040 # place auxiliary orders so we always have best bid and best offer as to not trigger the liquidity auction 1041 When the parties place the following orders: 1042 | party | market id | side | volume | price | resulting trades | type | tif | 1043 | aux | ETH/DEC19 | buy | 1 | 1 | 0 | TYPE_LIMIT | TIF_GTC | 1044 | aux | ETH/DEC19 | sell | 1 | 10001 | 0 | TYPE_LIMIT | TIF_GTC | 1045 | aux2 | ETH/DEC19 | buy | 1 | 2 | 0 | TYPE_LIMIT | TIF_GTC | 1046 | aux | ETH/DEC19 | sell | 1 | 2 | 0 | TYPE_LIMIT | TIF_GTC | 1047 Then the opening auction period ends for market "ETH/DEC19" 1048 And the trading mode should be "TRADING_MODE_CONTINUOUS" for the market "ETH/DEC19" 1049 1050 Given the parties place the following orders: 1051 | party | market id | side | volume | price | resulting trades | type | tif | 1052 | party2 | ETH/DEC19 | buy | 10 | 5 | 0 | TYPE_LIMIT | TIF_GTC | 1053 | party2 | ETH/DEC19 | buy | 1 | 10 | 0 | TYPE_LIMIT | TIF_GTC | 1054 | party2 | ETH/DEC19 | sell | 1 | 20 | 0 | TYPE_LIMIT | TIF_GTC | 1055 | party2 | ETH/DEC19 | sell | 10 | 25 | 0 | TYPE_LIMIT | TIF_GTC | 1056 And the parties place the following pegged iceberg orders: 1057 | party | market id | side | volume | resulting trades | type | tif | peak size | minimum visible size | pegged reference | offset | 1058 | party1 | ETH/DEC19 | buy | 10 | 0 | TYPE_LIMIT | TIF_GTC | 2 | 1 | BID | 1 | 1059 And the parties place the following pegged orders: 1060 | party | market id | side | volume | pegged reference | offset | 1061 | party1 | ETH/DEC19 | buy | 1 | BID | 2 | 1062 When the parties place the following orders: 1063 | party | market id | side | volume | price | resulting trades | type | tif | 1064 | party3 | ETH/DEC19 | sell | 12 | 8 | 3 | TYPE_LIMIT | TIF_GTC | 1065 # Check pegged ordinary and iceberg orders are not re-priced as the best-bid price-level is consumed 1066 Then the following trades should be executed: 1067 | buyer | seller | price | size | 1068 | party2 | party3 | 10 | 1 | 1069 | party1 | party3 | 9 | 10 | 1070 | party1 | party3 | 8 | 1 |