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

     1  Feature: Spot market
     2  
     3    Background:
     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        | 360000  | 0.999       | 1                 |
    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        | party3 | BTC   | 100    |
    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_GFA |
    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  
    48  
    49    Scenario: Immediate orders, continuous trading an aggressive persistent (GTC) limit order that crosses with trades >= to its volume
    50              is filled completely and does not appear on the order book or in the order book volume. Trades are atomically generated for the
    51              full volume. (0014-ORDT-082)
    52  
    53      # Place some orders to get some volume at a fixed price level
    54      And the parties place the following orders:
    55        | party  | market id | side | volume | price | resulting trades | type       | tif     | reference |
    56        | party3 | BTC/ETH   | sell | 1      | 1000  | 0                | TYPE_LIMIT | TIF_GTC | sell3     |
    57        | party4 | BTC/ETH   | sell | 1      | 1000  | 0                | TYPE_LIMIT | TIF_GTC | sell4     |
    58        | party5 | BTC/ETH   | sell | 1      | 1000  | 0                | TYPE_LIMIT | TIF_GTC | sell5     |
    59  
    60      # Now place the aggressive GTC order to fully fill from the available volume on the book
    61      And the parties place the following orders:
    62        | party  | market id | side | volume | price | resulting trades | type       | tif     | reference |
    63        | party1 | BTC/ETH   | buy  | 3      | 1000  | 3                | TYPE_LIMIT | TIF_GTC | buy1      |
    64  
    65      And the orders should have the following status:
    66        | party  | reference | status           |
    67        | party1 | buy1      | STATUS_FILLED    |
    68        | party3 | sell3     | STATUS_FILLED    |
    69        | party4 | sell4     | STATUS_FILLED    |
    70        | party5 | sell5     | STATUS_FILLED    |
    71  
    72  
    73    Scenario: Immediate orders, continuous trading an aggressive persistent (GTT) limit order that crosses with trades >= to its volume
    74              is filled completely and does not appear on the order book or in the order book volume. Trades are atomically generated for the
    75              full volume. (0014-ORDT-082)
    76  
    77      # Place some orders to get some volume at a fixed price level
    78      And the parties place the following orders:
    79        | party  | market id | side | volume | price | resulting trades | type       | tif     | reference |
    80        | party3 | BTC/ETH   | sell | 1      | 1000  | 0                | TYPE_LIMIT | TIF_GTC | sell3     |
    81        | party4 | BTC/ETH   | sell | 1      | 1000  | 0                | TYPE_LIMIT | TIF_GTC | sell4     |
    82        | party5 | BTC/ETH   | sell | 1      | 1000  | 0                | TYPE_LIMIT | TIF_GTC | sell5     |
    83  
    84      # Now place the aggressive GTC order to fully fill from the available volume on the book
    85      And the parties place the following orders:
    86        | party  | market id | side | volume | price | resulting trades | type       | tif     | reference | expires in |
    87        | party1 | BTC/ETH   | buy  | 3      | 1000  | 3                | TYPE_LIMIT | TIF_GTT | buy1      | 3600       |
    88  
    89      And the orders should have the following status:
    90        | party  | reference | status           |
    91        | party1 | buy1      | STATUS_FILLED    |
    92        | party3 | sell3     | STATUS_FILLED    |
    93        | party4 | sell4     | STATUS_FILLED    |
    94        | party5 | sell5     | STATUS_FILLED    |
    95