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

     1  Feature: Given the program specifies a source asset matching the quote asset of the market, it will place a buy order at the start of the auction. (0097-PAPU-039). The price of the order will equal the product of the oracle price and the programs oracle offset factor. (0097-PAPU-040). Given the program specifies a source asset matching the quote asset of the market, the size of the order will use the number of tokens earmarked for the auction during the latest snapshot to calculate the correct order size given the order price and current fee factors. (0097-PAPU-042).
     2      Background:
     3          Given the log normal risk model named "log-normal-risk-model":
     4              | risk aversion | tau | mu | r | sigma |
     5              | 0.000001      | 0.1 | 0  | 0 | 1.0   |
     6          And the following network parameters are set:
     7              | name                                    | value |
     8              | market.value.windowLength               | 60s   |
     9              | network.markPriceUpdateMaximumFrequency | 0s    |
    10              | limits.markets.maxPeggedOrders          | 6     |
    11              | market.auction.minimumDuration          | 1     |
    12              | market.fee.factors.infrastructureFee    | 0.001 |
    13              | market.fee.factors.makerFee             | 0.004 |
    14              | spam.protection.max.stopOrdersPerMarket | 5     |
    15          And the liquidity monitoring parameters:
    16              | name       | triggering ratio | time window | scaling factor |
    17              | lqm-params | 1.0              | 20s         | 1              |
    18          And the fees configuration named "fees-config-1":
    19              | maker fee | infrastructure fee |
    20              | 0.0004    | 0.001              |
    21          And the price monitoring named "price-monitoring":
    22              | horizon | probability | auction extension |
    23              | 3600    | 0.99        | 30                |
    24          And the liquidity sla params named "SLA-22":
    25              | price range | commitment min time fraction | performance hysteresis epochs | sla competition factor |
    26              | 0.5         | 0.6                          | 1                             | 1.0                    |
    27          And the following network parameters are set:
    28              | name                           | value |
    29              | limits.markets.maxPeggedOrders | 2     |
    30          And the following assets are registered:
    31              | id  | decimal places |
    32              | ETH | 0              |
    33  
    34          And the spot markets:
    35              | id      | name    | base asset | quote asset | liquidity monitoring | risk model            | auction duration | fees          | price monitoring | sla params |
    36              | BTC/ETH | BTC/ETH | BTC        | ETH         | lqm-params           | log-normal-risk-model | 2                | fees-config-1 | price-monitoring | SLA-22     |
    37  
    38          Given the parties deposit on asset's general account the following amount:
    39              | party  | asset | amount     |
    40              | party1 | ETH   | 1000000000 |
    41              | party2 | ETH   | 1000000000 |
    42              | party3 | ETH   | 1000000000 |
    43              | party1 | BTC   | 1000000000 |
    44              | party2 | BTC   | 1000000000 |
    45              | party3 | BTC   | 1000000000 |
    46              | lpprov | ETH   | 1000000000 |
    47              | lpprov | BTC   | 1000000000 |
    48  
    49          When the parties submit the following liquidity provision:
    50              | id  | party  | market id | commitment amount | fee | lp type    |
    51              | lp1 | lpprov | BTC/ETH   | 937000            | 0.1 | submission |
    52              | lp1 | lpprov | BTC/ETH   | 937000            | 0.1 | submission |
    53          And the parties place the following pegged iceberg orders:
    54              | party  | market id | peak size | minimum visible size | side | pegged reference | volume | offset |
    55              | lpprov | BTC/ETH   | 2         | 1                    | buy  | MID              | 50     | 100    |
    56              | lpprov | BTC/ETH   | 2         | 1                    | sell | MID              | 50     | 100    |
    57  
    58          # place orders and generate trades - slippage 100
    59          And the parties place the following orders:
    60              | party  | market id | side | volume | price   | resulting trades | type       | tif     | reference |
    61              | party2 | BTC/ETH   | buy  | 1      | 950000  | 0                | TYPE_LIMIT | TIF_GTC | t2-b-1    |
    62              | party1 | BTC/ETH   | buy  | 1      | 1000000 | 0                | TYPE_LIMIT | TIF_GFA | t1-b-1    |
    63              | party2 | BTC/ETH   | sell | 2      | 1000000 | 0                | TYPE_LIMIT | TIF_GTC | t2-s-1    |
    64  
    65          When the opening auction period ends for market "BTC/ETH"
    66  
    67          And the following trades should be executed:
    68              | buyer  | price   | size | seller |
    69              | party1 | 1000000 | 1    | party2 |
    70          And the mark price should be "1000000" for the market "BTC/ETH"
    71  
    72          And the composite price oracles from "0xCAFECAFE2":
    73              | name         | price property   | price type   | price decimals |
    74              | price_oracle | prices.ETH.value | TYPE_INTEGER | 0              |
    75  
    76          And the time triggers oracle spec is:
    77              | name                      | initial    | every |
    78              | auction_schedule          | 1727136001 | 30    |
    79              | auction_vol_snap_schedule | 1727136000 | 30    |
    80  
    81          And the average block duration is "1"
    82  
    83          And the parties deposit on asset's general account the following amount:
    84              | party                                                            | asset | amount   |
    85              | f0b40ebdc5b92cf2cf82ff5d0c3f94085d23d5ec2d37d0b929e177c6d4d37e4c | ETH   | 50000000 |
    86          Given time is updated to "2024-09-24T00:00:00Z"
    87          And the parties submit the following one off transfers:
    88              | id | from                                                             | from_account_type    | to                                                               | to_account_type            | asset | amount   | delivery_time        |
    89              | 1  | f0b40ebdc5b92cf2cf82ff5d0c3f94085d23d5ec2d37d0b929e177c6d4d37e4c | ACCOUNT_TYPE_GENERAL | 0000000000000000000000000000000000000000000000000000000000000000 | ACCOUNT_TYPE_BUY_BACK_FEES | ETH   | 50000000 | 2024-09-24T00:00:00Z |
    90  
    91      Scenario: 0097-PAPU-039 - pap from is the quote asset of the market so order side in pap auction is buy. the price is the oracle price scaled by the offset (0097-PAPU-040). The order size is equal to the available quote token in the last snapshot divided by the scaled price factored by the fees. (0097-PAPU-042)
    92          When the protocol automated purchase is defined as:
    93              | 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 |
    94              | 12345 | ETH  | ACCOUNT_TYPE_BUY_BACK_FEES | ACCOUNT_TYPE_NETWORK_TREASURY | BTC/ETH   | price_oracle | 10s                              | 0.99                 | auction_schedule        | auction_vol_snap_schedule               | 60s              | 100                  | 20000000             | 0                |
    95  
    96          Then the oracles broadcast data with block time signed with "0xCAFECAFE2":
    97              | name             | value   | time offset |
    98              | prices.ETH.value | 1000000 | -1s         |
    99  
   100          And the network moves ahead "30" blocks
   101  
   102          # maximum auction size is 20000000 so expect 20000000 to be earmarked
   103          Then the automated purchase program for market "BTC/ETH" should have a snapshot balance of "20000000"
   104  
   105          # we enter a pap auction
   106          And the trading mode should be "TRADING_MODE_PROTOCOL_AUTOMATED_PURCHASE_AUCTION" for the market "BTC/ETH"
   107  
   108          # an order for buy BTC with size 20e6/(1.101*990000)=18
   109          And the order book should have the following volumes for market "BTC/ETH":
   110              | side | price  | volume |
   111              | buy  | 990000 | 18     |