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

Updated: 2022-08-13

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.

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:
If Option A~B passes, the following plan will be executed step-by-step:

Step 1. The affected users will have to first stake any non-zero amount of PERP in the new vePERP system and choose a lock period of at least 6 months ((unlock date - create_lock date) >= 26 weeks).) in order to be eligible to receive vePERP compensation.

Step 2. In the beginning of each month, certain % (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 3. Distribute the PERP to the eligible affected users’ accounts using the _deposit_for function. If deposit_for() is reverted due to the user’s 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 (Source code). Users who are not eligible to receive compensation at the time of the distribution will be considered forfeiting that month’s PERP payout. The amount owed to them in USDC will still get lowered for that month regardless whether they are eligible to receive the PERP or not at the time. The eligibility can be verified by the unix timestamp from the wallet’s public on-chain record ((unlock date - create_lock date) >= 26 weeks).

Step 4. The unclaimed PERP will be either burned to a dead wallet with no private key or being redistribute to the eligible affected users to speed up their pay offs. The determination is up to the DAO treasury multisig.

Step 5. Repeat step 2-4 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: At the end of the locking period, the affected users will have to re-lock any amount of PERP into vePERP for at least another 6 months ((unlock date - create_lock date) >= 26 weeks) in order to be eligible to continue receive the monthly distribution. The affected users are responsible in picking the right locking periods with some buffer to avoid the locking period ends on the same week as the vePERP distribution to avoid not being able to receive the compensation

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!

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

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.

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

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

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!

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?