code.vegaprotocol.io/vega@v0.79.0/core/integration/features/settlement/0019-MCAL_018.feature (about) 1 Feature: check when settlement data precision is different/equal to the settlement asset precision, and also check decimal on the market with different market/position/asset decimal 2 3 Background: 4 5 Given the following assets are registered: 6 | id | decimal places | 7 | USD | 2 | 8 9 And the perpetual oracles from "0xCAFECAFE1": 10 | 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 | 11 | perp-oracle-1 | USD | perp.ETH.value | TYPE_INTEGER | perp.funding.cue | TYPE_TIMESTAMP | 0.5 | 0.05 | 0.1 | 0.5 | ETH | 5 | 12 And the perpetual oracles from "0xCAFECAFE2": 13 | 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 | 14 | perp-oracle-2 | USD | perp.ETH.value | TYPE_INTEGER | perp.funding.cue | TYPE_TIMESTAMP | 0.5 | 0.05 | 0.1 | 0.5 | ETH | 2 | 15 And the perpetual oracles from "0xCAFECAFE3": 16 | 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 | 17 | perp-oracle-3 | USD | perp.ETH.value | TYPE_INTEGER | perp.funding.cue | TYPE_TIMESTAMP | 0.5 | 0.05 | 0.1 | 0.5 | ETH | 1 | 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 following network parameters are set: 23 | name | value | 24 | market.auction.minimumDuration | 1 | 25 | limits.markets.maxPeggedOrders | 2 | 26 27 @Perpetual 28 Scenario: 001 oracle data decimal > asset decimal 0070-MKTD-018, 0019-MCAL-091 29 # start at this timestamp 30 Given time is updated to "2021-02-11T16:35:21Z" 31 And the markets: 32 | id | quote name | asset | risk model | margin calculator | auction duration | fees | price monitoring | data source config | linear slippage factor | quadratic slippage factor | position decimal places | market type | sla params | 33 | ETH/DEC19 | ETH | USD | default-simple-risk-model-3 | default-margin-calculator | 1 | default-none | default-none | perp-oracle-1 | 0.25 | 0 | -1 | perp | default-futures | 34 And the following network parameters are set: 35 | name | value | 36 | market.auction.minimumDuration | 1 | 37 | limits.markets.maxPeggedOrders | 2 | 38 | network.markPriceUpdateMaximumFrequency | 5s | 39 And the parties deposit on asset's general account the following amount: 40 | party | asset | amount | 41 | party1 | USD | 1000000000 | 42 | party2 | USD | 100000000 | 43 | party3 | USD | 100000000 | 44 | aux | USD | 300000000 | 45 | aux2 | USD | 300000000 | 46 | lp1 | USD | 500000000 | 47 48 When the parties submit the following liquidity provision: 49 | id | party | market id | commitment amount | fee | lp type | 50 | lp1 | lp1 | ETH/DEC19 | 1200000 | 0.001 | submission | 51 52 And the parties place the following pegged iceberg orders: 53 | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | reference | 54 | lp1 | ETH/DEC19 | 20 | 1 | buy | BID | 50 | 1 | lp-buy-1 | 55 | lp1 | ETH/DEC19 | 20 | 1 | sell | ASK | 50 | 1 | lp-sell-1 | 56 57 #place auxiliary orders so we always have best bid and best offer as to not trigger the liquidity auction 58 When the parties place the following orders: 59 | party | market id | side | volume | price | resulting trades | type | tif | 60 | aux | ETH/DEC19 | buy | 1 | 849 | 0 | TYPE_LIMIT | TIF_GTC | 61 | aux | ETH/DEC19 | sell | 1 | 2001 | 0 | TYPE_LIMIT | TIF_GTC | 62 | aux2 | ETH/DEC19 | buy | 1 | 1000 | 0 | TYPE_LIMIT | TIF_GTC | 63 | aux | ETH/DEC19 | sell | 1 | 1000 | 0 | TYPE_LIMIT | TIF_GTC | 64 65 # Time moves forwards 2s 66 Then the network moves ahead "2" blocks 67 And the trading mode should be "TRADING_MODE_CONTINUOUS" for the market "ETH/DEC19" 68 69 # Another +1s making it 2021-02-11T16:35:24 70 When the network moves ahead "1" blocks 71 And the parties place the following orders: 72 | party | market id | side | volume | price | resulting trades | type | tif | 73 | party1 | ETH/DEC19 | sell | 1 | 1000 | 0 | TYPE_LIMIT | TIF_GTC | 74 | party2 | ETH/DEC19 | buy | 1 | 1000 | 1 | TYPE_LIMIT | TIF_GTC | 75 76 Then the parties should have the following account balances: 77 | party | asset | market id | margin | general | 78 | party1 | USD | ETH/DEC19 | 120000 | 999880000 | 79 | party2 | USD | ETH/DEC19 | 132000 | 99867000 | 80 | lp1 | USD | ETH/DEC19 | 6600000 | 492200000 | 81 82 When the parties place the following orders: 83 | party | market id | side | volume | price | resulting trades | type | tif | 84 | party1 | ETH/DEC19 | sell | 1 | 2000 | 0 | TYPE_LIMIT | TIF_GTC | 85 | party3 | ETH/DEC19 | buy | 1 | 2000 | 1 | TYPE_LIMIT | TIF_GTC | 86 Then the parties should have the following account balances: 87 | party | asset | market id | margin | general | 88 | party1 | USD | ETH/DEC19 | 540000 | 999460000 | 89 | party2 | USD | ETH/DEC19 | 132000 | 99867000 | 90 | party3 | USD | ETH/DEC19 | 132000 | 99866000 | 91 | lp1 | USD | ETH/DEC19 | 6600000 | 492200000 | 92 93 94 And the oracles broadcast data with block time signed with "0xCAFECAFE1": 95 | name | value | time offset | 96 | perp.funding.cue | 1613061324 | 0s | 97 # 4320h is 6 * 30 * 24 (180days, or 6 months) with a block duration of 10 days (so 18 ticks) 98 # making it 2021-08-10T16:35:24 99 Then the network moves ahead "4320h" with block duration of "240h" 100 # now move ahead the remaining time to get to 2021-08-11T11:04:07 101 # We're moving by 66,583s (18 * 3600 + 29 * 60 + 43), divisible by 11 (6053) 102 # So set block duration to 6053 for 11 ticks 103 And the network moves ahead "18h29m43s" with block duration of "6053s" 104 #When time is updated to "2021-08-12T11:04:07Z" 105 106 When the network moves ahead "5" blocks 107 When the oracles broadcast data with block time signed with "0xCAFECAFE1": 108 | name | value | time offset | 109 | perp.ETH.value | 300000000 | 0s | 110 | perp.funding.cue | 1628766252 | 0s | 111 #1628766252 is half year after the first oracel time 112 113 And the following transfers should happen: 114 | from | to | from account | to account | market id | amount | asset | 115 | aux2 | market | ACCOUNT_TYPE_MARGIN | ACCOUNT_TYPE_SETTLEMENT | ETH/DEC19 | 74700 | USD | 116 | party2 | market | ACCOUNT_TYPE_MARGIN | ACCOUNT_TYPE_SETTLEMENT | ETH/DEC19 | 74700 | USD | 117 | party3 | market | ACCOUNT_TYPE_MARGIN | ACCOUNT_TYPE_SETTLEMENT | ETH/DEC19 | 74700 | USD | 118 | market | aux | ACCOUNT_TYPE_SETTLEMENT | ACCOUNT_TYPE_MARGIN | ETH/DEC19 | 74700 | USD | 119 | market | party1 | ACCOUNT_TYPE_SETTLEMENT | ACCOUNT_TYPE_MARGIN | ETH/DEC19 | 149400 | USD | 120 121 @Perpetual 122 Scenario: 002 oracle data decimal < asset decimal 0070-MKTD-019 123 Given time is updated to "2021-02-11T16:35:21Z" 124 And the markets: 125 | id | quote name | asset | risk model | margin calculator | auction duration | fees | price monitoring | data source config | linear slippage factor | quadratic slippage factor | position decimal places | decimal places | market type | sla params | 126 | ETH/DEC19 | ETH | USD | default-simple-risk-model-3 | default-margin-calculator | 1 | default-none | default-none | perp-oracle-3 | 0.25 | 0 | 1 | 2 | perp | default-futures | 127 And the following network parameters are set: 128 | name | value | 129 | market.auction.minimumDuration | 1 | 130 | limits.markets.maxPeggedOrders | 2 | 131 Given the following network parameters are set: 132 | name | value | 133 | network.markPriceUpdateMaximumFrequency | 5s | 134 And the parties deposit on asset's general account the following amount: 135 | party | asset | amount | 136 | party1 | USD | 1000000000 | 137 | party2 | USD | 100000000 | 138 | party3 | USD | 100000000 | 139 | aux | USD | 300000000 | 140 | aux2 | USD | 300000000 | 141 | lp1 | USD | 500000000 | 142 143 When the parties submit the following liquidity provision: 144 | id | party | market id | commitment amount | fee | lp type | 145 | lp1 | lp1 | ETH/DEC19 | 1200000 | 0.001 | submission | 146 147 And the parties place the following pegged iceberg orders: 148 | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | reference | 149 | lp1 | ETH/DEC19 | 20 | 100 | buy | BID | 5000 | 1 | lp-buy-1 | 150 | lp1 | ETH/DEC19 | 20 | 100 | sell | ASK | 5000 | 1 | lp-sell-1 | 151 152 #place auxiliary orders so we always have best bid and best offer as to not trigger the liquidity auction 153 When the parties place the following orders: 154 | party | market id | side | volume | price | resulting trades | type | tif | 155 | aux | ETH/DEC19 | buy | 100 | 84900 | 0 | TYPE_LIMIT | TIF_GTC | 156 | aux | ETH/DEC19 | sell | 100 | 200100 | 0 | TYPE_LIMIT | TIF_GTC | 157 | aux2 | ETH/DEC19 | buy | 100 | 100000 | 0 | TYPE_LIMIT | TIF_GTC | 158 | aux | ETH/DEC19 | sell | 100 | 100000 | 0 | TYPE_LIMIT | TIF_GTC | 159 160 Then the network moves ahead "2" blocks 161 And the trading mode should be "TRADING_MODE_CONTINUOUS" for the market "ETH/DEC19" 162 163 # Time at start of the scenario is now +3s 164 When the network moves ahead "1" blocks 165 And the parties place the following orders: 166 | party | market id | side | volume | price | resulting trades | type | tif | 167 | party1 | ETH/DEC19 | sell | 100 | 100000 | 0 | TYPE_LIMIT | TIF_GTC | 168 | party2 | ETH/DEC19 | buy | 100 | 100000 | 1 | TYPE_LIMIT | TIF_GTC | 169 170 Then the parties should have the following account balances: 171 | party | asset | market id | margin | general | 172 | party1 | USD | ETH/DEC19 | 120000 | 999880000 | 173 | party2 | USD | ETH/DEC19 | 132000 | 99867000 | 174 | lp1 | USD | ETH/DEC19 | 6600000 | 492200000 | 175 176 When the parties place the following orders: 177 | party | market id | side | volume | price | resulting trades | type | tif | 178 | party1 | ETH/DEC19 | sell | 100 | 200000 | 0 | TYPE_LIMIT | TIF_GTC | 179 | party3 | ETH/DEC19 | buy | 100 | 200000 | 1 | TYPE_LIMIT | TIF_GTC | 180 Then the parties should have the following account balances: 181 | party | asset | market id | margin | general | 182 | party1 | USD | ETH/DEC19 | 540000 | 999460000 | 183 | party2 | USD | ETH/DEC19 | 132000 | 99867000 | 184 | party3 | USD | ETH/DEC19 | 132000 | 99866000 | 185 | lp1 | USD | ETH/DEC19 | 6600000 | 492200000 | 186 187 188 When the oracles broadcast data with block time signed with "0xCAFECAFE3": 189 | name | value | time offset | 190 | perp.funding.cue | 1613061324 | 0s | 191 192 # 4320h is 6 * 30 * 24 (180days, or 6 months) with a block duration of 10 days (so 18 ticks) 193 # making it 2021-08-10T16:35:24 194 Then the network moves ahead "4320h" with block duration of "240h" 195 # now move ahead the remaining time to get to 2021-08-11T11:04:07 196 # We're moving by 66,583s (18 * 3600 + 29 * 60 + 43), divisible by 11 (6053) 197 # So set block duration to 6053 for 11 ticks 198 And the network moves ahead "18h29m43s" with block duration of "6053s" 199 200 # When time is updated to "2021-08-12T11:04:07Z" 201 202 And the network moves ahead "5" blocks 203 Then the oracles broadcast data with block time signed with "0xCAFECAFE3": 204 | name | value | time offset | 205 | perp.ETH.value | 30000 | 0s | 206 | perp.funding.cue | 1628766252 | 0s | 207 #1628766252 is half year after the first oracel time 208 209 #Then debug funding period events 210 And the following transfers should happen: 211 | from | to | from account | to account | market id | amount | asset | 212 | aux2 | market | ACCOUNT_TYPE_MARGIN | ACCOUNT_TYPE_SETTLEMENT | ETH/DEC19 | 74700 | USD | 213 | party2 | market | ACCOUNT_TYPE_MARGIN | ACCOUNT_TYPE_SETTLEMENT | ETH/DEC19 | 74700 | USD | 214 | party3 | market | ACCOUNT_TYPE_MARGIN | ACCOUNT_TYPE_SETTLEMENT | ETH/DEC19 | 74700 | USD | 215 | market | aux | ACCOUNT_TYPE_SETTLEMENT | ACCOUNT_TYPE_MARGIN | ETH/DEC19 | 74700 | USD | 216 | market | party1 | ACCOUNT_TYPE_SETTLEMENT | ACCOUNT_TYPE_MARGIN | ETH/DEC19 | 149400 | USD | 217 218 @PBlock 219 Scenario: 003 oracle data decimal = asset decimal, while market decimal is 1, 0070-MKTD-020 220 Given time is updated to "2021-02-11T16:35:21Z" 221 And the markets: 222 | id | quote name | asset | 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 | 223 | ETH/DEC19 | ETH | USD | default-simple-risk-model-3 | default-margin-calculator | 1 | default-none | default-none | perp-oracle-2 | 0.25 | 0 | 1 | -1 | perp | default-futures | 224 And the following network parameters are set: 225 | name | value | 226 | market.auction.minimumDuration | 1 | 227 | limits.markets.maxPeggedOrders | 2 | 228 And the following network parameters are set: 229 | name | value | 230 | network.markPriceUpdateMaximumFrequency | 5s | 231 And the parties deposit on asset's general account the following amount: 232 | party | asset | amount | 233 | party1 | USD | 1000000000 | 234 | party2 | USD | 100000000 | 235 | party3 | USD | 100000000 | 236 | aux | USD | 300000000 | 237 | aux2 | USD | 300000000 | 238 | lp1 | USD | 500000000 | 239 240 When the parties submit the following liquidity provision: 241 | id | party | market id | commitment amount | fee | lp type | 242 | lp1 | lp1 | ETH/DEC19 | 1200000 | 0.001 | submission | 243 244 And the parties place the following pegged iceberg orders: 245 | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | reference | 246 | lp1 | ETH/DEC19 | 20 | 1 | buy | BID | 50 | 1 | lp-buy-1 | 247 | lp1 | ETH/DEC19 | 20 | 1 | sell | ASK | 50 | 1 | lp-sell-1 | 248 249 #place auxiliary orders so we always have best bid and best offer as to not trigger the liquidity auction 250 When the parties place the following orders: 251 | party | market id | side | volume | price | resulting trades | type | tif | 252 | aux | ETH/DEC19 | buy | 1 | 8490 | 0 | TYPE_LIMIT | TIF_GTC | 253 | aux | ETH/DEC19 | sell | 1 | 20010 | 0 | TYPE_LIMIT | TIF_GTC | 254 | aux2 | ETH/DEC19 | buy | 1 | 10000 | 0 | TYPE_LIMIT | TIF_GTC | 255 | aux | ETH/DEC19 | sell | 1 | 10000 | 0 | TYPE_LIMIT | TIF_GTC | 256 257 Then the network moves ahead "2" blocks 258 And the trading mode should be "TRADING_MODE_CONTINUOUS" for the market "ETH/DEC19" 259 260 When the network moves ahead "1" blocks 261 When the parties place the following orders: 262 | party | market id | side | volume | price | resulting trades | type | tif | 263 | party1 | ETH/DEC19 | sell | 1 | 10000 | 0 | TYPE_LIMIT | TIF_GTC | 264 | party2 | ETH/DEC19 | buy | 1 | 10000 | 1 | TYPE_LIMIT | TIF_GTC | 265 266 Then the parties should have the following account balances: 267 | party | asset | market id | margin | general | 268 | party1 | USD | ETH/DEC19 | 120000 | 999880000 | 269 | party2 | USD | ETH/DEC19 | 132000 | 99867000 | 270 | lp1 | USD | ETH/DEC19 | 6600000 | 492200000 | 271 272 When the parties place the following orders: 273 | party | market id | side | volume | price | resulting trades | type | tif | 274 | party1 | ETH/DEC19 | sell | 1 | 20000 | 0 | TYPE_LIMIT | TIF_GTC | 275 | party3 | ETH/DEC19 | buy | 1 | 20000 | 1 | TYPE_LIMIT | TIF_GTC | 276 Then the parties should have the following account balances: 277 | party | asset | market id | margin | general | 278 | party1 | USD | ETH/DEC19 | 540000 | 999460000 | 279 | party2 | USD | ETH/DEC19 | 132000 | 99867000 | 280 | party3 | USD | ETH/DEC19 | 132000 | 99866000 | 281 | lp1 | USD | ETH/DEC19 | 6600000 | 492200000 | 282 283 284 When the oracles broadcast data with block time signed with "0xCAFECAFE2": 285 | name | value | time offset | 286 | perp.funding.cue | 1613061324 | 0s | 287 288 # 4320h is 6 * 30 * 24 (180days, or 6 months) with a block duration of 10 days (so 18 ticks) 289 # making it 2021-08-10T16:35:24 290 Then the network moves ahead "4320h" with block duration of "240h" 291 # now move ahead the remaining time to get to 2021-08-11T11:04:07 292 # We're moving by 66,583s (18 * 3600 + 29 * 60 + 43), divisible by 11 (6053) 293 # So set block duration to 6053 for 11 ticks 294 And the network moves ahead "18h29m43s" with block duration of "6053s" 295 296 And the network moves ahead "5" blocks 297 And the oracles broadcast data with block time signed with "0xCAFECAFE2": 298 | name | value | time offset | 299 | perp.ETH.value | 300000 | 0s | 300 | perp.funding.cue | 1628766252 | 0s | 301 #1628766252 is half year after the first oracel time 302 303 Then the following transfers should happen: 304 | from | to | from account | to account | market id | amount | asset | 305 | aux2 | market | ACCOUNT_TYPE_MARGIN | ACCOUNT_TYPE_SETTLEMENT | ETH/DEC19 | 74700 | USD | 306 | party2 | market | ACCOUNT_TYPE_MARGIN | ACCOUNT_TYPE_SETTLEMENT | ETH/DEC19 | 74700 | USD | 307 | party3 | market | ACCOUNT_TYPE_MARGIN | ACCOUNT_TYPE_SETTLEMENT | ETH/DEC19 | 74700 | USD | 308 | market | aux | ACCOUNT_TYPE_SETTLEMENT | ACCOUNT_TYPE_MARGIN | ETH/DEC19 | 74700 | USD | 309 | market | party1 | ACCOUNT_TYPE_SETTLEMENT | ACCOUNT_TYPE_MARGIN | ETH/DEC19 | 149400 | USD |