code.vegaprotocol.io/vega@v0.79.0/core/integration/features/liquidity-provision/bug-5147.feature (about)

     1  Feature: Test LP orders with different decimals for market and asset
     2  
     3    Background:
     4      Given the following assets are registered:
     5        | id  | decimal places |
     6        | ETH | 18             |
     7      And the log normal risk model named "log-normal-risk-model-1":
     8        | risk aversion | tau                    | mu | r     | sigma |
     9        | 0.001         | 0.00011407711613050422 | 0  | 0.016 | 1.5   |
    10      And the markets:
    11        | id        | quote name | asset | risk model              | margin calculator         | auction duration | fees         | price monitoring | data source config     | position decimal places | decimal places | linear slippage factor | quadratic slippage factor | sla params      |
    12        | ETH/DEC19 | ETH        | ETH   | log-normal-risk-model-1 | default-margin-calculator | 1                | default-none | default-none     | default-eth-for-future | 5                       | 5              | 5e-2                   | 0                         | default-futures |
    13      And the following network parameters are set:
    14        | name                                    | value |
    15        | market.auction.minimumDuration          | 1     |
    16        | network.markPriceUpdateMaximumFrequency | 0s    |
    17        | validators.epoch.length                 | 1s    |
    18      And the average block duration is "1"
    19  
    20    Scenario: create liquidity provisions
    21      Given the parties deposit on asset's general account the following amount:
    22        | party            | asset | amount                      |
    23        | party1           | ETH   | 100000000000000000000000000 |
    24        | party2           | ETH   | 100000000000000000000000000 |
    25        | party3           | ETH   | 100000000000000000000000000 |
    26        | sellSideProvider | ETH   | 100000000000000000000000000 |
    27        | buySideProvider  | ETH   | 100000000000000000000000000 |
    28        | auxiliary        | ETH   | 100000000000000000000000000 |
    29        | aux2             | ETH   | 100000000000000000000000000 |
    30        | lpprov           | ETH   | 100000000000000000000000000 |
    31  
    32      When the parties place the following orders:
    33        | party     | market id | side | volume | price     | resulting trades | type       | tif     | reference |
    34        | auxiliary | ETH/DEC19 | buy  | 100    | 80000000  | 0                | TYPE_LIMIT | TIF_GTC | oa-b-1    |
    35        | auxiliary | ETH/DEC19 | sell | 100    | 120000000 | 0                | TYPE_LIMIT | TIF_GTC | oa-s-1    |
    36        | aux2      | ETH/DEC19 | buy  | 100    | 100000000 | 0                | TYPE_LIMIT | TIF_GTC | oa-b-2    |
    37        | auxiliary | ETH/DEC19 | sell | 100    | 100000000 | 0                | TYPE_LIMIT | TIF_GTC | oa-s-2    |
    38      And the parties submit the following liquidity provision:
    39        | id  | party  | market id | commitment amount  | fee | lp type    |
    40        | lp1 | lpprov | ETH/DEC19 | 552900000000000000 | 0.1 | submission |
    41        | lp1 | lpprov | ETH/DEC19 | 552900000000000000 | 0.1 | submission |
    42      Then the opening auction period ends for market "ETH/DEC19"
    43      And the trading mode should be "TRADING_MODE_CONTINUOUS" for the market "ETH/DEC19"
    44  
    45      When the parties place the following orders with ticks:
    46        | party  | market id | side | volume | price       | resulting trades | type       | tif     | reference |
    47        | party2 | ETH/DEC19 | buy  | 500000 | 100100000   | 0                | TYPE_LIMIT | TIF_GTC | b1        |
    48        | party3 | ETH/DEC19 | sell | 500000 | 95100000    | 1                | TYPE_LIMIT | TIF_GTC | s1        |
    49        | party2 | ETH/DEC19 | buy  | 500000 | 90000000    | 0                | TYPE_LIMIT | TIF_GTC | b2        |
    50        | party3 | ETH/DEC19 | sell | 500000 | 120000000   | 0                | TYPE_LIMIT | TIF_GTC | s2        |
    51        | party2 | ETH/DEC19 | buy  | 100000 | 10000000    | 0                | TYPE_LIMIT | TIF_GTC | b3        |
    52        | party3 | ETH/DEC19 | sell | 100000 | 10000000000 | 0                | TYPE_LIMIT | TIF_GTC | s3        |
    53        | party2 | ETH/DEC19 | sell | 100000 | 95100000    | 0                | TYPE_LIMIT | TIF_GTC | b4        |
    54        | party3 | ETH/DEC19 | buy  | 100000 | 100100000   | 1                | TYPE_LIMIT | TIF_GTC | s4        |
    55  
    56      Then the parties submit the following liquidity provision:
    57        | id  | party  | market id | commitment amount         | fee | lp type    |
    58        | lp2 | party1 | ETH/DEC19 | 3905000000000000000000000 | 0.3 | submission |
    59        | lp2 | party1 | ETH/DEC19 | 3905000000000000000000000 | 0.3 | amendment  |
    60  
    61      Then the liquidity provisions should have the following states:
    62        | id  | party  | market    | commitment amount         | status         |
    63        | lp2 | party1 | ETH/DEC19 | 3905000000000000000000000 | STATUS_PENDING |
    64  
    65      # TODO (WG 31/07/23): why 3?
    66      When the network moves ahead "3" blocks
    67      Then the liquidity provisions should have the following states:
    68        | id  | party  | market    | commitment amount         | status        |
    69        | lp2 | party1 | ETH/DEC19 | 3905000000000000000000000 | STATUS_ACTIVE |