code.vegaprotocol.io/vega@v0.79.0/core/integration/features/spot/orders/0014-ORDT-094.feature (about)

     1  Feature: Spot market
     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 | 3              |
    14        | BTC | 3              |
    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        | 360000  | 0.999       | 1                 |
    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        | party3 | BTC   | 100    |
    36        | party4 | BTC   | 100    |
    37        | party5 | BTC   | 100    |
    38      And the average block duration is "1"
    39  
    40      # Place some orders to get out of auction
    41      And the parties place the following orders:
    42        | party  | market id | side | volume | price | resulting trades | type       | tif     |
    43        | party1 | BTC/ETH   | buy  | 1      | 1000  | 0                | TYPE_LIMIT | TIF_GFA |
    44        | party5 | BTC/ETH   | sell | 10     | 1000  | 0                | TYPE_LIMIT | TIF_GTC |
    45  
    46      Then "party1" should have holding account balance of "100" for asset "ETH"
    47      Then "party5" should have holding account balance of "100" for asset "BTC"
    48  
    49      And the opening auction period ends for market "BTC/ETH"
    50      When the network moves ahead "1" blocks
    51      Then the trading mode should be "TRADING_MODE_CONTINUOUS" for the market "BTC/ETH"
    52      And the mark price should be "1000" for the market "BTC/ETH"
    53  
    54    Scenario: In Spot market, for multiple iceberg orders submitted as a batch of orders with a mix of ordinary limit orders and market orders,
    55              the iceberg orders are processed atomically and the order book volume and price, holding calculations , order status are all
    56              correct. (0014-ORDT-094)
    57  
    58  
    59      # Party1 has no pending buys so their holding account will be empty
    60      Then "party1" should have holding account balance of "0" for asset "ETH"
    61      # Party5 has 9 pending sells so they will have 9 in their holding account
    62      Then "party5" should have holding account balance of "90" for asset "BTC"
    63  
    64  
    65      # Create a batch with iceberg and normal orders
    66      Then the party "party1" starts a batch instruction
    67  
    68      Then the party "party1" adds the following orders to a batch:
    69        | market id | side | volume | price | type        | tif     | reference | expires in |
    70        | BTC/ETH   | buy  | 1      | 0     | TYPE_MARKET | TIF_IOC | p1-buy1   |            |
    71        | BTC/ETH   | buy  | 1      | 999   | TYPE_LIMIT  | TIF_GTC | p1-buy2   |            |
    72        | BTC/ETH   | buy  | 1      | 999   | TYPE_LIMIT  | TIF_GFN | p1-buy3   |            |
    73        | BTC/ETH   | buy  | 1      | 999   | TYPE_LIMIT  | TIF_GTT | p1-buy4   | 3600       |
    74  
    75      Then the party "party1" adds the following iceberg orders to a batch:
    76        | market id | side | volume | price | type       | tif     | reference | peak size | minimum visible size |
    77        | BTC/ETH   | buy  | 4      | 999   | TYPE_LIMIT | TIF_GTC | p1-ib-1   | 2         | 1                    |
    78        | BTC/ETH   | buy  | 4      | 1000  | TYPE_LIMIT | TIF_GTC | p1-ib-2   | 2         | 1                    |
    79  
    80      Then the party "party1" submits their batch instruction
    81  
    82      # 2 trades should occur
    83      Then the following trades should be executed:
    84        | buyer  | seller | price | size |
    85        | party1 | party5 | 1000  | 1    |
    86        | party1 | party5 | 1000  | 4    |
    87  
    88      Then the orders should have the following states:
    89        | party  | market id | side | price | remaining | volume | reference | status          |
    90        | party1 | BTC/ETH   | buy  | 0     | 0         | 1      | p1-buy1   | STATUS_FILLED  | 
    91        | party1 | BTC/ETH   | buy  | 999   | 1         | 1      | p1-buy2   | STATUS_ACTIVE  | 
    92        | party1 | BTC/ETH   | buy  | 999   | 1         | 1      | p1-buy3   | STATUS_ACTIVE  | 
    93        | party1 | BTC/ETH   | buy  | 999   | 1         | 1      | p1-buy4   | STATUS_ACTIVE  | 
    94        | party1 | BTC/ETH   | buy  | 999   | 2         | 4      | p1-ib-1   | STATUS_ACTIVE  | 
    95        | party1 | BTC/ETH   | buy  | 1000  | 0         | 4      | p1-ib-2   | STATUS_FILLED  | 
    96  
    97      Then "party1" should have holding account balance of "696" for asset "ETH"
    98      Then "party5" should have holding account balance of "40" for asset "BTC"
    99  
   100  
   101  
   102    Scenario: In Spot market, for multiple iceberg orders submitted as a batch of orders with a mix of ordinary limit orders and market orders,
   103              the iceberg orders are processed atomically and the order book volume and price, holding calculations , order status are all
   104              correct. (0014-ORDT-094)
   105  
   106  
   107      # Party1 has no pending buys so their holding account will be empty
   108      Then "party1" should have holding account balance of "0" for asset "ETH"
   109      # Party5 has 9 pending sells so they will have 9 in their holding account
   110      Then "party5" should have holding account balance of "90" for asset "BTC"
   111  
   112      # Create a batch with only normal orders to make sure we get the same holding account values at the end
   113      Then the party "party1" starts a batch instruction
   114  
   115      Then the party "party1" adds the following orders to a batch:
   116        | market id | side | volume | price | type        | tif     | reference | expires in |
   117        | BTC/ETH   | buy  | 1      | 0     | TYPE_MARKET | TIF_IOC | p1-buy1   |            |
   118        | BTC/ETH   | buy  | 1      | 999   | TYPE_LIMIT  | TIF_GTC | p1-buy2   |            |
   119        | BTC/ETH   | buy  | 1      | 999   | TYPE_LIMIT  | TIF_GFN | p1-buy3   |            |
   120        | BTC/ETH   | buy  | 1      | 999   | TYPE_LIMIT  | TIF_GTT | p1-buy4   | 3600       |
   121        | BTC/ETH   | buy  | 4      | 999   | TYPE_LIMIT  | TIF_GTC | p1-buy5   |            |
   122        | BTC/ETH   | buy  | 4      | 1000  | TYPE_LIMIT  | TIF_GTC | p1-buy6   |            |
   123  
   124      Then the party "party1" submits their batch instruction
   125  
   126      # 2 trades should occur
   127      Then the following trades should be executed:
   128        | buyer  | seller | price | size |
   129        | party1 | party5 | 1000  | 1    |
   130        | party1 | party5 | 1000  | 4    |
   131  
   132      Then the orders should have the following states:
   133        | party  | market id | side | price | remaining | volume | reference | status         |
   134        | party1 | BTC/ETH   | buy  | 0     | 0         | 1      | p1-buy1   | STATUS_FILLED  | 
   135        | party1 | BTC/ETH   | buy  | 999   | 1         | 1      | p1-buy2   | STATUS_ACTIVE  | 
   136        | party1 | BTC/ETH   | buy  | 999   | 1         | 1      | p1-buy3   | STATUS_ACTIVE  | 
   137        | party1 | BTC/ETH   | buy  | 999   | 1         | 1      | p1-buy4   | STATUS_ACTIVE  | 
   138        | party1 | BTC/ETH   | buy  | 999   | 4         | 4      | p1-buy5   | STATUS_ACTIVE  | 
   139        | party1 | BTC/ETH   | buy  | 1000  | 0         | 4      | p1-buy6   | STATUS_FILLED  | 
   140  
   141      Then "party1" should have holding account balance of "696" for asset "ETH"
   142      Then "party5" should have holding account balance of "40" for asset "BTC"