code.vegaprotocol.io/vega@v0.79.0/core/integration/features/spot/orders/0014-ORDT-095.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 | 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        | 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        | 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_GFA |
    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    Scenario: For an iceberg order sitting on the book, when a batch containing normal orders and other iceberg orders that will trades
    51              against the existing iceberg sitting on the book is sent, the resting iceberg order refreshes between each order in the
    52              batch (0014-ORDT-095)
    53  
    54      # Place an iceberg on the book ready to be matched by the later batch
    55      When the parties place the following iceberg orders:
    56        | party  | market id | side | volume | price | resulting trades | type       | tif     | peak size | minimum visible size | only | reference |
    57        | party5 | BTC/ETH   | sell | 10     | 1000  | 0                | TYPE_LIMIT | TIF_GTC | 2         | 2                    | post | iceberg1  |
    58  
    59      # Create a batch with iceberg and normal orders
    60      Then the party "party1" starts a batch instruction
    61  
    62      Then the party "party1" adds the following orders to a batch:
    63        | market id | side | volume | price | type        | tif     | reference |
    64        | BTC/ETH   | buy  | 2      | 1000  | TYPE_LIMIT  | TIF_GTC | p1-buy1   |
    65  
    66      Then the party "party1" adds the following iceberg orders to a batch:
    67        | market id | side | volume | price | type       | tif     | reference | peak size | minimum visible size |
    68        | BTC/ETH   | buy  | 5      | 1000  | TYPE_LIMIT | TIF_GTC | iceberg2  | 2         | 1                    |
    69  
    70      Then the party "party1" adds the following orders to a batch:
    71        | market id | side | volume | price | type        | tif     | reference |
    72        | BTC/ETH   | buy  | 3      | 1000  | TYPE_LIMIT  | TIF_GTC | p1-buy2   |
    73  
    74      Then the party "party1" submits their batch instruction
    75  
    76      Then the following trades should be executed:
    77        | buyer  | seller | price | size |
    78        | party1 | party5 | 1000  | 2    |
    79        | party1 | party5 | 1000  | 5    |
    80        | party1 | party5 | 1000  | 3    |
    81  
    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  | 0         | 2      | p1-buy1   | STATUS_FILLED  | 
    85        | party1 | BTC/ETH   | buy  | 1000  | 0         | 5      | iceberg2  | STATUS_FILLED  | 
    86        | party1 | BTC/ETH   | buy  | 1000  | 0         | 3      | p1-buy2   | STATUS_FILLED  | 
    87        | party5 | BTC/ETH   | sell | 1000  | 0         | 10     | iceberg1  | STATUS_FILLED  | 
    88  
    89  
    90  
    91