code.vegaprotocol.io/vega@v0.79.0/core/integration/features/spot/liquidity_provision/0044-LIME-064.feature (about)

     1  Feature: Spot market SLA
     2  
     3    Scenario: 0044-LIME-064, When the LP increases its commitment and the increment is higher than its general account balance, the increments are rejected, and the old provision persists
     4      Given the fees configuration named "fees-config-1":
     5        | maker fee | infrastructure fee |
     6        | 0         | 0                  |
     7      Given the log normal risk model named "lognormal-risk-model-1":
     8        | risk aversion | tau  | mu | r   | sigma |
     9        | 0.001         | 0.01 | 0  | 0.0 | 1.2   |
    10  
    11      And the price monitoring named "price-monitoring-1":
    12        | horizon | probability | auction extension |
    13        | 360000  | 0.999       | 300               |
    14  
    15      And the liquidity sla params named "SLA-1":
    16        | price range | commitment min time fraction | performance hysteresis epochs | sla competition factor |
    17        | 0.001       | 0.1                          | 2                             | 0.2                    |
    18  
    19      Given the following assets are registered:
    20        | id  | decimal places |
    21        | ETH | 1              |
    22        | BTC | 1              |
    23  
    24      And the following network parameters are set:
    25        | name                                                | value |
    26        | network.markPriceUpdateMaximumFrequency             | 2s    |
    27        | market.liquidity.earlyExitPenalty                   | 0.25  |
    28        | market.liquidity.bondPenaltyParameter               | 0     |
    29        | market.liquidity.sla.nonPerformanceBondPenaltySlope | 0.5   |
    30        | market.liquidity.sla.nonPerformanceBondPenaltyMax   | 0.2   |
    31        | market.liquidity.maximumLiquidityFeeFactorLevel     | 0.4   |
    32        | validators.epoch.length                             | 2s    |
    33  
    34      Given time is updated to "2023-07-20T00:00:00Z"
    35  
    36      And the spot markets:
    37        | id       | name    | base asset | quote asset | risk model             | auction duration | fees          | price monitoring   | sla params |
    38        | BTC/ETH  | BTC/ETH | BTC        | ETH         | lognormal-risk-model-1 | 1                | fees-config-1 | price-monitoring-1 | SLA-1      |
    39        | BTC/ETH2 | BTC/ETH | BTC        | ETH         | lognormal-risk-model-1 | 1                | fees-config-1 | price-monitoring-1 | SLA-1      |
    40      And the following network parameters are set:
    41        | name                                             | value |
    42        | market.liquidity.providersFeeCalculationTimeStep | 1s    |
    43  
    44      Given the parties deposit on asset's general account the following amount:
    45        | party   | asset | amount |
    46        | party1  | ETH   | 10000  |
    47        | party2  | BTC   | 50     |
    48        | lpprov1 | ETH   | 4000   |
    49        | lpprov1 | BTC   | 60     |
    50        | lpprov2 | ETH   | 4000   |
    51        | lpprov2 | BTC   | 60     |
    52  
    53      And the average block duration is "1"
    54  
    55      Given the liquidity monitoring parameters:
    56        | name               | triggering ratio | time window | scaling factor |
    57        | updated-lqm-params | 0.2              | 20s         | 0.8            |
    58  
    59      When the spot markets are updated:
    60        | id      | liquidity monitoring | linear slippage factor | quadratic slippage factor |
    61        | BTC/ETH | updated-lqm-params   | 0.5                    | 0.5                       |
    62        
    63      #0044-LIME-076,If a party submits LP provisions in multiple markets then multiple bond accounts are created and managed by Vega
    64      When the parties submit the following liquidity provision:
    65        | id  | party   | market id | commitment amount | fee | lp type    |
    66        | lp1 | lpprov1 | BTC/ETH   | 2000              | 0.1 | submission |
    67        | lp2 | lpprov2 | BTC/ETH   | 2000              | 0.1 | submission |
    68        | lp3 | lpprov1 | BTC/ETH2  | 20                | 0.1 | submission |
    69  
    70      And the parties should have the following account balances:
    71        | party   | asset | market id | general |
    72        | lpprov1 | BTC   | BTC/ETH   | 60      |
    73        | lpprov1 | ETH   | BTC/ETH   | 1980    |
    74  
    75      Then the network moves ahead "1" blocks
    76      And the network treasury balance should be "0" for the asset "ETH"
    77      And the party "lpprov1" lp liquidity fee account balance should be "0" for the market "BTC/ETH"
    78      Then the party "lpprov1" lp liquidity bond account balance should be "2000" for the market "BTC/ETH"
    79      Then the party "lpprov1" lp liquidity bond account balance should be "20" for the market "BTC/ETH2"
    80  
    81      Then the market data for the market "BTC/ETH" should be:
    82        | mark price | trading mode                 | auction trigger         | target stake | supplied stake | open interest |
    83        | 0          | TRADING_MODE_OPENING_AUCTION | AUCTION_TRIGGER_OPENING | 3200         | 4000           | 0             |
    84  
    85      # place orders and generate trades
    86      And the parties place the following orders:
    87        | party   | market id | side | volume | price | resulting trades | type       | tif     | reference    | only |
    88        | party1  | BTC/ETH   | buy  | 1      | 12    | 0                | TYPE_LIMIT | TIF_GTC | party-order1 |      |
    89        | party2  | BTC/ETH   | sell | 1      | 19    | 0                | TYPE_LIMIT | TIF_GTC | party-order2 |      |
    90        | party1  | BTC/ETH   | buy  | 1      | 15    | 0                | TYPE_LIMIT | TIF_GTC | party-order3 |      |
    91        | party2  | BTC/ETH   | sell | 1      | 15    | 0                | TYPE_LIMIT | TIF_GTC | party-order4 |      |
    92        | lpprov1 | BTC/ETH   | buy  | 6      | 8     | 0                | TYPE_LIMIT | TIF_GTC | lp-order1    |      |
    93        | lpprov1 | BTC/ETH   | sell | 6      | 24    | 0                | TYPE_LIMIT | TIF_GTC | lp-order2    |      |
    94  
    95      When the network moves ahead "1" blocks
    96  
    97      Then the market data for the market "BTC/ETH" should be:
    98        | mark price | trading mode            | auction trigger             | target stake | supplied stake | open interest |
    99        | 15         | TRADING_MODE_CONTINUOUS | AUCTION_TRIGGER_UNSPECIFIED | 3200         | 4000           | 0             |
   100  
   101      And the parties should have the following account balances:
   102        | party   | asset | market id | general |
   103        | lpprov1 | BTC   | BTC/ETH   | 0       |
   104        | lpprov1 | ETH   | BTC/ETH   | 1500    |
   105  
   106      Then the network moves ahead "2" blocks
   107  
   108      When the parties submit the following liquidity provision:
   109        | id  | party   | market id | commitment amount | fee | lp type   | error                                            |
   110        | lp1 | lpprov1 | BTC/ETH   | 20000             | 0.1 | amendment | commitment submission rejected, not enough stake |
   111  
   112      Then the market data for the market "BTC/ETH" should be:
   113        | mark price | trading mode            | auction trigger             | target stake | supplied stake |
   114        | 15         | TRADING_MODE_CONTINUOUS | AUCTION_TRIGGER_UNSPECIFIED | 3200         | 4000           |
   115      # since earlyExitPenalty=0.25, so bond slashed is: 1200*0.25=300
   116      And the network treasury balance should be "0" for the asset "ETH"
   117