Re-post: PERP Buyback Proposal to Support Affected v1 Users

Proposals
1

Updated: 2022-08-24

TLDR
In the previous vote, full compensation for the affected v1 users has won, however it didn’t get executed due to it not reaching the quorum. We re-posted it here via LeeKB’s suggestion to get some feedback and understanding on why the largest stake holders don’t vote.

Linked to the original post: PERP Buyback to Support Affected v1 Users and Boost User Confidence to prepare for the BULL run of PERP!

UPDATE: Below is the updated proposal based on Shao’s feedback:

Background and Problem statements:

During the market downturn in the past few months, the entire crypto industry has been facing a liquidity crisis. Users confidence collapsed, leading to massive sell-offs.

Despite best efforts from the PERP team to keep v1 running, it couldn’t escape shutdown as funds were being withdrawn at a high rate. The team responded by shutting down the v1 exchange and put the decision of how to distribute the remaining funds to a vote: Sunsetting Perp V1

The stake holders voted to make whole 99% of wallets (option2), which resulted in the remaining 1% wallets taking massive losses from hundreds of thousands to millions of dollars. Among the affected wallets, a group of mid-size low leverage users were especially outraged and felt that their funds are being taken away in an unjustified manner: Use PERP to provide max(op2, op4) to Perp v1 users) They have been actively spreading the injustice and their negative experience as well as filing for law suits that could further damage the credibility and the user confidence of PERP.

In the v1 documentation, it’s mentioned that PERP will be sold to compensate affected users during exchange shortfall.

image
image762×77 13.2 KB

Source

However, the PERP price is already too low at around $1/share at the time of this writing, and selling PERP to compensate at such a low price would result in a significant dilution. But if Perp doesn’t compensate the affected users, it will be perceived as they are not honoring their own documentation, and thus risk losing even more credibility and user confidence. This puts PERP holders in a very difficult spot. As Hana recently stated “The lifeblood of a DeFi project is its users and community.” Proposal: Community DAO Without users confidence, there will be no future for PERP.

Proposed Solution:

Herein, we propose a solution to this dilemma via a long-term PERP Buyback Plan that benefits both the PERP holders and the affected v1 users (credit to LeeKB):

The plan will use a portion (17.5%~25%) of the monthly treasury fee income to buy back PERP tokens (with a minimum locking period of 6 months) regularly over many years to fulfill its promise in the documentation to compensate the affected users with PERP.

The PERP price will receive a monthly price boost as a result of the buy back. The affected users who care enough to stake any amount of PERP in the new vePERP staking system will receive vePERP from the buyback each month with a locking period of at least 6 months as the compensation. Users who do not bother to lock any PERP to claim the compensation is basically taking PERP off the market and giving free money to the PERP holders. The locking period for the affected users can be longer than 6 months if the affected users choose to, so that they can earn more rewards from the staking system…

The source of the fund used to buy back PERP is coming from the treasury fee income, which is the portion of the trading fee income that got overflown into the treasury, and it’s only a tiny fraction (<2.5%) of the total trading fee income under the current fee structure. Thus this will NOT affect the LPs/insurance fund/stake rewards. Please refer to Proposal: Fee Distribution for the detail fee structure.

Benefits:

  • Regular monthly price boost to PERP.
  • Unclaimed PERP could be burnt to further boost PERP price
  • This tells the rest of the crypto community that Perpetual Protocol is indeed honoring its documentation to compensate affected users with PERP.
  • Adding tremendous credibility to the Perpetual Protocol platform.
  • Align interest of the affected users with PERP holders, so they can spread positive news rather than negatives.
  • Reinvigorate user confidence to both the Perpetual Protocol as well as the Crypto community as a whole.
  • The return of users confidence will likely result in further price increase of PERP.
  • The PERP price increase will likely prompt prospective investors on the side line to put more money to buy PERP (i.e. BULL run!)

Proposals:

Option A: Use 17.5% monthly treasury fee income to buy back PERP over the years to cover all op4>op2 users, for their op4-op2 amount.($3.59M), pro rata to compensation amount.

Option B: Use 25% monthly treasury fee income to buy back PERP over the years to cover all remaining users who did not benefit from op2, for the amount of (MAX(all options) - op2). ($5.2M) , pro rata to compensation amount.

Option C: Do not compensate.

The amount of buybacks/compensations are calculated below in this google sheet:

Detailed Distribution Plan:
The implementation will be done via the vePERP reward system/interface similar to referral reward .

If Option A~B passes, the following plan will be executed step-by-step:

Step 1. In the beginning of each month, 17.5%~25 % (determined by the winning option) of the USDC from the monthly treasury fee income will be used to buy back PERP token at market price at the time. This is done manually by DAO Treasury Multisig. The Buyback will only start after DAO Treasury start to receive fee revenue from Perpetual Protocol V2 ( fee distribution is still WIP but will come from the surplus of the InsuranceFund )

Step 2. To distribute the bought-back PERP token to the affected users, contract admin calls vePERPRewardDistributor.seedAllocation() to store which user can get how much of the bought-back PERP according to the google sheet (pro-rata by compensation amount). The required amount of PERP will be transferred from the caller into the vePERPRewardDistributor. The amount owe to the users will be reduced by that amount, which can be updated to the google sheet for record keeping.

Step 3. Once the affected users decide to claim the accumulated vePERP, they will need to first lock any non-zero amount of PERP for at least 26 weeks to be eligible to claim. Once they have a lock duration of 26 weeks or more, they can then simply click the “Claim” button on the interface or call vePERPRewardDistributor contract claimWeek or claimWeeks to claim their accumulated vePERP.

Step 4. Repeat step 1-3 until the USDC amount owed to the users reduces to 0 or less. If certain affected users were paid off earlier, they will be taken off the compensation list so the next round of pay off will be focused on the remaining affected users.

Note: If a particular user becomes inactive and did not claim any compensation for more than 1 year, or it becomes clear that the user doesn’t want to claim, then the DAO treasury multisig has the full right to decide whether to withdraw that PERP and redistribute to the other users to speed up their pay offs, or simply leave it as it. The determination is up to the DAO treasury multisig.

Summary:

All in all, this is a win-win solution to both PERP holders and the affected v1 users, and it could have a far reaching implication for the entire Crypto community on its path to regain user confidence and reignite the excitement of DeFi!

2

A few suggestions to make this proposal feasible and more complete, to avoid potential wrong interpret:

  • Use a spreadsheet with the full address instead of a screenshot ( example ). Ideally we should export to CSV and upload it to IPFS or Arweave to make it immutable, but should be fine by checking the edit history from google sheet
  • The distribution will only start after DAO Treasury start to receive fee revenue from Perpetual Protocol V2 ( fee distribution is still WIP but will come from the surplus of the InsuranceFund )
  • Questions about option C
    • Based on how the smart contract is being coded, full compensation won’t be more than the smart contract has. Wondering how we come up with the numbers? Do we have a complete spreadsheet with the address and USD so the team can know how to distribute the fund?
    • Could you elaborate more on how to use even distribution among the affected addresses?
  • Questions about the “Detailed Distribution Plan” section:
    • Let’s say Alice lock 0 PERP for 6 months on Jan 1. The lock period will decrease to 5 months on Feb 1. Does Alice still be eligible? I guess no but just want to double check
    • Step 2: I guess the way to buy back PERP is up to the DAO Treasury? Just a reminder currently the DAO treasury is a Gnosis multisig SAFE wallet, so the buyback can only be handled manually
    • Step 4: who can decide how to deal with the unclaimed PERP, the DAO treasury multisig?

My personal opinion:
I’d suggest to simplify the options, ex. pick either A or B and drop C since it’s still a bit vague to me. It also will be a lot easier for voters to understand with fewer options.

1 Like
3

Shao, thanks for your response. I didn’t expect you would respond, and I hope it’s earnest effort. We are honestly just retail users and don’t have the expert knowledge like you guys, but we’ll try our best to answer your questions:

  1. We will post the numbers on a google sheet here with edit history enabled. The number from this sheet is based on the Sunsetting v1 sheet that you guys posted.

  2. We understand this distribution is coming from the fee overflow. We will emphasize that in the proposal.

  3. Regarding full compensation, we observed that all bottom 99% users have a ratio of op2/op1 = 6.98697. We know that op2 made those users whole, so to make the remaining users whole we proposed to use (op1*6.98697 - op2). “Even distribution” means that let say the overflow treasury income = x for a particular month, and there’re 25 affected wallets who’re eligible, so each of those wallet would receive x/25 for that month. We’ll drop option C per your suggestion if this still sounds too vague.

  4. Alice will still be eligible in February because the Create_lock record is public on chain, and one can tell from the unix timestamps to see if Alice did lock for more than 6 months (26 weeks). In your scenario. I understand you want to do a rolling 6-month lock. However, when I tried the new lock system, I realized I can’t have two separate unlocked dates, meaning all locked PERP can only be unlocked in one date, making it impossible to have overlapping locking periods.

  5. I don’t know the nuance of who handles the buyback and who decides what to do with the unclaimed PERP. It matters very little to us. I will specify it to be the DAO treasury multisig unless you have some other ideas.

We will update the proposal based on your feedback, please let us know if you have other questions.

4

For 4, unfortunately it’s not technically possible. deposit_for() will be reverted when the vePERP is expired.

from vePERP ( fork from veCRV )

    assert _locked.end > block.timestamp, "Cannot add to expired lock. Withdraw"

ex. Alice lock on Jan 1 for a week, her locked.end is Jan 8, her vePERP is expired after Jan 8 and no one can call deposit for Ailce

I’d suggest modifying this part to make it feasible!

1 Like
5

Shao, thanks for taking the time to look into the code.

How about Alice on Jan 8th immediately creates a new lock as soon as the old lock expired? This way _locked.end becomes a new lock date (Source code) ,
image
thus still satisfying the _locked.end > block.timestamp requirement.

We can add an extra eligibility requirement:
If deposit_for() is reverted due to the lock has expired and no new lock was created, it automatically disqualifies that user for that month’s payout. The amount owed to them in USDC will still get lowered anyway because it’s not the team’s fault that the deposit_for() got reverted; the users are responsible for making sure _lock.end > block.timestamp.

We can modify the proposal to include the above statements regarding the eligibility when deposit_for() was reverted to make it simple for the team. Would that work? Any thoughts?

1 Like
6

Hi RDL, the L435 you pasted is inside the internal function _deposit_for, but if we look at the external function deposit_for, no one other than the vePERP owner herself can increase the lock time ( so the 4th params unlock_time is 0 in L475 when calling the internal function

def deposit_for(_addr: address, _value: uint256):
    // ignore line 462 to 474
    self._deposit_for(msg.sender, _addr, _value, 0, self.locked[_addr], DEPOSIT_FOR_TYPE)

Just want to try my best to clarify what vePERP can & can not do, so you and the community can make a better decision. I hope this helps!

7

Shao, thanks for the clarification that only the wallet owners can increase the unlock time.

We can all agree that wallet owners are the ones responsible in making sure _lock.end > block.timestamp. They can do so simply by clicking “increase unlock time” on the interface to extend eligibility or immediately create a new lock after the old one expires. I don’t see any issue here.

I personally am okay with keep increasing unlock time at least once a year (max time to increase is 1 year) to continue to be eligible to receive the compensation. What matters is that the Perp team/large stake holders do their best and show honest effort in trying to compensate. So do you think there is any other remaining issue from the team/large stake holders’ perspective?

8

Hi RDL, I can’t speak for the team or any large stakeholder, but as an engineer, I think this is how I can contribute to the community. I believe if the community passes an unclear proposal, it will be a governance crisis.

I take a look at how the vePERP reward works, and there is one thing it may work differently than we think, but should not be a blocker for this proposal; it just probably needs some minor modification, and perhaps we can have a better idea after fully understand how it works.

This is harder to explain but let me use referral reward as an example since it’s the only program distributing vePERP as rewards now.

  1. Contract admin call vePERPRewardDistributor.seedAllocation() to store who can get how much, and the required amount of PERP will be transferred from the caller into the vePERPRewardDistributor
  2. Users can call vePERPRewardDistributor contract claimWeek or claimWeeks if they have any reward belonging to them, then the contract will call vePERP.deposit_for that deposit PERP for this user to vePERP. However, there’s a userLockTimeCheck check that will require the claimer has a minimum lock duration. In the case of the referral reward program, it’s 4 weeks.

Back to the original proposal, Alice needs to lock any amount of PERP into vePERP for 26 weeks at least WHEN she wants to claim the reward. The rewards will never go away ( unless the contract admin withdraws, a bug or hack ).

Everything above assumes we want to reuse what we have now without rewriting another set of contracts to deliver this proposal.

Let me know if I didn’t explain it clearly.

1 Like
9

Thank you Shao, that’s way simpler! Just to double check my understanding, the referral rewards will keep accumulating weekly even if the users don’t claim right away, right? It looks like claimWeeks will do a for loop to go through all the unclaimed weeks’ rewards and distribute to the user as vePERP: Source

Similarly, for this proposal, (if I understand correctly) the bought PERP will be allocated to the vePERPRewardsDistributor monthly regardless whether Alice staked any vePERP, and it will start to accumulate. Once Alice decides to claim them, she will stake any non-zero amount of Perp and lock it for at least 26 weeks to satisfy
image
in userLockTimeCheck

Overall I think it’s a great idea! This way the distribution/lock is truly on a rolling basis. Can we implement this proposal on the existing referral rewards interface? It seems everything is in place already.

1 Like
10

Yes, referral rewards will keep accumulating weekly even if the users don’t claim immediately.

Yes, PERP will be allocated to the vePERPRewardsDistributor monthly regardless of whether Alice staked any vePERP, and it will start to accumulate to Alice’s vePERP balance once Alice decides to claim them.

Yes, this proposal can reuse the existing referral reward interface, but it will probably need some modification and separate from the referral reward to avoid confusion.

If you agree it’d be great if we could slightly modify the “Detailed Distribution Plan” based on how vePERPRewardsDistributor works.

1 Like
11

Just updated, please let me know if you see any issue or if it needs further modification. Thanks!

2 Likes
12

Sir once the decision to combine with 863 or not combine is finalized, let’s get your vote started asap - if you are ready!

I do have a couple of comments however.

  • I strongly recommend uploading a final csv of the payout recipients to IPFS using a service like https://app.pinata.cloud/ so we have an immutable version.
  • Your option 2 will result in more being paid to addresses on your list than was paid to other v1 users via the first v1 sunset vote. It is your choice, but this seems to create more problems in general. Personally I would use the same amount for all options (first sunset vote op4-op2 amount) and give different options for percentage of treasury fee income to use, e.g. Option 1 17.5%, Option 2 25% …)

Will you use the same address as last time? 0x89...39C

Please also post title, description, and vote options here so we can have everything ready to go. Previously we handled this on discord but I feel it’s more appropriate to handle everything here on the gov forum :pray:

13

@LeeKB I’ve followed your recommendation to create an IPFS version of csv as well as modifying the option 2.

Since I ran out of edit attempts on this post, I’ve posted the updated proposal to here:

Yes, I will be using the 0x89…39C address to create the vote.

Please see below for the tile…etc:
Title: Modified Perp Buyback Proposal to Support Affected v1 Users
Description:
In the previous Buyback vote, full compensation for the affected v1 users has won, however it didn’t get executed due to it not reaching the quorum. We re-posted for feedback and worked with the team to come up with the following modified version utilizing the new vePERP system for implementation: Modified Perp Buyback Proposal to Support Affected v1 Users

Vote options:

Option A: Use 17.5% monthly treasury fee income to buy back PERP over the years to cover all op4>op2 users, for their op4-op2 amount.($3.59M), pro rata to compensation amount.

Option B: Use 25% monthly treasury fee income to buy back PERP over the years to cover all op4>op2 users, for their op4-op2 amount.($3.59M), pro rata to compensation amount.

Option C: Do not compensate.

Please let me know if you see other issues. Thanks.

14

Discussion moved to Modified Perp Buyback Proposal to Support Affected v1 Users