code.vegaprotocol.io/vega@v0.79.0/core/integration/features/spot/orders/0074-BTCH-019.feature (about) 1 Feature: Testing batch orders in spot markets 2 3 Background: 4 Given time is updated to "2024-01-01T00:00:00Z" 5 6 Given the following network parameters are set: 7 | name | value | 8 | network.markPriceUpdateMaximumFrequency | 0s | 9 | market.value.windowLength | 1h | 10 11 Given the following assets are registered: 12 | id | decimal places | 13 | ETH | 2 | 14 | BTC | 2 | 15 16 Given the fees configuration named "fees-config-1": 17 | maker fee | infrastructure fee | 18 | 0.01 | 0.03 | 19 Given the log normal risk model named "lognormal-risk-model-1": 20 | risk aversion | tau | mu | r | sigma | 21 | 0.001 | 0.01 | 0 | 0.0 | 1.2 | 22 And the price monitoring named "price-monitoring-1": 23 | horizon | probability | auction extension | 24 | 3600 | 0.999 | 10 | 25 26 And the spot markets: 27 | id | name | base asset | quote asset | risk model | auction duration | fees | price monitoring | decimal places | position decimal places | sla params | 28 | BTC/ETH | BTC/ETH | BTC | ETH | lognormal-risk-model-1 | 1 | fees-config-1 | price-monitoring-1 | 2 | 2 | default-basic | 29 30 # setup accounts 31 Given the parties deposit on asset's general account the following amount: 32 | party | asset | amount | 33 | party1 | ETH | 10000 | 34 | party2 | ETH | 10000 | 35 | party4 | BTC | 100 | 36 | party5 | BTC | 100 | 37 And the average block duration is "1" 38 39 # Place some orders to get out of auction 40 And the parties place the following orders: 41 | party | market id | side | volume | price | resulting trades | type | tif | 42 | party1 | BTC/ETH | buy | 1 | 1000 | 0 | TYPE_LIMIT | TIF_GTC | 43 | party5 | BTC/ETH | sell | 1 | 1000 | 0 | TYPE_LIMIT | TIF_GTC | 44 45 And the opening auction period ends for market "BTC/ETH" 46 When the network moves ahead "1" blocks 47 Then the trading mode should be "TRADING_MODE_CONTINUOUS" for the market "BTC/ETH" 48 And the mark price should be "1000" for the market "BTC/ETH" 49 50 And the market data for the market "BTC/ETH" should be: 51 | mark price | trading mode | horizon | min bound | max bound | target stake | supplied stake | open interest | 52 | 1000 | TRADING_MODE_CONTINUOUS | 3600 | 959 | 1042 | 0 | 0 | 0 | 53 54 @OrdCan 55 Scenario: Funds released by cancellations or amendments within the batch should be immediately available 56 for later instructions (0074-BTCH-019) 57 58 # Try to place 3 orders, the third one should fail due to not having enough ETH to put into the holding account 59 When the parties place the following orders: 60 | party | market id | side | volume | price | resulting trades | type | tif | reference | error | 61 | party1 | BTC/ETH | buy | 400 | 1000 | 0 | TYPE_LIMIT | TIF_GTC | order-a | | 62 | party1 | BTC/ETH | buy | 400 | 1000 | 0 | TYPE_LIMIT | TIF_GTC | order-b | | 63 | party1 | BTC/ETH | buy | 400 | 1000 | 0 | TYPE_LIMIT | TIF_GTC | order-c | party does not have sufficient balance to cover the trade and fees | 64 65 Then "party1" should have holding account balance of "8000" for asset "ETH" 66 Then the orders should have the following states: 67 | party | market id | side | price | remaining | volume | reference | status | 68 | party1 | BTC/ETH | buy | 1000 | 400 | 400 | order-a | STATUS_ACTIVE | 69 | party1 | BTC/ETH | buy | 1000 | 400 | 400 | order-b | STATUS_ACTIVE | 70 71 # If I cancel an existing order and place a new one of the same size it should work 72 Then the party "party1" starts a batch instruction 73 Then the party "party1" adds the following cancels to a batch: 74 | market id | reference | 75 | BTC/ETH | order-a | 76 Then the party "party1" adds the following orders to a batch: 77 | market id | side | volume | price | type | tif | reference | 78 | BTC/ETH | buy | 400 | 1000 | TYPE_LIMIT | TIF_GTC | order-d | 79 Then the party "party1" submits their batch instruction 80 81 Then "party1" should have holding account balance of "8000" for asset "ETH" 82 Then the orders should have the following states: 83 | party | market id | side | price | remaining | volume | reference | status | 84 | party1 | BTC/ETH | buy | 1000 | 400 | 400 | order-a | STATUS_CANCELLED | 85 | party1 | BTC/ETH | buy | 1000 | 400 | 400 | order-b | STATUS_ACTIVE | 86 | party1 | BTC/ETH | buy | 1000 | 400 | 400 | order-d | STATUS_ACTIVE | 87 88 # If we amend an order to size 1, we should be able to place an order of 400 successfully. 89 Then the party "party1" starts a batch instruction 90 Then the party "party1" adds the following amends to a batch: 91 | market id | reference | price | size delta | tif | 92 | BTC/ETH | order-b | 1000 | -399 | TIF_GTC | 93 94 Then the party "party1" adds the following orders to a batch: 95 | market id | side | volume | price | type | tif | reference | 96 | BTC/ETH | buy | 400 | 1000 | TYPE_LIMIT | TIF_GTC | order-e | 97 Then the party "party1" submits their batch instruction 98 99 Then "party1" should have holding account balance of "8010" for asset "ETH" 100 Then the orders should have the following states: 101 | party | market id | side | price | remaining | volume | reference | status | 102 | party1 | BTC/ETH | buy | 1000 | 400 | 400 | order-a | STATUS_CANCELLED | 103 | party1 | BTC/ETH | buy | 1000 | 1 | 1 | order-b | STATUS_ACTIVE | 104 | party1 | BTC/ETH | buy | 1000 | 400 | 400 | order-d | STATUS_ACTIVE | 105 | party1 | BTC/ETH | buy | 1000 | 400 | 400 | order-e | STATUS_ACTIVE | 106 107 108 109