code.vegaprotocol.io/vega@v0.79.0/core/integration/features/spot/orders/0011-MARA-continuous.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  
    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      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        | party2 | BTC   | 10     |
    35        | party3 | ETH   | 10000  |
    36        | party5 | BTC   | 100    |
    37      And the average block duration is "1"
    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      And the opening auction period ends for market "BTC/ETH"
    44      When the network moves ahead "1" blocks
    45      Then the trading mode should be "TRADING_MODE_CONTINUOUS" for the market "BTC/ETH"
    46  
    47  
    48    Scenario: In Spot market, holding in holding account is correctly calculated for all order types in continuous trading limit GTT. (0011-MARA-022)
    49      Given the parties place the following orders:
    50        | party  | market id | side | volume | price | resulting trades | type       | tif     | expires in | reference |
    51        | party5 | BTC/ETH   | sell | 5      | 1000  | 0                | TYPE_LIMIT | TIF_GTT | 50         | sell1     |
    52  
    53      And "party5" should have holding account balance of "5" for asset "BTC"
    54  
    55    Scenario: In Spot market, holding in holding account is correctly calculated for all order types in continuous trading limit GTC. (0011-MARA-023)
    56      Given the parties place the following orders:
    57        | party  | market id | side | volume | price | resulting trades | type       | tif     | reference |
    58        | party5 | BTC/ETH   | sell | 5      | 1000  | 0                | TYPE_LIMIT | TIF_GTC | sell1     |
    59  
    60      And "party5" should have holding account balance of "5" for asset "BTC"
    61  
    62    Scenario: In Spot market, holding in holding account is correctly calculated for all order types in continuous trading limit GFN. (0011-MARA-024)
    63      Given the parties place the following orders:
    64        | party  | market id | side | volume | price | resulting trades | type       | tif     | reference |
    65        | party5 | BTC/ETH   | sell | 1      | 1000  | 0                | TYPE_LIMIT | TIF_GFN | sell1     |
    66  
    67      And "party5" should have holding account balance of "1" for asset "BTC"
    68  
    69    Scenario: In Spot market, holding in holding account is correctly calculated for all order types in continuous trading pegged GTT. (0011-MARA-025)
    70      Given the following network parameters are set:
    71        | name                           | value |
    72        | limits.markets.maxPeggedOrders | 10    |
    73  
    74      When the parties place the following orders:
    75        | party  | market id | side | volume | price   | resulting trades | type       | tif     | reference |
    76        | party2 | BTC/ETH   | sell | 5      | 1000000 | 0                | TYPE_LIMIT | TIF_GTC | t2-s-1    |
    77  
    78      And the parties place the following pegged orders:
    79        | party  | market id | side | volume | pegged reference | offset |
    80        | party5 | BTC/ETH   | sell | 1      | ASK              | 100    |
    81  
    82      Then "party5" should have holding account balance of "1" for asset "BTC"
    83  
    84      And the order book should have the following volumes for market "BTC/ETH":
    85        | side | price | volume |
    86        | sell | 1000  | 0      |
    87        
    88      #0068-MATC-072, Incoming limit GTT orders match if possible, any remaining is placed on the book.
    89      When the parties place the following orders:
    90        | party  | market id | side | volume | price | resulting trades | type       | tif     | expires in | reference |
    91        | party1 | BTC/ETH   | buy  | 1      | 1000  | 0                | TYPE_LIMIT | TIF_GTT | 2          | buy2      |
    92        | party5 | BTC/ETH   | sell | 2      | 1000  | 1                | TYPE_LIMIT | TIF_GTT | 2          | sell2     |
    93  
    94      Then the orders should have the following status:
    95        | party  | reference | status        |
    96        | party1 | buy2      | STATUS_FILLED |
    97        | party5 | sell2     | STATUS_ACTIVE |
    98      And the order book should have the following volumes for market "BTC/ETH":
    99        | side | price | volume |
   100        | sell | 1000  | 1      |
   101  
   102      When the network moves ahead "2" blocks
   103      Then the orders should have the following status:
   104        | party  | reference | status         |
   105        | party5 | sell2     | STATUS_EXPIRED |
   106  
   107    Scenario: In Spot market, holding in holding account is correctly calculated for all order types in continuous trading pegged GTC. (0011-MARA-026)
   108      Given the following network parameters are set:
   109        | name                           | value |
   110        | limits.markets.maxPeggedOrders | 10    |
   111  
   112      When the parties place the following orders:
   113        | party  | market id | side | volume | price   | resulting trades | type       | tif     | reference |
   114        | party2 | BTC/ETH   | sell | 5      | 1000000 | 0                | TYPE_LIMIT | TIF_GTC | t2-s-1    |
   115  
   116      When the parties place the following pegged orders:
   117        | party  | market id | side | volume | pegged reference | offset |
   118        | party5 | BTC/ETH   | sell | 1      | ASK              | 100    |
   119  
   120      Then "party5" should have holding account balance of "1" for asset "BTC"
   121  
   122    Scenario: In Spot market, holding in holding account is correctly calculated for all order types in continuous trading pegged GFN. (0011-MARA-027)
   123      Given the following network parameters are set:
   124        | name                           | value |
   125        | limits.markets.maxPeggedOrders | 10    |
   126  
   127      When the parties place the following orders:
   128        | party  | market id | side | volume | price   | resulting trades | type       | tif     | reference |
   129        | party2 | BTC/ETH   | sell | 5      | 1000000 | 0                | TYPE_LIMIT | TIF_GFN | t2-s-1    |
   130  
   131      When the parties place the following pegged orders:
   132        | party  | market id | side | volume | pegged reference | offset |
   133        | party5 | BTC/ETH   | sell | 1      | ASK              | 100    |
   134  
   135      Then "party5" should have holding account balance of "1" for asset "BTC"
   136