code.vegaprotocol.io/vega@v0.79.0/core/integration/features/spot/liquidity_provision/0044-LIME-103.feature (about) 1 Feature: Check LP slashing after intra-epoch change to time on book requirements 2 Background: 3 4 Given the following network parameters are set: 5 | name | value | 6 | market.liquidity.bondPenaltyParameter | 1 | 7 | network.markPriceUpdateMaximumFrequency | 0s | 8 | limits.markets.maxPeggedOrders | 2 | 9 | validators.epoch.length | 10s | 10 | market.liquidity.earlyExitPenalty | 0.25 | 11 | market.liquidity.stakeToCcyVolume | 1.0 | 12 | market.liquidity.sla.nonPerformanceBondPenaltySlope | 0.19 | 13 | market.liquidity.sla.nonPerformanceBondPenaltyMax | 1 | 14 And the liquidity monitoring parameters: 15 | name | triggering ratio | time window | scaling factor | 16 | lqm-params | 0.10 | 24h | 1 | 17 18 And the average block duration is "1" 19 And the simple risk model named "simple-risk-model-1": 20 | long | short | max move up | min move down | probability of trading | 21 | 0.1 | 0.1 | 60 | 50 | 0.2 | 22 And the fees configuration named "fees-config-1": 23 | maker fee | infrastructure fee | 24 | 0.004 | 0.001 | 25 And the price monitoring named "price-monitoring-1": 26 | horizon | probability | auction extension | 27 | 1 | 0.99 | 5 | 28 And the liquidity sla params named "SLA": 29 | price range | commitment min time fraction | performance hysteresis epochs | sla competition factor | 30 | 0.05 | 0.6 | 1 | 1.0 | 31 And the liquidity sla params named "SLA-2": 32 | price range | commitment min time fraction | performance hysteresis epochs | sla competition factor | 33 | 0.05 | 0.3 | 1 | 1.0 | 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 | simple-risk-model-1 | 2 | fees-config-1 | price-monitoring-1 | SLA | 37 And the following network parameters are set: 38 | name | value | 39 | market.liquidity.providersFeeCalculationTimeStep | 5s | 40 41 And the parties deposit on asset's general account the following amount: 42 | party | asset | amount | 43 | party1 | ETH | 100000000 | 44 | party2 | ETH | 100000000 | 45 | party1 | BTC | 100000000 | 46 | party2 | BTC | 100000000 | 47 And the parties submit the following liquidity provision: 48 | id | party | market id | commitment amount | fee | lp type | 49 | lp1 | party1 | BTC/ETH | 1000 | 0.001 | submission | 50 And the parties place the following orders: 51 | party | market id | side | volume | price | resulting trades | type | tif | reference | 52 | party1 | BTC/ETH | buy | 30 | 910 | 0 | TYPE_LIMIT | TIF_GTC | party1-order1 | 53 | party1 | BTC/ETH | sell | 20 | 1000 | 0 | TYPE_LIMIT | TIF_GTC | party1-order2 | 54 | party2 | BTC/ETH | buy | 10 | 1000 | 0 | TYPE_LIMIT | TIF_GTC | party2-order1 | 55 56 Scenario: If a liquidity provider has fraction_of_time_on_book >= market.liquidity.commitmentMinTimeFraction, no penalty will be taken from their bond account (0044-LIME-103) 57 58 When the opening auction period ends for market "BTC/ETH" 59 And the auction ends with a traded volume of "10" at a price of "1000" 60 Then the market data for the market "BTC/ETH" should be: 61 | mark price | trading mode | target stake | supplied stake | open interest | best static bid price | static mid price | best static offer price | 62 | 1000 | TRADING_MODE_CONTINUOUS | 0 | 1000 | 0 | 910 | 955 | 1000 | 63 64 And the parties should have the following account balances: 65 | party | asset | market id | general | bond | 66 | party1 | ETH | BTC/ETH | 99981700 | 1000 | 67 68 # Move forward an epoch and make sure the accounts do not change as we have 5/5 blocks covered 69 When the network moves ahead "1" epochs 70 Then the liquidity provisions should have the following states: 71 | id | party | market | commitment amount | status | 72 | lp1 | party1 | BTC/ETH | 1000 | STATUS_ACTIVE | 73 And the parties should have the following account balances: 74 | party | asset | market id | general | bond | 75 | party1 | ETH | BTC/ETH | 99981700 | 1000 | 76 77 # Move forward 6 blocks and then cancel the commitment covering order 78 When the network moves ahead "3" blocks 79 # Cancel the order so we are no longer covering our commitment 80 Then the parties cancel the following orders: 81 | party | reference | 82 | party1 | party1-order1 | 83 | party1 | party1-order2 | 84 85 Then the spot markets are updated: 86 | id | sla params | 87 | BTC/ETH | SLA-2 | 88 Then the network moves ahead "1" epochs 89 90 # Move forward 1 block to end the epoch and make sure we still are punished as SLA should not have updated yet 91 And the parties should have the following account balances: 92 | party | asset | market id | general | bond | 93 | party1 | ETH | BTC/ETH | 100009000 | 890 | 94 95 When the parties place the following orders: 96 | party | market id | side | volume | price | resulting trades | type | tif | reference | 97 | party1 | BTC/ETH | buy | 30 | 910 | 0 | TYPE_LIMIT | TIF_GTC | party1-order1 | 98 | party1 | BTC/ETH | sell | 20 | 1000 | 0 | TYPE_LIMIT | TIF_GTC | party1-order2 | 99 100 Then the network moves ahead "4" blocks 101 Then the parties cancel the following orders: 102 | party | reference | 103 | party1 | party1-order1 | 104 | party1 | party1-order2 | 105 106 Then the network moves ahead "1" epochs 107 108 # Move forward 1 block to end the epoch and make sure we still are punished as SLA should not have updated yet 109 And the parties should have the following account balances: 110 | party | asset | market id | general | bond | 111 | party1 | ETH | BTC/ETH | 100009000 | 890 |