code.vegaprotocol.io/vega@v0.79.0/core/integration/features/spot/orders/0034-PROB-010.feature (about) 1 Feature: Spot market quality of committed liquidity 2 3 Background: 4 Given time is updated to "2024-01-01T00:00:00Z" 5 6 Given the following network parameters are set: 7 | name | value | 8 | network.markPriceUpdateMaximumFrequency | 0s | 9 | market.value.windowLength | 1h | 10 | market.liquidity.probabilityOfTrading.tau.scaling | 1 | 11 | limits.markets.maxPeggedOrders | 4 | 12 13 Given the following assets are registered: 14 | id | decimal places | 15 | ETH | 2 | 16 | BTC | 2 | 17 18 And the liquidity sla params named "SLA": 19 | price range | commitment min time fraction | performance hysteresis epochs | sla competition factor | 20 | 1.0 | 0.5 | 1 | 1.0 | 21 22 And the spot markets: 23 | id | name | base asset | quote asset | risk model | auction duration | fees | price monitoring | decimal places | position decimal places | sla params | 24 | BTC/ETH | BTC/ETH | BTC | ETH | default-log-normal-risk-model | 1 | default-none | default-none | 2 | 2 | SLA | 25 26 # setup accounts 27 Given the parties deposit on asset's general account the following amount: 28 | party | asset | amount | 29 | party1 | ETH | 10000 | 30 | party5 | BTC | 100 | 31 | lp1 | ETH | 100000 | 32 | lp1 | BTC | 1000 | 33 | lp2 | ETH | 100000 | 34 | lp2 | BTC | 1000 | 35 36 And the average block duration is "1" 37 38 # Set up 2 users with liquidity commitments 39 And the parties submit the following liquidity provision: 40 | id | party | market id | commitment amount | fee | lp type | 41 | lp1 | lp1 | BTC/ETH | 10000 | 0.001 | submission | 42 | lp2 | lp2 | BTC/ETH | 10000 | 0.001 | submission | 43 44 # Place some orders to get out of auction 45 And the parties place the following orders: 46 | party | market id | side | volume | price | resulting trades | type | tif | reference | 47 | party1 | BTC/ETH | buy | 1 | 999 | 0 | TYPE_LIMIT | TIF_GTC | p1-buy1 | 48 | party1 | BTC/ETH | buy | 1 | 1000 | 0 | TYPE_LIMIT | TIF_GTC | p1-buy2 | 49 | party5 | BTC/ETH | sell | 1 | 1000 | 0 | TYPE_LIMIT | TIF_GTC | p5-sell1 | 50 | party5 | BTC/ETH | sell | 1 | 1001 | 0 | TYPE_LIMIT | TIF_GTC | p5-sell2 | 51 52 # Place pegged orders to cover their commitment, one close to top of the book, one further away 53 And the parties place the following pegged iceberg orders: 54 | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | reference | 55 | lp1 | BTC/ETH | 200 | 100 | buy | BID | 200 | 1 | lp1-buy | 56 | lp1 | BTC/ETH | 200 | 100 | sell | ASK | 200 | 1 | lp1-sell | 57 | lp2 | BTC/ETH | 200 | 100 | buy | BID | 200 | 10 | lp2-buy | 58 | lp2 | BTC/ETH | 200 | 100 | sell | ASK | 200 | 10 | lp2-sell | 59 60 And the opening auction period ends for market "BTC/ETH" 61 Then the trading mode should be "TRADING_MODE_CONTINUOUS" for the market "BTC/ETH" 62 And the mark price should be "1000" for the market "BTC/ETH" 63 And the network moves ahead "1" epochs 64 65 Scenario: Change of market.liquidity.probabilityOfTrading.tau.scaling will immediately change the 66 scaling parameter, hence will change the probability of trading used for comparing quality 67 of committed liquidity (0034-PROB-010) 68 69 And the orders should have the following states: 70 | party | market id | reference | side | volume | remaining | price | status | 71 | party1 | BTC/ETH | p1-buy1 | buy | 1 | 1 | 999 | STATUS_ACTIVE | 72 | party1 | BTC/ETH | p1-buy2 | buy | 1 | 0 | 1000 | STATUS_FILLED | 73 | party5 | BTC/ETH | p5-sell1 | sell | 1 | 0 | 1000 | STATUS_FILLED | 74 | party5 | BTC/ETH | p5-sell2 | sell | 1 | 1 | 1001 | STATUS_ACTIVE | 75 76 Then the pegged orders should have the following states: 77 | party | market id | side | volume | reference | offset | price | status | 78 | lp1 | BTC/ETH | buy | 200 | BID | 1 | 998 | STATUS_ACTIVE | 79 | lp1 | BTC/ETH | sell | 200 | ASK | 1 | 1002 | STATUS_ACTIVE | 80 | lp2 | BTC/ETH | buy | 200 | BID | 10 | 989 | STATUS_ACTIVE | 81 | lp2 | BTC/ETH | sell | 200 | ASK | 10 | 1011 | STATUS_ACTIVE | 82 83 Given the network moves ahead "1" epochs 84 Then the liquidity provider fee shares for the market "BTC/ETH" should be: 85 | party | equity like share | average entry valuation | average score | 86 | lp1 | 0.5 | 10000 | 0.6007854709 | 87 | lp2 | 0.5 | 20000 | 0.3992145291 | 88 89 # Now change the PoT value and move forward an epoch to apply the change 90 When the following network parameters are set: 91 | name | value | 92 | market.liquidity.probabilityOfTrading.tau.scaling | 1000 | 93 And the network moves ahead "1" epochs 94 95 # The average score should be updated to be different from the numbers above 96 Then the liquidity provider fee shares for the market "BTC/ETH" should be: 97 | party | equity like share | average entry valuation | average score | 98 | lp1 | 0.5 | 10000 | 0.561840354 | 99 | lp2 | 0.5 | 20000 | 0.438159646 |