code.vegaprotocol.io/vega@v0.79.0/core/integration/features/spot/orders/0074-BTCH-016.feature (about)

     1  Feature: An instruction which is valid at the start of the batch execution but becomes invalid before it is executed should fail. (0074-BTCH-016)
     2    Background:
     3      Given time is updated to "2024-01-01T00:00:00Z"
     4  
     5      Given the following network parameters are set:
     6        | name                                                | value |
     7        | network.markPriceUpdateMaximumFrequency             | 0s    |
     8        | market.value.windowLength                           | 1h    |
     9      
    10      Given the following assets are registered:
    11        | id  | decimal places |
    12        | ETH | 2              |
    13        | BTC | 2              |
    14  
    15      Given the fees configuration named "fees-config-1":
    16        | maker fee | infrastructure fee |
    17        | 0.01      | 0.03               |
    18      Given the log normal risk model named "lognormal-risk-model-1":
    19        | risk aversion | tau  | mu | r   | sigma |
    20        | 0.001         | 0.01 | 0  | 0.0 | 1.2   |
    21      And the price monitoring named "price-monitoring-1":
    22        | horizon | probability | auction extension |
    23        | 3600    | 0.999       | 10                |
    24  
    25      And the spot markets:
    26        | id      | name    | base asset | quote asset | risk model             | auction duration | fees          | price monitoring   | decimal places | position decimal places | sla params    |
    27        | BTC/ETH | BTC/ETH | BTC        | ETH         | lognormal-risk-model-1 | 1                | fees-config-1 | price-monitoring-1 | 2              | 2                       | default-basic |
    28  
    29      # setup accounts
    30      Given the parties deposit on asset's general account the following amount:
    31        | party  | asset | amount |
    32        | party1 | ETH   | 10000  |
    33        | party2 | ETH   | 10000  |
    34        | party4 | BTC   | 100    |
    35        | party5 | BTC   | 100    |
    36      And the average block duration is "1"
    37  
    38      # Place some orders to get out of auction
    39      And the parties place the following orders:
    40        | party  | market id | side | volume | price | resulting trades | type       | tif     |
    41        | party1 | BTC/ETH   | buy  | 1      | 1000  | 0                | TYPE_LIMIT | TIF_GTC |
    42        | party5 | BTC/ETH   | sell | 1      | 1000  | 0                | TYPE_LIMIT | TIF_GTC |
    43  
    44      And the opening auction period ends for market "BTC/ETH"
    45      When the network moves ahead "1" blocks
    46      Then the trading mode should be "TRADING_MODE_CONTINUOUS" for the market "BTC/ETH"
    47      And the mark price should be "1000" for the market "BTC/ETH"
    48  
    49      And the market data for the market "BTC/ETH" should be:
    50        | mark price | trading mode            | horizon | min bound | max bound | target stake | supplied stake | open interest |
    51        | 1000       | TRADING_MODE_CONTINUOUS | 3600    | 959       | 1042      | 0            | 0              | 0             |
    52  
    53    Scenario: A batch consisting of two limit order placements p1-buy1 and pl-buy2 where the party has enough balance to place
    54              either of them individually but not both should place C1 but reject C2.
    55  
    56      Then the party "party1" starts a batch instruction
    57        Then the party "party1" adds the following orders to a batch:
    58          | market id | side | volume | price | type        | tif     | reference | error |
    59          | BTC/ETH   | buy  | 500    | 1000  | TYPE_LIMIT  | TIF_GTC | p1-buy1   |       |
    60          | BTC/ETH   | buy  | 500    | 1000  | TYPE_LIMIT  | TIF_GTC | p1-buy2   |       |
    61      Then the party "party1" submits their batch instruction with error "party does not have sufficient balance to cover the trade and fees"
    62      When the network moves ahead "1" blocks
    63  
    64      Then the orders should have the following states:
    65        | party  | market id | side | price | remaining | volume | reference | status         |
    66        | party1 | BTC/ETH   | buy  | 1000  | 500       | 500    | p1-buy1   | STATUS_ACTIVE  | 
    67  
    68  
    69    Scenario: A batch transaction containing aggressive limit order C1 which moves the market into price monitoring auction
    70              and a C2 which is marked GFN (good for normal) should execute C1 but reject C2.
    71  
    72      And the parties place the following orders:
    73        | party  | market id | side | volume | price | resulting trades | type       | tif     |
    74        | party5 | BTC/ETH   | sell | 1      | 1050  | 0                | TYPE_LIMIT | TIF_GTC |
    75  
    76      Then the party "party1" starts a batch instruction
    77        Then the party "party1" adds the following orders to a batch:
    78          | market id | side | volume | price | type        | tif     | reference | error |
    79          | BTC/ETH   | buy  | 1      | 1050  | TYPE_LIMIT  | TIF_GTC | p1-buy1   |       |
    80          | BTC/ETH   | buy  | 1      | 1000  | TYPE_LIMIT  | TIF_GFN | p1-buy2   |       |
    81      Then the party "party1" submits their batch instruction with error "gfn order received during auction trading"
    82      When the network moves ahead "1" blocks
    83  
    84      # Both orders rest on the book in the auction instead of crossing
    85      Then the orders should have the following states:
    86        | party  | market id | side | price | remaining | volume | reference | status         |
    87        | party1 | BTC/ETH   | buy  | 1050  | 1         | 1      | p1-buy1   | STATUS_ACTIVE  | 
    88