code.vegaprotocol.io/vega@v0.79.0/core/integration/features/rewards/average_notional_rewards.feature (about) 1 Feature: Average position metric rewards 2 3 Background: 4 Given the following network parameters are set: 5 | name | value | 6 | reward.asset | VEGA | 7 | validators.epoch.length | 10s | 8 | validators.delegation.minAmount | 10 | 9 | reward.staking.delegation.delegatorShare | 0.883 | 10 | reward.staking.delegation.minimumValidatorStake | 100 | 11 | reward.staking.delegation.maxPayoutPerParticipant | 100000 | 12 | reward.staking.delegation.competitionLevel | 1.1 | 13 | reward.staking.delegation.minValidators | 5 | 14 | reward.staking.delegation.optimalStakeMultiplier | 5.0 | 15 | network.markPriceUpdateMaximumFrequency | 0s | 16 | limits.markets.maxPeggedOrders | 2 | 17 18 Given the fees configuration named "fees-config-1": 19 | maker fee | infrastructure fee | 20 | 0.005 | 0.002 | 21 And the price monitoring named "price-monitoring": 22 | horizon | probability | auction extension | 23 | 3600 | 0.99 | 3 | 24 25 And the simple risk model named "simple-risk-model-1": 26 | long | short | max move up | min move down | probability of trading | 27 | 0.2 | 0.1 | 100 | -100 | 0.1 | 28 29 30 And the markets: 31 | id | quote name | asset | risk model | margin calculator | auction duration | fees | price monitoring | data source config | linear slippage factor | quadratic slippage factor | sla params | 32 | ETH/DEC21 | ETH | ETH | simple-risk-model-1 | default-margin-calculator | 2 | fees-config-1 | price-monitoring | default-eth-for-future | 0.25 | 0 | default-futures | 33 | ETH/DEC22 | ETH | ETH | simple-risk-model-1 | default-margin-calculator | 2 | fees-config-1 | price-monitoring | default-eth-for-future | 0.25 | 0 | default-futures | 34 35 Given the parties deposit on asset's general account the following amount: 36 | party | asset | amount | 37 | a3c024b4e23230c89884a54a813b1ecb4cb0f827a38641c66eeca466da6b2ddf | VEGA | 1000000 | 38 | aux1 | ETH | 100000000 | 39 | aux2 | ETH | 100000000 | 40 | trader3 | ETH | 10000 | 41 | trader4 | ETH | 10000 | 42 | lpprov | ETH | 200000000 | 43 | party1 | ETH | 100000 | 44 | party2 | ETH | 100000 | 45 46 47 And the parties deposit on staking account the following amount: 48 | party | asset | amount | 49 | aux1 | VEGA | 2000 | 50 | aux2 | VEGA | 1000 | 51 | trader3 | VEGA | 1500 | 52 | trader4 | VEGA | 1000 | 53 | lpprov | VEGA | 10000 | 54 | party1 | VEGA | 2000 | 55 | party2 | VEGA | 2000 | 56 57 58 Given time is updated to "2023-09-23T00:00:00Z" 59 Given the average block duration is "1" 60 61 #complete the epoch to advance to a meaningful epoch (can't setup transfer to start at epoch 0) 62 Then the network moves ahead "1" epochs 63 64 # Scenario: No trader is eligible - no transfer is made 65 # # setup recurring transfer to the reward account - this will start at the end of this epoch (1) 66 # Given the parties submit the following recurring transfers: 67 # | id | from | from_account_type | to | to_account_type | asset | amount | start_epoch | end_epoch | factor | metric | metric_asset | markets | lock_period | window_length | distribution_strategy | entity_scope | individual_scope | staking_requirement | notional_requirement | 68 # | 1 | a3c024b4e23230c89884a54a813b1ecb4cb0f827a38641c66eeca466da6b2ddf | ACCOUNT_TYPE_GENERAL | 0000000000000000000000000000000000000000000000000000000000000000 | ACCOUNT_TYPE_REWARD_AVERAGE_NOTIONAL | VEGA | 10000 | 1 | | 1 | DISPATCH_METRIC_AVERAGE_NOTIONAL | ETH | | 2 | 2 | PRO_RATA | INDIVIDUALS | ALL | 1500 | 50 | 69 70 # Then the network moves ahead "1" epochs 71 72 # And "a3c024b4e23230c89884a54a813b1ecb4cb0f827a38641c66eeca466da6b2ddf" should have general account balance of "1000000" for asset "VEGA" 73 74 # Scenario: eligible party with staking less than threshold doesn't get a reward (0056-REWA-076) 75 # # setup recurring transfer to the reward account - this will start at the end of this epoch (1) 76 # Given the parties submit the following recurring transfers: 77 # | id | from | from_account_type | to | to_account_type | asset | amount | start_epoch | end_epoch | factor | metric | metric_asset | markets | lock_period | window_length | distribution_strategy | entity_scope | individual_scope | staking_requirement | notional_requirement | 78 # | 1 | a3c024b4e23230c89884a54a813b1ecb4cb0f827a38641c66eeca466da6b2ddf | ACCOUNT_TYPE_GENERAL | 0000000000000000000000000000000000000000000000000000000000000000 | ACCOUNT_TYPE_REWARD_AVERAGE_NOTIONAL | VEGA | 10000 | 1 | | 1 | DISPATCH_METRIC_AVERAGE_NOTIONAL | ETH | | 2 | 2 | PRO_RATA | INDIVIDUALS | ALL | 1500 | 0 | 79 80 # When the parties submit the following liquidity provision: 81 # | id | party | market id | commitment amount | fee | lp type | 82 # | lp1 | lpprov | ETH/DEC21 | 90000 | 0.1 | submission | 83 # | lp1 | lpprov | ETH/DEC21 | 90000 | 0.1 | submission | 84 85 # And the parties place the following pegged iceberg orders: 86 # | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | 87 # | lpprov | ETH/DEC21 | 90 | 1 | buy | BID | 90 | 10 | 88 # | lpprov | ETH/DEC21 | 90 | 1 | sell | ASK | 90 | 10 | 89 90 # Then the parties place the following orders: 91 # | party | market id | side | volume | price | resulting trades | type | tif | reference | 92 # | aux1 | ETH/DEC21 | buy | 10 | 1000 | 0 | TYPE_LIMIT | TIF_GTC | | 93 # | aux2 | ETH/DEC21 | sell | 10 | 1000 | 0 | TYPE_LIMIT | TIF_GTC | | 94 # | aux1 | ETH/DEC21 | buy | 1 | 900 | 0 | TYPE_LIMIT | TIF_GTC | buy1 | 95 # | aux2 | ETH/DEC21 | sell | 1 | 1100 | 0 | TYPE_LIMIT | TIF_GTC | sell1 | 96 97 # # let the position update be in the middle of the epoch 98 # Given time is updated to "2023-09-23T00:00:18Z" 99 100 # Then the network moves ahead "1" epochs 101 102 # # aux1 has a position of 10 103 # # aux2 has a position of -10 104 # # however aux1 has sufficient vega staked 105 # # and aux2 doesn't 106 # # therefore the transfer is made and the full amount goes to aux1 107 # And "a3c024b4e23230c89884a54a813b1ecb4cb0f827a38641c66eeca466da6b2ddf" should have general account balance of "990000" for asset "VEGA" 108 # And "aux1" should have vesting account balance of "10000" for asset "VEGA" 109 110 # Scenario: eligible party with average notional less than threshold doesn't get a reward (0056-REWA-077) 111 # # setup recurring transfer to the reward account - this will start at the end of this epoch (1) 112 # Given the parties submit the following recurring transfers: 113 # | id | from | from_account_type | to | to_account_type | asset | amount | start_epoch | end_epoch | factor | metric | metric_asset | markets | lock_period | window_length | distribution_strategy | entity_scope | individual_scope | staking_requirement | notional_requirement | 114 # | 1 | a3c024b4e23230c89884a54a813b1ecb4cb0f827a38641c66eeca466da6b2ddf | ACCOUNT_TYPE_GENERAL | 0000000000000000000000000000000000000000000000000000000000000000 | ACCOUNT_TYPE_REWARD_AVERAGE_NOTIONAL | VEGA | 10000 | 1 | | 1 | DISPATCH_METRIC_AVERAGE_NOTIONAL | ETH | | 2 | 2 | PRO_RATA | INDIVIDUALS | ALL | 0 | 10000 | 115 116 # When the parties submit the following liquidity provision: 117 # | id | party | market id | commitment amount | fee | lp type | 118 # | lp1 | lpprov | ETH/DEC21 | 90000 | 0.1 | submission | 119 # | lp1 | lpprov | ETH/DEC21 | 90000 | 0.1 | submission | 120 121 # And the parties place the following pegged iceberg orders: 122 # | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | 123 # | lpprov | ETH/DEC21 | 90 | 1 | buy | BID | 90 | 10 | 124 # | lpprov | ETH/DEC21 | 90 | 1 | sell | ASK | 90 | 10 | 125 126 # Then the parties place the following orders: 127 # | party | market id | side | volume | price | resulting trades | type | tif | reference | 128 # | aux1 | ETH/DEC21 | buy | 10 | 1000 | 0 | TYPE_LIMIT | TIF_GTC | | 129 # | aux2 | ETH/DEC21 | sell | 10 | 1000 | 0 | TYPE_LIMIT | TIF_GTC | | 130 # | aux1 | ETH/DEC21 | buy | 1 | 900 | 0 | TYPE_LIMIT | TIF_GTC | buy1 | 131 # | aux2 | ETH/DEC21 | sell | 1 | 1100 | 0 | TYPE_LIMIT | TIF_GTC | sell1 | 132 133 # # let the position update be in the middle of the epoch 134 # Given time is updated to "2023-09-23T00:00:18Z" 135 136 # Then the network moves ahead "1" epochs 137 138 # # aux1 has a position of 10 139 # # aux2 has a position of -10 140 # # the average notional for both is 5*1000 = 5000 < minimum average notional = 10000 therefore no one gets a reward 141 # And "a3c024b4e23230c89884a54a813b1ecb4cb0f827a38641c66eeca466da6b2ddf" should have general account balance of "1000000" for asset "VEGA" 142 143 # # advance one epoch 144 # Then the network moves ahead "1" epochs 145 146 # # now their average notional is 10*1000 = 10000 therefore they both are eligible 147 # And "a3c024b4e23230c89884a54a813b1ecb4cb0f827a38641c66eeca466da6b2ddf" should have general account balance of "990000" for asset "VEGA" 148 # And "aux1" should have vesting account balance of "5000" for asset "VEGA" 149 # And "aux2" should have vesting account balance of "5000" for asset "VEGA" 150 151 # Scenario: multiple eligible parties split the reward equally 152 # # setup recurring transfer to the reward account - this will start at the end of this epoch (1) 153 # Given the parties submit the following recurring transfers: 154 # | id | from | from_account_type | to | to_account_type | asset | amount | start_epoch | end_epoch | factor | metric | metric_asset | markets | lock_period | window_length | distribution_strategy | entity_scope | individual_scope | staking_requirement | notional_requirement | 155 # | 1 | a3c024b4e23230c89884a54a813b1ecb4cb0f827a38641c66eeca466da6b2ddf | ACCOUNT_TYPE_GENERAL | 0000000000000000000000000000000000000000000000000000000000000000 | ACCOUNT_TYPE_REWARD_AVERAGE_NOTIONAL | VEGA | 10000 | 1 | | 1 | DISPATCH_METRIC_AVERAGE_NOTIONAL | ETH | | 2 | 2 | PRO_RATA | INDIVIDUALS | ALL | 1000 | 0 | 156 157 # When the parties submit the following liquidity provision: 158 # | id | party | market id | commitment amount | fee | lp type | 159 # | lp1 | lpprov | ETH/DEC21 | 90000 | 0.1 | submission | 160 # | lp1 | lpprov | ETH/DEC21 | 90000 | 0.1 | submission | 161 162 # And the parties place the following pegged iceberg orders: 163 # | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | 164 # | lpprov | ETH/DEC21 | 90 | 1 | buy | BID | 90 | 10 | 165 # | lpprov | ETH/DEC21 | 90 | 1 | sell | ASK | 90 | 10 | 166 167 # Then the parties place the following orders: 168 # | party | market id | side | volume | price | resulting trades | type | tif | reference | 169 # | aux1 | ETH/DEC21 | buy | 10 | 1000 | 0 | TYPE_LIMIT | TIF_GTC | | 170 # | aux2 | ETH/DEC21 | sell | 10 | 1000 | 0 | TYPE_LIMIT | TIF_GTC | | 171 # | aux1 | ETH/DEC21 | buy | 1 | 900 | 0 | TYPE_LIMIT | TIF_GTC | buy1 | 172 # | aux2 | ETH/DEC21 | sell | 1 | 1100 | 0 | TYPE_LIMIT | TIF_GTC | sell1 | 173 174 # # let the position update be in the middle of the epoch 175 # Given time is updated to "2023-09-23T00:00:18Z" 176 177 # Then the network moves ahead "1" epochs 178 179 # # aux1 has a position of 10 180 # # aux2 has a position of -10 181 # # however aux1 and aux2 have sufficient vega staked 182 # # therefore the transfer is made and the reward amount is split between aux1 and aux2 183 # And "a3c024b4e23230c89884a54a813b1ecb4cb0f827a38641c66eeca466da6b2ddf" should have general account balance of "990000" for asset "VEGA" 184 # And "aux1" should have vesting account balance of "5000" for asset "VEGA" 185 # And "aux2" should have vesting account balance of "5000" for asset "VEGA" 186 187 # Scenario: multiple epochs multiple positions (0056-REWA-083) 188 # # setup recurring transfer to the reward account - this will start at the end of this epoch (1) 189 # Given the parties submit the following recurring transfers: 190 # | id | from | from_account_type | to | to_account_type | asset | amount | start_epoch | end_epoch | factor | metric | metric_asset | markets | lock_period | window_length | distribution_strategy | entity_scope | individual_scope | staking_requirement | notional_requirement | 191 # | 1 | a3c024b4e23230c89884a54a813b1ecb4cb0f827a38641c66eeca466da6b2ddf | ACCOUNT_TYPE_GENERAL | 0000000000000000000000000000000000000000000000000000000000000000 | ACCOUNT_TYPE_REWARD_AVERAGE_NOTIONAL | VEGA | 10000 | 1 | | 1 | DISPATCH_METRIC_AVERAGE_NOTIONAL | ETH | | 2 | 2 | PRO_RATA | INDIVIDUALS | ALL | 1000 | 0 | 192 193 # When the parties submit the following liquidity provision: 194 # | id | party | market id | commitment amount | fee | lp type | 195 # | lp1 | lpprov | ETH/DEC21 | 90000 | 0.1 | submission | 196 # | lp1 | lpprov | ETH/DEC21 | 90000 | 0.1 | submission | 197 198 # And the parties place the following pegged iceberg orders: 199 # | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | 200 # | lpprov | ETH/DEC21 | 90 | 1 | buy | BID | 90 | 10 | 201 # | lpprov | ETH/DEC21 | 90 | 1 | sell | ASK | 90 | 10 | 202 203 # Then the parties place the following orders: 204 # | party | market id | side | volume | price | resulting trades | type | tif | reference | 205 # | aux1 | ETH/DEC21 | buy | 10 | 1000 | 0 | TYPE_LIMIT | TIF_GTC | | 206 # | aux2 | ETH/DEC21 | sell | 10 | 1000 | 0 | TYPE_LIMIT | TIF_GTC | | 207 # | aux1 | ETH/DEC21 | buy | 1 | 900 | 0 | TYPE_LIMIT | TIF_GTC | buy1 | 208 # | aux2 | ETH/DEC21 | sell | 1 | 1100 | 0 | TYPE_LIMIT | TIF_GTC | sell1 | 209 210 # # let the position update be in the middle of the epoch 211 # Given time is updated to "2023-09-23T00:00:18Z" 212 213 # Then the network moves ahead "1" epochs 214 215 # # aux1 has a position of 10 216 # # aux2 has a position of -10 217 # # however aux1 and aux2 have sufficient vega staked 218 # # therefore the transfer is made and the reward amount is split between aux1 and aux2 219 # And "a3c024b4e23230c89884a54a813b1ecb4cb0f827a38641c66eeca466da6b2ddf" should have general account balance of "990000" for asset "VEGA" 220 # And "aux1" should have vesting account balance of "5000" for asset "VEGA" 221 # And "aux2" should have vesting account balance of "5000" for asset "VEGA" 222 223 # # 20% into the epoch, lets get a trade done 224 # Given time is updated to "2023-09-23T00:00:26Z" 225 226 # Then the parties place the following orders: 227 # | party | market id | side | volume | price | resulting trades | type | tif | reference | 228 # | party1 | ETH/DEC21 | buy | 5 | 1001 | 0 | TYPE_LIMIT | TIF_GTC | aux1-buy1 | 229 # | aux2 | ETH/DEC21 | sell | 5 | 1001 | 1 | TYPE_LIMIT | TIF_GTC | aux2-sell1 | 230 231 # # 80% into the epoch do another trade 232 # Given time is updated to "2023-09-23T00:00:34Z" 233 234 # Then the parties place the following orders: 235 # | party | market id | side | volume | price | resulting trades | type | tif | reference | 236 # | aux1 | ETH/DEC21 | sell | 20 | 1002 | 0 | TYPE_LIMIT | TIF_GTC | aux1-sell2 | 237 # | party1 | ETH/DEC21 | buy | 20 | 1002 | 1 | TYPE_LIMIT | TIF_GTC | aux2-buy2 | 238 239 # Then the network moves ahead "1" epochs 240 241 # And "a3c024b4e23230c89884a54a813b1ecb4cb0f827a38641c66eeca466da6b2ddf" should have general account balance of "980000" for asset "VEGA" 242 # # lets calculate the expected scores: 243 # # at the beginning of the epoch: 244 # # aux1: time weighted average position = 5 245 # # aux2: time weighted average position = 5 246 # # party1 : time weighted average position = 0 247 248 # # 20% into the epoch: 249 # # aux2: time weighted average position = 5 * 0 + 10 * 1 250 # # party1 : time weighted average position = 0 251 252 # # 80% into the epoch: 253 # # aux2: time weighted average position = 5 * 0 + 10 * 1 254 # # party1 : time weighted average position = 0.8 * 5 = 4 255 256 # # end of epoch 257 # # aux1: time weighted average position = 10 258 # # aux2: (1-10/12) * 10 + 10/12 * 15 = 14.1666666667 259 # # party1: (1-2/12) * 4 + 2/12 * 25 = 7.5 260 261 # # considering both epochs as window is 2: 262 # # aux1: [5, 10] => metric for window = 7.5 263 # # aux2: [5, 14.1666666667] => metric for window = 9.5833333334 264 # # party1: [0, 7.5] => metric for window = 3.75 265 266 # # aux1 gets 10000 * 7.5 / 20.8333333334 = 3600 267 # # aux2 gets 10000 * 9.5833333334 / 20.8333333334 = 4600 268 # # party1 gets 10000 * 3.75 / 20.8333333334 = 1,799.9999999942 = 1799 269 270 # And "aux1" should have vesting account balance of "8600" for asset "VEGA" 271 # And "aux2" should have vesting account balance of "9600" for asset "VEGA" 272 # And "party1" should have vesting account balance of "1799" for asset "VEGA" 273 274 # Scenario: multiple multiple markets - only one in scope 275 # # setup recurring transfer to the reward account - this will start at the end of this epoch (1) 276 # Given the parties submit the following recurring transfers: 277 # | id | from | from_account_type | to | to_account_type | asset | amount | start_epoch | end_epoch | factor | metric | metric_asset | markets | lock_period | window_length | distribution_strategy | entity_scope | individual_scope | staking_requirement | notional_requirement | 278 # | 1 | a3c024b4e23230c89884a54a813b1ecb4cb0f827a38641c66eeca466da6b2ddf | ACCOUNT_TYPE_GENERAL | 0000000000000000000000000000000000000000000000000000000000000000 | ACCOUNT_TYPE_REWARD_AVERAGE_NOTIONAL | VEGA | 10000 | 1 | | 1 | DISPATCH_METRIC_AVERAGE_NOTIONAL | ETH | ETH/DEC21 | 2 | 2 | PRO_RATA | INDIVIDUALS | ALL | 1000 | 0 | 279 280 # When the parties submit the following liquidity provision: 281 # | id | party | market id | commitment amount | fee | lp type | 282 # | lp1 | lpprov | ETH/DEC21 | 90000 | 0.1 | submission | 283 # | lp1 | lpprov | ETH/DEC21 | 90000 | 0.1 | submission | 284 # | lp2 | lpprov | ETH/DEC22 | 90000 | 0.1 | submission | 285 # | lp2 | lpprov | ETH/DEC22 | 90000 | 0.1 | submission | 286 287 # And the parties place the following pegged iceberg orders: 288 # | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | 289 # | lpprov | ETH/DEC21 | 90 | 1 | buy | BID | 90 | 10 | 290 # | lpprov | ETH/DEC21 | 90 | 1 | sell | ASK | 90 | 10 | 291 # | lpprov | ETH/DEC22 | 90 | 1 | buy | BID | 90 | 10 | 292 # | lpprov | ETH/DEC22 | 90 | 1 | sell | ASK | 90 | 10 | 293 294 # Then the parties place the following orders: 295 # | party | market id | side | volume | price | resulting trades | type | tif | reference | 296 # | aux1 | ETH/DEC21 | buy | 10 | 1000 | 0 | TYPE_LIMIT | TIF_GTC | | 297 # | aux2 | ETH/DEC21 | sell | 10 | 1000 | 0 | TYPE_LIMIT | TIF_GTC | | 298 # | aux1 | ETH/DEC21 | buy | 1 | 900 | 0 | TYPE_LIMIT | TIF_GTC | buy1 | 299 # | aux2 | ETH/DEC21 | sell | 1 | 1100 | 0 | TYPE_LIMIT | TIF_GTC | sell1 | 300 # | party1 | ETH/DEC22 | buy | 5 | 2000 | 0 | TYPE_LIMIT | TIF_GTC | | 301 # | party2 | ETH/DEC22 | sell | 5 | 2000 | 0 | TYPE_LIMIT | TIF_GTC | | 302 # | aux1 | ETH/DEC22 | buy | 1 | 1800 | 0 | TYPE_LIMIT | TIF_GTC | buy2 | 303 # | aux2 | ETH/DEC22 | sell | 1 | 2200 | 0 | TYPE_LIMIT | TIF_GTC | sell2 | 304 305 306 # # let the position update be in the middle of the epoch 307 # Given time is updated to "2023-09-23T00:00:18Z" 308 309 # Then the network moves ahead "1" epochs 310 311 # # only ETH/DEC21 is inscope 312 # # aux1 has a position of 10 313 # # aux2 has a position of -10 314 # # however aux1 and aux2 have sufficient vega staked 315 # # therefore the transfer is made and the reward amount is split between aux1 and aux2 316 # And "a3c024b4e23230c89884a54a813b1ecb4cb0f827a38641c66eeca466da6b2ddf" should have general account balance of "990000" for asset "VEGA" 317 # And "aux1" should have vesting account balance of "5000" for asset "VEGA" 318 # And "aux2" should have vesting account balance of "5000" for asset "VEGA" 319 320 Scenario: If an eligible party held positions in multiple in-scope markets, their average notional position reward metric should be the sum of their time-weighted-average-notional-position in each market (0056-REWA-198). f a window_length>1 is specified in the recurring transfer, an eligible parties average notional position reward metric should be the average of their reward metrics over the last window_length epochs (0056-REWA-199). 321 # setup recurring transfer to the reward account - this will start at the end of this epoch (1) 322 Given the parties submit the following recurring transfers: 323 | id | from | from_account_type | to | to_account_type | asset | amount | start_epoch | end_epoch | factor | metric | metric_asset | markets | lock_period | window_length | distribution_strategy | entity_scope | individual_scope | staking_requirement | notional_requirement | 324 | 1 | a3c024b4e23230c89884a54a813b1ecb4cb0f827a38641c66eeca466da6b2ddf | ACCOUNT_TYPE_GENERAL | 0000000000000000000000000000000000000000000000000000000000000000 | ACCOUNT_TYPE_REWARD_AVERAGE_NOTIONAL | VEGA | 10000 | 1 | | 1 | DISPATCH_METRIC_AVERAGE_NOTIONAL | ETH | | 2 | 2 | PRO_RATA | INDIVIDUALS | ALL | 1000 | 0 | 325 326 When the parties submit the following liquidity provision: 327 | id | party | market id | commitment amount | fee | lp type | 328 | lp1 | lpprov | ETH/DEC21 | 90000 | 0.1 | submission | 329 | lp1 | lpprov | ETH/DEC21 | 90000 | 0.1 | submission | 330 | lp2 | lpprov | ETH/DEC22 | 90000 | 0.1 | submission | 331 | lp2 | lpprov | ETH/DEC22 | 90000 | 0.1 | submission | 332 333 And the parties place the following pegged iceberg orders: 334 | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | 335 | lpprov | ETH/DEC21 | 90 | 1 | buy | BID | 90 | 10 | 336 | lpprov | ETH/DEC21 | 90 | 1 | sell | ASK | 90 | 10 | 337 | lpprov | ETH/DEC22 | 90 | 1 | buy | BID | 90 | 10 | 338 | lpprov | ETH/DEC22 | 90 | 1 | sell | ASK | 90 | 10 | 339 340 Then the parties place the following orders: 341 | party | market id | side | volume | price | resulting trades | type | tif | reference | 342 | aux1 | ETH/DEC21 | buy | 10 | 1000 | 0 | TYPE_LIMIT | TIF_GTC | | 343 | aux2 | ETH/DEC21 | sell | 10 | 1000 | 0 | TYPE_LIMIT | TIF_GTC | | 344 | aux1 | ETH/DEC21 | buy | 1 | 900 | 0 | TYPE_LIMIT | TIF_GTC | buy1 | 345 | aux2 | ETH/DEC21 | sell | 1 | 1100 | 0 | TYPE_LIMIT | TIF_GTC | sell1 | 346 | party1 | ETH/DEC22 | buy | 20 | 1010 | 0 | TYPE_LIMIT | TIF_GTC | | 347 | party2 | ETH/DEC22 | sell | 20 | 1010 | 0 | TYPE_LIMIT | TIF_GTC | | 348 | aux1 | ETH/DEC22 | buy | 1 | 910 | 0 | TYPE_LIMIT | TIF_GTC | buy2 | 349 | aux2 | ETH/DEC22 | sell | 1 | 1110 | 0 | TYPE_LIMIT | TIF_GTC | sell2 | 350 351 # let the position update be in the middle of the epoch 352 Given time is updated to "2023-09-23T00:00:18Z" 353 354 Then the network moves ahead "1" epochs 355 356 # only ETH/DEC21 is inscope 357 # aux1 has a position of 10 => time weighted notional = 0.0005, window = 2 => 0.00025 => 10000 * 0.00025/0.00151 = 1655 358 # aux2 has a position of -10 => time weighted notional = 0.0005, window = 2 => 0.00025 => 10000 * 0.00025/0.00151 = 1655 359 # party1 has a position of 20 => time weighted notional = 0.00101, window = 2 => 0.000505 => 10000 * 0.000505/0.00151 = 3344 360 # party2 has a position of -20 => time weighted notional = 0.00101, window = 2 => 0.000505 => 10000 * 0.000505/0.00151 = 3344 361 And "a3c024b4e23230c89884a54a813b1ecb4cb0f827a38641c66eeca466da6b2ddf" should have general account balance of "990000" for asset "VEGA" 362 And "aux1" should have vesting account balance of "1655" for asset "VEGA" 363 And "aux2" should have vesting account balance of "1655" for asset "VEGA" 364 And "party1" should have vesting account balance of "3344" for asset "VEGA" 365 And "party2" should have vesting account balance of "3344" for asset "VEGA" 366 367 # 20% into the epoch, lets get a trade done 368 Given time is updated to "2023-09-23T00:00:26Z" 369 370 Then the parties place the following orders: 371 | party | market id | side | volume | price | resulting trades | type | tif | reference | 372 | party1 | ETH/DEC21 | buy | 5 | 1001 | 0 | TYPE_LIMIT | TIF_GTC | aux1-buy1 | 373 | aux2 | ETH/DEC21 | sell | 5 | 1001 | 1 | TYPE_LIMIT | TIF_GTC | aux2-sell1 | 374 375 # 80% into the epoch do another trade 376 Given time is updated to "2023-09-23T00:00:34Z" 377 378 Then the parties place the following orders: 379 | party | market id | side | volume | price | resulting trades | type | tif | reference | 380 | aux1 | ETH/DEC21 | sell | 20 | 1002 | 0 | TYPE_LIMIT | TIF_GTC | aux1-sell2 | 381 | party1 | ETH/DEC21 | buy | 20 | 1002 | 1 | TYPE_LIMIT | TIF_GTC | aux2-buy2 | 382 383 Then the network moves ahead "1" epochs 384 385 And "a3c024b4e23230c89884a54a813b1ecb4cb0f827a38641c66eeca466da6b2ddf" should have general account balance of "980000" for asset "VEGA" 386 387 # epoch1 388 # market1: aux1 = 5000, aux2 = 5000 389 # market2: party1 = 10100, party2 = 10100 390 # epoch2 391 # market1: aux1 = 10003, aux2 = 14179, party1 = 7511 392 # market2: party1 = 20200, party2 = 20200 393 # considering the window=2: 394 # aux1 = [5000,10003] => 0.00075015 395 # aux2 = [5000,14179] => 0.00095895 396 # party1 = [10100, 27711] => 0.00189055 397 # part2 = [10100,20200] = 0.001515 398 # aux1 reward = 10000*0.00075015/0.00511465 = 1466 + 1655 => 3121 399 # aux2 reward = 10000*0.00095895/0.00511465 = 1875 + 1655 => 3530 400 # party1 reward = 10000*0.00189055/0.00511465 = 3697 + 3344 => 7041 401 # party2 reward = 10000*0.001515/0.00511465 = 2962 + 3344 => 6306 402 And "aux1" should have vesting account balance of "3121" for asset "VEGA" 403 And "aux2" should have vesting account balance of "3531" for asset "VEGA" 404 And "party1" should have vesting account balance of "7040" for asset "VEGA" 405 And "party2" should have vesting account balance of "6306" for asset "VEGA" 406 407 Scenario: If an eligible party opens a position at the beginning of the epoch, their average notional reward metric should be equal to the size of the notional at the end of the epoch (0056-REWA-192). If an eligible party held an open position at the start of the epoch, their average position notional metric should be equal to the size of the notional at the end of the epoch (0056-REWA-194). 408 When the parties submit the following liquidity provision: 409 | id | party | market id | commitment amount | fee | lp type | 410 | lp1 | lpprov | ETH/DEC21 | 90000 | 0.1 | submission | 411 | lp1 | lpprov | ETH/DEC21 | 90000 | 0.1 | submission | 412 413 And the parties place the following pegged iceberg orders: 414 | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | 415 | lpprov | ETH/DEC21 | 90 | 1 | buy | BID | 90 | 10 | 416 | lpprov | ETH/DEC21 | 90 | 1 | sell | ASK | 90 | 10 | 417 418 Then the parties place the following orders: 419 | party | market id | side | volume | price | resulting trades | type | tif | reference | 420 | aux1 | ETH/DEC21 | buy | 10 | 1000 | 0 | TYPE_LIMIT | TIF_GTC | | 421 | aux2 | ETH/DEC21 | sell | 10 | 1000 | 0 | TYPE_LIMIT | TIF_GTC | | 422 | aux1 | ETH/DEC21 | buy | 1 | 900 | 0 | TYPE_LIMIT | TIF_GTC | buy1 | 423 | aux2 | ETH/DEC21 | sell | 1 | 1100 | 0 | TYPE_LIMIT | TIF_GTC | sell1 | 424 425 # leave opening auction 426 Then the network moves ahead "1" epochs 427 428 # setup recurring transfer to the reward account - this will start at the end of this epoch (1) 429 Given the parties submit the following recurring transfers: 430 | id | from | from_account_type | to | to_account_type | asset | amount | start_epoch | end_epoch | factor | metric | metric_asset | markets | lock_period | window_length | distribution_strategy | entity_scope | individual_scope | staking_requirement | notional_requirement | 431 | 1 | a3c024b4e23230c89884a54a813b1ecb4cb0f827a38641c66eeca466da6b2ddf | ACCOUNT_TYPE_GENERAL | 0000000000000000000000000000000000000000000000000000000000000000 | ACCOUNT_TYPE_REWARD_AVERAGE_NOTIONAL | VEGA | 10000 | 2 | | 1 | DISPATCH_METRIC_AVERAGE_NOTIONAL | ETH | | 2 | 1 | PRO_RATA | INDIVIDUALS | ALL | 1000 | 0 | 432 433 # the time is the beginning of the epoch 434 Then the parties place the following orders: 435 | party | market id | side | volume | price | resulting trades | type | tif | reference | 436 | party1 | ETH/DEC21 | buy | 5 | 1001 | 0 | TYPE_LIMIT | TIF_GTC | p1-buy1 | 437 | party2 | ETH/DEC21 | sell | 5 | 1001 | 1 | TYPE_LIMIT | TIF_GTC | p2-sell1 | 438 439 Then the network moves ahead "1" epochs 440 441 # aux1 and aux2 have a position of 10 - which is equal to their position held at the beginning of the epoch 442 # party1 and party2 has position of 5 - which is equal to the position opened at the beginning of the epoch 443 And "a3c024b4e23230c89884a54a813b1ecb4cb0f827a38641c66eeca466da6b2ddf" should have general account balance of "990000" for asset "VEGA" 444 And "aux1" should have vesting account balance of "3333" for asset "VEGA" 445 And "aux2" should have vesting account balance of "3333" for asset "VEGA" 446 And "party1" should have vesting account balance of "1666" for asset "VEGA" 447 And "party2" should have vesting account balance of "1666" for asset "VEGA" 448 449 Scenario: If an eligible party opens a position half way through the epoch, their average notional reward metric should be half the size of the position at the end of the epoch (0056-REWA-196). If an eligible party held an open position at the start of the epoch and closes it half-way through the epoch, their average notional reward metric should be equal to the size of that position at the end of the epoch (0056-REWA-197). 450 When the parties submit the following liquidity provision: 451 | id | party | market id | commitment amount | fee | lp type | 452 | lp1 | lpprov | ETH/DEC21 | 90000 | 0.1 | submission | 453 | lp1 | lpprov | ETH/DEC21 | 90000 | 0.1 | submission | 454 455 And the parties place the following pegged iceberg orders: 456 | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | 457 | lpprov | ETH/DEC21 | 90 | 1 | buy | BID | 90 | 10 | 458 | lpprov | ETH/DEC21 | 90 | 1 | sell | ASK | 90 | 10 | 459 460 Then the parties place the following orders: 461 | party | market id | side | volume | price | resulting trades | type | tif | reference | 462 | aux1 | ETH/DEC21 | buy | 10 | 1000 | 0 | TYPE_LIMIT | TIF_GTC | | 463 | aux2 | ETH/DEC21 | sell | 10 | 1000 | 0 | TYPE_LIMIT | TIF_GTC | | 464 | aux1 | ETH/DEC21 | buy | 1 | 900 | 0 | TYPE_LIMIT | TIF_GTC | buy1 | 465 | aux2 | ETH/DEC21 | sell | 1 | 1100 | 0 | TYPE_LIMIT | TIF_GTC | sell1 | 466 467 # leave opening auction 468 Then the network moves ahead "1" epochs 469 470 # setup recurring transfer to the reward account - this will start at the end of this epoch (1) 471 Given the parties submit the following recurring transfers: 472 | id | from | from_account_type | to | to_account_type | asset | amount | start_epoch | end_epoch | factor | metric | metric_asset | markets | lock_period | window_length | distribution_strategy | entity_scope | individual_scope | staking_requirement | notional_requirement | 473 | 1 | a3c024b4e23230c89884a54a813b1ecb4cb0f827a38641c66eeca466da6b2ddf | ACCOUNT_TYPE_GENERAL | 0000000000000000000000000000000000000000000000000000000000000000 | ACCOUNT_TYPE_REWARD_AVERAGE_NOTIONAL | VEGA | 10000 | 2 | | 1 | DISPATCH_METRIC_AVERAGE_NOTIONAL | ETH | | 2 | 1 | PRO_RATA | INDIVIDUALS | ALL | 1000 | 0 | 474 475 # let the position update be in the middle of the epoch 476 Given time is updated to "2023-09-23T00:00:30Z" 477 Then the parties place the following orders: 478 | party | market id | side | volume | price | resulting trades | type | tif | reference | 479 | party1 | ETH/DEC21 | buy | 10 | 1001 | 0 | TYPE_LIMIT | TIF_GTC | p1-buy1 | 480 | aux1 | ETH/DEC21 | sell | 10 | 1001 | 1 | TYPE_LIMIT | TIF_GTC | | 481 482 Then the parties place the following orders: 483 | party | market id | side | volume | price | resulting trades | type | tif | reference | 484 | party2 | ETH/DEC21 | sell | 5 | 999 | 0 | TYPE_LIMIT | TIF_GTC | p2-sell | 485 | aux2 | ETH/DEC21 | buy | 5 | 999 | 1 | TYPE_LIMIT | TIF_GTC | | 486 487 Then the network moves ahead "1" epochs 488 489 # aux1 - sells all of their position mid epoch - so their notional metric is 0.0005 490 # aux2 - sells half of its position mid epoch - so their notional metric is 0.0007497 491 # party1 - got into position mid epoch so their notional metric is 0.0005005 492 # party2 - got into position mid epoch so their notional metric is 0.0002497 493 And "a3c024b4e23230c89884a54a813b1ecb4cb0f827a38641c66eeca466da6b2ddf" should have general account balance of "990000" for asset "VEGA" 494 And "aux1" should have vesting account balance of "2501" for asset "VEGA" 495 And "aux2" should have vesting account balance of "3750" for asset "VEGA" 496 And "party1" should have vesting account balance of "2498" for asset "VEGA" 497 And "party2" should have vesting account balance of "1249" for asset "VEGA" 498 499 Scenario: If an eligible party opens a position at the beginning of the epoch, and the price changes during the epoch, their average notional position reward metric should be set equal to the notional value of the position at the end of the epoch (0056-REWA-193). If an eligible party held an open position at the start of the epoch, and the mark price does change during the epoch, their average notional position reward metric should be equal to the notional value of the position at the end of the epoch (0056-REWA-195). Given the following dispatch metrics, if no `eligible keys` list is specified in the recurring transfer, all parties meeting other eligibility criteria should receive a score (0056-REWA-206). 500 When the parties submit the following liquidity provision: 501 | id | party | market id | commitment amount | fee | lp type | 502 | lp1 | lpprov | ETH/DEC21 | 90000 | 0.1 | submission | 503 | lp1 | lpprov | ETH/DEC21 | 90000 | 0.1 | submission | 504 505 And the parties place the following pegged iceberg orders: 506 | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | 507 | lpprov | ETH/DEC21 | 90 | 1 | buy | BID | 90 | 10 | 508 | lpprov | ETH/DEC21 | 90 | 1 | sell | ASK | 90 | 10 | 509 510 Then the parties place the following orders: 511 | party | market id | side | volume | price | resulting trades | type | tif | reference | 512 | aux1 | ETH/DEC21 | buy | 10 | 1000 | 0 | TYPE_LIMIT | TIF_GTC | | 513 | aux2 | ETH/DEC21 | sell | 10 | 1000 | 0 | TYPE_LIMIT | TIF_GTC | | 514 | aux1 | ETH/DEC21 | buy | 1 | 900 | 0 | TYPE_LIMIT | TIF_GTC | buy1 | 515 | aux2 | ETH/DEC21 | sell | 1 | 1100 | 0 | TYPE_LIMIT | TIF_GTC | sell1 | 516 517 # leave opening auction 518 Then the network moves ahead "1" epochs 519 520 # setup recurring transfer to the reward account - this will start at the end of this epoch (1) 521 Given the parties submit the following recurring transfers: 522 | id | from | from_account_type | to | to_account_type | asset | amount | start_epoch | end_epoch | factor | metric | metric_asset | markets | lock_period | window_length | distribution_strategy | entity_scope | individual_scope | staking_requirement | notional_requirement | 523 | 1 | a3c024b4e23230c89884a54a813b1ecb4cb0f827a38641c66eeca466da6b2ddf | ACCOUNT_TYPE_GENERAL | 0000000000000000000000000000000000000000000000000000000000000000 | ACCOUNT_TYPE_REWARD_AVERAGE_NOTIONAL | VEGA | 10000 | 2 | | 1 | DISPATCH_METRIC_AVERAGE_NOTIONAL | ETH | | 2 | 1 | PRO_RATA | INDIVIDUALS | ALL | 1000 | 0 | 524 525 # the time is the beginning of the epoch 526 Then the parties place the following orders: 527 | party | market id | side | volume | price | resulting trades | type | tif | reference | 528 | party1 | ETH/DEC21 | buy | 5 | 1001 | 0 | TYPE_LIMIT | TIF_GTC | p1-buy1 | 529 | party2 | ETH/DEC21 | sell | 5 | 1001 | 1 | TYPE_LIMIT | TIF_GTC | p2-sell1 | 530 531 Then the network moves ahead "5" blocks 532 533 Then the parties place the following orders: 534 | party | market id | side | volume | price | resulting trades | type | tif | reference | 535 | aux1 | ETH/DEC21 | buy | 5 | 999 | 0 | TYPE_LIMIT | TIF_GTC | p1-buy1 | 536 | aux2 | ETH/DEC21 | sell | 5 | 999 | 1 | TYPE_LIMIT | TIF_GTC | p2-sell1 | 537 538 Then the network moves ahead "1" epochs 539 540 And "a3c024b4e23230c89884a54a813b1ecb4cb0f827a38641c66eeca466da6b2ddf" should have general account balance of "990000" for asset "VEGA" 541 # aux1 and aux2 had a position of 10 at the beginning of the epoch which was update by a trade of 5@999 at the middle of the epoch 542 # 10000 * 0.5 + (10000+999*5)*0.5 = 12497 543 And "aux1" should have vesting account balance of "3604" for asset "VEGA" 544 And "aux2" should have vesting account balance of "3604" for asset "VEGA" 545 # party1 and party2 has position of 5@999 (the last mark price) 546 And "party1" should have vesting account balance of "1395" for asset "VEGA" 547 And "party2" should have vesting account balance of "1395" for asset "VEGA" 548 549 # now at the beginning of the epoch party1 and party2 had a position, half way through the epoch the mark price changes to 1000 550 Then the network moves ahead "5" blocks 551 552 Then the parties place the following orders: 553 | party | market id | side | volume | price | resulting trades | type | tif | reference | 554 | aux1 | ETH/DEC21 | buy | 5 | 1000 | 0 | TYPE_LIMIT | TIF_GTC | p1-buy1 | 555 | aux2 | ETH/DEC21 | sell | 5 | 1000 | 1 | TYPE_LIMIT | TIF_GTC | p2-sell1 | 556 557 # aux1 and aux2 had a position of 10 at the beginning of the epoch which was update by a trade of 5@999 at the middle of the epoch 558 # (10000+999*5)*0.5 + 10000 * 0.5 = 12497 559 And "aux1" should have vesting account balance of "3604" for asset "VEGA" 560 And "aux2" should have vesting account balance of "3604" for asset "VEGA" 561 # party1 and party2 has position of 5@1000 (the last mark price) 562 And "party1" should have vesting account balance of "1395" for asset "VEGA" 563 And "party2" should have vesting account balance of "1395" for asset "VEGA" 564 565 566 Scenario: Given the following dispatch metrics, if an `eligible keys` list is specified in the recurring transfer, only parties included in the list and meeting other eligibility criteria should receive a score (0056-REWA-216). 567 When the parties submit the following liquidity provision: 568 | id | party | market id | commitment amount | fee | lp type | 569 | lp1 | lpprov | ETH/DEC21 | 90000 | 0.1 | submission | 570 | lp1 | lpprov | ETH/DEC21 | 90000 | 0.1 | submission | 571 572 And the parties place the following pegged iceberg orders: 573 | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | 574 | lpprov | ETH/DEC21 | 90 | 1 | buy | BID | 90 | 10 | 575 | lpprov | ETH/DEC21 | 90 | 1 | sell | ASK | 90 | 10 | 576 577 Then the parties place the following orders: 578 | party | market id | side | volume | price | resulting trades | type | tif | reference | 579 | aux1 | ETH/DEC21 | buy | 10 | 1000 | 0 | TYPE_LIMIT | TIF_GTC | | 580 | aux2 | ETH/DEC21 | sell | 10 | 1000 | 0 | TYPE_LIMIT | TIF_GTC | | 581 | aux1 | ETH/DEC21 | buy | 1 | 900 | 0 | TYPE_LIMIT | TIF_GTC | buy1 | 582 | aux2 | ETH/DEC21 | sell | 1 | 1100 | 0 | TYPE_LIMIT | TIF_GTC | sell1 | 583 584 # leave opening auction 585 Then the network moves ahead "1" epochs 586 587 # setup recurring transfer to the reward account - this will start at the end of this epoch (1) 588 Given the parties submit the following recurring transfers: 589 | id | from | from_account_type | to | to_account_type | asset | amount | start_epoch | end_epoch | factor | metric | metric_asset | markets | lock_period | window_length | distribution_strategy | entity_scope | individual_scope | staking_requirement | notional_requirement | eligible_keys | 590 | 1 | a3c024b4e23230c89884a54a813b1ecb4cb0f827a38641c66eeca466da6b2ddf | ACCOUNT_TYPE_GENERAL | 0000000000000000000000000000000000000000000000000000000000000000 | ACCOUNT_TYPE_REWARD_AVERAGE_NOTIONAL | VEGA | 10000 | 2 | | 1 | DISPATCH_METRIC_AVERAGE_NOTIONAL | ETH | | 2 | 1 | PRO_RATA | INDIVIDUALS | ALL | 1000 | 0 | party1,party2 | 591 592 # the time is the beginning of the epoch 593 Then the parties place the following orders: 594 | party | market id | side | volume | price | resulting trades | type | tif | reference | 595 | party1 | ETH/DEC21 | buy | 5 | 1001 | 0 | TYPE_LIMIT | TIF_GTC | p1-buy1 | 596 | party2 | ETH/DEC21 | sell | 5 | 1001 | 1 | TYPE_LIMIT | TIF_GTC | p2-sell1 | 597 598 Then the network moves ahead "5" blocks 599 600 Then the parties place the following orders: 601 | party | market id | side | volume | price | resulting trades | type | tif | reference | 602 | aux1 | ETH/DEC21 | buy | 5 | 999 | 0 | TYPE_LIMIT | TIF_GTC | p1-buy1 | 603 | aux2 | ETH/DEC21 | sell | 5 | 999 | 1 | TYPE_LIMIT | TIF_GTC | p2-sell1 | 604 605 Then the network moves ahead "1" epochs 606 607 And "a3c024b4e23230c89884a54a813b1ecb4cb0f827a38641c66eeca466da6b2ddf" should have general account balance of "990000" for asset "VEGA" 608 # party1 and party2 has position of 5@999 (the last mark price) - they are the only eligible ones that are in the eligible keys so only they split the reward 609 And "party1" should have vesting account balance of "5000" for asset "VEGA" 610 And "party2" should have vesting account balance of "5000" for asset "VEGA" 611 612 # now at the beginning of the epoch party1 and party2 had a position, half way through the epoch the mark price changes to 1000 613 Then the network moves ahead "5" blocks 614 615 Then the parties place the following orders: 616 | party | market id | side | volume | price | resulting trades | type | tif | reference | 617 | aux1 | ETH/DEC21 | buy | 5 | 1000 | 0 | TYPE_LIMIT | TIF_GTC | p1-buy1 | 618 | aux2 | ETH/DEC21 | sell | 5 | 1000 | 1 | TYPE_LIMIT | TIF_GTC | p2-sell1 | 619 620 # party1 and party2 has position of 5@1000 (the last mark price) 621 And "party1" should have vesting account balance of "5000" for asset "VEGA" 622 And "party2" should have vesting account balance of "5000" for asset "VEGA" 623