Proposal 35 - Add Time-Lock & Launch xCVP without the security Audits

[DrGonzo]

Abstract

The team publicly shared the ready xCVP code on the 8th of March, almost two months ago. Due to the auditors’ overhead, the current estimate to receive the audits is the second half of May despite the audit subscription proposal. We all know that it could take longer.

I suggest launching xCVP before receiving security audit details to allow risk-neutral users to start using this feature, while risk-averse users can wait for audit results.

Additionally, it is worth raising a time-lock question. So far, the proposed xCVP implementation allows to immediately unstake CVP and burn xCVP. In my opinion, to better align long-term goals, time-lock could be implemented.

Motivation

The PowerPool team demonstrated its ability to develop and deploy groundbreaking tech, such as Dynamic AMM technology with automatic re-establishing weights by means of Power Agent and PowerOracle v2. It proved its ability to react to emergencies during the Cover exploit when the PowerPool team quickly acted and saved user’s funds intact quickly.

xCVP is a long-requested feature, drastically increasing CVP utility and allowing CVP holders to participate in cash flows collected by the protocol. Currently, the CVP community treasury holds around 1 million dollars in assets. It’s time to distribute it to CVP holders.

You can find the smart contract code here

Specifications

If the proposal is accepted, that would mean the following steps are performed:

1. Add timelock function to xCVP smart-contract with following specifications:

Minimum lock period: 70 days
Maximum lock period: 360 days

To incentivise Long-term stakers and prevent system abuse, while allowing stakers access to capital in a case of emergency:

Set MAX long-term staking rewards multiplier: 300% (Linearly Increasing).

Set MAX super-early withdrawal penalty (before 70 days): 100% of all earned rewards. (Linearly Decreasing).

Set MAX early withdrawal penalty (Before set time-lock): 100% of bonus rewards.

*Penalized rewards are deposited back into the community treasury.

This will allow long-term stakers and supporters to enjoy higher rewards, while preventing users from choosing the longest time-lock and withdrawing early to game the system.

2. Deploy xCVP contract

3. Place a disclaimer on top of every page consisting of information regarding xCVP, that the code has not passed the external security audit yet, but will pass ASAP (May as an estimation)

4. Place a link to GitHub repository with xCVP code on top of every page consisting of information regarding xCVP near the disclaimer

5. Get audit results and proceed with insurance and adding xCVP to other DeFi platforms.

Non-binding poll to understand the sentiment

• Add Time-Lock & Deploy xCVP
• Add Time-Lock & Wait for security audits
• Against Time-Lock

[bscgemshunter]

sounds like a good idea to me, I’d personally put my money into an UNaudited code, as I expect bigger rewards

[Glow]

I am definitely agains time-lock integration to xCVP proposal. The main benefit of cryptocurrency is the free flow of capital and if you gonna prevent stakers from moving their capital just to artificially increase usability and price of CVP, we are going to loose in the end because our protocol will be less atractive for investors than other similar projects.

[DrGonzo]

The time lock design will allow stakers to withdraw capital anytime, while rewarding long-term stakers and decreasing attack angles.

I think by now pretty much every protocol has a similar system in place.

[Glow]

How does it allow stakers to withdraw capital anytime when there is high penalty for early withdrawals? Please do not spoil the xCVP upgrade! I am not aware of the fact that time-lock feature was discussed in the draft proposal…

[curmudgeon]

I think it’s best practice to wait for the audit. Most of the time those are routine, but if they would have caught something that’s missed, then PowerPool team and CVP as a franchise value would suffer harm that you can’t recover from.

Moreover, I view deploying unaudited code on real money beyond small test amounts as at least a yellow flag if not a red flag on a project. I’m sure I’m not the only one. The disclaimer that the project has passed public security audits “but not the contract on our own token” - it’s really just not a good look.

Short term loss of value by delaying to preserve the longer term viability seems like a sensible trade-off. If you want to try to make up the economics for the delay, increase the rewards for the first x days or for people who stake on day one and it’ll be close enough.

[DrGonzo]

Thanks for sharing your view You are raising very valid points.

@Glow

I am not aware of the fact that time-lock feature was discussed in the draft proposal…

There is no Time-lock feature in the current smart-contract design and it hasn’t been discussed yet

[richard]

I’m desperate for xCVP as much as the next person, but I’m against this proposal because I’m against deploying un-audited code. Seems like a can of worms we should avoid.

[richard]

On the other hand, I support the time-lock. Could we have 2 separate polls so as not to muddy the vote?

These are the 4 possible options (in fact one of them isn’t represented in the original options in the proposal):

1. Support time-lock, Deploy before audit
2. Against time-lock, Deploy before audit
3. Support time-lock, Wait for audit
4. Against time-lock, Wait for audit

Imagine the votes were:

1. 35%
2. 5%
3. 30%
4. 30%

Naively, option 1 wins the vote, but actually 60% (options 3 + 4) prefer waiting for the audit. Presumably we would require a majority (50%+) to actually enact anything, but still, you can see how including 2 orthogonal options muddies the waters. Here we can see a majority of people both support time-lock (1 + 3), and waiting for the audit (3 + 4) but we would do nothing, given that we require a majority.

Instead with two independent proposals the votes would be:
1A. Support time-lock (65% - 1&3)
2A. Against time-lock (35% - 2&4)

1B. Deploy before audit (40% - 1&2)
2B. Wait for audit (60% - 3&4)

[DrGonzo]

Thanks for the feedback! It’s just a sentiment poll to understand the right format for the actual proposal

[AlexMC]

Deploy non-audited - In favor
It’s opt-in and clearly stated, every day we wait translates into opportunity loss, the TVL almost hasn’t moved for a long time and in the middle of a bull run CVP is staled, risking losing all of the market momenta is worse than the possibility of an exploit. Adding to this, if I understand correctly, we are on the verge of a supply increase in CVP if we allow for this to happen before xCVP release we will be in deep trouble.

Time lock - in favor
I think people are misreading the proposal, you will never lose the deposited xCVP if you withdraw early, only the potential rewards.

[bgelb0]

1. The time lock and non-audit issues seem orthogonal. I think they should be considered as two separate proposals.

2. Launching w/o audit seems to force CVP holders to choose between taking the risk associated with an unaudited contract, or potentially ceding their share of the cashflows to other users who take said risk. That seems like an unfair proposition, given that the norm/expectations is that all contracts are going to go through an audit. Audits are either important, or they aren’t, but its important to be consistent. Switching it up when it suits doesn’t seem like the right way to operate. Also if the point is to incentivize long term holding, whats the rush anyway?

3. I’m not really a big fan of the time-lock feature either. The intent is to distribute the collected fees to CVP holders. That in itself should be the incentive to hold CVP. It seems a bit onerous to add a lockup requirement.

[bgelb0]

Here’s what I wrote in the discord:

doesn’t deploying xCVP early mean that people who stake early (taking the risk due to no audit) get a disproportionate share of the collected fees in the treasury?

[ 10:44 AM ]

doesn’t really seem fair to ask people to make that choiec

[ 10:45 AM ]

i think as a project you have to do the audits, or not, but should be consistent

[ 10:46 AM ]

seems wrong to tell people community fees will be distributed to holders and then at the last minute decide to give a larger share to people who will agree to use unaudited code

[Jomari]

The proper alignment of incentives is important to any system. Time-locks explicitly create a medium for aligning the incentives of holders with the protocol. Their ability to redeem in the future is dependent on their contributions to a vibrant and sustainable product.

There is clearly a significant movement in the space in this direction and it would be foolish to ignore. Crv and Pickle have already implemented systems like this. Andre Cronje has suggested it for Sushi and Snowball on Avalanche is also planning to implement. I believe Frax is also launching a timelocked version of their governance token.