code.vegaprotocol.io/vega@v0.79.0/core/integration/features/perpetual.feature (about) 1 Feature: Simple test creating a perpetual market. 2 3 Background: 4 Given the following assets are registered: 5 | id | decimal places | 6 | ETH | 18 | 7 | USD | 0 | 8 And the perpetual oracles from "0xCAFECAFE1": 9 | name | asset | settlement property | settlement type | schedule property | schedule type | margin funding factor | interest rate | clamp lower bound | clamp upper bound | quote name | settlement decimals | source weights | source staleness tolerance | 10 | perp-oracle | ETH | perp.ETH.value | TYPE_INTEGER | perp.funding.cue | TYPE_TIMESTAMP | 0 | 0 | 0 | 0 | ETH | 18 | 1,0,0,0 | 100s,0s,0s,0s | 11 And the liquidity sla params named "SLA": 12 | price range | commitment min time fraction | performance hysteresis epochs | sla competition factor | 13 | 1.0 | 0.5 | 1 | 1.0 | 14 And the liquidity monitoring parameters: 15 | name | triggering ratio | time window | scaling factor | 16 | lqm-params | 0.01 | 10s | 5 | 17 18 And the markets: 19 | id | quote name | asset | liquidity monitoring | risk model | margin calculator | auction duration | fees | price monitoring | data source config | linear slippage factor | quadratic slippage factor | decimal places | position decimal places | market type | sla params | tick size | 20 | ETH/DEC19 | ETH | ETH | lqm-params | default-st-risk-model | default-margin-calculator | 1 | default-none | default-none | perp-oracle | 0.1 | 0 | 5 | 5 | perp | SLA | 1 | 21 And the following network parameters are set: 22 | name | value | 23 | network.markPriceUpdateMaximumFrequency | 0s | 24 | market.auction.minimumDuration | 1 | 25 | market.fee.factors.infrastructureFee | 0.001 | 26 | market.fee.factors.makerFee | 0.004 | 27 | market.value.windowLength | 60s | 28 | market.liquidity.bondPenaltyParameter | 0.1 | 29 | validators.epoch.length | 5s | 30 | limits.markets.maxPeggedOrders | 2 | 31 | market.liquidity.providersFeeCalculationTimeStep | 5s | 32 33 And the average block duration is "1" 34 35 # All parties have 1,000,000.000,000,000,000,000,000 36 # Add as many parties as needed here 37 And the parties deposit on asset's general account the following amount: 38 | party | asset | amount | 39 | lpprov | ETH | 10000000000000000000000000 | 40 | trader1 | ETH | 10000000000000000000000000 | 41 | trader2 | ETH | 10000000000000000000000000 | 42 | trader3 | ETH | 10000000000000000000000000 | 43 | trader4 | ETH | 10000000000000000000000000 | 44 | trader5 | ETH | 10000000000000000000000000 | 45 46 47 @Perpetual 48 Scenario: 001 Create a new perp market and leave opening auction in the same way the system tests do 49 # the amount ought to be 390,500.000,000,000,000,000,000 50 Given the parties submit the following liquidity provision: 51 | id | party | market id | commitment amount | fee | lp type | 52 | lp1 | lpprov | ETH/DEC19 | 3905000000000000 | 0.3 | 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 | lpprov | ETH/DEC19 | 4000000000000000 | 3905000000000000 | buy | BID | 4000000000000000 | 1 | lp-ice-buy | 56 | lpprov | ETH/DEC19 | 4000000000000000 | 3905000000000000 | sell | ASK | 4000000000000000 | 1 | lp-ice-sell | 57 And the parties place the following orders: 58 | party | market id | side | volume | price | resulting trades | type | tif | reference | 59 | trader1 | ETH/DEC19 | buy | 5 | 1001 | 0 | TYPE_LIMIT | TIF_GTC | t1-b-1 | 60 | trader1 | ETH/DEC19 | buy | 5 | 900 | 0 | TYPE_LIMIT | TIF_GTC | t1-b-2 | 61 | trader1 | ETH/DEC19 | buy | 1 | 100 | 0 | TYPE_LIMIT | TIF_GTC | t1-b-3 | 62 | trader2 | ETH/DEC19 | sell | 5 | 1200 | 0 | TYPE_LIMIT | TIF_GTC | t2-s-1 | 63 | trader2 | ETH/DEC19 | sell | 1 | 100000 | 0 | TYPE_LIMIT | TIF_GTC | t2-s-2 | 64 | trader2 | ETH/DEC19 | sell | 5 | 951 | 0 | TYPE_LIMIT | TIF_GTC | t2-s-3 | 65 When the opening auction period ends for market "ETH/DEC19" 66 Then the market data for the market "ETH/DEC19" should be: 67 | mark price | trading mode | auction trigger | target stake | supplied stake | open interest | 68 | 976 | TRADING_MODE_CONTINUOUS | AUCTION_TRIGGER_UNSPECIFIED | 134907600000 | 3905000000000000 | 5 | 69 And the parties should have the following account balances: 70 | party | asset | market id | margin | general | 71 | trader1 | ETH | ETH/DEC19 | 126362285504 | 9999999999999873637714496 | 72 And the parties should have the following margin levels: 73 | party | market id | maintenance | 74 | trader1 | ETH/DEC19 | 105301904587 | 75 76 # example of how to use the oracle 77 When the oracles broadcast data with block time signed with "0xCAFECAFE1": 78 | name | value | time offset | 79 | perp.funding.cue | 1511924180 | -100s | 80 | perp.ETH.value | 975 | -2s | 81 | perp.ETH.value | 977 | -1s | 82 83 84 @Perpetual 85 Scenario: 002 Create a new perp market and leave opening auction, then terminate the market through governance 86 # the amount ought to be 390,500.000,000,000,000,000,000 87 Given the parties submit the following liquidity provision: 88 | id | party | market id | commitment amount | fee | lp type | 89 | lp1 | lpprov | ETH/DEC19 | 3905000000000000 | 0.3 | submission | 90 And the parties place the following pegged iceberg orders: 91 | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | reference | 92 | lpprov | ETH/DEC19 | 4000000000000000 | 3905000000000000 | buy | BID | 4000000000000000 | 1 | lp-ice-buy | 93 | lpprov | ETH/DEC19 | 4000000000000000 | 3905000000000000 | sell | ASK | 4000000000000000 | 1 | lp-ice-sell | 94 And the parties place the following orders: 95 | party | market id | side | volume | price | resulting trades | type | tif | reference | 96 | trader1 | ETH/DEC19 | buy | 5 | 1001 | 0 | TYPE_LIMIT | TIF_GTC | t1-b-1 | 97 | trader1 | ETH/DEC19 | buy | 5 | 900 | 0 | TYPE_LIMIT | TIF_GTC | t1-b-2 | 98 | trader1 | ETH/DEC19 | buy | 1 | 100 | 0 | TYPE_LIMIT | TIF_GTC | t1-b-3 | 99 | trader2 | ETH/DEC19 | sell | 5 | 1200 | 0 | TYPE_LIMIT | TIF_GTC | t2-s-1 | 100 | trader2 | ETH/DEC19 | sell | 1 | 100000 | 0 | TYPE_LIMIT | TIF_GTC | t2-s-2 | 101 | trader2 | ETH/DEC19 | sell | 5 | 951 | 0 | TYPE_LIMIT | TIF_GTC | t2-s-3 | 102 When the opening auction period ends for market "ETH/DEC19" 103 Then the market data for the market "ETH/DEC19" should be: 104 | mark price | trading mode | auction trigger | target stake | supplied stake | open interest | 105 | 976 | TRADING_MODE_CONTINUOUS | AUCTION_TRIGGER_UNSPECIFIED | 134907600000 | 3905000000000000 | 5 | 106 And the parties should have the following account balances: 107 | party | asset | market id | margin | general | 108 | trader1 | ETH | ETH/DEC19 | 126362285504 | 9999999999999873637714496 | 109 And the parties should have the following margin levels: 110 | party | market id | maintenance | 111 | trader1 | ETH/DEC19 | 105301904587 | 112 113 114 # example of how to use the oracle 115 When the oracles broadcast data with block time signed with "0xCAFECAFE1": 116 | name | value | time offset | 117 | perp.funding.cue | 1511924180 | -100s | 118 | perp.ETH.value | 975 | -2s | 119 | perp.ETH.value | 977 | -1s | 120 121 When the market states are updated through governance: 122 | market id | state | settlement price | 123 | ETH/DEC19 | MARKET_STATE_UPDATE_TYPE_TERMINATE | 976 | 124 Then the market state should be "STATE_CLOSED" for the market "ETH/DEC19" 125 126 @PerpetualCancel 127 Scenario: 003 Cancel a perps market in opening auction 128 # the amount ought to be 390,500.000,000,000,000,000,000 129 Given the parties submit the following liquidity provision: 130 | id | party | market id | commitment amount | fee | lp type | 131 | lp1 | lpprov | ETH/DEC19 | 3905000000000000 | 0.3 | submission | 132 And the parties place the following pegged iceberg orders: 133 | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | reference | 134 | lpprov | ETH/DEC19 | 4000000000000000 | 3905000000000000 | buy | BID | 4000000000000000 | 1 | lp-ice-buy | 135 | lpprov | ETH/DEC19 | 4000000000000000 | 3905000000000000 | sell | ASK | 4000000000000000 | 1 | lp-ice-sell | 136 And the parties place the following orders: 137 | party | market id | side | volume | price | resulting trades | type | tif | reference | 138 | trader1 | ETH/DEC19 | buy | 5 | 1001 | 0 | TYPE_LIMIT | TIF_GTC | t1-b-1 | 139 | trader1 | ETH/DEC19 | buy | 5 | 900 | 0 | TYPE_LIMIT | TIF_GTC | t1-b-2 | 140 | trader1 | ETH/DEC19 | buy | 1 | 100 | 0 | TYPE_LIMIT | TIF_GTC | t1-b-3 | 141 | trader2 | ETH/DEC19 | sell | 5 | 1200 | 0 | TYPE_LIMIT | TIF_GTC | t2-s-1 | 142 | trader2 | ETH/DEC19 | sell | 1 | 100000 | 0 | TYPE_LIMIT | TIF_GTC | t2-s-2 | 143 When the opening auction period ends for market "ETH/DEC19" 144 Then the market data for the market "ETH/DEC19" should be: 145 | mark price | trading mode | auction trigger | 146 | 0 | TRADING_MODE_OPENING_AUCTION | AUCTION_TRIGGER_OPENING | 147 And the parties should have the following account balances: 148 | party | asset | market id | margin | general | 149 | trader1 | ETH | ETH/DEC19 | 60659552186 | 9999999999999939340447814 | 150 151 152 # example of how to use the oracle 153 When the oracles broadcast data with block time signed with "0xCAFECAFE1": 154 | name | value | time offset | 155 | perp.ETH.value | 975 | -2s | 156 | perp.ETH.value | 977 | -1s | 157 158 And the parties place the following orders with ticks: 159 | party | market id | side | volume | price | resulting trades | type | tif | reference | 160 | trader2 | ETH/DEC19 | sell | 1 | 951 | 0 | TYPE_LIMIT | TIF_GTC | t2-s-2 | 161 Then the market data for the market "ETH/DEC19" should be: 162 | mark price | trading mode | auction trigger | 163 | 976 | TRADING_MODE_CONTINUOUS | AUCTION_TRIGGER_UNSPECIFIED | 164 When the market states are updated through governance: 165 | market id | state | settlement price | 166 | ETH/DEC19 | MARKET_STATE_UPDATE_TYPE_TERMINATE | 976 | 167 Then the market state should be "STATE_CLOSED" for the market "ETH/DEC19" 168 169 @PerpetualCancel 170 Scenario: 003 Cancel a perps market in opening auction 171 # the amount ought to be 390,500.000,000,000,000,000,000 172 Given the parties submit the following liquidity provision: 173 | id | party | market id | commitment amount | fee | lp type | 174 | lp1 | lpprov | ETH/DEC19 | 3905000000000000 | 0.3 | submission | 175 And the parties place the following pegged iceberg orders: 176 | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | reference | 177 | lpprov | ETH/DEC19 | 4000000000000000 | 3905000000000000 | buy | BID | 4000000000000000 | 1 | lp-ice-buy | 178 | lpprov | ETH/DEC19 | 4000000000000000 | 3905000000000000 | sell | ASK | 4000000000000000 | 1 | lp-ice-sell | 179 And the parties place the following orders: 180 | party | market id | side | volume | price | resulting trades | type | tif | reference | 181 | trader1 | ETH/DEC19 | buy | 5 | 1001 | 0 | TYPE_LIMIT | TIF_GTC | t1-b-1 | 182 | trader1 | ETH/DEC19 | buy | 5 | 900 | 0 | TYPE_LIMIT | TIF_GTC | t1-b-2 | 183 | trader1 | ETH/DEC19 | buy | 1 | 100 | 0 | TYPE_LIMIT | TIF_GTC | t1-b-3 | 184 | trader2 | ETH/DEC19 | sell | 5 | 1200 | 0 | TYPE_LIMIT | TIF_GTC | t2-s-1 | 185 | trader2 | ETH/DEC19 | sell | 1 | 100000 | 0 | TYPE_LIMIT | TIF_GTC | t2-s-2 | 186 When the opening auction period ends for market "ETH/DEC19" 187 Then the market data for the market "ETH/DEC19" should be: 188 | mark price | trading mode | auction trigger | 189 | 0 | TRADING_MODE_OPENING_AUCTION | AUCTION_TRIGGER_OPENING | 190 And the parties should have the following account balances: 191 | party | asset | market id | margin | general | 192 | trader1 | ETH | ETH/DEC19 | 60659552186 | 9999999999999939340447814 | 193 194 195 # example of how to use the oracle 196 When the oracles broadcast data with block time signed with "0xCAFECAFE1": 197 | name | value | time offset | 198 | perp.ETH.value | 975 | -2s | 199 | perp.ETH.value | 977 | -1s | 200 201 And the market states are updated through governance: 202 | market id | state | settlement price | 203 | ETH/DEC19 | MARKET_STATE_UPDATE_TYPE_TERMINATE | 976 | 204 Then the market state should be "STATE_CANCELLED" for the market "ETH/DEC19" 205 206 @Perpetual 207 Scenario: 004 Create a new perp market and run through funding periods with: no oracle data -> no payment, 1 oracle observation & no trading -> payment based internal TWAP=auction uncrossing price, multiple internal and external observations => funding payment calculated as expected. 208 Given the following network parameters are set: 209 | name | value | 210 | network.internalCompositePriceUpdateFrequency | 0s | 211 And the parties submit the following liquidity provision: 212 | id | party | market id | commitment amount | fee | lp type | 213 | lp1 | lpprov | ETH/DEC19 | 3905000000000000 | 0.3 | submission | 214 And the parties place the following pegged iceberg orders: 215 | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | 216 | lpprov | ETH/DEC19 | 400000000 | 100 | buy | BID | 8000000000 | 1 | 217 | lpprov | ETH/DEC19 | 400000000 | 100 | sell | ASK | 8000000000 | 1 | 218 And the parties place the following orders: 219 | party | market id | side | volume | price | type | tif | 220 | trader1 | ETH/DEC19 | buy | 1 | 1001 | TYPE_LIMIT | TIF_GTC | 221 | trader2 | ETH/DEC19 | sell | 1 | 951 | TYPE_LIMIT | TIF_GTC | 222 When the opening auction period ends for market "ETH/DEC19" 223 Then system unix time is "1575072002" 224 And the market data for the market "ETH/DEC19" should be: 225 | mark price | trading mode | auction trigger | open interest | 226 | 976 | TRADING_MODE_CONTINUOUS | AUCTION_TRIGGER_UNSPECIFIED | 1 | 227 And the following funding period events should be emitted: 228 | start | end | internal twap | external twap | 229 | 1575072002 | | | | 230 231 # perps payment doesn't happen in the absence of oracle data 232 When the oracles broadcast data with block time signed with "0xCAFECAFE1": 233 | name | value | time offset | 234 | perp.funding.cue | 1575072003 | 0s | 235 And the following funding period events should be emitted: 236 | start | end | internal twap | external twap | 237 | 1575072002 | 1575072003 | 9760000000000000 | | 238 | 1575072003 | | 9760000000000000 | | 239 Then the transfers of following types should NOT happen: 240 | type | 241 | TRANSFER_TYPE_PERPETUALS_FUNDING_LOSS | 242 | TRANSFER_TYPE_PERPETUALS_FUNDING_WIN | 243 244 # perps payment happens in absence of trades after the opening auction (opening auction sets mark price so that's already one internal observation) 245 When the network moves ahead "4" blocks 246 And the oracles broadcast data with block time signed with "0xCAFECAFE1": 247 | name | value | time offset | 248 | perp.ETH.value | 9770000000000000 | -1s | 249 | perp.funding.cue | 1575072007 | 0s | 250 Then system unix time is "1575072006" 251 # funding payment = 976 - 977 = -1 252 # TODO: is 13 decimal places fine, it's asset - market so seems like internal precision, do we ever use that externally?? It's fine on API but would be nice to understand 253 And the following funding period events should be emitted: 254 | start | end | internal twap | external twap | funding payment | funding rate | 255 | 1575072003 | 1575072007 | 9760000000000000 | 9770000000000000 | -10000000000000 | -0.0010235414534289 | 256 | 1575072007 | | 9760000000000000 | 9770000000000000 | | | 257 And the following transfers should happen: 258 | type | from | to | from account | to account | market id | amount | asset | 259 | TRANSFER_TYPE_PERPETUALS_FUNDING_LOSS | trader2 | market | ACCOUNT_TYPE_MARGIN | ACCOUNT_TYPE_SETTLEMENT | ETH/DEC19 | 100000000 | ETH | 260 | TRANSFER_TYPE_PERPETUALS_FUNDING_WIN | market | trader1 | ACCOUNT_TYPE_SETTLEMENT | ACCOUNT_TYPE_MARGIN | ETH/DEC19 | 100000000 | ETH | 261 262 # perps payment calculated correctly with multiple internal and external observations 263 When the network moves ahead "2" blocks 264 265 Then the mark price should be "976" for the market "ETH/DEC19" 266 267 And the parties place the following orders with ticks: 268 | party | market id | side | volume | price | type | tif | resulting trades | 269 | trader3 | ETH/DEC19 | buy | 1 | 980 | TYPE_LIMIT | TIF_GTC | 0 | 270 | trader4 | ETH/DEC19 | sell | 1 | 980 | TYPE_LIMIT | TIF_FOK | 1 | 271 272 Then the market data for the market "ETH/DEC19" should be: 273 | mark price | trading mode | auction trigger | 274 | 980 | TRADING_MODE_CONTINUOUS | AUCTION_TRIGGER_UNSPECIFIED | 275 And system unix time is "1575072008" 276 277 When the network moves ahead "4" blocks 278 And the parties place the following orders with ticks: 279 | party | market id | side | volume | price | type | tif | resulting trades | 280 | trader3 | ETH/DEC19 | buy | 1 | 989 | TYPE_LIMIT | TIF_GTC | 0 | 281 | trader4 | ETH/DEC19 | sell | 1 | 989 | TYPE_LIMIT | TIF_FOK | 1 | 282 283 And the following trades should be executed: 284 | buyer | price | size | seller | 285 | trader3 | 989 | 1 | trader4 | 286 287 Then the market data for the market "ETH/DEC19" should be: 288 | mark price | trading mode | auction trigger | 289 | 989 | TRADING_MODE_CONTINUOUS | AUCTION_TRIGGER_UNSPECIFIED | 290 And system unix time is "1575072012" 291 292 When the network moves ahead "1" blocks 293 And the oracles broadcast data with block time signed with "0xCAFECAFE1": 294 | name | value | time offset | 295 | perp.ETH.value | 9760000000000000 | -5s | 296 # resubmitting same value at a different time should have no effect 297 | perp.ETH.value | 9760000000000000 | -2s | 298 | perp.ETH.value | 9720000000000000 | -1s | 299 | perp.funding.cue | 1575072014 | 0s | 300 Then system unix time is "1575072013" 301 # internal TWAP = (976*1+980*4+989*2)/7=982 302 # external TWAP = (977*1+976*4+972*2)/7=975 303 # funding payment = 7 304 Then debug funding period events 305 306 And the following funding period events should be emitted: 307 | start | end | internal twap | external twap | funding payment | funding rate | 308 | 1575072007 | 1575072014 | 9820000000000000 | 9750000000000000 | 70000000000000 | 0.0071794871794872 | 309 | 1575072014 | | 9890000000000000 | 9720000000000000 | | | 310 And the following funding payment events should be emitted: 311 | party | market | amount | 312 | trader2 | ETH/DEC19 | -100000000 | 313 | trader2 | ETH/DEC19 | 700000000 | 314 | trader1 | ETH/DEC19 | 100000000 | 315 | trader1 | ETH/DEC19 | -700000000 | 316 | trader3 | ETH/DEC19 | -1400000000 | 317 | trader4 | ETH/DEC19 | 1400000000 | 318 # payments for trader3 and trader4 should be twice those of trader1 and trader2 319 And the following transfers should happen: 320 | type | from | to | from account | to account | market id | amount | asset | 321 | TRANSFER_TYPE_PERPETUALS_FUNDING_LOSS | trader1 | market | ACCOUNT_TYPE_MARGIN | ACCOUNT_TYPE_SETTLEMENT | ETH/DEC19 | 700000000 | ETH | 322 | TRANSFER_TYPE_PERPETUALS_FUNDING_WIN | market | trader2 | ACCOUNT_TYPE_SETTLEMENT | ACCOUNT_TYPE_MARGIN | ETH/DEC19 | 700000000 | ETH | 323 | TRANSFER_TYPE_PERPETUALS_FUNDING_LOSS | trader3 | market | ACCOUNT_TYPE_MARGIN | ACCOUNT_TYPE_SETTLEMENT | ETH/DEC19 | 1400000000 | ETH | 324 | TRANSFER_TYPE_PERPETUALS_FUNDING_WIN | market | trader4 | ACCOUNT_TYPE_SETTLEMENT | ACCOUNT_TYPE_MARGIN | ETH/DEC19 | 1400000000 | ETH | 325