code.vegaprotocol.io/vega@v0.79.0/core/integration/features/rewards/0056-REWA-111.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 49 And the parties deposit on staking account the following amount: 50 | party | asset | amount | 51 | aux1 | VEGA | 2000 | 52 | aux2 | VEGA | 800 | 53 | trader3 | VEGA | 1500 | 54 | trader4 | VEGA | 1000 | 55 | lpprov | VEGA | 10000 | 56 | party1 | VEGA | 2000 | 57 | party2 | VEGA | 800 | 58 | party3 | VEGA | 2000 | 59 | party4 | VEGA | 2000 | 60 61 62 Given time is updated to "2023-09-23T00:00:00Z" 63 Given the average block duration is "1" 64 65 #complete the epoch to advance to a meaningful epoch (can't setup transfer to start at epoch 0) 66 Then the network moves ahead "1" epochs 67 68 When the parties submit the following liquidity provision: 69 | id | party | market id | commitment amount | fee | lp type | 70 | lp1 | lpprov | ETH/DEC21 | 90000 | 0.1 | submission | 71 | lp1 | lpprov | ETH/DEC21 | 90000 | 0.1 | submission | 72 | lp2 | lpprov | ETH/DEC22 | 90000 | 0.1 | submission | 73 | lp2 | lpprov | ETH/DEC22 | 90000 | 0.1 | submission | 74 75 And the parties place the following pegged iceberg orders: 76 | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | 77 | lpprov | ETH/DEC21 | 90 | 1 | buy | BID | 90 | 10 | 78 | lpprov | ETH/DEC21 | 90 | 1 | sell | ASK | 90 | 10 | 79 | lpprov | ETH/DEC22 | 90 | 1 | buy | BID | 90 | 10 | 80 | lpprov | ETH/DEC22 | 90 | 1 | sell | ASK | 90 | 10 | 81 82 Then the parties place the following orders: 83 | party | market id | side | volume | price | resulting trades | type | tif | reference | 84 | aux1 | ETH/DEC21 | buy | 10 | 1000 | 0 | TYPE_LIMIT | TIF_GTC | | 85 | aux2 | ETH/DEC21 | sell | 10 | 1000 | 0 | TYPE_LIMIT | TIF_GTC | | 86 | aux1 | ETH/DEC21 | buy | 1 | 900 | 0 | TYPE_LIMIT | TIF_GTC | buy1 | 87 | aux2 | ETH/DEC21 | sell | 1 | 1100 | 0 | TYPE_LIMIT | TIF_GTC | sell1 | 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 91 Scenario: If an eligible party has zero net returns, their relative returns reward metric should be zero(0056-REWA-111) 92 # setup recurring transfer to the reward account - this will start at the end of this epoch 93 Given the parties submit the following recurring transfers: 94 | 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 | 95 | 1 | a3c024b4e23230c89884a54a813b1ecb4cb0f827a38641c66eeca466da6b2ddf | ACCOUNT_TYPE_GENERAL | 0000000000000000000000000000000000000000000000000000000000000000 | ACCOUNT_TYPE_REWARD_RELATIVE_RETURN | VEGA | 10000 | 1 | | 1 | DISPATCH_METRIC_RELATIVE_RETURN | ETH | | 2 | 1 | PRO_RATA | INDIVIDUALS | ALL | 0 | 0 | 96 97 Then the network moves ahead "1" epochs 98 99 Given time is updated to "2023-09-23T00:00:30Z" 100 Then the parties place the following orders: 101 | party | market id | side | volume | price | resulting trades | type | tif | reference | 102 | party1 | ETH/DEC21 | buy | 10 | 1000 | 0 | TYPE_LIMIT | TIF_GTC | p1-buy1 | 103 | aux1 | ETH/DEC21 | sell | 10 | 1000 | 1 | TYPE_LIMIT | TIF_GTC | | 104 105 Then the parties place the following orders: 106 | party | market id | side | volume | price | resulting trades | type | tif | reference | 107 | party2 | ETH/DEC21 | sell | 10 | 1000 | 0 | TYPE_LIMIT | TIF_GTC | p2-sell | 108 | aux2 | ETH/DEC21 | buy | 10 | 1000 | 1 | TYPE_LIMIT | TIF_GTC | | 109 110 Then the network moves ahead "1" epochs 111 112 # M2M 113 # party1 = 0 114 # aux1 = 0 115 116 # relative return metric for party1 = 0 117 # relative return metric for aux1 = 0 118 And "a3c024b4e23230c89884a54a813b1ecb4cb0f827a38641c66eeca466da6b2ddf" should have general account balance of "1000000" for asset "VEGA" 119 120 Scenario: If a `window_length>1` is specified in the recurring transfer, if an eligible party has zero net returns in all epochs, their relative return metric should be zero(0056-REWA-114) 121 Given the parties submit the following recurring transfers: 122 | 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 | 123 | 1 | a3c024b4e23230c89884a54a813b1ecb4cb0f827a38641c66eeca466da6b2ddf | ACCOUNT_TYPE_GENERAL | 0000000000000000000000000000000000000000000000000000000000000000 | ACCOUNT_TYPE_REWARD_RELATIVE_RETURN | VEGA | 10000 | 1 | | 1 | DISPATCH_METRIC_RELATIVE_RETURN | ETH | | 2 | 6 | PRO_RATA | INDIVIDUALS | ALL | 0 | 0 | 124 125 Then the network moves ahead "1" epochs 126 127 Given time is updated to "2023-09-23T00:00:30Z" 128 Then the parties place the following orders: 129 | party | market id | side | volume | price | resulting trades | type | tif | reference | 130 | aux1 | ETH/DEC21 | buy | 10 | 1000 | 0 | TYPE_LIMIT | TIF_GTC | p1-buy1 | 131 | aux2 | ETH/DEC21 | sell | 10 | 1000 | 1 | TYPE_LIMIT | TIF_GTC | | 132 133 Then the network moves ahead "1" epochs 134 135 # M2M 136 # party1 = 0 137 # aux1 = 0 138 # relative return metric for party1 = 0 139 # relative return metric for aux1 = 0 140 And "a3c024b4e23230c89884a54a813b1ecb4cb0f827a38641c66eeca466da6b2ddf" should have general account balance of "1000000" for asset "VEGA" 141