code.vegaprotocol.io/vega@v0.79.0/core/integration/features/spot/liquidity_provision/0041-TSTK.feature (about)

     1  Feature: Target stake calculation in spot markets
     2  
     3      Tests check the target stake of spot markets, which is calculated as a
     4      multiple of the maximum supplied stake over a given time window, is
     5      calculated correctly.
     6  
     7      Tests check both markets using zero decimal places, and markets using 
     8      non-zero decimal places.
     9  
    10    Background:
    11  
    12      # Initialise the network and register assets
    13      Given time is updated to "2024-01-01T00:00:00Z"
    14      And the following network parameters are set:
    15        | name                                              | value |
    16        | market.liquidity.earlyExitPenalty                 | 0     |
    17        | market.liquidity.sla.nonPerformanceBondPenaltyMax | 0     |
    18      And the following assets are registered:
    19        | id         | decimal places | quantum |
    20        | USDT.0.1   | 0              | 1       |
    21        | BTC.0.1    | 0              | 1       |
    22        | USDC.2.100 | 2              | 100     |
    23        | ETH.2.100  | 2              | 100     |
    24      And the average block duration is "1"
    25  
    26      # Initialise the zero and non-zero decimal places spot markets
    27      And the spot markets:
    28        | id       | name     | base asset | quote asset | risk model                    | auction duration | fees         | price monitoring | decimal places | position decimal places | sla params    |
    29        | BTC/USDT | BTC/USDT | BTC.0.1    | USDT.0.1    | default-log-normal-risk-model | 1                | default-none | default-none     | 0              | 0                       | default-basic |
    30        | ETH/USDC | BTC/USDT | ETH.2.100  | USDC.2.100  | default-log-normal-risk-model | 1                | default-none | default-none     | 1              | 1                       | default-basic |
    31  
    32      # Deposits for assets with zero decimal places
    33      Given the parties deposit on asset's general account the following amount:
    34        | party | asset    | amount   |
    35        | lp1   | USDT.0.1 | 10000000 |
    36        | lp2   | USDT.0.1 | 10000000 |
    37        | aux1  | USDT.0.1 | 10000000 |
    38        | aux2  | USDT.0.1 | 10000000 |
    39      Given the parties deposit on asset's general account the following amount:
    40        | party | asset   | amount |
    41        | lp1   | BTC.0.1 | 10000  |
    42        | lp2   | BTC.0.1 | 10000  |
    43        | aux1  | BTC.0.1 | 10000  |
    44        | aux2  | BTC.0.1 | 10000  |
    45  
    46      # Deposits for assets with non-zero decimal places
    47      Given the parties deposit on asset's general account the following amount:
    48        | party | asset      | amount     |
    49        | lp1   | USDC.2.100 | 1000000000 |
    50        | lp2   | USDC.2.100 | 1000000000 |
    51        | aux1  | USDC.2.100 | 1000000000 |
    52        | aux2  | USDC.2.100 | 1000000000 |
    53      Given the parties deposit on asset's general account the following amount:
    54        | party | asset     | amount  |
    55        | lp1   | ETH.2.100 | 1000000 |
    56        | lp2   | ETH.2.100 | 1000000 |
    57        | aux1  | ETH.2.100 | 1000000 |
    58        | aux2  | ETH.2.100 | 1000000 |
    59  
    60  
    61    Scenario Outline: Given a spot market using zero decimals, the target stake should be correctly set to the product of the scaling factor and maximum supplied stake over the window. (0041-TSTK-106)(0041-TSTK-108)
    62  
    63      # Set the target stake time window to two epochs
    64      Given the following network parameters are set:
    65        | name                    | value |
    66        | validators.epoch.length | 10s   |
    67      And the liquidity monitoring parameters:
    68        | name       | triggering ratio | scaling factor   | time window |
    69        | lqm-params | 1.0              | <scaling factor> | 20s         |
    70      And the spot markets are updated:
    71        | id       | liquidity monitoring |
    72        | ETH/USDC | lqm-params           |
    73  
    74      Given the parties submit the following liquidity provision:
    75        | id  | party | market id | commitment amount | fee  | lp type    |
    76        | lp1 | lp1   | ETH/USDC  | 10000             | 0.02 | submission |
    77      When the parties place the following orders:
    78        | party | market id | side | volume | price | resulting trades | type       | tif     |
    79        | aux1  | ETH/USDC  | buy  | 10     | 10000 | 0                | TYPE_LIMIT | TIF_GTC |
    80        | aux2  | ETH/USDC  | sell | 10     | 10000 | 0                | TYPE_LIMIT | TIF_GTC |
    81      And the network moves ahead "2" blocks
    82      Then the market data for the market "ETH/USDC" should be:
    83        | trading mode            | target stake   | supplied stake |
    84        | TRADING_MODE_CONTINUOUS | <target stake> | 10000          |
    85  
    86    Examples:
    87        | scaling factor | target stake |
    88        | 0              | 0            |
    89        | 0.5            | 5000         |
    90        | 1              | 10000        |
    91  
    92  
    93    Scenario Outline: Given a spot market using non-zero decimals, the target stake should be correctly set to the product of the scaling factor and maximum supplied stake over the window. (0041-TSTK-107)(0041-TSTK-108)
    94  
    95      # Set the target stake time window to two epochs
    96      Given the following network parameters are set:
    97        | name                    | value |
    98        | validators.epoch.length | 10s   |
    99      And the liquidity monitoring parameters:
   100        | name       | triggering ratio | scaling factor   | time window |
   101        | lqm-params | 1.0              | <scaling factor> | 20s         |
   102      And the spot markets are updated:
   103        | id       | liquidity monitoring |
   104        | BTC/USDT | lqm-params           |
   105  
   106      Given the parties submit the following liquidity provision:
   107        | id  | party | market id | commitment amount | fee  | lp type    |
   108        | lp1 | lp1   | BTC/USDT  | 10000             | 0.02 | submission |
   109      When the parties place the following orders:
   110        | party | market id | side | volume | price | resulting trades | type       | tif     |
   111        | aux1  | BTC/USDT  | buy  | 1      | 1000  | 0                | TYPE_LIMIT | TIF_GTC |
   112        | aux2  | BTC/USDT  | sell | 1      | 1000  | 0                | TYPE_LIMIT | TIF_GTC |
   113      And the network moves ahead "2" blocks
   114      Then the market data for the market "BTC/USDT" should be:
   115        | trading mode            | target stake   | supplied stake |
   116        | TRADING_MODE_CONTINUOUS | <target stake> | 10000          |
   117  
   118    Examples:
   119        | scaling factor | target stake |
   120        | 0              | 0            |
   121        | 0.5            | 5000         |
   122        | 1              | 10000        |
   123  
   124  
   125    Scenario: Given a spot market, if an LP increases or decreases their commitment the target stake should be updated correctly. (0041-TSTK-109)(0041-TSTK-110)(0041-TSTK-112)
   126  
   127      # Set the target stake time window to two epochs
   128      Given the following network parameters are set:
   129        | name                    | value |
   130        | validators.epoch.length | 10s   |
   131      And the liquidity monitoring parameters:
   132        | name       | triggering ratio | scaling factor | time window |
   133        | lqm-params | 1.0              | 1              | 20s         |
   134      And the spot markets are updated:
   135        | id       | liquidity monitoring |
   136        | BTC/USDT | lqm-params           |
   137  
   138      Given the parties submit the following liquidity provision:
   139        | id  | party | market id | commitment amount | fee  | lp type    |
   140        | lp1 | lp1   | BTC/USDT  | 10000             | 0.02 | submission |
   141      When the parties place the following orders:
   142        | party | market id | side | volume | price | resulting trades | type       | tif     |
   143        | aux1  | BTC/USDT  | buy  | 1      | 1000  | 0                | TYPE_LIMIT | TIF_GTC |
   144        | aux2  | BTC/USDT  | sell | 1      | 1000  | 0                | TYPE_LIMIT | TIF_GTC |
   145      And the network moves ahead "2" blocks
   146      Then the market data for the market "BTC/USDT" should be:
   147        | trading mode            | target stake | supplied stake |
   148        | TRADING_MODE_CONTINUOUS | 10000        | 10000          |
   149  
   150      # LP reduces commitment, supplied and target stake increased immediately (0041-TSTK-109)
   151      Given the parties submit the following liquidity provision:
   152        | id  | party | market id | commitment amount | fee  | lp type   |
   153        | lp1 | lp1   | BTC/USDT  | 20000             | 0.02 | amendment |
   154      When the network moves ahead "1" blocks
   155      Then the market data for the market "BTC/USDT" should be:
   156        | trading mode            | target stake | supplied stake |
   157        | TRADING_MODE_CONTINUOUS | 20000        | 20000          |
   158  
   159      # LP reduces commitment, supplied and target stake not decreased immediately (0041-TSTK-110)
   160      Given the parties submit the following liquidity provision:
   161        | id  | party | market id | commitment amount | fee  | lp type   |
   162        | lp1 | lp1   | BTC/USDT  | 10000             | 0.02 | amendment |
   163      When the network moves ahead "1" blocks
   164      Then the market data for the market "BTC/USDT" should be:
   165        | trading mode            | target stake | supplied stake |
   166        | TRADING_MODE_CONTINUOUS | 20000        | 20000          |
   167  
   168      # LP commitment reduction processed, supplied stake decreases
   169      Given the network moves ahead "1" epochs
   170      Then the market data for the market "BTC/USDT" should be:
   171        | trading mode            | target stake | supplied stake |
   172        | TRADING_MODE_CONTINUOUS | 20000        | 10000          |
   173  
   174      # Previous supplied stake value dropped, target stake decreases
   175      Given the network moves ahead "19" blocks
   176      Then the market data for the market "BTC/USDT" should be:
   177        | trading mode            | target stake | supplied stake |
   178        | TRADING_MODE_CONTINUOUS | 20000        | 10000          |
   179      Given the network moves ahead "1" blocks
   180      Then the market data for the market "BTC/USDT" should be:
   181        | trading mode            | target stake | supplied stake |
   182        | TRADING_MODE_CONTINUOUS | 10000        | 10000          |
   183  
   184      # Increase time window, previous supplied stake NOT included despite being within time window, target stake does not change (0041-TSTK-112)
   185      Given the liquidity monitoring parameters:
   186        | name               | triggering ratio | scaling factor | time window |
   187        | updated-lqm-params | 1.0              | 1.0            | 30s         |
   188      When the spot markets are updated:
   189        | id       | liquidity monitoring |
   190        | BTC/USDT | updated-lqm-params   |
   191      Then the market data for the market "BTC/USDT" should be:
   192        | trading mode            | target stake | supplied stake |
   193        | TRADING_MODE_CONTINUOUS | 10000        | 10000          |
   194  
   195  
   196  
   197    Scenario Outline: Given a spot market, change of market.stake.target.scalingFactor will immediately change the target stake. (0041-TSTK-111)
   198  
   199      # Set the target stake time window to two epochs
   200      Given the following network parameters are set:
   201        | name                    | value |
   202        | validators.epoch.length | 10s   |
   203      And the liquidity monitoring parameters:
   204        | name       | triggering ratio | scaling factor | time window |
   205        | lqm-params | 1.0              | 1              | 20s         |
   206      And the spot markets are updated:
   207        | id       | liquidity monitoring |
   208        | BTC/USDT | lqm-params           |
   209  
   210      Given the parties submit the following liquidity provision:
   211        | id  | party | market id | commitment amount | fee  | lp type    |
   212        | lp1 | lp1   | BTC/USDT  | 10000             | 0.02 | submission |
   213      When the parties place the following orders:
   214        | party | market id | side | volume | price | resulting trades | type       | tif     |
   215        | aux1  | BTC/USDT  | buy  | 1      | 1000  | 0                | TYPE_LIMIT | TIF_GTC |
   216        | aux2  | BTC/USDT  | sell | 1      | 1000  | 0                | TYPE_LIMIT | TIF_GTC |
   217      And the network moves ahead "2" blocks
   218      Then the market data for the market "BTC/USDT" should be:
   219        | trading mode            | target stake | supplied stake |
   220        | TRADING_MODE_CONTINUOUS | 10000        | 10000          |
   221  
   222      Given the liquidity monitoring parameters:
   223        | name               | triggering ratio | scaling factor   | time window |
   224        | updated-lqm-params | 1.0              | <scaling factor> | 20s         |
   225      When the spot markets are updated:
   226        | id       | liquidity monitoring |
   227        | BTC/USDT | updated-lqm-params   |
   228      Then the market data for the market "BTC/USDT" should be:
   229        | trading mode            | target stake   | supplied stake |
   230        | TRADING_MODE_CONTINUOUS | <target stake> | 10000          |
   231  
   232    Examples:
   233        | scaling factor | target stake |
   234        | 0              | 0            |
   235        | 0.5            | 5000         |
   236        | 1              | 10000        |
   237  
   238  
   239    Scenario: Given a spot market, a decrease of time_window will immediately change the length of time window over which the total stake is measured and old records will be dropped hence the target stake will immediately change. (0041-TSTK-113)
   240  
   241      # Set the target stake time window to two epochs
   242      Given the following network parameters are set:
   243        | name                    | value |
   244        | validators.epoch.length | 10s   |
   245      And the liquidity monitoring parameters:
   246        | name       | triggering ratio | scaling factor | time window |
   247        | lqm-params | 1.0              | 1              | 20s         |
   248      And the spot markets are updated:
   249        | id       | liquidity monitoring |
   250        | BTC/USDT | lqm-params           |
   251  
   252      Given the parties submit the following liquidity provision:
   253        | id  | party | market id | commitment amount | fee  | lp type    |
   254        | lp1 | lp1   | BTC/USDT  | 10000             | 0.02 | submission |
   255      When the parties place the following orders:
   256        | party | market id | side | volume | price | resulting trades | type       | tif     |
   257        | aux1  | BTC/USDT  | buy  | 1      | 1000  | 0                | TYPE_LIMIT | TIF_GTC |
   258        | aux2  | BTC/USDT  | sell | 1      | 1000  | 0                | TYPE_LIMIT | TIF_GTC |
   259      And the network moves ahead "2" blocks
   260      Then the market data for the market "BTC/USDT" should be:
   261        | trading mode            | target stake | supplied stake |
   262        | TRADING_MODE_CONTINUOUS | 10000        | 10000          |
   263  
   264      Given the parties submit the following liquidity provision:
   265        | id  | party | market id | commitment amount | fee  | lp type   |
   266        | lp1 | lp1   | BTC/USDT  | 5000              | 0.02 | amendment |
   267      When the network moves ahead "1" epochs
   268      And the network moves ahead "1" blocks
   269      Then the market data for the market "BTC/USDT" should be:
   270        | trading mode            | target stake | supplied stake |
   271        | TRADING_MODE_CONTINUOUS | 10000        | 5000           |
   272  
   273      # Decrease time window, previous supplied stake dropped, target stake decreeases (0041-TSTK-112)
   274      Given the liquidity monitoring parameters:
   275        | name               | triggering ratio | scaling factor | time window |
   276        | updated-lqm-params | 1.0              | 1.0            | 0s          |
   277      When the spot markets are updated:
   278        | id       | liquidity monitoring |
   279        | BTC/USDT | updated-lqm-params   |
   280      Then the market data for the market "BTC/USDT" should be:
   281        | trading mode            | target stake | supplied stake |
   282        | TRADING_MODE_CONTINUOUS | 5000         | 5000           |