code.vegaprotocol.io/vega@v0.79.0/core/integration/features/rewards/0056-REWA-116.feature (about) 1 Feature: Relative return 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 | party3 | ETH | 100000 | 46 | party4 | ETH | 100000 | 47 48 And the parties deposit on staking account the following amount: 49 | party | asset | amount | 50 | aux1 | VEGA | 2000 | 51 | aux2 | VEGA | 2000 | 52 | trader3 | VEGA | 1500 | 53 | trader4 | VEGA | 1000 | 54 | lpprov | VEGA | 10000 | 55 | party1 | VEGA | 800 | 56 | party2 | VEGA | 2000 | 57 | party3 | VEGA | 2000 | 58 | party4 | VEGA | 2000 | 59 60 Given time is updated to "2023-09-23T00:00:00Z" 61 Given the average block duration is "1" 62 63 #complete the epoch to advance to a meaningful epoch (can't setup transfer to start at epoch 0) 64 Then the network moves ahead "1" epochs 65 66 When the parties submit the following liquidity provision: 67 | id | party | market id | commitment amount | fee | lp type | 68 | lp1 | lpprov | ETH/DEC21 | 90000 | 0.1 | submission | 69 | lp1 | lpprov | ETH/DEC21 | 90000 | 0.1 | submission | 70 | lp2 | lpprov | ETH/DEC22 | 90000 | 0.1 | submission | 71 | lp2 | lpprov | ETH/DEC22 | 90000 | 0.1 | submission | 72 73 And the parties place the following pegged iceberg orders: 74 | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | 75 | lpprov | ETH/DEC21 | 90 | 1 | buy | BID | 90 | 10 | 76 | lpprov | ETH/DEC21 | 90 | 1 | sell | ASK | 90 | 10 | 77 | lpprov | ETH/DEC22 | 90 | 1 | buy | BID | 90 | 10 | 78 | lpprov | ETH/DEC22 | 90 | 1 | sell | ASK | 90 | 10 | 79 80 Then the parties place the following orders: 81 | party | market id | side | volume | price | resulting trades | type | tif | reference | 82 | aux1 | ETH/DEC21 | buy | 10 | 1000 | 0 | TYPE_LIMIT | TIF_GTC | | 83 | aux2 | ETH/DEC21 | sell | 10 | 1000 | 0 | TYPE_LIMIT | TIF_GTC | | 84 | aux1 | ETH/DEC21 | buy | 1 | 900 | 0 | TYPE_LIMIT | TIF_GTC | buy1 | 85 | aux2 | ETH/DEC21 | sell | 1 | 1100 | 0 | TYPE_LIMIT | TIF_GTC | sell1 | 86 | party1 | ETH/DEC22 | buy | 5 | 2000 | 0 | TYPE_LIMIT | TIF_GTC | | 87 | party2 | ETH/DEC22 | sell | 5 | 2000 | 0 | TYPE_LIMIT | TIF_GTC | | 88 | aux1 | ETH/DEC22 | buy | 1 | 1800 | 0 | TYPE_LIMIT | TIF_GTC | buy2 | 89 | aux2 | ETH/DEC22 | sell | 1 | 2200 | 0 | TYPE_LIMIT | TIF_GTC | sell2 | 90 And the mark price should be "0" for the market "ETH/DEC21" 91 92 Scenario: Given a recurring transfer is setup such that all eligible parties have a positive reward score, each parties metric is not offset and parties receive the correct rewards. (0056-REWA-116). 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-207). 93 # setup recurring transfer to the reward account - this will start at the end of this epoch 94 Given the parties submit the following recurring transfers: 95 | 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 | 96 | 1 | a3c024b4e23230c89884a54a813b1ecb4cb0f827a38641c66eeca466da6b2ddf | ACCOUNT_TYPE_GENERAL | 0000000000000000000000000000000000000000000000000000000000000000 | ACCOUNT_TYPE_REWARD_RELATIVE_RETURN | VEGA | 10000 | 1 | | 1 | DISPATCH_METRIC_RELATIVE_RETURN | ETH | | 2 | 2 | PRO_RATA | INDIVIDUALS | ALL | 1000 | 0 | 97 98 Then the network moves ahead "1" epochs 99 And the mark price should be "1000" for the market "ETH/DEC21" 100 Then the trading mode should be "TRADING_MODE_CONTINUOUS" for the market "ETH/DEC21" 101 102 Given time is updated to "2023-09-23T00:00:30Z" 103 Then the parties place the following orders: 104 | party | market id | side | volume | price | resulting trades | type | tif | reference | 105 | party1 | ETH/DEC21 | buy | 10 | 1002 | 0 | TYPE_LIMIT | TIF_GTC | p1-buy1 | 106 | aux1 | ETH/DEC21 | sell | 10 | 1002 | 1 | TYPE_LIMIT | TIF_GTC | | 107 And the mark price should be "1000" for the market "ETH/DEC21" 108 109 Then the parties place the following orders: 110 | party | market id | side | volume | price | resulting trades | type | tif | reference | 111 | party2 | ETH/DEC21 | sell | 10 | 999 | 0 | TYPE_LIMIT | TIF_GTC | p2-sell | 112 | aux2 | ETH/DEC21 | buy | 10 | 999 | 1 | TYPE_LIMIT | TIF_GTC | | 113 And the mark price should be "1000" for the market "ETH/DEC21" 114 115 Then the network moves ahead "1" epochs 116 And the mark price should be "999" for the market "ETH/DEC21" 117 118 # M2M 119 # party1 = -30 120 # aux1 = 20 121 # aux2 = 10 122 # party1 is not eligible because they don't have sufficient staking 123 # relative return metric for aux1 = 20/5 = 4 124 # relative return metric for aux2 = 10/5 = 2 125 # aux1 gets 10000 * 4/6 = 6666 126 # aux2 gets 10000 * 2/6 = 3333 127 128 And "a3c024b4e23230c89884a54a813b1ecb4cb0f827a38641c66eeca466da6b2ddf" should have general account balance of "990000" for asset "VEGA" 129 And "aux1" should have vesting account balance of "6666" for asset "VEGA" 130 And "aux2" should have vesting account balance of "3333" for asset "VEGA" 131 132 Then debug trades 133 134 135 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-217). 136 # setup recurring transfer to the reward account - this will start at the end of this epoch 137 Given the parties submit the following recurring transfers: 138 | 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 | 139 | 1 | a3c024b4e23230c89884a54a813b1ecb4cb0f827a38641c66eeca466da6b2ddf | ACCOUNT_TYPE_GENERAL | 0000000000000000000000000000000000000000000000000000000000000000 | ACCOUNT_TYPE_REWARD_RELATIVE_RETURN | VEGA | 10000 | 1 | | 1 | DISPATCH_METRIC_RELATIVE_RETURN | ETH | | 2 | 2 | PRO_RATA | INDIVIDUALS | ALL | 1000 | 0 | aux1 | 140 141 Then the network moves ahead "1" epochs 142 And the mark price should be "1000" for the market "ETH/DEC21" 143 Then the trading mode should be "TRADING_MODE_CONTINUOUS" for the market "ETH/DEC21" 144 145 Given time is updated to "2023-09-23T00:00:30Z" 146 Then the parties place the following orders: 147 | party | market id | side | volume | price | resulting trades | type | tif | reference | 148 | party1 | ETH/DEC21 | buy | 10 | 1002 | 0 | TYPE_LIMIT | TIF_GTC | p1-buy1 | 149 | aux1 | ETH/DEC21 | sell | 10 | 1002 | 1 | TYPE_LIMIT | TIF_GTC | | 150 And the mark price should be "1000" for the market "ETH/DEC21" 151 152 Then the parties place the following orders: 153 | party | market id | side | volume | price | resulting trades | type | tif | reference | 154 | party2 | ETH/DEC21 | sell | 10 | 999 | 0 | TYPE_LIMIT | TIF_GTC | p2-sell | 155 | aux2 | ETH/DEC21 | buy | 10 | 999 | 1 | TYPE_LIMIT | TIF_GTC | | 156 And the mark price should be "1000" for the market "ETH/DEC21" 157 158 Then the network moves ahead "1" epochs 159 And the mark price should be "999" for the market "ETH/DEC21" 160 161 # M2M 162 # party1 = -30 163 # aux1 = 20 164 # aux2 = 10 165 # party1 is not eligible because they don't have sufficient staking 166 # relative return metric for aux1 = 20/5 = 4 167 # relative return metric for aux2 = 10/5 = 2 168 # aux1 gets 10000 * 4/6 = 6666 169 # aux2 gets 10000 * 2/6 = 3333 170 # but only aux1 is in the eligible keys so they get 10k 171 172 And "a3c024b4e23230c89884a54a813b1ecb4cb0f827a38641c66eeca466da6b2ddf" should have general account balance of "990000" for asset "VEGA" 173 And "aux1" should have vesting account balance of "10000" for asset "VEGA" 174 175 Then debug trades 176 177