code.vegaprotocol.io/vega@v0.79.0/core/integration/features/vesting/0085-VSPR-vesting.feature (about) 1 Feature: Setting and applying activity streak benefits 2 3 Background: 4 5 # Initialise the network 6 Given time is updated to "2023-01-01T00:00:00Z" 7 And the average block duration is "1" 8 And the following network parameters are set: 9 | name | value | 10 | market.fee.factors.makerFee | 0.001 | 11 | network.markPriceUpdateMaximumFrequency | 0s | 12 | market.auction.minimumDuration | 1 | 13 | validators.epoch.length | 20s | 14 | limits.markets.maxPeggedOrders | 4 | 15 16 # Set vesting parameters and disable multipliers 17 And the following network parameters are set: 18 | name | value | 19 | rewards.vesting.baseRate | 0.1 | 20 | rewards.vesting.minimumTransfer | 1 | 21 | rewards.vesting.benefitTiers | {"tiers": [{"minimum_quantum_balance": "1", "reward_multiplier": "1"}]} | 22 | rewards.activityStreak.benefitTiers | {"tiers": [{"minimum_activity_streak": 1, "reward_multiplier": "1", "vesting_multiplier": "1"}]} | 23 24 # Initialise the markets 25 And the following assets are registered: 26 | id | decimal places | quantum | 27 | USD.1.10 | 1 | 10 | 28 29 And the markets: 30 | id | quote name | asset | risk model | margin calculator | auction duration | fees | price monitoring | data source config | linear slippage factor | quadratic slippage factor | sla params | decimal places | position decimal places | 31 | ETH/USD.1.10 | ETH | USD.1.10 | default-log-normal-risk-model | default-margin-calculator | 1 | default-none | default-none | default-eth-for-future | 1e-3 | 0 | default-futures | 0 | 0 | 32 | BTC/USD.1.10 | ETH | USD.1.10 | default-log-normal-risk-model | default-margin-calculator | 1 | default-none | default-none | default-eth-for-future | 1e-3 | 0 | default-futures | 0 | 0 | 33 And the network moves ahead "1" blocks 34 35 # Initialise the parties 36 Given the parties deposit on asset's general account the following amount: 37 | party | asset | amount | 38 | lpprov | USD.1.10 | 10000000000 | 39 | aux1 | USD.1.10 | 10000000 | 40 | aux2 | USD.1.10 | 10000000 | 41 | trader1 | USD.1.10 | 10000000 | 42 | trader2 | USD.1.10 | 10000000 | 43 | a3c024b4e23230c89884a54a813b1ecb4cb0f827a38641c66eeca466da6b2ddf | USD.1.10 | 100000000000 | 44 45 # Exit opening auctions 46 Given the parties submit the following liquidity provision: 47 | id | party | market id | commitment amount | fee | lp type | 48 | lp1 | lpprov | ETH/USD.1.10 | 1000000 | 0.01 | submission | 49 | lp2 | lpprov | BTC/USD.1.10 | 1000000 | 0.01 | submission | 50 And the parties place the following pegged iceberg orders: 51 | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | 52 | lpprov | ETH/USD.1.10 | 5000 | 1000 | buy | BID | 10000 | 1 | 53 | lpprov | ETH/USD.1.10 | 5000 | 1000 | sell | ASK | 10000 | 1 | 54 | lpprov | BTC/USD.1.10 | 5000 | 1000 | buy | BID | 10000 | 1 | 55 | lpprov | BTC/USD.1.10 | 5000 | 1000 | sell | ASK | 10000 | 1 | 56 When the parties place the following orders: 57 | party | market id | side | volume | price | resulting trades | type | tif | 58 | aux1 | ETH/USD.1.10 | buy | 1 | 990 | 0 | TYPE_LIMIT | TIF_GTC | 59 | aux1 | ETH/USD.1.10 | buy | 1 | 1000 | 0 | TYPE_LIMIT | TIF_GTC | 60 | aux2 | ETH/USD.1.10 | sell | 1 | 1000 | 0 | TYPE_LIMIT | TIF_GTC | 61 | aux2 | ETH/USD.1.10 | sell | 1 | 1100 | 0 | TYPE_LIMIT | TIF_GTC | 62 | aux1 | BTC/USD.1.10 | buy | 10 | 990 | 0 | TYPE_LIMIT | TIF_GTC | 63 | aux1 | BTC/USD.1.10 | buy | 10 | 1000 | 0 | TYPE_LIMIT | TIF_GTC | 64 | aux2 | BTC/USD.1.10 | sell | 10 | 1000 | 0 | TYPE_LIMIT | TIF_GTC | 65 | aux2 | BTC/USD.1.10 | sell | 10 | 1100 | 0 | TYPE_LIMIT | TIF_GTC | 66 # And the opening auction period ends for market "ETH/USD.1.10" 67 And the opening auction period ends for market "BTC/USD.1.10" 68 Then the network moves ahead "1" blocks 69 And the trading mode should be "TRADING_MODE_CONTINUOUS" for the market "ETH/USD.1.10" 70 And the trading mode should be "TRADING_MODE_CONTINUOUS" for the market "BTC/USD.1.10" 71 72 73 Scenario Outline: Parties rewards vest at the correct rate and adhere to the minimum quantum transfer (0085-RVST-009)(0085-RVST-010) 74 # Expectation: rewards should be distributed into the same vesting account and transferred to the same vested account 75 76 # Test cases: 77 # - the expected base transfer is greater than the minimum transfer 78 # - the expected base transfer is smaller than the minimum transfer 79 # - the minimum transfer is smaller than the full balance 80 81 Given the following network parameters are set: 82 | name | value | 83 | rewards.vesting.baseRate | <base rate> | 84 | rewards.vesting.minimumTransfer | <minimum transfer> | 85 86 Given the parties submit the following recurring transfers: 87 | id | from | from_account_type | to | to_account_type | asset | amount | start_epoch | end_epoch | factor | metric | metric_asset | markets | 88 | 1 | a3c024b4e23230c89884a54a813b1ecb4cb0f827a38641c66eeca466da6b2ddf | ACCOUNT_TYPE_GENERAL | 0000000000000000000000000000000000000000000000000000000000000000 | ACCOUNT_TYPE_REWARD_MAKER_PAID_FEES | USD.1.10 | 10000 | 1 | | 1 | DISPATCH_METRIC_MAKER_FEES_PAID | USD.1.10 | ETH/USD.1.10 | 89 And the network moves ahead "1" blocks 90 91 Given the parties place the following orders: 92 | party | market id | side | volume | price | resulting trades | type | tif | 93 | aux1 | ETH/USD.1.10 | sell | 10 | 1000 | 0 | TYPE_LIMIT | TIF_GTC | 94 | trader1 | ETH/USD.1.10 | buy | 10 | 1000 | 1 | TYPE_LIMIT | TIF_GTC | 95 | aux1 | BTC/USD.1.10 | sell | 10 | 1000 | 0 | TYPE_LIMIT | TIF_GTC | 96 | trader1 | BTC/USD.1.10 | buy | 10 | 1000 | 1 | TYPE_LIMIT | TIF_GTC | 97 When the network moves ahead "1" epochs 98 Then "trader1" should have vesting account balance of "10000" for asset "USD.1.10" 99 100 When the network moves ahead "1" epochs 101 Then "trader1" should have vested account balance of <vested amount> for asset "USD.1.10" 102 103 Examples: 104 | base rate | minimum transfer | vested amount | 105 | 0.1 | 1 | "1000" | 106 | 0.1 | 200 | "2000" | 107 | 0.1 | 2000 | "10000" | 108 | 1.0 | 1 | "10000" | 109 110 111 Scenario: Parties rewards from different markets (using the same settlement asset) are transferred into the same vesting account (0085-RVST-004)(0085-RVST-005) 112 # Expectation: rewards should be distributed into the same vesting account and t to the same vested account 113 114 Given the parties submit the following recurring transfers: 115 | id | from | from_account_type | to | to_account_type | asset | amount | start_epoch | end_epoch | factor | metric | metric_asset | markets | 116 | 1 | a3c024b4e23230c89884a54a813b1ecb4cb0f827a38641c66eeca466da6b2ddf | ACCOUNT_TYPE_GENERAL | 0000000000000000000000000000000000000000000000000000000000000000 | ACCOUNT_TYPE_REWARD_MAKER_PAID_FEES | USD.1.10 | 10000 | 1 | | 1 | DISPATCH_METRIC_MAKER_FEES_PAID | USD.1.10 | ETH/USD.1.10 | 117 | 2 | a3c024b4e23230c89884a54a813b1ecb4cb0f827a38641c66eeca466da6b2ddf | ACCOUNT_TYPE_GENERAL | 0000000000000000000000000000000000000000000000000000000000000000 | ACCOUNT_TYPE_REWARD_MAKER_PAID_FEES | USD.1.10 | 10000 | 1 | | 1 | DISPATCH_METRIC_MAKER_FEES_PAID | USD.1.10 | BTC/USD.1.10 | 118 And the network moves ahead "1" blocks 119 120 Given the parties place the following orders: 121 | party | market id | side | volume | price | resulting trades | type | tif | 122 | aux1 | ETH/USD.1.10 | sell | 10 | 1000 | 0 | TYPE_LIMIT | TIF_GTC | 123 | trader1 | ETH/USD.1.10 | buy | 10 | 1000 | 1 | TYPE_LIMIT | TIF_GTC | 124 | aux1 | BTC/USD.1.10 | sell | 10 | 1000 | 0 | TYPE_LIMIT | TIF_GTC | 125 | trader1 | BTC/USD.1.10 | buy | 10 | 1000 | 1 | TYPE_LIMIT | TIF_GTC | 126 When the network moves ahead "1" epochs 127 Then "trader1" should have vesting account balance of "20000" for asset "USD.1.10" 128 129 When the network moves ahead "1" epochs 130 Then "trader1" should have vesting account balance of "18000" for asset "USD.1.10" 131 And "trader1" should have vested account balance of "2000" for asset "USD.1.10" 132 133 134 Scenario: Party receive rewards from pool funded with a transfer with a non-zero lock period (0085-RVST-011) 135 # Expectation: rewards should only start vesting once the lock-period has expired 136 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 | 139 | 1 | a3c024b4e23230c89884a54a813b1ecb4cb0f827a38641c66eeca466da6b2ddf | ACCOUNT_TYPE_GENERAL | 0000000000000000000000000000000000000000000000000000000000000000 | ACCOUNT_TYPE_REWARD_MAKER_PAID_FEES | USD.1.10 | 10000 | 1 | | 1 | DISPATCH_METRIC_MAKER_FEES_PAID | USD.1.10 | ETH/USD.1.10 | 2 | 140 And the network moves ahead "1" blocks 141 142 Given the parties place the following orders: 143 | party | market id | side | volume | price | resulting trades | type | tif | 144 | aux1 | ETH/USD.1.10 | sell | 10 | 1000 | 0 | TYPE_LIMIT | TIF_GTC | 145 | trader1 | ETH/USD.1.10 | buy | 10 | 1000 | 1 | TYPE_LIMIT | TIF_GTC | 146 When the network moves ahead "1" epochs 147 Then "trader1" should have vesting account balance of "10000" for asset "USD.1.10" 148 149 # Lock period of first batch of rewards expired - no vesting occurs 150 When the network moves ahead "1" epochs 151 Then "trader1" should have vesting account balance of "10000" for asset "USD.1.10" 152 153 # Lock period of first batch of rewards expired - full vesting occurs 154 When the network moves ahead "1" epochs 155 And "trader1" should have vesting account balance of "9000" for asset "USD.1.10" 156 Then "trader1" should have vested account balance of "1000" for asset "USD.1.10" 157 158 # Generate some more rewards 159 Given the parties place the following orders: 160 | party | market id | side | volume | price | resulting trades | type | tif | 161 | aux1 | ETH/USD.1.10 | sell | 10 | 1000 | 0 | TYPE_LIMIT | TIF_GTC | 162 | trader1 | ETH/USD.1.10 | buy | 10 | 1000 | 1 | TYPE_LIMIT | TIF_GTC | 163 When the network moves ahead "1" epochs 164 Then "trader1" should have vesting account balance of "18100" for asset "USD.1.10" 165 And "trader1" should have vested account balance of "1900" for asset "USD.1.10" 166 167 # Lock period of second batch of rewards not expired - partial vesting occurs 168 When the network moves ahead "1" epochs 169 Then "trader1" should have vesting account balance of "17290" for asset "USD.1.10" 170 And "trader1" should have vested account balance of "2710" for asset "USD.1.10" 171 172 # Lock period of second batch of rewards has expired - full vesting occurs 173 When the network moves ahead "1" epochs 174 And "trader1" should have vesting account balance of "15561" for asset "USD.1.10" 175 Then "trader1" should have vested account balance of "4439" for asset "USD.1.10" 176 177 178 Scenario Outline: Party receives rewards but does not withdraw them in order to receive a bonus multiplier (0085-RVST-012)(0085-RVST-013)(0085-RVST-014) 179 # Expectation: if the party meets the minimum quantum balance requirement, they should receive a multiplier and a greater share of future rewards 180 181 # Test Cases: 182 # - party does meet the minimum quantum balance requirement, they receive a multiplier and a greater share of future rewards (3:1) 183 # - party does meet the minimum quantum balance requirement, they receive a multiplier and a greater share of future rewards (4:1) 184 # - party does not meet the minimum quantum balance requirement, they receive no multipliers and the same share of future rewards (1:1) 185 186 Given the following network parameters are set: 187 | name | value | 188 | rewards.vesting.baseRate | 1.0 | 189 | rewards.vesting.benefitTiers | {"tiers": [{"minimum_quantum_balance": <minimum quantum balance>, "reward_multiplier": <reward multiplier>}]} | 190 191 Given the parties submit the following recurring transfers: 192 | id | from | from_account_type | to | to_account_type | asset | amount | start_epoch | end_epoch | factor | metric | metric_asset | markets | 193 | 1 | a3c024b4e23230c89884a54a813b1ecb4cb0f827a38641c66eeca466da6b2ddf | ACCOUNT_TYPE_GENERAL | 0000000000000000000000000000000000000000000000000000000000000000 | ACCOUNT_TYPE_REWARD_MAKER_PAID_FEES | USD.1.10 | 10000 | 1 | | 1 | DISPATCH_METRIC_MAKER_FEES_PAID | USD.1.10 | ETH/USD.1.10 | 194 And the network moves ahead "1" blocks 195 196 Given the parties place the following orders: 197 | party | market id | side | volume | price | resulting trades | type | tif | 198 | aux1 | ETH/USD.1.10 | sell | 10 | 1000 | 0 | TYPE_LIMIT | TIF_GTC | 199 | trader1 | ETH/USD.1.10 | buy | 10 | 1000 | 1 | TYPE_LIMIT | TIF_GTC | 200 And the network moves ahead "1" epochs 201 Then "trader1" should have vesting account balance of "10000" for asset "USD.1.10" 202 203 Given the parties place the following orders: 204 | party | market id | side | volume | price | resulting trades | type | tif | 205 | aux1 | ETH/USD.1.10 | sell | 10 | 1000 | 0 | TYPE_LIMIT | TIF_GTC | 206 | trader1 | ETH/USD.1.10 | buy | 10 | 1000 | 1 | TYPE_LIMIT | TIF_GTC | 207 | aux1 | ETH/USD.1.10 | sell | 10 | 1000 | 0 | TYPE_LIMIT | TIF_GTC | 208 | trader2 | ETH/USD.1.10 | buy | 10 | 1000 | 1 | TYPE_LIMIT | TIF_GTC | 209 When the network moves ahead "1" epochs 210 Then "trader1" should have vesting account balance of <trader1 rewards> for asset "USD.1.10" 211 And "trader2" should have vesting account balance of <trader2 rewards> for asset "USD.1.10" 212 213 Examples: 214 | minimum quantum balance | reward multiplier | trader1 rewards | trader2 rewards | 215 | "500" | "3" | "7500" | "2500" | 216 | "500" | "4" | "8000" | "2000" | 217 | "5000000" | "3" | "5000" | "5000" | 218 219 220 Scenario: Parties attempt to transfer rewards to or from vesting and vested accounts (0085-RVST-006)(0085-RVST-007)(0085-RVST-008) 221 # Expectation: only transfers from the vested account should be valid, all other transfers should be rejected 222 223 Given the parties submit the following recurring transfers: 224 | id | from | from_account_type | to | to_account_type | asset | amount | start_epoch | end_epoch | factor | metric | metric_asset | markets | lock_period | 225 | 1 | a3c024b4e23230c89884a54a813b1ecb4cb0f827a38641c66eeca466da6b2ddf | ACCOUNT_TYPE_GENERAL | 0000000000000000000000000000000000000000000000000000000000000000 | ACCOUNT_TYPE_REWARD_MAKER_PAID_FEES | USD.1.10 | 10000 | 1 | | 1 | DISPATCH_METRIC_MAKER_FEES_PAID | USD.1.10 | ETH/USD.1.10 | 0 | 226 And the network moves ahead "1" blocks 227 228 Given the parties place the following orders: 229 | party | market id | side | volume | price | resulting trades | type | tif | 230 | aux1 | ETH/USD.1.10 | sell | 10 | 1000 | 0 | TYPE_LIMIT | TIF_GTC | 231 | a3c024b4e23230c89884a54a813b1ecb4cb0f827a38641c66eeca466da6b2ddf | ETH/USD.1.10 | buy | 10 | 1000 | 1 | TYPE_LIMIT | TIF_GTC | 232 When the network moves ahead "1" epochs 233 Then "a3c024b4e23230c89884a54a813b1ecb4cb0f827a38641c66eeca466da6b2ddf" should have vesting account balance of "9000" for asset "USD.1.10" 234 And "a3c024b4e23230c89884a54a813b1ecb4cb0f827a38641c66eeca466da6b2ddf" should have vested account balance of "1000" for asset "USD.1.10" 235 236 # Check rewards cannot be transferred to or from the following accounts 237 Given the parties submit the following one off transfers: 238 | id | from | from_account_type | to | to_account_type | asset | amount | delivery_time | error | 239 | oo1 | a3c024b4e23230c89884a54a813b1ecb4cb0f827a38641c66eeca466da6b2ddf | ACCOUNT_TYPE_VESTED_REWARDS | a3c024b4e23230c89884a54a813b1ecb4cb0f827a38641c66eeca466da6b2ddf | ACCOUNT_TYPE_GENERAL | USD.1.10 | 1 | 2023-01-01T01:00:00Z | | 240 | oo2 | a3c024b4e23230c89884a54a813b1ecb4cb0f827a38641c66eeca466da6b2ddf | ACCOUNT_TYPE_VESTING_REWARDS | a3c024b4e23230c89884a54a813b1ecb4cb0f827a38641c66eeca466da6b2ddf | ACCOUNT_TYPE_GENERAL | USD.1.10 | 1 | 2023-01-01T01:00:00Z | unsupported from account type | 241 | oo3 | a3c024b4e23230c89884a54a813b1ecb4cb0f827a38641c66eeca466da6b2ddf | ACCOUNT_TYPE_GENERAL | a3c024b4e23230c89884a54a813b1ecb4cb0f827a38641c66eeca466da6b2ddf | ACCOUNT_TYPE_VESTED_REWARDS | USD.1.10 | 1 | 2023-01-01T01:00:00Z | unsupported to account type | 242 | oo4 | a3c024b4e23230c89884a54a813b1ecb4cb0f827a38641c66eeca466da6b2ddf | ACCOUNT_TYPE_GENERAL | a3c024b4e23230c89884a54a813b1ecb4cb0f827a38641c66eeca466da6b2ddf | ACCOUNT_TYPE_VESTING_REWARDS | USD.1.10 | 1 | 2023-01-01T01:00:00Z | unsupported to account type | 243 And "a3c024b4e23230c89884a54a813b1ecb4cb0f827a38641c66eeca466da6b2ddf" should have vested account balance of "999" for asset "USD.1.10"