code.vegaprotocol.io/vega@v0.79.0/core/integration/features/settlement/0053-PERP-040.feature (about) 1 Feature: Assert that the scaling factor is applied before the funding cap is applied (0053-PERP-040). 2 3 @Perpetual 4 Scenario: Make sure that the scaling is handled first and the bounds do not touch the result 5 6 And the perpetual oracles from "0xCAFECAFE1": 7 | 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 | funding rate scaling factor | funding rate lower bound | funding rate upper bound | 8 | perp-oracle | USD | perp.ETH.value | TYPE_INTEGER | perp.funding.cue | TYPE_TIMESTAMP | 1.0 | 0.0 | 0.1 | 0.9 | ETH | 18 | 10.0 | -6.0 | 6.0 | 9 And the liquidity sla params named "SLA": 10 | price range | commitment min time fraction | performance hysteresis epochs | sla competition factor | 11 | 1.0 | 0.5 | 1 | 1.0 | 12 13 And the markets: 14 | 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 | 15 | ETH/DEC19 | ETH | USD | default-simple-risk-model-3 | default-margin-calculator | 1 | default-none | default-none | perp-oracle | 0.25 | 0 | -3 | perp | default-futures | 16 And the initial insurance pool balance is "200" for all the markets 17 And the following network parameters are set: 18 | name | value | 19 | market.auction.minimumDuration | 1 | 20 | limits.markets.maxPeggedOrders | 2 | 21 22 Given the following network parameters are set: 23 | name | value | 24 | network.markPriceUpdateMaximumFrequency | 5s | 25 And the parties deposit on asset's general account the following amount: 26 | party | asset | amount | 27 | party1 | USD | 100000000 | 28 | party2 | USD | 100000000 | 29 | party3 | USD | 100000000 | 30 | aux | USD | 100000000 | 31 | aux2 | USD | 100000000 | 32 | lpprov | USD | 100000000 | 33 34 When the parties submit the following liquidity provision: 35 | id | party | market id | commitment amount | fee | lp type | 36 | lp1 | lpprov | ETH/DEC19 | 10000000 | 0.001 | submission | 37 And the parties place the following pegged iceberg orders: 38 | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | 39 | lpprov | ETH/DEC19 | 2 | 1 | buy | BID | 50 | 1 | 40 | lpprov | ETH/DEC19 | 2 | 1 | sell | ASK | 50 | 1 | 41 42 # place auxiliary orders so we always have best bid and best offer as to not trigger the liquidity auction 43 When the parties place the following orders: 44 | party | market id | side | volume | price | resulting trades | type | tif | 45 | aux | ETH/DEC19 | buy | 1 | 49 | 0 | TYPE_LIMIT | TIF_GTC | 46 | aux | ETH/DEC19 | sell | 1 | 5001 | 0 | TYPE_LIMIT | TIF_GTC | 47 | aux2 | ETH/DEC19 | buy | 1 | 1000 | 0 | TYPE_LIMIT | TIF_GTC | 48 | aux | ETH/DEC19 | sell | 1 | 1000 | 0 | TYPE_LIMIT | TIF_GTC | 49 50 Then the opening auction period ends for market "ETH/DEC19" 51 And the trading mode should be "TRADING_MODE_CONTINUOUS" for the market "ETH/DEC19" 52 # back sure we end the block so we're in a new one after opening auction 53 When the network moves ahead "1" blocks 54 55 When the parties place the following orders: 56 | party | market id | side | volume | price | resulting trades | type | tif | 57 | party1 | ETH/DEC19 | sell | 1 | 1000 | 0 | TYPE_LIMIT | TIF_GTC | 58 | party2 | ETH/DEC19 | buy | 1 | 1000 | 1 | TYPE_LIMIT | TIF_GTC | 59 | party1 | ETH/DEC19 | sell | 1 | 1200 | 0 | TYPE_LIMIT | TIF_GTC | 60 | party3 | ETH/DEC19 | buy | 1 | 1200 | 1 | TYPE_LIMIT | TIF_GTC | 61 62 # send in external data to the perpetual market, it should not change anything and a MTM should not happen 63 When the network moves ahead "1" blocks 64 Then system unix time is "1575072004" 65 66 When the oracles broadcast data with block time signed with "0xCAFECAFE1": 67 | name | value | time offset | 68 | perp.ETH.value | 3000000000000000000000 | 0s | 69 | perp.funding.cue | 1575072004 | 0s | 70 When the network moves ahead "6" blocks 71 72 When the oracles broadcast data with block time signed with "0xCAFECAFE1": 73 | name | value | time offset | 74 | perp.ETH.value | 3000000000000000000000 | 0s | 75 | perp.funding.cue | 1575072012 | 0s | 76 # funding payments = s_twap * delta_t * interest_rate * fund rate scaling * dp = (3000-1200)*1*10.0*1000 = 18,000,000 77 # funding rate will be funding payment / s_twap = 18,000,000/(3,000*dp) = 6 78 # So having a lower/upper bound of -6/+6 will not change the result 79 And the following transfers should happen: 80 | from | to | from account | to account | market id | amount | asset | 81 | market | party2 | ACCOUNT_TYPE_SETTLEMENT | ACCOUNT_TYPE_MARGIN | ETH/DEC19 | 18000000| USD | 82 83 84 85 @Perpetual 86 Scenario: Make sure that the scaling is handled first and the bounds can change the final result 87 88 And the perpetual oracles from "0xCAFECAFE1": 89 | 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 | funding rate scaling factor | funding rate lower bound | funding rate upper bound | 90 | perp-oracle | USD | perp.ETH.value | TYPE_INTEGER | perp.funding.cue | TYPE_TIMESTAMP | 1.0 | 0.0 | 0.1 | 0.9 | ETH | 18 | 10.0 | -5.0 | 5.0 | 91 And the liquidity sla params named "SLA": 92 | price range | commitment min time fraction | performance hysteresis epochs | sla competition factor | 93 | 1.0 | 0.5 | 1 | 1.0 | 94 95 And the markets: 96 | 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 | 97 | ETH/DEC19 | ETH | USD | default-simple-risk-model-3 | default-margin-calculator | 1 | default-none | default-none | perp-oracle | 0.25 | 0 | -3 | perp | default-futures | 98 And the initial insurance pool balance is "200" for all the markets 99 And the following network parameters are set: 100 | name | value | 101 | market.auction.minimumDuration | 1 | 102 | limits.markets.maxPeggedOrders | 2 | 103 104 Given the following network parameters are set: 105 | name | value | 106 | network.markPriceUpdateMaximumFrequency | 5s | 107 And the parties deposit on asset's general account the following amount: 108 | party | asset | amount | 109 | party1 | USD | 100000000 | 110 | party2 | USD | 100000000 | 111 | party3 | USD | 100000000 | 112 | aux | USD | 100000000 | 113 | aux2 | USD | 100000000 | 114 | lpprov | USD | 100000000 | 115 116 When the parties submit the following liquidity provision: 117 | id | party | market id | commitment amount | fee | lp type | 118 | lp1 | lpprov | ETH/DEC19 | 10000000 | 0.001 | submission | 119 And the parties place the following pegged iceberg orders: 120 | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | 121 | lpprov | ETH/DEC19 | 2 | 1 | buy | BID | 50 | 1 | 122 | lpprov | ETH/DEC19 | 2 | 1 | sell | ASK | 50 | 1 | 123 124 # place auxiliary orders so we always have best bid and best offer as to not trigger the liquidity auction 125 When the parties place the following orders: 126 | party | market id | side | volume | price | resulting trades | type | tif | 127 | aux | ETH/DEC19 | buy | 1 | 49 | 0 | TYPE_LIMIT | TIF_GTC | 128 | aux | ETH/DEC19 | sell | 1 | 5001 | 0 | TYPE_LIMIT | TIF_GTC | 129 | aux2 | ETH/DEC19 | buy | 1 | 1000 | 0 | TYPE_LIMIT | TIF_GTC | 130 | aux | ETH/DEC19 | sell | 1 | 1000 | 0 | TYPE_LIMIT | TIF_GTC | 131 132 Then the opening auction period ends for market "ETH/DEC19" 133 And the trading mode should be "TRADING_MODE_CONTINUOUS" for the market "ETH/DEC19" 134 # back sure we end the block so we're in a new one after opening auction 135 When the network moves ahead "1" blocks 136 137 When the parties place the following orders: 138 | party | market id | side | volume | price | resulting trades | type | tif | 139 | party1 | ETH/DEC19 | sell | 1 | 1000 | 0 | TYPE_LIMIT | TIF_GTC | 140 | party2 | ETH/DEC19 | buy | 1 | 1000 | 1 | TYPE_LIMIT | TIF_GTC | 141 | party1 | ETH/DEC19 | sell | 1 | 1200 | 0 | TYPE_LIMIT | TIF_GTC | 142 | party3 | ETH/DEC19 | buy | 1 | 1200 | 1 | TYPE_LIMIT | TIF_GTC | 143 144 # send in external data to the perpetual market, it should not change anything and a MTM should not happen 145 When the network moves ahead "1" blocks 146 Then system unix time is "1575072004" 147 148 When the oracles broadcast data with block time signed with "0xCAFECAFE1": 149 | name | value | time offset | 150 | perp.ETH.value | 3000000000000000000000 | 0s | 151 | perp.funding.cue | 1575072004 | 0s | 152 When the network moves ahead "6" blocks 153 154 When the oracles broadcast data with block time signed with "0xCAFECAFE1": 155 | name | value | time offset | 156 | perp.ETH.value | 3000000000000000000000 | 0s | 157 | perp.funding.cue | 1575072012 | 0s | 158 159 # funding payments = s_twap * delta_t * interest_rate * fund rate scaling * dp = (3000-1200)*1*10.0*1000 = 18,000,000 160 # funding rate will be funding payment / s_twap = 18,000,000/(3,000*dp) = 6 161 # So having a lower/upper bound of -5/+5 if applied after the scaling will reduce the payment to 15,000,000 162 # If the bounds are incorrectly handled first the result will be the same as the run above, 18,000,000 163 And the following transfers should happen: 164 | from | to | from account | to account | market id | amount | asset | 165 | market | party2 | ACCOUNT_TYPE_SETTLEMENT | ACCOUNT_TYPE_MARGIN | ETH/DEC19 | 15000000 | USD | 166