code.vegaprotocol.io/vega@v0.79.0/core/integration/features/pap/0097-PAPU-030.feature (about)

     1  Feature: Given the market is currently in a monitoring auction, once an auction trigger occurs, if the current auction end time is greater than the current time plus the program auction length, the auction end time is unchanged. (0097-PAPU-030).
     2  
     3      Background:
     4          Given the log normal risk model named "log-normal-risk-model":
     5              | risk aversion | tau | mu | r | sigma |
     6              | 0.000001      | 0.1 | 0  | 0 | 1.0   |
     7          And the following network parameters are set:
     8              | name                                    | value |
     9              | market.value.windowLength               | 60s   |
    10              | network.markPriceUpdateMaximumFrequency | 0s    |
    11              | limits.markets.maxPeggedOrders          | 6     |
    12              | market.auction.minimumDuration          | 1     |
    13              | market.fee.factors.infrastructureFee    | 0.001 |
    14              | market.fee.factors.makerFee             | 0.004 |
    15              | spam.protection.max.stopOrdersPerMarket | 5     |
    16              | validators.epoch.length                 | 60m   |
    17          And the liquidity monitoring parameters:
    18              | name       | triggering ratio | time window | scaling factor |
    19              | lqm-params | 1.0              | 20s         | 1              |
    20          And the fees configuration named "fees-config-1":
    21              | maker fee | infrastructure fee |
    22              | 0.0004    | 0.001              |
    23          And the price monitoring named "price-monitoring":
    24              | horizon | probability | auction extension |
    25              | 3600    | 0.99        | 30                |
    26          And the liquidity sla params named "SLA-22":
    27              | price range | commitment min time fraction | performance hysteresis epochs | sla competition factor |
    28              | 0.5         | 0.6                          | 1                             | 1.0                    |
    29          And the following network parameters are set:
    30              | name                           | value |
    31              | limits.markets.maxPeggedOrders | 2     |
    32          And the following assets are registered:
    33              | id  | decimal places |
    34              | ETH | 0              |
    35  
    36          And the spot markets:
    37              | id      | name    | base asset | quote asset | liquidity monitoring | risk model            | auction duration | fees          | price monitoring | sla params |
    38              | BTC/ETH | BTC/ETH | BTC        | ETH         | lqm-params           | log-normal-risk-model | 300              | fees-config-1 | price-monitoring | SLA-22     |
    39  
    40          Given the parties deposit on asset's general account the following amount:
    41              | party  | asset | amount     |
    42              | party1 | ETH   | 1000000000 |
    43              | party2 | ETH   | 1000000000 |
    44              | party3 | ETH   | 1000000000 |
    45              | party1 | BTC   | 1000000000 |
    46              | party3 | BTC   | 1000000000 |
    47              | lpprov | ETH   | 1000000000 |
    48              | lpprov | BTC   | 1000000000 |
    49  
    50          When the parties submit the following liquidity provision:
    51              | id  | party  | market id | commitment amount | fee | lp type    |
    52              | lp1 | lpprov | BTC/ETH   | 937000            | 0.1 | submission |
    53              | lp1 | lpprov | BTC/ETH   | 937000            | 0.1 | submission |
    54          And the parties place the following pegged iceberg orders:
    55              | party  | market id | peak size | minimum visible size | side | pegged reference | volume | offset |
    56              | lpprov | BTC/ETH   | 2         | 1                    | buy  | MID              | 50     | 100    |
    57              | lpprov | BTC/ETH   | 2         | 1                    | sell | MID              | 50     | 100    |
    58  
    59          # place orders and generate trades - slippage 100
    60          And the parties place the following orders:
    61              | party  | market id | side | volume | price   | resulting trades | type       | tif     | reference |
    62              | party2 | BTC/ETH   | buy  | 1      | 950000  | 0                | TYPE_LIMIT | TIF_GTC | t2-b-1    |
    63              | party1 | BTC/ETH   | buy  | 1      | 1000000 | 0                | TYPE_LIMIT | TIF_GFA | t1-b-1    |
    64              | party3 | BTC/ETH   | sell | 1      | 1000000 | 0                | TYPE_LIMIT | TIF_GTC | t2-s-1    |
    65  
    66          When the opening auction period ends for market "BTC/ETH"
    67  
    68          And the following trades should be executed:
    69              | buyer  | price   | size | seller |
    70              | party1 | 1000000 | 1    | party3 |
    71          And the mark price should be "1000000" for the market "BTC/ETH"
    72  
    73          And the composite price oracles from "0xCAFECAFE2":
    74              | name         | price property   | price type   | price decimals |
    75              | price_oracle | prices.ETH.value | TYPE_INTEGER | 0              |
    76  
    77          And the time triggers oracle spec is:
    78              | name                      | initial    | every |
    79              | auction_schedule          | 1727136001 | 30    |
    80              | auction_vol_snap_schedule | 1727136000 | 30    |
    81  
    82          And the average block duration is "1"
    83  
    84          And the parties deposit on asset's general account the following amount:
    85              | party                                                            | asset | amount |
    86              | f0b40ebdc5b92cf2cf82ff5d0c3f94085d23d5ec2d37d0b929e177c6d4d37e4c | BTC   | 50000  |
    87          Given time is updated to "2024-09-24T00:00:00Z"
    88          And the parties submit the following one off transfers:
    89              | id | from                                                             | from_account_type    | to                                                               | to_account_type            | asset | amount | delivery_time        |
    90              | 1  | f0b40ebdc5b92cf2cf82ff5d0c3f94085d23d5ec2d37d0b929e177c6d4d37e4c | ACCOUNT_TYPE_GENERAL | 0000000000000000000000000000000000000000000000000000000000000000 | ACCOUNT_TYPE_BUY_BACK_FEES | BTC   | 5000   | 2024-09-23T00:00:00Z |
    91  
    92          And the buy back fees balance should be "5000" for the asset "BTC"
    93  
    94      Scenario: PAP auction is started when market is in monitoring auction that expires later than the expiration by the pap auction therefore the expiry of the auction remains unchanged. (0097-PAPU-030)
    95          And the parties place the following orders:
    96              | party  | market id | side | volume | price | resulting trades | type       | tif     | reference |
    97              | party2 | BTC/ETH   | buy  | 200    | 500   | 0                | TYPE_LIMIT | TIF_GTC | t2-b-1    |
    98              | party1 | BTC/ETH   | sell | 200    | 500   | 0                | TYPE_LIMIT | TIF_GTC | t2-b-1    |
    99  
   100          And the trading mode should be "TRADING_MODE_MONITORING_AUCTION" for the market "BTC/ETH"
   101          # 24 September 2024 00:00:00 GMT
   102          Then the starting auction time for market "BTC/ETH" is "1727136000000000000"
   103          # 30 seconds later - as implied by the price monitoring configuration
   104          And the ending auction time for market "BTC/ETH" is "1727136030000000000"
   105  
   106          When the protocol automated purchase is defined as:
   107              | id    | from | from account type          | to account type               | market id | price oracle | price oracle staleness tolerance | oracle offset factor | auction schedule oracle | auction volume snapshot schedule oracle | auction duration | minimum auction size | maximum auction size | expiry timestamp |
   108              | 12345 | BTC  | ACCOUNT_TYPE_BUY_BACK_FEES | ACCOUNT_TYPE_NETWORK_TREASURY | BTC/ETH   | price_oracle | 10s                              | 1.01                 | auction_schedule        | auction_vol_snap_schedule               | 20s              | 100                  | 200                  | 0                |
   109  
   110          Then the oracles broadcast data with block time signed with "0xCAFECAFE2":
   111              | name             | value   | time offset |
   112              | prices.ETH.value | 1000000 | -1s         |
   113  
   114          And the network moves ahead "5" blocks
   115  
   116          # maximum auction size is 200 so expect 200 to be earmarked
   117          Then the automated purchase program for market "BTC/ETH" should have a snapshot balance of "200"
   118  
   119          # we enter a pap auction
   120          And the trading mode should be "TRADING_MODE_MONITORING_AUCTION" for the market "BTC/ETH"
   121  
   122          Then the starting auction time for market "BTC/ETH" is "1727136000000000000"
   123          # 30 seconds later - as implied by the price monitoring configuration - the pap auction is 20 seconds so doesn't extend the monitoring auction
   124          And the ending auction time for market "BTC/ETH" is "1727136030000000000"