code.vegaprotocol.io/vega@v0.79.0/core/integration/features/spot/liquidity_provision/0042-LIQF-084.feature (about) 1 Feature: Calculating SLA Performance 2 3 Background: 4 Given the simple risk model named "simple-risk-model-1": 5 | long | short | max move up | min move down | probability of trading | 6 | 0.1 | 0.1 | 500 | 500 | 0.1 | 7 And the fees configuration named "fees-config-1": 8 | maker fee | infrastructure fee | 9 | 0.0004 | 0.001 | 10 And the price monitoring named "price-monitoring": 11 | horizon | probability | auction extension | 12 | 1 | 0.99 | 3 | 13 And the liquidity monitoring parameters: 14 | name | triggering ratio | time window | scaling factor | 15 | lqm-params | 0.0 | 10s | 0.75 | 16 And the liquidity sla params named "SLA": 17 | price range | commitment min time fraction | performance hysteresis epochs | sla competition factor | 18 | 1.0 | 0.5 | 0 | 0 | 19 20 And the spot markets: 21 | id | name | base asset | quote asset | risk model | auction duration | fees | price monitoring | sla params | liquidity monitoring | 22 | BTC/ETH | BTC/ETH | BTC | ETH | simple-risk-model-1 | 2 | fees-config-1 | price-monitoring | SLA | lqm-params | 23 24 And the following network parameters are set: 25 | name | value | 26 | limits.markets.maxPeggedOrders | 2 | 27 | network.markPriceUpdateMaximumFrequency | 0s | 28 | market.liquidity.providersFeeCalculationTimeStep | 1s | 29 | validators.epoch.length | 58s | 30 | market.liquidity.stakeToCcyVolume | 1 | 31 32 And the average block duration is "1" 33 34 And the parties deposit on asset's general account the following amount: 35 | party | asset | amount | 36 | lp1 | ETH | 1000000000000000000 | 37 | lp1 | BTC | 1000000000000000000 | 38 | aux1 | ETH | 1000000000000000000 | 39 | aux1 | BTC | 1000000000000000000 | 40 | aux2 | ETH | 1000000000000000000 | 41 | aux2 | BTC | 1000000000000000000 | 42 | party1 | ETH | 1000000000000000000 | 43 | party1 | BTC | 1000000000000000000 | 44 | party2 | BTC | 1000000000000000000 | 45 46 @SPOTSLA 47 Scenario: LP fulfills the mininum time fraction but is not always on the book when the sla competition factor is zero. (0042-LIQF-084) 48 49 # Setup the market with 1 LP who is initially meeting their commitment 50 Given the parties submit the following liquidity provision: 51 | id | party | market id | commitment amount | fee | lp type | 52 | lp1 | lp1 | BTC/ETH | 500 | 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 | reference | 55 | lp1 | BTC/ETH | 4 | 1 | buy | MID | 4 | 1 | lp1-ice-buy-1 | 56 | lp1 | BTC/ETH | 4 | 1 | sell | MID | 4 | 1 | lp1-ice-sell-1 | 57 58 When the parties place the following orders: 59 | party | market id | side | volume | price | resulting trades | type | tif | 60 | aux1 | BTC/ETH | buy | 1 | 990 | 0 | TYPE_LIMIT | TIF_GTC | 61 | aux2 | BTC/ETH | buy | 1 | 1000 | 0 | TYPE_LIMIT | TIF_GTC | 62 | aux1 | BTC/ETH | sell | 1 | 1000 | 0 | TYPE_LIMIT | TIF_GTC | 63 | aux2 | BTC/ETH | sell | 1 | 1010 | 0 | TYPE_LIMIT | TIF_GTC | 64 # Leave opening auction, then nothing happens for 31 blocks (getting us past 50% of the time fraction) 65 And the network moves ahead "45" blocks 66 Then the trading mode should be "TRADING_MODE_CONTINUOUS" for the market "BTC/ETH" 67 68 # Generate liquidity fees to be allocated to the LP 69 When the parties place the following orders: 70 | party | market id | side | volume | price | resulting trades | type | tif | 71 | party1 | BTC/ETH | buy | 1 | 1000 | 0 | TYPE_LIMIT | TIF_GTC | 72 | party2 | BTC/ETH | sell | 1 | 1000 | 1 | TYPE_LIMIT | TIF_GTC | 73 Then the accumulated liquidity fees should be "101" for the market "BTC/ETH" 74 75 # Ensure LPs timeBookFraction ~=0.75, then check ~0.0 fees are penalised 76 # 50 blocks in to the 58s (or 58 block) long epoch. 77 When the network moves ahead "5" blocks 78 Then the parties cancel the following orders: 79 | party | reference | 80 | lp1 | lp1-ice-buy-1 | 81 | lp1 | lp1-ice-sell-1 | 82 83 When the network moves ahead "1" epochs 84 # We should see these transfers 85 Then the following transfers should happen: 86 | from | to | from account | to account | market id | amount | asset | 87 | | lp1 | ACCOUNT_TYPE_FEES_LIQUIDITY | ACCOUNT_TYPE_LP_LIQUIDITY_FEES | BTC/ETH | 101 | ETH | 88 | lp1 | lp1 | ACCOUNT_TYPE_LP_LIQUIDITY_FEES | ACCOUNT_TYPE_GENERAL | BTC/ETH | 101 | ETH | 89 90 @SPOTSLA 91 Scenario: LP fulfills the mininum time fraction but is not always on the book when the sla competition factor is zero. Same as previous scenario, different timings. (0042-LIQF-084) 92 93 # Setup the market with 1 LP who is initially meeting their commitment 94 Given the parties submit the following liquidity provision: 95 | id | party | market id | commitment amount | fee | lp type | 96 | lp1 | lp1 | BTC/ETH | 500 | 0.1 | submission | 97 And the parties place the following pegged iceberg orders: 98 | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | reference | 99 | lp1 | BTC/ETH | 4 | 1 | buy | MID | 4 | 1 | lp1-ice-buy-1 | 100 | lp1 | BTC/ETH | 4 | 1 | sell | MID | 4 | 1 | lp1-ice-sell-1 | 101 102 When the parties place the following orders: 103 | party | market id | side | volume | price | resulting trades | type | tif | 104 | aux1 | BTC/ETH | buy | 1 | 990 | 0 | TYPE_LIMIT | TIF_GTC | 105 | aux2 | BTC/ETH | buy | 1 | 1000 | 0 | TYPE_LIMIT | TIF_GTC | 106 | aux1 | BTC/ETH | sell | 1 | 1000 | 0 | TYPE_LIMIT | TIF_GTC | 107 | aux2 | BTC/ETH | sell | 1 | 1010 | 0 | TYPE_LIMIT | TIF_GTC | 108 # Leave opening auction, then nothing happens for 31 blocks (getting us past 50% of the time fraction) 109 And the network moves ahead "3" blocks 110 Then the trading mode should be "TRADING_MODE_CONTINUOUS" for the market "BTC/ETH" 111 112 # Generate liquidity fees to be allocated to the LP 113 When the parties place the following orders: 114 | party | market id | side | volume | price | resulting trades | type | tif | 115 | party1 | BTC/ETH | buy | 1 | 1000 | 0 | TYPE_LIMIT | TIF_GTC | 116 | party2 | BTC/ETH | sell | 1 | 1000 | 1 | TYPE_LIMIT | TIF_GTC | 117 Then the accumulated liquidity fees should be "101" for the market "BTC/ETH" 118 119 # Ensure LPs timeBookFraction ~=0.75, then check ~0.0 fees are penalised 120 When the network moves ahead "45" blocks 121 Then the parties cancel the following orders: 122 | party | reference | 123 | lp1 | lp1-ice-buy-1 | 124 | lp1 | lp1-ice-sell-1 | 125 126 When the network moves ahead "1" epochs 127 # We should see these transfers 128 Then the following transfers should happen: 129 | from | to | from account | to account | market id | amount | asset | 130 | | lp1 | ACCOUNT_TYPE_FEES_LIQUIDITY | ACCOUNT_TYPE_LP_LIQUIDITY_FEES | BTC/ETH | 101 | ETH | 131 | lp1 | lp1 | ACCOUNT_TYPE_LP_LIQUIDITY_FEES | ACCOUNT_TYPE_GENERAL | BTC/ETH | 101 | ETH | 132 133 @SPOTSLA 134 Scenario: LP fulfills the mininum time fraction but is not always on the book when the sla competition factor is zero. (0042-LIQF-085) 135 136 # Setup the market with 1 LP who is initially meeting their commitment 137 Given the parties submit the following liquidity provision: 138 | id | party | market id | commitment amount | fee | lp type | 139 | lp1 | lp1 | BTC/ETH | 500 | 0.1 | submission | 140 And the parties place the following pegged iceberg orders: 141 | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | reference | 142 | lp1 | BTC/ETH | 4 | 1 | buy | MID | 4 | 1 | lp1-ice-buy-1 | 143 | lp1 | BTC/ETH | 4 | 1 | sell | MID | 4 | 1 | lp1-ice-sell-1 | 144 145 When the parties place the following orders: 146 | party | market id | side | volume | price | resulting trades | type | tif | 147 | aux1 | BTC/ETH | buy | 1 | 990 | 0 | TYPE_LIMIT | TIF_GTC | 148 | aux2 | BTC/ETH | buy | 1 | 1000 | 0 | TYPE_LIMIT | TIF_GTC | 149 | aux1 | BTC/ETH | sell | 1 | 1000 | 0 | TYPE_LIMIT | TIF_GTC | 150 | aux2 | BTC/ETH | sell | 1 | 1010 | 0 | TYPE_LIMIT | TIF_GTC | 151 # Leave opening auction, then nothing happens for 31 blocks (getting us past 50% of the time fraction) 152 And the network moves ahead "45" blocks 153 Then the trading mode should be "TRADING_MODE_CONTINUOUS" for the market "BTC/ETH" 154 155 # Generate liquidity fees to be allocated to the LP 156 When the parties place the following orders: 157 | party | market id | side | volume | price | resulting trades | type | tif | 158 | party1 | BTC/ETH | buy | 1 | 1000 | 0 | TYPE_LIMIT | TIF_GTC | 159 | party2 | BTC/ETH | sell | 1 | 1000 | 1 | TYPE_LIMIT | TIF_GTC | 160 Then the accumulated liquidity fees should be "101" for the market "BTC/ETH" 161 162 # Ensure LPs timeBookFraction ~=0.75, then check ~0.0 fees are penalised 163 # 50 blocks in to the 58s (or 58 block) long epoch. 164 When the network moves ahead "5" blocks 165 Then the parties cancel the following orders: 166 | party | reference | 167 | lp1 | lp1-ice-buy-1 | 168 | lp1 | lp1-ice-sell-1 | 169 170 When the network moves ahead "1" epochs 171 # We should see these transfers 172 Then the following transfers should happen: 173 | from | to | from account | to account | market id | amount | asset | 174 | | lp1 | ACCOUNT_TYPE_FEES_LIQUIDITY | ACCOUNT_TYPE_LP_LIQUIDITY_FEES | BTC/ETH | 101 | ETH | 175 | lp1 | lp1 | ACCOUNT_TYPE_LP_LIQUIDITY_FEES | ACCOUNT_TYPE_GENERAL | BTC/ETH | 101 | ETH | 176 177 @SPOTSLA 178 Scenario: LP fulfills the mininum time fraction but is not always on the book when the sla competition factor is zero. Same as previous scenario, different timings. The next epoch they meet their commitment such that time on book is 0.75, penalty should be 0.25. (0042-LIQF-085) 179 180 # Setup the market with 1 LP who is initially meeting their commitment 181 Given the parties submit the following liquidity provision: 182 | id | party | market id | commitment amount | fee | lp type | 183 | lp1 | lp1 | BTC/ETH | 500 | 0.1 | submission | 184 And the parties place the following pegged iceberg orders: 185 | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | reference | 186 | lp1 | BTC/ETH | 4 | 1 | buy | MID | 4 | 1 | lp1-ice-buy-1 | 187 | lp1 | BTC/ETH | 4 | 1 | sell | MID | 4 | 1 | lp1-ice-sell-1 | 188 189 When the parties place the following orders: 190 | party | market id | side | volume | price | resulting trades | type | tif | 191 | aux1 | BTC/ETH | buy | 1 | 990 | 0 | TYPE_LIMIT | TIF_GTC | 192 | aux2 | BTC/ETH | buy | 1 | 1000 | 0 | TYPE_LIMIT | TIF_GTC | 193 | aux1 | BTC/ETH | sell | 1 | 1000 | 0 | TYPE_LIMIT | TIF_GTC | 194 | aux2 | BTC/ETH | sell | 1 | 1010 | 0 | TYPE_LIMIT | TIF_GTC | 195 # Leave opening auction, then nothing happens for 31 blocks (getting us past 50% of the time fraction) 196 And the network moves ahead "3" blocks 197 Then the trading mode should be "TRADING_MODE_CONTINUOUS" for the market "BTC/ETH" 198 199 # Generate liquidity fees to be allocated to the LP 200 When the parties place the following orders: 201 | party | market id | side | volume | price | resulting trades | type | tif | 202 | party1 | BTC/ETH | buy | 1 | 1000 | 0 | TYPE_LIMIT | TIF_GTC | 203 | party2 | BTC/ETH | sell | 1 | 1000 | 1 | TYPE_LIMIT | TIF_GTC | 204 Then the accumulated liquidity fees should be "101" for the market "BTC/ETH" 205 206 # Ensure LPs timeBookFraction ~=0.75, then check ~0.0 fees are penalised 207 When the network moves ahead "44" blocks 208 Then the parties cancel the following orders: 209 | party | reference | 210 | lp1 | lp1-ice-buy-1 | 211 | lp1 | lp1-ice-sell-1 | 212 # re-submit the orders to meet commitment amount 213 When the network moves ahead "1" blocks 214 And the parties place the following pegged iceberg orders: 215 | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | reference | 216 | lp1 | BTC/ETH | 4 | 1 | buy | MID | 4 | 1 | lp1-ice-buy-2 | 217 | lp1 | BTC/ETH | 4 | 1 | sell | MID | 4 | 1 | lp1-ice-sell-2 | 218 219 When the network moves ahead "1" epochs 220 # We should see these transfers 221 Then the following transfers should happen: 222 | from | to | from account | to account | market id | amount | asset | 223 | | lp1 | ACCOUNT_TYPE_FEES_LIQUIDITY | ACCOUNT_TYPE_LP_LIQUIDITY_FEES | BTC/ETH | 101 | ETH | 224 | lp1 | lp1 | ACCOUNT_TYPE_LP_LIQUIDITY_FEES | ACCOUNT_TYPE_GENERAL | BTC/ETH | 101 | ETH | 225 226 # Now perform some trade so that there are fees to go around once again 227 When the network moves ahead "40" blocks 228 And the parties place the following orders: 229 | party | market id | side | volume | price | resulting trades | type | tif | 230 | party1 | BTC/ETH | buy | 1 | 1000 | 0 | TYPE_LIMIT | TIF_GTC | 231 | party2 | BTC/ETH | sell | 1 | 1000 | 1 | TYPE_LIMIT | TIF_GTC | 232 Then the accumulated liquidity fees should be "101" for the market "BTC/ETH" 233 # Move forwards another 4 blocks to get to 75% of time on book (58 block epochs, 75% == 43.5 blocks) 234 When the network moves ahead "4" blocks 235 Then the parties cancel the following orders: 236 | party | reference | 237 | lp1 | lp1-ice-buy-2 | 238 | lp1 | lp1-ice-sell-2 | 239 When the network moves ahead "1" epochs 240 # We should see these transfers 241 Then debug transfers 242 Then the following transfers should happen: 243 | from | to | from account | to account | market id | amount | asset | 244 | | lp1 | ACCOUNT_TYPE_FEES_LIQUIDITY | ACCOUNT_TYPE_LP_LIQUIDITY_FEES | BTC/ETH | 101 | ETH | 245 | lp1 | lp1 | ACCOUNT_TYPE_LP_LIQUIDITY_FEES | ACCOUNT_TYPE_GENERAL | BTC/ETH | 101 | ETH |