VesterCap Updates

esGMX rewards may be duplicated by transferring bnGMX from accounts that have already been processed by the updateBnGmxForAccount function to accounts that have yet to be processed.

For example:

• Account A has accumulated X bnGMX sitting in it's balance after the compound
• Account B is empty
• Account A is processed and receives esGMX rewards for X bnGMX
• Account A transfers their account to Account B
• Account B is processed and receives esGMX rewards for X bnGMX

Rewards are granted for 2X bnGMX, though the owner of Account A & B only had X bnGMX.

Consider burning the bnGMX, unclaimed bnGMX, and reserved for vesting bnGMX for an account after it is processed.

Accounts where the vested esGMX amount is paired with sbfGMX which is backed by bnGMX will effectively receive pair-free vesting because the bnGMX is removed for them while their vest is allowed to continue.

As a result users may begin vests with sbfGMX which is backed by bnGMX so that they can intentionally receive pair-free vesting.

Do not announce when this migration will take place, and do not emphasize the details of the unreserving so that it is less likely to be gamed. Additionally, consider adding a disincentive such as a reward deduction for accounts which would receive an effectively pair-free vest.

Escrowed GMX (esGMX) tokens can be converted into GMX tokens through vesting.

When vesting is initiated, the average amount of GMX tokens that was used to earn the esGMX rewards will be reserved.

The update aims to mint 1 esGMX for every 25 bnGMX, and then a user can vest those esGMX. However, the newly minted esGMX did not originate from the stakedGMXTracker, and are not considered in the averageStakedAmounts.

Consequently, less pair tokens are taken from the user for their vests than an account that would've vest the same amount of esGMX but earned them through the stakedGmxTracker.

Consider making up for this deficit by increasing the transferredAverageStakedAmounts to maintain the existing ratio of averageStakedAmounts / maxVestableAmount for pair tokens.

When the function updateBnGmxForAccounts is called, the tracker tokens are transferred directly to the _account without updating the pair amounts in the Vester. As a result, there is a divergence between the Vester's internal balance and its true pair balance.

The syncFeeGmxTrackerBalance is intended to sync these balances as soon as one of these accounts withdraws their paired tokens from the vester. This will correctly fix the gap in the vester contract, however when the amount of sbfGMX that is reserved and backed by bnGMX exceeds that of sbfGMX reserved and backed by non-bnGMX these users may be unable to withdraw from the vester in the first place.

For example:

• User A holds 5 sbfGMX backed by staked GMX in the vester
• User B holds 8 sbfGMX backed by bnGMX and 2 sbfGMX backed by staked GMX in the vester
• User B’s 8 sbfGMX backed by bnGMX is unreserved from the vester
• The vester’s sbfGMX balance is reduced to 7
• User A may withdraw their sbfGMX tokens and leave the vester balance at 3
• User B can not withdraw their paired tokens either before nor after User A withdraws as the vester does not have sufficient balance

In anticipation of the migration, consider minting additional sbfGMX to the vester contract so that it can cover any deficit that may be created and ensure that users can rightfully withdraw their sbfGMX.

Currently in the tests and in the deployVesterCap.js file, the maxBoostBasisPoints are configured to 20_000.

However the new vester cap deployment should utilize a maxBoostBasisPoints of 0 as no bnGMX may be staked.

When updating the scripts to deploy the new version of the VesterCap contract, be sure to assign the maxBoostBasisPoints to 0.

In the _unstakeGMX function a portion of the account's staked bnGMX balance is burned as a punishment for unstaking.

However the account may not hold the required sbfGMX amount in order for the call to unstakeForAccount for the reductionAmount to work.

As a result accounts which have at least a portion of their reserved sbfGMX backed by staked bnGMX will be unable to unstake all of their GMX or esGMX until the vest is completed or withdrawn.

For example:

• Account A has 9 sbfGMX backed by staked bnGMX and 1 sbfGMX backed by GMX
• Account A has 9 sbfGMX reserved in the vester contract
• Account A unstakes their 1 sbfGMX which is not reserved
• The reductionAmount is 0.9
• unstakeForAccount is called but it reverts as the account has no more remaining sbfGMX

As a result the user cannot unstake their GMX until the vest is over or withdrawn.

This behavior is resolved by the VesterCap functionality once it has been carried out. In the meantime be aware of this unexpected behavior.

"gmxVester" is used as the prefix in _validateReceiver when the glpVester staked amounts are validated.

Consider changing the prefix to glpVester.