code.vegaprotocol.io/vega@v0.79.0/core/integration/features/spot/orders/0014-ORDT-093.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        | party3 | BTC   | 100    |
    36        | party4 | BTC   | 100    |
    37        | party5 | BTC   | 100    |
    38      And the average block duration is "1"
    39  
    40    Scenario: For an iceberg order that's submitted when the market is in auction, iceberg orders trade according to their behaviour if
    41              they were already on the book (trading first the visible size, then additional if the full visible price level is exhausted
    42              in the uncrossing) (0014-ORDT-093)
    43  
    44  
    45      # Place an iceberg order that we want to full match
    46      When the parties place the following iceberg orders:
    47        | party  | market id | side | volume | price | resulting trades | type       | tif     | peak size | minimum visible size | only | reference |
    48        | party1 | BTC/ETH   | buy  | 10     | 1000  | 0                | TYPE_LIMIT | TIF_GTC | 2         | 2                    | post | iceberg1  |
    49  
    50  
    51      # Place normal GFA orders to match with the full amount of the iceberg order
    52      And the parties place the following orders:
    53        | party  | market id | side | volume | price | resulting trades | type       | tif     | reference |
    54        | party5 | BTC/ETH   | sell | 10     | 1000  | 0                | TYPE_LIMIT | TIF_GFA | sell1     |
    55  
    56      And the opening auction period ends for market "BTC/ETH"
    57      When the network moves ahead "1" blocks
    58      Then the trading mode should be "TRADING_MODE_CONTINUOUS" for the market "BTC/ETH"
    59  
    60      And the orders should have the following status:
    61        | party  | reference | status           |
    62        | party1 | iceberg1  | STATUS_FILLED    |
    63        | party5 | sell1     | STATUS_FILLED    |
    64  
    65      And the following trades should be executed:
    66        | buyer  | price | size | seller |
    67        | party1 | 1000  | 10   | party5 |
    68  
    69  
    70  Scenario: For an iceberg order that's submitted when the market is in auction, iceberg orders trade according to their behaviour if
    71              they were already on the book (trading first the visible size, then additional if the full visible price level is exhausted
    72              in the uncrossing) (0014-ORDT-093)
    73  
    74  
    75      # Place an iceberg order that we want to full match
    76      When the parties place the following iceberg orders:
    77        | party  | market id | side | volume | price | resulting trades | type       | tif     | peak size | minimum visible size | only | reference |
    78        | party1 | BTC/ETH   | buy  | 10     | 1000  | 0                | TYPE_LIMIT | TIF_GTC | 2         | 2                    | post | iceberg1  |
    79  
    80  
    81      # Place normal GFA orders to partially match with the iceberg order
    82      And the parties place the following orders:
    83        | party  | market id | side | volume | price | resulting trades | type       | tif     | reference |
    84        | party5 | BTC/ETH   | sell | 8      | 1000  | 0                | TYPE_LIMIT | TIF_GFA | sell1     |
    85  
    86      And the opening auction period ends for market "BTC/ETH"
    87      When the network moves ahead "1" blocks
    88      Then the trading mode should be "TRADING_MODE_CONTINUOUS" for the market "BTC/ETH"
    89  
    90      And the orders should have the following status:
    91        | party  | reference | status           |
    92        | party1 | iceberg1  | STATUS_ACTIVE    |
    93        | party5 | sell1     | STATUS_FILLED    |
    94  
    95      And the following trades should be executed:
    96        | buyer  | price | size | seller |
    97        | party1 | 1000  | 8    | party5 |