code.vegaprotocol.io/vega@v0.79.0/core/integration/features/rewards/eligible_entities_rewards.feature (about) 1 Feature: Eligible parties 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 | a3c024b4e23230c89884a54a813b1ecb4cb0f827a38641c66eeca466da6b2dda | VEGA | 1000000 | 38 | a3c024b4e23230c89884a54a813b1ecb4cb0f827a38641c66eeca466da6b2ddb | VEGA | 1000000 | 39 | a3c024b4e23230c89884a54a813b1ecb4cb0f827a38641c66eeca466da6b2ddc | VEGA | 1000000 | 40 | a3c024b4e23230c89884a54a813b1ecb4cb0f827a38641c66eeca466da6b2ddd | VEGA | 1000000 | 41 | aux1 | ETH | 100000000 | 42 | aux2 | ETH | 100000000 | 43 | trader3 | ETH | 10000 | 44 | trader4 | ETH | 10000 | 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 54 Given time is updated to "2023-09-23T00:00:00Z" 55 Given the average block duration is "1" 56 57 # Initalise the referral program then move forwards an epoch to start the program 58 Given the referral benefit tiers "rbt": 59 | minimum running notional taker volume | minimum epochs | referral reward infra factor | referral reward maker factor | referral reward liquidity factor | referral discount infra factor | referral discount maker factor | referral discount liquidity factor | 60 | 500 | 1 | 0.021 | 0.022 | 0.023 | 0.024 | 0.025 | 0.026 | 61 | 1000 | 1 | 0.21 | 0.22 | 0.23 | 0.24 | 0.25 | 0.26 | 62 And the referral staking tiers "rst": 63 | minimum staked tokens | referral reward multiplier | 64 | 1 | 1 | 65 And the referral program: 66 | end of program | window length | benefit tiers | staking tiers | 67 | 2023-12-12T12:12:12Z | 7 | rbt | rst | 68 69 #complete the epoch to advance to a meaningful epoch (can't setup transfer to start at epoch 0) 70 Then the network moves ahead "1" epochs 71 72 Scenario: Given a recurring transfer using the eligible entities metric and specifying only a staking requirement. If an entity meets the staking requirement they will receive rewards. (0056-REWA-182). Given a recurring transfer using the eligible entities metric and specifying only a staking requirement. If an entity does not meet the staking requirement they will receive no rewards. (0056-REWA-183).Given a recurring transfer using the eligible entities metric and specifying only a position requirement (assume all markets within scope). If an entity meets the position requirement they will receive rewards. (0056-REWA-184). Given a recurring transfer using the eligible entities metric and specifying only a position requirement (assume all markets within scope). If an entity does not meet the position requirement they will receive no rewards. (0056-REWA-185).Given a recurring transfer using the eligible entities metric and specifying both a staking and position requirement. If an entity meets neither the staking or position requirement, they will receive no rewards. (0056-REWA-186).Given a recurring transfer using the eligible entities metric and specifying both a staking and position requirement. If an entity meets the staking but not the position requirement, they will receive no rewards. (0056-REWA-187).Given a recurring transfer using the eligible entities metric and specifying both a staking and position requirement. If an entity meets the position requirement but not the staking requirement, they will receive no rewards. (0056-REWA-188).Given a recurring transfer using the eligible entities metric and specifying both a staking and position requirement. If an entity meets both the staking and position requirement, they will receive rewards. (0056-REWA-189). 73 # setup recurring transfer to the reward account - this will start at the end of this epoch (1) 74 Given the parties submit the following recurring transfers: 75 | 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 | 76 | 1 | a3c024b4e23230c89884a54a813b1ecb4cb0f827a38641c66eeca466da6b2dda | ACCOUNT_TYPE_GENERAL | 0000000000000000000000000000000000000000000000000000000000000000 | ACCOUNT_TYPE_REWARD_ELIGIBLE_ENTITIES | VEGA | 10000 | 1 | | 1 | DISPATCH_METRIC_ELIGIBLE_ENTITIES | | | 2 | 1 | PRO_RATA | INDIVIDUALS | ALL | 0 | 0 | 77 | 2 | a3c024b4e23230c89884a54a813b1ecb4cb0f827a38641c66eeca466da6b2ddb | ACCOUNT_TYPE_GENERAL | 0000000000000000000000000000000000000000000000000000000000000000 | ACCOUNT_TYPE_REWARD_ELIGIBLE_ENTITIES | VEGA | 10000 | 1 | | 1 | DISPATCH_METRIC_ELIGIBLE_ENTITIES | | | 2 | 1 | PRO_RATA | INDIVIDUALS | ALL | 1200 | 0 | 78 | 3 | a3c024b4e23230c89884a54a813b1ecb4cb0f827a38641c66eeca466da6b2ddc | ACCOUNT_TYPE_GENERAL | 0000000000000000000000000000000000000000000000000000000000000000 | ACCOUNT_TYPE_REWARD_ELIGIBLE_ENTITIES | VEGA | 10000 | 1 | | 1 | DISPATCH_METRIC_ELIGIBLE_ENTITIES | ETH | | 2 | 1 | PRO_RATA | INDIVIDUALS | ALL | 0 | 10000 | 79 | 4 | a3c024b4e23230c89884a54a813b1ecb4cb0f827a38641c66eeca466da6b2ddd | ACCOUNT_TYPE_GENERAL | 0000000000000000000000000000000000000000000000000000000000000000 | ACCOUNT_TYPE_REWARD_ELIGIBLE_ENTITIES | VEGA | 10000 | 1 | | 1 | DISPATCH_METRIC_ELIGIBLE_ENTITIES | ETH | | 2 | 1 | PRO_RATA | INDIVIDUALS | ALL | 1000 | 10000 | 80 81 Then the parties place the following orders: 82 | party | market id | side | volume | price | resulting trades | type | tif | 83 | aux1 | ETH/DEC21 | buy | 10 | 1000 | 0 | TYPE_LIMIT | TIF_GTC | 84 | aux2 | ETH/DEC21 | sell | 10 | 1000 | 0 | TYPE_LIMIT | TIF_GTC | 85 | aux1 | ETH/DEC21 | buy | 1 | 900 | 0 | TYPE_LIMIT | TIF_GTC | 86 | aux2 | ETH/DEC21 | sell | 1 | 1100 | 0 | TYPE_LIMIT | TIF_GTC | 87 88 Then the opening auction period ends for market "ETH/DEC21" 89 And the market data for the market "ETH/DEC21" should be: 90 | mark price | trading mode | 91 | 1000 | TRADING_MODE_CONTINUOUS | 92 93 When the parties place the following orders with ticks: 94 | party | market id | side | volume | price | resulting trades | type | tif | 95 | trader3 | ETH/DEC21 | buy | 3 | 1002 | 0 | TYPE_LIMIT | TIF_GTC | 96 97 Then the parties place the following orders with ticks: 98 | party | market id | side | volume | price | resulting trades | type | tif | 99 | trader4 | ETH/DEC21 | sell | 4 | 1002 | 1 | TYPE_LIMIT | TIF_GTC | 100 101 Then the network moves ahead "1" epochs 102 # no requirement so surely distributed 103 And "a3c024b4e23230c89884a54a813b1ecb4cb0f827a38641c66eeca466da6b2dda" should have general account balance of "990000" for asset "VEGA" 104 # only staking requirement so distributed 105 And "a3c024b4e23230c89884a54a813b1ecb4cb0f827a38641c66eeca466da6b2ddb" should have general account balance of "990000" for asset "VEGA" 106 # not distributed as the notional requirement not met 107 And "a3c024b4e23230c89884a54a813b1ecb4cb0f827a38641c66eeca466da6b2ddc" should have general account balance of "1000000" for asset "VEGA" 108 # not distributed as the notional requirement not met 109 And "a3c024b4e23230c89884a54a813b1ecb4cb0f827a38641c66eeca466da6b2ddd" should have general account balance of "1000000" for asset "VEGA" 110 111 # they get 1/8 of the reward with no requirements + 1/2 of the reward with staking minimum = 1250+5000=6250 112 And "aux1" should have vesting account balance of "6250" for asset "VEGA" 113 # they get 1/8 of the reward with no requirements = 1250 114 And "aux2" should have vesting account balance of "1250" for asset "VEGA" 115 # they get 1/8 of the reward with no requirements + 1/2 of the reward with staking minimum = 1250+5000=6250 116 And "trader3" should have vesting account balance of "6250" for asset "VEGA" 117 # they get 1/8 of the reward with no requirements = 1250 118 And "trader4" should have vesting account balance of "1250" for asset "VEGA" 119 120 # now lets get some notional so we can satisfy the notional requirement 121 When the parties place the following orders with ticks: 122 | party | market id | side | volume | price | resulting trades | type | tif | 123 | trader3 | ETH/DEC21 | buy | 10 | 1002 | 1 | TYPE_LIMIT | TIF_GTC | 124 | trader4 | ETH/DEC21 | sell | 10 | 1002 | 1 | TYPE_LIMIT | TIF_GTC | 125 126 Then the network moves ahead "1" epochs 127 # no requirement so surely distributed 128 And "a3c024b4e23230c89884a54a813b1ecb4cb0f827a38641c66eeca466da6b2dda" should have general account balance of "980000" for asset "VEGA" 129 # only staking requirement so distributed 130 And "a3c024b4e23230c89884a54a813b1ecb4cb0f827a38641c66eeca466da6b2ddb" should have general account balance of "980000" for asset "VEGA" 131 # we have trade3 statisfying the notional requirement so distributed 132 And "a3c024b4e23230c89884a54a813b1ecb4cb0f827a38641c66eeca466da6b2ddc" should have general account balance of "990000" for asset "VEGA" 133 # we have trade3 statisfying the notional requirement so distributed 134 And "a3c024b4e23230c89884a54a813b1ecb4cb0f827a38641c66eeca466da6b2ddd" should have general account balance of "990000" for asset "VEGA" 135 136 # for reward (1) each gets a 1/8 137 # for reward (2) aux1 and trader3 split the reward 138 # for reward (3) each gets a quarter (all have sufficient notional) 139 # for reward (4) each gets a quarter 140 # aux1 = 6250 + 1250 + 5000 + 2500 + 2500 = 17500 141 And "aux1" should have vesting account balance of "17500" for asset "VEGA" 142 # aux2 = 1250 + 1250 + 2500 + 2500 = 7500 143 And "aux2" should have vesting account balance of "7500" for asset "VEGA" 144 # trader3 = 6250 + 1250 + 5000 + 2500 + 2500 = 17500 145 And "trader3" should have vesting account balance of "17500" for asset "VEGA" 146 # trader4 = 1250 + 1250 + 2500 + 2500 = 7500 147 And "trader4" should have vesting account balance of "7500" for asset "VEGA" 148 149 Scenario: Given a recurring transfer using the eligible entries metric and scoping individuals. If multiple parties meet all eligibility they should receive rewards proportional to any reward multipliers. (0056-REWA-178) 150 Given the following network parameters are set: 151 | name | value | 152 | network.markPriceUpdateMaximumFrequency | 0s | 153 | market.auction.minimumDuration | 1 | 154 | validators.epoch.length | 20s | 155 | limits.markets.maxPeggedOrders | 4 | 156 | rewards.activityStreak.inactivityLimit | 1 | 157 | rewards.activityStreak.minQuantumTradeVolume | 1000000000000000 | 158 | rewards.activityStreak.minQuantumOpenVolume | 10000 | 159 | rewards.activityStreak.benefitTiers | {"tiers": [{"minimum_activity_streak": 2, "reward_multiplier": "2", "vesting_multiplier": "2"}]} | 160 161 Then the parties place the following orders: 162 | party | market id | side | volume | price | resulting trades | type | tif | 163 | aux1 | ETH/DEC21 | buy | 10 | 1000 | 0 | TYPE_LIMIT | TIF_GTC | 164 | aux2 | ETH/DEC21 | sell | 10 | 1000 | 0 | TYPE_LIMIT | TIF_GTC | 165 | aux1 | ETH/DEC21 | buy | 1 | 900 | 0 | TYPE_LIMIT | TIF_GTC | 166 | aux2 | ETH/DEC21 | sell | 1 | 1100 | 0 | TYPE_LIMIT | TIF_GTC | 167 168 Then the opening auction period ends for market "ETH/DEC21" 169 And the market data for the market "ETH/DEC21" should be: 170 | mark price | trading mode | 171 | 1000 | TRADING_MODE_CONTINUOUS | 172 173 Given the current epoch is "1" 174 And the parties place the following orders: 175 | party | market id | side | volume | price | resulting trades | type | tif | 176 | aux1 | ETH/DEC21 | buy | 11 | 1000 | 0 | TYPE_LIMIT | TIF_GTC | 177 | trader3 | ETH/DEC21 | sell | 11 | 1000 | 1 | TYPE_LIMIT | TIF_GTC | 178 179 When the network moves ahead "2" epochs 180 Then the activity streaks at epoch "2" should be: 181 | party | active for | inactive for | reward multiplier | vesting multiplier | 182 | trader3 | 2 | 0 | 2 | 2 | 183 | aux1 | 2 | 0 | 2 | 2 | 184 185 # now we know that trader3 has >1 multipliers so lets set up a reward 186 Given the parties submit the following recurring transfers: 187 | 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 | 188 | 1 | a3c024b4e23230c89884a54a813b1ecb4cb0f827a38641c66eeca466da6b2dda | ACCOUNT_TYPE_GENERAL | 0000000000000000000000000000000000000000000000000000000000000000 | ACCOUNT_TYPE_REWARD_ELIGIBLE_ENTITIES | VEGA | 10000 | 3 | | 1 | DISPATCH_METRIC_ELIGIBLE_ENTITIES | | | 2 | 1 | PRO_RATA | INDIVIDUALS | ALL | 0 | 0 | 189 190 Then the network moves ahead "1" epochs 191 # no requirement so surely distributed 192 # trader3 and aux1 have multipliers of 2 193 And "a3c024b4e23230c89884a54a813b1ecb4cb0f827a38641c66eeca466da6b2dda" should have general account balance of "990000" for asset "VEGA" 194 And "aux1" should have vesting account balance of "2000" for asset "VEGA" 195 And "aux2" should have vesting account balance of "1000" for asset "VEGA" 196 And "trader3" should have vesting account balance of "2000" for asset "VEGA" 197 And "trader4" should have vesting account balance of "1000" for asset "VEGA" 198 And "a3c024b4e23230c89884a54a813b1ecb4cb0f827a38641c66eeca466da6b2dda" should have vesting account balance of "1000" for asset "VEGA" 199 And "a3c024b4e23230c89884a54a813b1ecb4cb0f827a38641c66eeca466da6b2ddb" should have vesting account balance of "1000" for asset "VEGA" 200 And "a3c024b4e23230c89884a54a813b1ecb4cb0f827a38641c66eeca466da6b2ddc" should have vesting account balance of "1000" for asset "VEGA" 201 And "a3c024b4e23230c89884a54a813b1ecb4cb0f827a38641c66eeca466da6b2ddd" should have vesting account balance of "1000" for asset "VEGA" 202 203 Scenario: Given a recurring transfer using the eligible entities metric and a reward window length N greater than one, a party who met the eligibility requirements in the current epoch as well as the previous N-1 epochs will receive rewards at the end of the epoch. (0056-REWA-179) 204 # setup recurring transfer to the reward account - this will start at the end of this epoch (1) 205 Given the parties submit the following recurring transfers: 206 | 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 | 207 | 1 | a3c024b4e23230c89884a54a813b1ecb4cb0f827a38641c66eeca466da6b2dda | ACCOUNT_TYPE_GENERAL | 0000000000000000000000000000000000000000000000000000000000000000 | ACCOUNT_TYPE_REWARD_ELIGIBLE_ENTITIES | VEGA | 10000 | 1 | | 1 | DISPATCH_METRIC_ELIGIBLE_ENTITIES | | | 2 | 2 | PRO_RATA | INDIVIDUALS | ALL | 0 | 0 | 208 | 2 | a3c024b4e23230c89884a54a813b1ecb4cb0f827a38641c66eeca466da6b2ddb | ACCOUNT_TYPE_GENERAL | 0000000000000000000000000000000000000000000000000000000000000000 | ACCOUNT_TYPE_REWARD_ELIGIBLE_ENTITIES | VEGA | 10000 | 1 | | 1 | DISPATCH_METRIC_ELIGIBLE_ENTITIES | | | 2 | 2 | PRO_RATA | INDIVIDUALS | ALL | 1200 | 0 | 209 | 3 | a3c024b4e23230c89884a54a813b1ecb4cb0f827a38641c66eeca466da6b2ddc | ACCOUNT_TYPE_GENERAL | 0000000000000000000000000000000000000000000000000000000000000000 | ACCOUNT_TYPE_REWARD_ELIGIBLE_ENTITIES | VEGA | 10000 | 1 | | 1 | DISPATCH_METRIC_ELIGIBLE_ENTITIES | ETH | | 2 | 2 | PRO_RATA | INDIVIDUALS | ALL | 0 | 10000 | 210 | 4 | a3c024b4e23230c89884a54a813b1ecb4cb0f827a38641c66eeca466da6b2ddd | ACCOUNT_TYPE_GENERAL | 0000000000000000000000000000000000000000000000000000000000000000 | ACCOUNT_TYPE_REWARD_ELIGIBLE_ENTITIES | VEGA | 10000 | 1 | | 1 | DISPATCH_METRIC_ELIGIBLE_ENTITIES | ETH | | 2 | 2 | PRO_RATA | INDIVIDUALS | ALL | 1000 | 10000 | 211 212 Then the parties place the following orders: 213 | party | market id | side | volume | price | resulting trades | type | tif | 214 | aux1 | ETH/DEC21 | buy | 10 | 1000 | 0 | TYPE_LIMIT | TIF_GTC | 215 | aux2 | ETH/DEC21 | sell | 10 | 1000 | 0 | TYPE_LIMIT | TIF_GTC | 216 | aux1 | ETH/DEC21 | buy | 1 | 900 | 0 | TYPE_LIMIT | TIF_GTC | 217 | aux2 | ETH/DEC21 | sell | 1 | 1100 | 0 | TYPE_LIMIT | TIF_GTC | 218 219 Then the opening auction period ends for market "ETH/DEC21" 220 And the market data for the market "ETH/DEC21" should be: 221 | mark price | trading mode | 222 | 1000 | TRADING_MODE_CONTINUOUS | 223 224 When the parties place the following orders with ticks: 225 | party | market id | side | volume | price | resulting trades | type | tif | 226 | trader3 | ETH/DEC21 | buy | 3 | 1002 | 0 | TYPE_LIMIT | TIF_GTC | 227 228 Then the parties place the following orders with ticks: 229 | party | market id | side | volume | price | resulting trades | type | tif | 230 | trader4 | ETH/DEC21 | sell | 4 | 1002 | 1 | TYPE_LIMIT | TIF_GTC | 231 232 Then the network moves ahead "1" epochs 233 # no requirement so surely distributed 234 And "a3c024b4e23230c89884a54a813b1ecb4cb0f827a38641c66eeca466da6b2dda" should have general account balance of "990000" for asset "VEGA" 235 # only staking requirement so distributed 236 And "a3c024b4e23230c89884a54a813b1ecb4cb0f827a38641c66eeca466da6b2ddb" should have general account balance of "990000" for asset "VEGA" 237 # not distributed as the notional requirement not met 238 And "a3c024b4e23230c89884a54a813b1ecb4cb0f827a38641c66eeca466da6b2ddc" should have general account balance of "1000000" for asset "VEGA" 239 # not distributed as the notional requirement not met 240 And "a3c024b4e23230c89884a54a813b1ecb4cb0f827a38641c66eeca466da6b2ddd" should have general account balance of "1000000" for asset "VEGA" 241 242 # they get 1/8 of the reward with no requirements + 1/2 of the reward with staking minimum = 1250+5000=6250 243 And "aux1" should have vesting account balance of "6250" for asset "VEGA" 244 # they get 1/8 of the reward with no requirements = 1250 245 And "aux2" should have vesting account balance of "1250" for asset "VEGA" 246 # they get 1/8 of the reward with no requirements + 1/2 of the reward with staking minimum = 1250+5000=6250 247 And "trader3" should have vesting account balance of "6250" for asset "VEGA" 248 # they get 1/8 of the reward with no requirements = 1250 249 And "trader4" should have vesting account balance of "1250" for asset "VEGA" 250 251 # now lets get some notional so we can satisfy the notional requirement 252 When the parties place the following orders with ticks: 253 | party | market id | side | volume | price | resulting trades | type | tif | 254 | trader3 | ETH/DEC21 | buy | 10 | 1002 | 1 | TYPE_LIMIT | TIF_GTC | 255 | trader4 | ETH/DEC21 | sell | 10 | 1002 | 1 | TYPE_LIMIT | TIF_GTC | 256 257 Then the network moves ahead "1" epochs 258 # no requirement so surely distributed 259 And "a3c024b4e23230c89884a54a813b1ecb4cb0f827a38641c66eeca466da6b2dda" should have general account balance of "980000" for asset "VEGA" 260 # only staking requirement so distributed 261 And "a3c024b4e23230c89884a54a813b1ecb4cb0f827a38641c66eeca466da6b2ddb" should have general account balance of "980000" for asset "VEGA" 262 # we have trade3 statisfying the notional requirement so distributed 263 And "a3c024b4e23230c89884a54a813b1ecb4cb0f827a38641c66eeca466da6b2ddc" should have general account balance of "990000" for asset "VEGA" 264 # we have trade3 statisfying the notional requirement so distributed 265 And "a3c024b4e23230c89884a54a813b1ecb4cb0f827a38641c66eeca466da6b2ddd" should have general account balance of "990000" for asset "VEGA" 266 267 # for reward (1) each gets a 1/8 268 # for reward (2) aux1 and trader3 split the reward 269 # for reward (3) each gets a quarter (all have sufficient notional) 270 # for reward (4) each gets a quarter 271 # aux1 = 6250 + 1250 + 5000 + 2500 + 2500 = 17500 272 And "aux1" should have vesting account balance of "17500" for asset "VEGA" 273 # aux2 = 1250 + 1250 + 2500 + 2500 = 7500 274 And "aux2" should have vesting account balance of "7500" for asset "VEGA" 275 # trader3 = 6250 + 1250 + 5000 + 2500 + 2500 = 17500 276 And "trader3" should have vesting account balance of "17500" for asset "VEGA" 277 # trader4 = 1250 + 1250 + 2500 + 2500 = 7500 278 And "trader4" should have vesting account balance of "7500" for asset "VEGA" 279 280 Scenario: Given a recurring transfer using the eligible entities metric and a reward window length N greater than one, a party who met the eligibility requirements in the current epoch only will receive no rewards at the end of the epoch. 281 # setup recurring transfer to the reward account - this will start at the end of this epoch (1) 282 Given the parties submit the following recurring transfers: 283 | 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 | 284 | 1 | a3c024b4e23230c89884a54a813b1ecb4cb0f827a38641c66eeca466da6b2ddb | ACCOUNT_TYPE_GENERAL | 0000000000000000000000000000000000000000000000000000000000000000 | ACCOUNT_TYPE_REWARD_ELIGIBLE_ENTITIES | VEGA | 10000 | 1 | | 1 | DISPATCH_METRIC_ELIGIBLE_ENTITIES | | | 2 | 2 | PRO_RATA | INDIVIDUALS | ALL | 1200 | 0 | 285 | 2 | a3c024b4e23230c89884a54a813b1ecb4cb0f827a38641c66eeca466da6b2ddc | ACCOUNT_TYPE_GENERAL | 0000000000000000000000000000000000000000000000000000000000000000 | ACCOUNT_TYPE_REWARD_ELIGIBLE_ENTITIES | VEGA | 10000 | 1 | | 1 | DISPATCH_METRIC_ELIGIBLE_ENTITIES | ETH | | 2 | 2 | PRO_RATA | INDIVIDUALS | ALL | 0 | 10000 | 286 | 3 | a3c024b4e23230c89884a54a813b1ecb4cb0f827a38641c66eeca466da6b2ddd | ACCOUNT_TYPE_GENERAL | 0000000000000000000000000000000000000000000000000000000000000000 | ACCOUNT_TYPE_REWARD_ELIGIBLE_ENTITIES | VEGA | 10000 | 1 | | 1 | DISPATCH_METRIC_ELIGIBLE_ENTITIES | ETH | | 2 | 2 | PRO_RATA | INDIVIDUALS | ALL | 1000 | 10000 | 287 288 Then the parties place the following orders: 289 | party | market id | side | volume | price | resulting trades | type | tif | 290 | aux1 | ETH/DEC21 | buy | 10 | 1000 | 0 | TYPE_LIMIT | TIF_GTC | 291 | aux2 | ETH/DEC21 | sell | 10 | 1000 | 0 | TYPE_LIMIT | TIF_GTC | 292 | aux1 | ETH/DEC21 | buy | 1 | 900 | 0 | TYPE_LIMIT | TIF_GTC | 293 | aux2 | ETH/DEC21 | sell | 1 | 1100 | 0 | TYPE_LIMIT | TIF_GTC | 294 295 Then the opening auction period ends for market "ETH/DEC21" 296 And the market data for the market "ETH/DEC21" should be: 297 | mark price | trading mode | 298 | 1000 | TRADING_MODE_CONTINUOUS | 299 300 When the parties place the following orders with ticks: 301 | party | market id | side | volume | price | resulting trades | type | tif | 302 | trader3 | ETH/DEC21 | buy | 3 | 1002 | 0 | TYPE_LIMIT | TIF_GTC | 303 304 Then the parties place the following orders with ticks: 305 | party | market id | side | volume | price | resulting trades | type | tif | 306 | trader4 | ETH/DEC21 | sell | 4 | 1002 | 1 | TYPE_LIMIT | TIF_GTC | 307 308 Then the network moves ahead "1" epochs 309 # only staking requirement so distributed 310 And "a3c024b4e23230c89884a54a813b1ecb4cb0f827a38641c66eeca466da6b2ddb" should have general account balance of "990000" for asset "VEGA" 311 # not distributed as the notional requirement not met 312 And "a3c024b4e23230c89884a54a813b1ecb4cb0f827a38641c66eeca466da6b2ddc" should have general account balance of "1000000" for asset "VEGA" 313 # not distributed as the notional requirement not met 314 And "a3c024b4e23230c89884a54a813b1ecb4cb0f827a38641c66eeca466da6b2ddd" should have general account balance of "1000000" for asset "VEGA" 315 316 # they get 1/2 of the reward with staking minimum = 5000 317 And "aux1" should have vesting account balance of "5000" for asset "VEGA" 318 # they get 1/2 of the reward with staking minimum = 5000 319 And "trader3" should have vesting account balance of "5000" for asset "VEGA" 320 321 # now lets get some notional so we can satisfy the notional requirement 322 When the parties place the following orders with ticks: 323 | party | market id | side | volume | price | resulting trades | type | tif | 324 | trader3 | ETH/DEC21 | buy | 10 | 1002 | 1 | TYPE_LIMIT | TIF_GTC | 325 | trader4 | ETH/DEC21 | sell | 10 | 1002 | 1 | TYPE_LIMIT | TIF_GTC | 326 327 # now lets make aux2 and trader 4 satisfy the staking requirement 328 And the parties deposit on staking account the following amount: 329 | party | asset | amount | 330 | aux2 | VEGA | 1200 | 331 | trader4 | VEGA | 1200 | 332 333 Then the network moves ahead "1" epochs 334 And "a3c024b4e23230c89884a54a813b1ecb4cb0f827a38641c66eeca466da6b2ddb" should have general account balance of "980000" for asset "VEGA" 335 And "a3c024b4e23230c89884a54a813b1ecb4cb0f827a38641c66eeca466da6b2ddc" should have general account balance of "990000" for asset "VEGA" 336 And "a3c024b4e23230c89884a54a813b1ecb4cb0f827a38641c66eeca466da6b2ddd" should have general account balance of "990000" for asset "VEGA" 337 338 # for reward (1) aux1 and trader3 split the reward (because they satisfied the requirement for both epochs) 339 # for reward (2) split 4 ways - all have notional, no staking requirement 340 # for reward (3) split 4 ways - all have notional, lower staking requirement met in both epochs 341 And "aux1" should have vesting account balance of "15000" for asset "VEGA" 342 And "aux2" should have vesting account balance of "5000" for asset "VEGA" 343 And "trader3" should have vesting account balance of "15000" for asset "VEGA" 344 And "trader4" should have vesting account balance of "5000" for asset "VEGA" 345 346 Then the network moves ahead "1" epochs 347 And "a3c024b4e23230c89884a54a813b1ecb4cb0f827a38641c66eeca466da6b2ddb" should have general account balance of "970000" for asset "VEGA" 348 And "a3c024b4e23230c89884a54a813b1ecb4cb0f827a38641c66eeca466da6b2ddc" should have general account balance of "980000" for asset "VEGA" 349 And "a3c024b4e23230c89884a54a813b1ecb4cb0f827a38641c66eeca466da6b2ddd" should have general account balance of "980000" for asset "VEGA" 350 351 # all 3 rewards are now split 4 ways 352 # aux1 = 15000 + 2500 + 2500 + 2500 = 22500 353 And "aux1" should have vesting account balance of "22500" for asset "VEGA" 354 # aux2 = 5000 + 2500 + 2500 + 2500 = 12500 355 And "aux2" should have vesting account balance of "12500" for asset "VEGA" 356 # trader3 = 15000 + 2500 + 2500 + 2500 = 22500 357 And "trader3" should have vesting account balance of "22500" for asset "VEGA" 358 # trader4 = 5000 + 2500 + 2500 + 2500 = 7500 359 And "trader4" should have vesting account balance of "12500" for asset "VEGA" 360 361 Scenario: Given a recurring transfer using the eligible entities metric and a reward window length greater than one, a party who met the eligibility requirements in a previous epoch in the window, but not the current epoch will receive no rewards at the end of the epoch. (0056-REWA-181) 362 # setup recurring transfer to the reward account - this will start at the end of this epoch (1) 363 Given the parties submit the following recurring transfers: 364 | 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 | 365 | 1 | a3c024b4e23230c89884a54a813b1ecb4cb0f827a38641c66eeca466da6b2ddb | ACCOUNT_TYPE_GENERAL | 0000000000000000000000000000000000000000000000000000000000000000 | ACCOUNT_TYPE_REWARD_ELIGIBLE_ENTITIES | VEGA | 10000 | 1 | | 1 | DISPATCH_METRIC_ELIGIBLE_ENTITIES | | | 2 | 2 | PRO_RATA | INDIVIDUALS | ALL | 1200 | 0 | 366 | 2 | a3c024b4e23230c89884a54a813b1ecb4cb0f827a38641c66eeca466da6b2ddc | ACCOUNT_TYPE_GENERAL | 0000000000000000000000000000000000000000000000000000000000000000 | ACCOUNT_TYPE_REWARD_ELIGIBLE_ENTITIES | VEGA | 10000 | 1 | | 1 | DISPATCH_METRIC_ELIGIBLE_ENTITIES | ETH | | 2 | 2 | PRO_RATA | INDIVIDUALS | ALL | 0 | 10000 | 367 | 3 | a3c024b4e23230c89884a54a813b1ecb4cb0f827a38641c66eeca466da6b2ddd | ACCOUNT_TYPE_GENERAL | 0000000000000000000000000000000000000000000000000000000000000000 | ACCOUNT_TYPE_REWARD_ELIGIBLE_ENTITIES | VEGA | 10000 | 1 | | 1 | DISPATCH_METRIC_ELIGIBLE_ENTITIES | ETH | | 2 | 2 | PRO_RATA | INDIVIDUALS | ALL | 1000 | 10000 | 368 369 Then the parties place the following orders: 370 | party | market id | side | volume | price | resulting trades | type | tif | 371 | aux1 | ETH/DEC21 | buy | 10 | 1000 | 0 | TYPE_LIMIT | TIF_GTC | 372 | aux2 | ETH/DEC21 | sell | 10 | 1000 | 0 | TYPE_LIMIT | TIF_GTC | 373 | aux1 | ETH/DEC21 | buy | 1 | 900 | 0 | TYPE_LIMIT | TIF_GTC | 374 | aux2 | ETH/DEC21 | sell | 1 | 1100 | 0 | TYPE_LIMIT | TIF_GTC | 375 376 Then the opening auction period ends for market "ETH/DEC21" 377 And the market data for the market "ETH/DEC21" should be: 378 | mark price | trading mode | 379 | 1000 | TRADING_MODE_CONTINUOUS | 380 381 When the parties place the following orders with ticks: 382 | party | market id | side | volume | price | resulting trades | type | tif | 383 | trader3 | ETH/DEC21 | buy | 3 | 1002 | 0 | TYPE_LIMIT | TIF_GTC | 384 385 Then the parties place the following orders with ticks: 386 | party | market id | side | volume | price | resulting trades | type | tif | 387 | trader4 | ETH/DEC21 | sell | 4 | 1002 | 1 | TYPE_LIMIT | TIF_GTC | 388 389 Then the network moves ahead "1" epochs 390 # only staking requirement so distributed 391 And "a3c024b4e23230c89884a54a813b1ecb4cb0f827a38641c66eeca466da6b2ddb" should have general account balance of "990000" for asset "VEGA" 392 # not distributed as the notional requirement not met 393 And "a3c024b4e23230c89884a54a813b1ecb4cb0f827a38641c66eeca466da6b2ddc" should have general account balance of "1000000" for asset "VEGA" 394 # not distributed as the notional requirement not met 395 And "a3c024b4e23230c89884a54a813b1ecb4cb0f827a38641c66eeca466da6b2ddd" should have general account balance of "1000000" for asset "VEGA" 396 397 # they get 1/2 of the reward with staking minimum = 5000 398 And "aux1" should have vesting account balance of "5000" for asset "VEGA" 399 # they get 1/2 of the reward with staking minimum = 5000 400 And "trader3" should have vesting account balance of "5000" for asset "VEGA" 401 402 # now lets get some notional so we can satisfy the notional requirement 403 When the parties place the following orders with ticks: 404 | party | market id | side | volume | price | resulting trades | type | tif | 405 | trader3 | ETH/DEC21 | buy | 10 | 1002 | 1 | TYPE_LIMIT | TIF_GTC | 406 | trader4 | ETH/DEC21 | sell | 10 | 1002 | 1 | TYPE_LIMIT | TIF_GTC | 407 408 # lets withdraw the staking to make them ineligible in the following window 409 And the parties withdraw from staking account the following amount: 410 | party | asset | amount | 411 | aux1 | VEGA | 1200 | 412 | aux2 | VEGA | 800 | 413 | trader4 | VEGA | 1000 | 414 415 Then the network moves ahead "1" epochs 416 And "a3c024b4e23230c89884a54a813b1ecb4cb0f827a38641c66eeca466da6b2ddb" should have general account balance of "980000" for asset "VEGA" 417 And "a3c024b4e23230c89884a54a813b1ecb4cb0f827a38641c66eeca466da6b2ddc" should have general account balance of "990000" for asset "VEGA" 418 And "a3c024b4e23230c89884a54a813b1ecb4cb0f827a38641c66eeca466da6b2ddd" should have general account balance of "990000" for asset "VEGA" 419 420 # for reward (1) is paid only to trader 3 421 # for reward (2) split 4 ways - all have notional, no staking requirement 422 # for reward (3) is paid only to trader 3 423 And "aux1" should have vesting account balance of "7500" for asset "VEGA" 424 And "aux2" should have vesting account balance of "2500" for asset "VEGA" 425 And "trader3" should have vesting account balance of "27500" for asset "VEGA" 426 And "trader4" should have vesting account balance of "2500" for asset "VEGA" 427 428 429 Scenario: Given a recurring transfer using the eligible entities metric and the below combination of fields, rewards should be uniformly distributed amongst all entities in the eligible keys meeting the staking and trading activity requirements. a dispatch asset specified,a set of markets specified,a staking requirement specified,a position requirement specified,an eligible keys list specified (0056-REWA-225). 430 # setup recurring transfer to the reward account - this will start at the end of this epoch (1) 431 Given the parties submit the following recurring transfers: 432 | 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 | 433 | 1 | a3c024b4e23230c89884a54a813b1ecb4cb0f827a38641c66eeca466da6b2ddd | ACCOUNT_TYPE_GENERAL | 0000000000000000000000000000000000000000000000000000000000000000 | ACCOUNT_TYPE_REWARD_ELIGIBLE_ENTITIES | VEGA | 10000 | 1 | | 1 | DISPATCH_METRIC_ELIGIBLE_ENTITIES | ETH | ETH/DEC21 | 2 | 1 | PRO_RATA | INDIVIDUALS | ALL | 500 | 500 | trader3,trader4 | 434 435 Then the parties place the following orders: 436 | party | market id | side | volume | price | resulting trades | type | tif | 437 | aux1 | ETH/DEC21 | buy | 10 | 1000 | 0 | TYPE_LIMIT | TIF_GTC | 438 | aux2 | ETH/DEC21 | sell | 10 | 1000 | 0 | TYPE_LIMIT | TIF_GTC | 439 | aux1 | ETH/DEC21 | buy | 1 | 900 | 0 | TYPE_LIMIT | TIF_GTC | 440 | aux2 | ETH/DEC21 | sell | 1 | 1100 | 0 | TYPE_LIMIT | TIF_GTC | 441 442 Then the opening auction period ends for market "ETH/DEC21" 443 And the market data for the market "ETH/DEC21" should be: 444 | mark price | trading mode | 445 | 1000 | TRADING_MODE_CONTINUOUS | 446 447 Then the network moves ahead "1" epochs 448 449 When the parties place the following orders with ticks: 450 | party | market id | side | volume | price | resulting trades | type | tif | 451 | trader3 | ETH/DEC21 | buy | 3 | 1002 | 0 | TYPE_LIMIT | TIF_GTC | 452 453 Then the parties place the following orders with ticks: 454 | party | market id | side | volume | price | resulting trades | type | tif | 455 | trader4 | ETH/DEC21 | sell | 4 | 1002 | 1 | TYPE_LIMIT | TIF_GTC | 456 457 Then the network moves ahead "1" epochs 458 # we have trade3 statisfying the notional requirement so distributed 459 And "a3c024b4e23230c89884a54a813b1ecb4cb0f827a38641c66eeca466da6b2ddd" should have general account balance of "990000" for asset "VEGA" 460 461 # each would get a quarter but only trader3 and trader4 are in the eligible so they get half each 462 And "trader3" should have vesting account balance of "5000" for asset "VEGA" 463 And "trader4" should have vesting account balance of "5000" for asset "VEGA" 464 465 Scenario: Given a recurring transfer using the eligible entities metric and the below combination of fields, rewards should be uniformly distributed amongst all entities in the eligible keys meeting the staking and trading activity requirements. a dispatch asset specified,no set of markets specified,no staking requirement specified,a position requirement specified,an eligible keys list specified (0056-REWA-224). 466 # setup recurring transfer to the reward account - this will start at the end of this epoch (1) 467 Given the parties submit the following recurring transfers: 468 | 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 | 469 | 1 | a3c024b4e23230c89884a54a813b1ecb4cb0f827a38641c66eeca466da6b2ddd | ACCOUNT_TYPE_GENERAL | 0000000000000000000000000000000000000000000000000000000000000000 | ACCOUNT_TYPE_REWARD_ELIGIBLE_ENTITIES | VEGA | 10000 | 1 | | 1 | DISPATCH_METRIC_ELIGIBLE_ENTITIES | ETH | | 2 | 1 | PRO_RATA | INDIVIDUALS | ALL | 0 | 500 | trader3,trader4 | 470 471 Then the parties place the following orders: 472 | party | market id | side | volume | price | resulting trades | type | tif | 473 | aux1 | ETH/DEC21 | buy | 10 | 1000 | 0 | TYPE_LIMIT | TIF_GTC | 474 | aux2 | ETH/DEC21 | sell | 10 | 1000 | 0 | TYPE_LIMIT | TIF_GTC | 475 | aux1 | ETH/DEC21 | buy | 1 | 900 | 0 | TYPE_LIMIT | TIF_GTC | 476 | aux2 | ETH/DEC21 | sell | 1 | 1100 | 0 | TYPE_LIMIT | TIF_GTC | 477 478 Then the opening auction period ends for market "ETH/DEC21" 479 And the market data for the market "ETH/DEC21" should be: 480 | mark price | trading mode | 481 | 1000 | TRADING_MODE_CONTINUOUS | 482 483 Then the network moves ahead "1" epochs 484 485 When the parties place the following orders with ticks: 486 | party | market id | side | volume | price | resulting trades | type | tif | 487 | trader3 | ETH/DEC21 | buy | 3 | 1002 | 0 | TYPE_LIMIT | TIF_GTC | 488 489 Then the parties place the following orders with ticks: 490 | party | market id | side | volume | price | resulting trades | type | tif | 491 | trader4 | ETH/DEC21 | sell | 4 | 1002 | 1 | TYPE_LIMIT | TIF_GTC | 492 493 Then the network moves ahead "1" epochs 494 # we have trade3 statisfying the notional requirement so distributed 495 And "a3c024b4e23230c89884a54a813b1ecb4cb0f827a38641c66eeca466da6b2ddd" should have general account balance of "990000" for asset "VEGA" 496 497 # each would get a quarter but only trader3 and trader4 are in the eligible so they get half each 498 And "trader3" should have vesting account balance of "5000" for asset "VEGA" 499 And "trader4" should have vesting account balance of "5000" for asset "VEGA" 500 501 Scenario: Given a recurring transfer using the eligible entities metric and the below combination of fields, rewards should be uniformly distributed amongst all entities in the eligible keys meeting the staking and trading activity requirements. no dispatch asset specified,no set of markets specified,a staking requirement specified,no position requirement specified,an eligible keys list specified (0056-REWA-223). 502 # setup recurring transfer to the reward account - this will start at the end of this epoch (1) 503 Given the parties submit the following recurring transfers: 504 | 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 | 505 | 1 | a3c024b4e23230c89884a54a813b1ecb4cb0f827a38641c66eeca466da6b2ddd | ACCOUNT_TYPE_GENERAL | 0000000000000000000000000000000000000000000000000000000000000000 | ACCOUNT_TYPE_REWARD_ELIGIBLE_ENTITIES | VEGA | 10000 | 1 | | 1 | DISPATCH_METRIC_ELIGIBLE_ENTITIES | | | 2 | 1 | PRO_RATA | INDIVIDUALS | ALL | 500 | 0 | trader3,trader4 | 506 507 Then the parties place the following orders: 508 | party | market id | side | volume | price | resulting trades | type | tif | 509 | aux1 | ETH/DEC21 | buy | 10 | 1000 | 0 | TYPE_LIMIT | TIF_GTC | 510 | aux2 | ETH/DEC21 | sell | 10 | 1000 | 0 | TYPE_LIMIT | TIF_GTC | 511 | aux1 | ETH/DEC21 | buy | 1 | 900 | 0 | TYPE_LIMIT | TIF_GTC | 512 | aux2 | ETH/DEC21 | sell | 1 | 1100 | 0 | TYPE_LIMIT | TIF_GTC | 513 514 Then the opening auction period ends for market "ETH/DEC21" 515 And the market data for the market "ETH/DEC21" should be: 516 | mark price | trading mode | 517 | 1000 | TRADING_MODE_CONTINUOUS | 518 519 When the parties place the following orders with ticks: 520 | party | market id | side | volume | price | resulting trades | type | tif | 521 | trader3 | ETH/DEC21 | buy | 3 | 1002 | 0 | TYPE_LIMIT | TIF_GTC | 522 523 Then the parties place the following orders with ticks: 524 | party | market id | side | volume | price | resulting trades | type | tif | 525 | trader4 | ETH/DEC21 | sell | 4 | 1002 | 1 | TYPE_LIMIT | TIF_GTC | 526 527 Then the network moves ahead "1" epochs 528 # we have trade3 statisfying the notional requirement so distributed 529 And "a3c024b4e23230c89884a54a813b1ecb4cb0f827a38641c66eeca466da6b2ddd" should have general account balance of "990000" for asset "VEGA" 530 531 # each would get a quarter but only trader3 and trader4 are in the eligible so they get half each 532 And "trader3" should have vesting account balance of "5000" for asset "VEGA" 533 And "trader4" should have vesting account balance of "5000" for asset "VEGA" 534 535 536 Scenario: Given a recurring transfer using the eligible entities metric and the below combination of fields, rewards should be uniformly distributed amongst all entities in the eligible keys meeting the staking and trading activity requirements. no dispatch asset specified,no set of markets specified,no staking requirement specified,no position requirement specified,an eligible keys list specified (0056-REWA-222). 537 # setup recurring transfer to the reward account - this will start at the end of this epoch (1) 538 Given the parties submit the following recurring transfers: 539 | 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 | 540 | 1 | a3c024b4e23230c89884a54a813b1ecb4cb0f827a38641c66eeca466da6b2ddd | ACCOUNT_TYPE_GENERAL | 0000000000000000000000000000000000000000000000000000000000000000 | ACCOUNT_TYPE_REWARD_ELIGIBLE_ENTITIES | VEGA | 10000 | 1 | | 1 | DISPATCH_METRIC_ELIGIBLE_ENTITIES | | | 2 | 1 | PRO_RATA | INDIVIDUALS | ALL | 0 | 0 | trader3,trader4 | 541 542 Then the parties place the following orders: 543 | party | market id | side | volume | price | resulting trades | type | tif | 544 | aux1 | ETH/DEC21 | buy | 10 | 1000 | 0 | TYPE_LIMIT | TIF_GTC | 545 | aux2 | ETH/DEC21 | sell | 10 | 1000 | 0 | TYPE_LIMIT | TIF_GTC | 546 | aux1 | ETH/DEC21 | buy | 1 | 900 | 0 | TYPE_LIMIT | TIF_GTC | 547 | aux2 | ETH/DEC21 | sell | 1 | 1100 | 0 | TYPE_LIMIT | TIF_GTC | 548 549 Then the opening auction period ends for market "ETH/DEC21" 550 And the market data for the market "ETH/DEC21" should be: 551 | mark price | trading mode | 552 | 1000 | TRADING_MODE_CONTINUOUS | 553 554 When the parties place the following orders with ticks: 555 | party | market id | side | volume | price | resulting trades | type | tif | 556 | trader3 | ETH/DEC21 | buy | 3 | 1002 | 0 | TYPE_LIMIT | TIF_GTC | 557 558 Then the parties place the following orders with ticks: 559 | party | market id | side | volume | price | resulting trades | type | tif | 560 | trader4 | ETH/DEC21 | sell | 4 | 1002 | 1 | TYPE_LIMIT | TIF_GTC | 561 562 Then the network moves ahead "1" epochs 563 564 # we have trade3 statisfying the notional requirement so distributed 565 And "a3c024b4e23230c89884a54a813b1ecb4cb0f827a38641c66eeca466da6b2ddd" should have general account balance of "990000" for asset "VEGA" 566 567 # each would get a quarter but only trader3 and trader4 are in the eligible so they get half each 568 And "trader3" should have vesting account balance of "5000" for asset "VEGA" 569 And "trader4" should have vesting account balance of "5000" for asset "VEGA" 570 571 Scenario: Given a recurring transfer using the eligible entities metric and the below combination of fields, rewards should be uniformly distributed amongst all entities in the eligible keys meeting the staking and trading activity requirements. no dispatch asset specified,no set of markets specified,no staking requirement specified,no position requirement specified,an eligible keys list specified (0056-REWA-222). 572 # setup recurring transfer to the reward account - this will start at the end of this epoch (1) 573 Given the parties submit the following recurring transfers: 574 | 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 | 575 | 1 | a3c024b4e23230c89884a54a813b1ecb4cb0f827a38641c66eeca466da6b2ddd | ACCOUNT_TYPE_GENERAL | 0000000000000000000000000000000000000000000000000000000000000000 | ACCOUNT_TYPE_REWARD_ELIGIBLE_ENTITIES | VEGA | 10000 | 1 | | 1 | DISPATCH_METRIC_ELIGIBLE_ENTITIES | | | 2 | 1 | PRO_RATA | INDIVIDUALS | ALL | 0 | 0 | trader3,trader4 | 576 577 Then the parties place the following orders: 578 | party | market id | side | volume | price | resulting trades | type | tif | 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 | 582 | aux2 | ETH/DEC21 | sell | 1 | 1100 | 0 | TYPE_LIMIT | TIF_GTC | 583 584 Then the opening auction period ends for market "ETH/DEC21" 585 And the market data for the market "ETH/DEC21" should be: 586 | mark price | trading mode | 587 | 1000 | TRADING_MODE_CONTINUOUS | 588 589 When the parties place the following orders with ticks: 590 | party | market id | side | volume | price | resulting trades | type | tif | 591 | trader3 | ETH/DEC21 | buy | 3 | 1002 | 0 | TYPE_LIMIT | TIF_GTC | 592 593 Then the parties place the following orders with ticks: 594 | party | market id | side | volume | price | resulting trades | type | tif | 595 | trader4 | ETH/DEC21 | sell | 4 | 1002 | 1 | TYPE_LIMIT | TIF_GTC | 596 597 Then the network moves ahead "1" epochs 598 599 # we have trade3 statisfying the notional requirement so distributed 600 And "a3c024b4e23230c89884a54a813b1ecb4cb0f827a38641c66eeca466da6b2ddd" should have general account balance of "990000" for asset "VEGA" 601 602 # each would get a quarter but only trader3 and trader4 are in the eligible so they get half each 603 And "trader3" should have vesting account balance of "5000" for asset "VEGA" 604 And "trader4" should have vesting account balance of "5000" for asset "VEGA" 605 606 Scenario: Given a recurring transfer using the eligible entities metric and the below combination of fields, rewards should be uniformly distributed amongst all entities in the eligible keys meeting the staking and trading activity requirements. no dispatch asset specified,no set of markets specified,no staking requirement specified,no position requirement specified,no eligible keys list specified (0056-REWA-171). 607 # setup recurring transfer to the reward account - this will start at the end of this epoch (1) 608 Given the parties submit the following recurring transfers: 609 | 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 | 610 | 1 | a3c024b4e23230c89884a54a813b1ecb4cb0f827a38641c66eeca466da6b2ddd | ACCOUNT_TYPE_GENERAL | 0000000000000000000000000000000000000000000000000000000000000000 | ACCOUNT_TYPE_REWARD_ELIGIBLE_ENTITIES | VEGA | 10000 | 1 | | 1 | DISPATCH_METRIC_ELIGIBLE_ENTITIES | | | 2 | 1 | PRO_RATA | INDIVIDUALS | ALL | 0 | 0 | 611 612 Then the parties place the following orders: 613 | party | market id | side | volume | price | resulting trades | type | tif | 614 | aux1 | ETH/DEC21 | buy | 10 | 1000 | 0 | TYPE_LIMIT | TIF_GTC | 615 | aux2 | ETH/DEC21 | sell | 10 | 1000 | 0 | TYPE_LIMIT | TIF_GTC | 616 | aux1 | ETH/DEC21 | buy | 1 | 900 | 0 | TYPE_LIMIT | TIF_GTC | 617 | aux2 | ETH/DEC21 | sell | 1 | 1100 | 0 | TYPE_LIMIT | TIF_GTC | 618 619 Then the opening auction period ends for market "ETH/DEC21" 620 And the market data for the market "ETH/DEC21" should be: 621 | mark price | trading mode | 622 | 1000 | TRADING_MODE_CONTINUOUS | 623 624 Then the network moves ahead "1" epochs 625 626 # we have trade3 statisfying the notional requirement so distributed 627 And "a3c024b4e23230c89884a54a813b1ecb4cb0f827a38641c66eeca466da6b2ddd" should have general account balance of "990000" for asset "VEGA" 628 629 # split 8 ways 630 And "aux1" should have vesting account balance of "1250" for asset "VEGA" 631 And "aux2" should have vesting account balance of "1250" for asset "VEGA" 632 And "trader3" should have vesting account balance of "1250" for asset "VEGA" 633 And "trader4" should have vesting account balance of "1250" for asset "VEGA" 634 And "a3c024b4e23230c89884a54a813b1ecb4cb0f827a38641c66eeca466da6b2dda" should have vesting account balance of "1250" for asset "VEGA" 635 And "a3c024b4e23230c89884a54a813b1ecb4cb0f827a38641c66eeca466da6b2ddb" should have vesting account balance of "1250" for asset "VEGA" 636 And "a3c024b4e23230c89884a54a813b1ecb4cb0f827a38641c66eeca466da6b2ddc" should have vesting account balance of "1250" for asset "VEGA" 637 And "a3c024b4e23230c89884a54a813b1ecb4cb0f827a38641c66eeca466da6b2ddd" should have vesting account balance of "1250" for asset "VEGA" 638 639 Scenario: Given a recurring transfer using the eligible entities metric and the below combination of fields, rewards should be uniformly distributed amongst all entities in the eligible keys meeting the staking and trading activity requirements. no dispatch asset specified,no set of markets specified,no staking requirement specified,no position requirement specified,no eligible keys list specified (0056-REWA-172). 640 # setup recurring transfer to the reward account - this will start at the end of this epoch (1) 641 Given the parties submit the following recurring transfers: 642 | 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 | 643 | 1 | a3c024b4e23230c89884a54a813b1ecb4cb0f827a38641c66eeca466da6b2ddd | ACCOUNT_TYPE_GENERAL | 0000000000000000000000000000000000000000000000000000000000000000 | ACCOUNT_TYPE_REWARD_ELIGIBLE_ENTITIES | VEGA | 10000 | 1 | | 1 | DISPATCH_METRIC_ELIGIBLE_ENTITIES | | | 2 | 1 | PRO_RATA | INDIVIDUALS | ALL | 1200 | 0 | 644 645 Then the parties place the following orders: 646 | party | market id | side | volume | price | resulting trades | type | tif | 647 | aux1 | ETH/DEC21 | buy | 10 | 1000 | 0 | TYPE_LIMIT | TIF_GTC | 648 | aux2 | ETH/DEC21 | sell | 10 | 1000 | 0 | TYPE_LIMIT | TIF_GTC | 649 | aux1 | ETH/DEC21 | buy | 1 | 900 | 0 | TYPE_LIMIT | TIF_GTC | 650 | aux2 | ETH/DEC21 | sell | 1 | 1100 | 0 | TYPE_LIMIT | TIF_GTC | 651 652 Then the opening auction period ends for market "ETH/DEC21" 653 And the market data for the market "ETH/DEC21" should be: 654 | mark price | trading mode | 655 | 1000 | TRADING_MODE_CONTINUOUS | 656 657 Then the network moves ahead "1" epochs 658 659 # we have trade3 statisfying the notional requirement so distributed 660 And "a3c024b4e23230c89884a54a813b1ecb4cb0f827a38641c66eeca466da6b2ddd" should have general account balance of "990000" for asset "VEGA" 661 662 # split equally between parties with stake >= 1200, i.e. aux1 and trader3 663 And "aux1" should have vesting account balance of "5000" for asset "VEGA" 664 And "trader3" should have vesting account balance of "5000" for asset "VEGA" 665 666 Scenario: Given a recurring transfer using the eligible entities metric and the below combination of fields, rewards should be uniformly distributed amongst all entities in the eligible keys meeting the staking and trading activity requirements. no dispatch asset specified,no set of markets specified,no staking requirement specified,no position requirement specified,no eligible keys list specified (0056-REWA-173). 667 # setup recurring transfer to the reward account - this will start at the end of this epoch (1) 668 Given the parties submit the following recurring transfers: 669 | 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 | 670 | 1 | a3c024b4e23230c89884a54a813b1ecb4cb0f827a38641c66eeca466da6b2ddd | ACCOUNT_TYPE_GENERAL | 0000000000000000000000000000000000000000000000000000000000000000 | ACCOUNT_TYPE_REWARD_ELIGIBLE_ENTITIES | VEGA | 10000 | 1 | | 1 | DISPATCH_METRIC_ELIGIBLE_ENTITIES | ETH | | 2 | 1 | PRO_RATA | INDIVIDUALS | ALL | 0 | 5000 | 671 672 Then the parties place the following orders: 673 | party | market id | side | volume | price | resulting trades | type | tif | 674 | aux1 | ETH/DEC21 | buy | 10 | 1000 | 0 | TYPE_LIMIT | TIF_GTC | 675 | aux2 | ETH/DEC21 | sell | 10 | 1000 | 0 | TYPE_LIMIT | TIF_GTC | 676 | aux1 | ETH/DEC21 | buy | 1 | 900 | 0 | TYPE_LIMIT | TIF_GTC | 677 | aux2 | ETH/DEC21 | sell | 1 | 1100 | 0 | TYPE_LIMIT | TIF_GTC | 678 679 Then the opening auction period ends for market "ETH/DEC21" 680 And the market data for the market "ETH/DEC21" should be: 681 | mark price | trading mode | 682 | 1000 | TRADING_MODE_CONTINUOUS | 683 684 When the parties place the following orders with ticks: 685 | party | market id | side | volume | price | resulting trades | type | tif | 686 | trader3 | ETH/DEC21 | buy | 3 | 1002 | 0 | TYPE_LIMIT | TIF_GTC | 687 688 Then the parties place the following orders with ticks: 689 | party | market id | side | volume | price | resulting trades | type | tif | 690 | trader4 | ETH/DEC21 | sell | 4 | 1002 | 1 | TYPE_LIMIT | TIF_GTC | 691 692 Then the network moves ahead "1" epochs 693 694 # we have trade3 statisfying the notional requirement so distributed 695 And "a3c024b4e23230c89884a54a813b1ecb4cb0f827a38641c66eeca466da6b2ddd" should have general account balance of "990000" for asset "VEGA" 696 697 # split equally between aux1, aux2. trader3 and trader4 do not meet the notional requirement 698 And "aux1" should have vesting account balance of "5000" for asset "VEGA" 699 And "aux2" should have vesting account balance of "5000" for asset "VEGA" 700 701 Scenario: Given a recurring transfer using the eligible entities metric and the below combination of fields, rewards should be uniformly distributed amongst all entities in the eligible keys meeting the staking and trading activity requirements.a dispatch asset specified,a set of markets specified,no staking requirement specified,no position requirement specified,no eligible keys list specified (0056-REWA-174). 702 # setup recurring transfer to the reward account - this will start at the end of this epoch (1) 703 Given the parties submit the following recurring transfers: 704 | 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 | 705 | 1 | a3c024b4e23230c89884a54a813b1ecb4cb0f827a38641c66eeca466da6b2ddd | ACCOUNT_TYPE_GENERAL | 0000000000000000000000000000000000000000000000000000000000000000 | ACCOUNT_TYPE_REWARD_ELIGIBLE_ENTITIES | VEGA | 10000 | 1 | | 1 | DISPATCH_METRIC_ELIGIBLE_ENTITIES | ETH | ETH/DEC21 | 2 | 1 | PRO_RATA | INDIVIDUALS | ALL | 0 | 5000 | 706 707 Then the parties place the following orders: 708 | party | market id | side | volume | price | resulting trades | type | tif | 709 | aux1 | ETH/DEC21 | buy | 10 | 1000 | 0 | TYPE_LIMIT | TIF_GTC | 710 | aux2 | ETH/DEC21 | sell | 10 | 1000 | 0 | TYPE_LIMIT | TIF_GTC | 711 | aux1 | ETH/DEC21 | buy | 1 | 900 | 0 | TYPE_LIMIT | TIF_GTC | 712 | aux2 | ETH/DEC21 | sell | 1 | 1100 | 0 | TYPE_LIMIT | TIF_GTC | 713 | aux1 | ETH/DEC22 | buy | 10 | 1000 | 0 | TYPE_LIMIT | TIF_GTC | 714 | aux2 | ETH/DEC22 | sell | 10 | 1000 | 0 | TYPE_LIMIT | TIF_GTC | 715 | aux1 | ETH/DEC22 | buy | 1 | 900 | 0 | TYPE_LIMIT | TIF_GTC | 716 | aux2 | ETH/DEC22 | sell | 1 | 1100 | 0 | TYPE_LIMIT | TIF_GTC | 717 718 Then the opening auction period ends for market "ETH/DEC21" 719 And the market data for the market "ETH/DEC21" should be: 720 | mark price | trading mode | 721 | 1000 | TRADING_MODE_CONTINUOUS | 722 723 And the market data for the market "ETH/DEC22" should be: 724 | mark price | trading mode | 725 | 1000 | TRADING_MODE_CONTINUOUS | 726 727 When the parties place the following orders with ticks: 728 | party | market id | side | volume | price | resulting trades | type | tif | 729 | trader3 | ETH/DEC22 | buy | 10 | 1002 | 0 | TYPE_LIMIT | TIF_GTC | 730 731 Then the parties place the following orders with ticks: 732 | party | market id | side | volume | price | resulting trades | type | tif | 733 | trader4 | ETH/DEC22 | sell | 10 | 1002 | 1 | TYPE_LIMIT | TIF_GTC | 734 735 When the parties place the following orders with ticks: 736 | party | market id | side | volume | price | resulting trades | type | tif | 737 | trader3 | ETH/DEC21 | buy | 3 | 1002 | 0 | TYPE_LIMIT | TIF_GTC | 738 739 Then the parties place the following orders with ticks: 740 | party | market id | side | volume | price | resulting trades | type | tif | 741 | trader4 | ETH/DEC21 | sell | 4 | 1002 | 1 | TYPE_LIMIT | TIF_GTC | 742 743 Then the network moves ahead "1" epochs 744 745 # we have trade3 statisfying the notional requirement so distributed 746 And "a3c024b4e23230c89884a54a813b1ecb4cb0f827a38641c66eeca466da6b2ddd" should have general account balance of "990000" for asset "VEGA" 747 748 # split equally between aux1, aux2. trader3 and trader4 do not meet the notional requirement for the market in scope although they do for the market ETH/DEC22. 749 And "aux1" should have vesting account balance of "5000" for asset "VEGA" 750 And "aux2" should have vesting account balance of "5000" for asset "VEGA" 751 752 Scenario: Given a recurring transfer using the eligible entities metric and the below combination of fields, rewards should be uniformly distributed amongst all entities in the eligible keys meeting the staking and trading activity requirements. dispatch asset specified,a set of markets specified,a staking requirement specified,a position requirement specified,with eligible keys list specified (0056-REWA-225). 753 # setup recurring transfer to the reward account - this will start at the end of this epoch (1) 754 Given the parties submit the following recurring transfers: 755 | 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 | 756 | 1 | a3c024b4e23230c89884a54a813b1ecb4cb0f827a38641c66eeca466da6b2ddd | ACCOUNT_TYPE_GENERAL | 0000000000000000000000000000000000000000000000000000000000000000 | ACCOUNT_TYPE_REWARD_ELIGIBLE_ENTITIES | VEGA | 10000 | 1 | | 1 | DISPATCH_METRIC_ELIGIBLE_ENTITIES | ETH | ETH/DEC21 | 2 | 1 | PRO_RATA | INDIVIDUALS | ALL | 1200 | 5000 | aux1 | 757 758 Then the parties place the following orders: 759 | party | market id | side | volume | price | resulting trades | type | tif | 760 | aux1 | ETH/DEC21 | buy | 10 | 1000 | 0 | TYPE_LIMIT | TIF_GTC | 761 | aux2 | ETH/DEC21 | sell | 10 | 1000 | 0 | TYPE_LIMIT | TIF_GTC | 762 | aux1 | ETH/DEC21 | buy | 1 | 900 | 0 | TYPE_LIMIT | TIF_GTC | 763 | aux2 | ETH/DEC21 | sell | 1 | 1100 | 0 | TYPE_LIMIT | TIF_GTC | 764 | aux1 | ETH/DEC22 | buy | 10 | 1000 | 0 | TYPE_LIMIT | TIF_GTC | 765 | aux2 | ETH/DEC22 | sell | 10 | 1000 | 0 | TYPE_LIMIT | TIF_GTC | 766 | aux1 | ETH/DEC22 | buy | 1 | 900 | 0 | TYPE_LIMIT | TIF_GTC | 767 | aux2 | ETH/DEC22 | sell | 1 | 1100 | 0 | TYPE_LIMIT | TIF_GTC | 768 769 Then the opening auction period ends for market "ETH/DEC21" 770 And the market data for the market "ETH/DEC21" should be: 771 | mark price | trading mode | 772 | 1000 | TRADING_MODE_CONTINUOUS | 773 774 And the market data for the market "ETH/DEC22" should be: 775 | mark price | trading mode | 776 | 1000 | TRADING_MODE_CONTINUOUS | 777 778 When the parties place the following orders with ticks: 779 | party | market id | side | volume | price | resulting trades | type | tif | 780 | trader3 | ETH/DEC22 | buy | 10 | 1002 | 0 | TYPE_LIMIT | TIF_GTC | 781 782 Then the parties place the following orders with ticks: 783 | party | market id | side | volume | price | resulting trades | type | tif | 784 | trader4 | ETH/DEC22 | sell | 10 | 1002 | 1 | TYPE_LIMIT | TIF_GTC | 785 786 When the parties place the following orders with ticks: 787 | party | market id | side | volume | price | resulting trades | type | tif | 788 | trader3 | ETH/DEC21 | buy | 3 | 1002 | 0 | TYPE_LIMIT | TIF_GTC | 789 790 Then the parties place the following orders with ticks: 791 | party | market id | side | volume | price | resulting trades | type | tif | 792 | trader4 | ETH/DEC21 | sell | 4 | 1002 | 1 | TYPE_LIMIT | TIF_GTC | 793 794 Then the network moves ahead "1" epochs 795 796 # we have trade3 statisfying the notional requirement so distributed 797 And "a3c024b4e23230c89884a54a813b1ecb4cb0f827a38641c66eeca466da6b2ddd" should have general account balance of "990000" for asset "VEGA" 798 799 # only aux1 meets all criteria and is in the eligible keys 800 And "aux1" should have vesting account balance of "10000" for asset "VEGA"