Proposal to add sdTokens tokens pools to the gauge controller

Hey 0xLeibniz
Pretty easy to avoid flashloan governance attacks: just need to take a snapshot date which is in the past compared to the transaction pushed on snapshot. This is already what we do: the snapshot block is the same as on Curve so that people can’t have double vote and can’t use MEV to flashloan attack the governance.

8 Likes

The opposition to this proposal seems very tribal and somewhat blinded to the increased demand this will bring to Curve.
I shall be supporting this proposal

13 Likes

sounds like a logical further step to further decentralized VeCRV

have yet to see a good argument against this proposal, just noise

voting in favor of this proposal

6 Likes

StakeDAO aims to make governance on CRV fully liquid. It would open Curve up to more short term stakeholders. I’m sorry, but that’s a terrible idea. Why not put in a lock for governance votes?

I’m voting no.

4 Likes

We can put a lock for governance votes, but this is a proposal for the gauge, let’s not mix things up. We want to make things as protocol friendly as possible, the idea is really to help Curve here. Currently, CRV gets dumped massively because of this whitelist issue that was already flagged by the team.

7 Likes

I don’t get the arguments against the proposal:

  • the risk for flash loans attacks is mitigated by snapshots + it would work exactly the same for someone buying CVX.
  • “it would fracture liquidity away from the Convex Platform’s cvxCRV + fxsFXS liquidity tokens” is exactly why this proposal is interesting: it brings competition to Convex: any monopolistic situation should be avoided.
  • “StakeDAO aims to make governance on CRV fully liquid”: it’s a locker, so any CRV deposited there is locked forever, so it’s exactly like CVXCRV / CRV. Even if in a second time the sdCRV / CRV trade is made possible, the overall number of CRV locked should increase, which benefits Curve.
15 Likes

I am totally for this proposal !

I think that @Hatashi and @picodes have responded very well (I invite you to read their messages twice! :smiley: ), so I have nothing else to add and like @Dydymoon said: “The liquid lockers are a very interesting feature for every veToken holders”.

9 Likes

Can everyone just stop the team X vs Y stuff?
It’s not needed here and not helping the conversation.

The main problem people are seeing is that there seems to be 0 lock time on these curve governance controlling tokens. So it’s taking a 4 year lock up and reducing it to 0 (or a few days if you want to participate in a proposal).

For reference Convex is 4 months, which is a lot shorter than 4 years. Mich from curve actually gave me a hard time for this because it’s so much shorter. Some of this was alleviated because we can veto an obvious attack. But even then 4 months was/is considered short.

Thus all that needs to be done here is add a timelock in some manner. there can be different ways to go about it. The simplest of course just a timelock on withdraw once you stake etc.

I dont think most people would have much of a problem after that.

So it’s simple really. Just put a time lock on the staked tokens. end of story.

20 Likes

Seems like a good way forward

4 Likes

sdCRV (sdFXS, sdAngle) holder need to lock SDT (veSDT) token for up 4 years to use full potential of LL tokens voting power. The max benefit will have sdCRV+veSDT (4 years lock) owners. This already implemented. IMO this a protection layer like 16 weeks lock in vlCVX case

6 Likes

Very interesting, what do you think of the fact that the rewards generated by CVX are in CRV, and thus a selling pressure on CRV → less valued rewards → less valued on CVX, and thus may let us think that CRV need a buy pressure regarding the interest of CVX (so veCRV not strictly stripped away and abstracted into CVX) ?
Curve community needs to think of those financial dyanmics cause i agree they may be a risk of centralization, questionning the interest of the 50% - epsillon CRV token when a DAO on top of CRV hold the 50 + epsillon )…

5 Likes

could you develop it more please ?

2 Likes

As the proposal stands, this would place CRV at risk for a governance attack.
A time lock is necessary to prevent a $BEAN style flash loan attack where someone buys a lot of curve, votes then dumps.

3 Likes

Hey C2tP, thanks for your feedback, that’s the sort of constructive feedback we are looking for in this kind of governance discussions. Would you support such proposal if we were to put together a locking mechanism such as some kind of vlsdCRV?

7 Likes

Also, what do you think of having a veto right from veSDT (which needs 4Y lock) able to decide that a vote seen as malicious should not be taken into account?

8 Likes

The mooting of veto abilities for those locked for 4yrs could be explored further to include different voting rights depending on your veSDT lock period, distinctly different to power of your vote. @Tube

3 Likes

a lot of merit in all the arguments above;
but let’s be honest about the current Curve governance landscape — there’s > 50% voting power held by one project! a proposal with competent mechanism design that helps correct for this is welcome to me

10 Likes

The basic idea we all want to avoid is some bad actor getting it in their head that it might be feasible to quickly acquire a large governance stake, pass a malicious vote, and be able to exit. There’s a number of protections that make this very difficult to pull off already, but since this concept is new to Curve, everyone I think will feel better if we’re all very sure this can’t happen.

veSDT is long term locked, and therefore the judgement of those stakeholders is trustworthy. If they are able to oversee the actions taken by sdCRV governance by vetoing a malicious vote, I would consider that a good compromise of giving sdCRV direct governance access while protecting the protocol by locked stakeholders.

I don’t know that it’s necessary to impose a timelock on sdCRV except maybe a short snapshot delay before governance power is active to prevent some kind of flashloan attempt.

11 Likes

Current veSDT governance in theory able vote to not execute malicious sdCRV voting. veSDT just need to approve time gap between sdCRV voting end and execution. This time gap (36-48 hours) should be enough to use emergency scheme veSDT voting if emergency case happened. Also veSDT holders can delegate to StakeDAO core team members in advance emergency rights to not execute malicious sdCRV voting in case of attack.

5 Likes

FOR - creating rebalance under Curve and among “liquid veToken makers” will drive to continuous and optimal progress pace

2 Likes