The veToken Standard

A set of standards for Curve DAO's secondary governance framework.

This research was spearheaded by @evmknows and @chonkypandu.

Useful Links

1. Asset Risk Assessment: Liquid Lockers & veSDT

2. StakeDAO docs

3. yCRV documentation

4. Convex Finance documentation

5. Quorum rules and shareholder voting

6. The impact of exposure to pre-election polls on voting behaviour

7. Bandwagon Effect

8. The Bandwagon Effect in an Online Voting Experiment With Real Political Organizations

9. Snapshot Shielded Voting

Definitions

1. Primary governance frameworks are a set of smart contracts implemented directly on top of the veCRV contract: 0x5f3b5DfEb7B28CDbD7FAba78963EE202a494e2A2. In such cases, Curve DAO whitelists smart contracts to lock CRV and mint veCRV (henceforth termed VoterProxy contracts). The locking of CRV into veCRV may or may not involve:

   1. a liquid veCRV derivative token (such as sdCRV) with or without governance power, minted (usually) 1:1 per CRV

   2. A secondary governance token (such as veSDT). The token may or may not be locked to gain additional power of veCRV in the VoterProxy.

2. Secondary lock mechanisms are systems where a token other than the veCRV derivative is locked for the veCRV derivative to obtain (any or more) voting rights. An example of a secondary lock mechanism is veSDT

3. Governance Power is quantified as the amount of veCRV per (locked or free) secondary governance token (such as veSDT or vlCVX) or liquid derivative token.

4. Secondary governance frameworks are governance frameworks implemented on top of primary veCRV governance frameworks. Example: Pirex's pxCVX, which is implemented on top of vlCVX.

5. Recurring locking is a token governance mechanism where the veCRV derivative's governance voting power is set to 0 at the end of the locking epoch (e.g. vlCVX). There may be a decay component in the governance framework where one's voting power decays closer to token unlock.

6. Non-recurring locking is a token governance mechanism with a minimum lock duration. As voting power is preserved beyond minimum duration, users may unlock their underlying governance token at any point. The voting power before the minimum locking duration may be determined by mechanisms such as TWAVP (e.g. sdCRV).

7. TWAVP, or Time-weighted average voting power, is a mechanism where a user's governance weight (or the voting power) increases corresponding to their token lock duration.

Abstract

This document proposes a technical and governance standard for Curve DAO's primary and secondary veCRV derivatives.

Disclaimer:

The recommendations proposed in this document are a product of analyzing existing veCRV derivatives. Under no circumstances shall these recommendations be considered as rules, requirements, or requests set by the Crypto Risks Team but rather as recommendations for Curve and associated DAOs. Crypto Risks Team intends to use these specifications as a reference for analyzing existing and future veCRV derivatives.

Specifications

Baseline Requirements

• Audits - Smart contracts in the proposed governance framework must be reviewed by auditors and DAO members familiar with the technical implementation of the Curve DAO governance framework.

• Ownership - 

  • Externally owned accounts (EOAs) - An EOA must not own the VoterProxy.

  • Multi-signature wallet (multisigs) - In cases where multisig wallets control the VoterProx: 

    • A majority of its signers must not be a part of the project. 

    • The multi-sig should be composed of trusted members from the community, such as DAO contributors with a track record displaying their technical and governance competence and no known history of governance collusion.

    • Alternatively, DAOs under the VoterProxy governance framework maybe use technologies like Tally SafeGuard to veto multi-sig actions.

  • Smart Contracts - In cases where a smart contract owns the VoterProxy, its ownership (if any) must follow the same rules as above (no EOAs, and trustable multisigs only).

• No infinite mints - The owner of the VoterProxy must not have the ability to infinitely mint the derivative(s) of veCRV.

• No custody - All staking contracts must be non-custodial: it should not be possible for the owners of the contracts to withdraw users' funds.

• No upgradability - Except for the multi-sig wallet, all contracts related to the specifications above should be non-upgradable (e.g. via a proxy upgrade pattern, where one can easily change its implementation contract).

Voting Power and Governance Scope

The following details dictate voting power and governance scope:

1. Liquid derivative veCRV voting power.

2. Secondary governance token voting power.

3. Secondary governance token lock type: recurring or non-recurring.

4. Lock duration.

5. Scope of governance. The veCRV derivative governance framework may or may not participate in either, or few, or all of the following governance proposals:

   1. Gauge weight votes.

   2. Ownership proposals.

   3. Parameter proposals.

6. Liquid derivative lock type: recurring or non-recurring.

The framework mentioned above derives its inspiration from existing veCRV derivative governance structures. Based on this, there are three veCRV governance classifications:

Note: Any changes to the rights or lock duration of veCRV derivatives bearing full governance rights should be a governance matter of the Curve DAO.

Type A (example: vlCVX)

1. The liquid derivative token has no governance power.

2. There is no secondary token.

3. Secondary token lock type: none

4. Minimum locking duration: 16 weeks + N days, where N is the number of days to the closest upcoming Thursday. 

5. Governance Scope: 

   1. Gauge weight votes: yes. 

   2. Ownership proposals: yes.

   3. Parameter proposals: yes.

6. Liquid derivative lock type: Recurring Lock. Governance weight goes to zero at the end of the epoch.

Type B (example: yCRV)

1. The liquid derivative token has partial governance power.

2. There is no secondary governance token.

3. Secondary token lock type: none

4. Locking Duration:

   1. A minimum 14/21-day lock, or

   2. A minimum 30-day lock TWAVP. The maximum governance at the end of the minimum locking period is capped at 0.4 veCRV per derivative token.

5. Governance Scope: 

   1. Gauge weight votes: yes. 

   2. Ownership proposals: no.

   3. Parameter proposals: no.

6. Liquid derivative lock type: non-recurring lock. Governance power does not go to zero at the end of the minimum locking duration.

Type C (example: sdCRV & veSDT)

1. The liquid derivative token has full governance power.

2. There is a secondary token that boosts governance power.

3. Secondary token lock type: Recurring Lock. Governance weight goes to 0.4 at the end of the epoch.

4. Locking Duration:

   1. A minimum 14/21-day lock, or

   2. A minimum 30-day lock TWAVP. The maximum governance at the end of the minimum locking period is capped at 0.4 veCRV per derivative token.

5. Governance scope:

   1. Gauge weight votes: yes. 

   2. Ownership proposals: yes.

   3. Parameter proposals: yes.

6. Liquid derivative lock type: non-recurring lock. Governance power does not go to zero at the end of the minimum locking duration.

Governance

Decentralization & censorship resistance

Off-chain governance is a centralization vector that may attract potential legal or regulatory oversight for the maintainers / multi-sig signers (if doxxed) and open up censorship vectors. The protocol maintaining derivative governance frameworks should hence implement (or pursue the implementation of) on-chain governance. 

It is recommended (optional, since it can be dealt with ad-hoc or ex-ante) that, in the event of legal or regulatory pressure, aggressive DNS or hosting censorship, the maintainers of primary and secondary governance protocols have an actionable plan for continuous operation. 

Quorum

Ideally, governance frameworks should implement fractional voting. In the absence of fractional voting, the quorum shall be set to:

1. Largest known token holder controlling over >2% of the supply (e.g. other DAOs or teams) plus 5% of all tokens that are eligible for voting, or

2. 5% of all tokens that are eligible for voting, or

3. The greater of 1 and 2.

With this quorum benchmark, the forming of voting coalitions is incentivized. These coalitions can act as an effective counterweight to the dominant tokenholder/s. Furthermore, this would increase representativeness and ensure that the dominant token holders cannot pass a vote by themselves. (Charléty et al., 2019)

Delegation

It is recommended that governance frameworks have a voting delegation feature with a dual delegation system:

1. Gauge-weight delegation system: the delegate may only vote for gauge weights and not Curve DAO Ownership and Parameter votes. Such a delegation system prevents the misuse of delegated voting power utilized for automated yield farming.

2. Ownership and Parameter delegation system: the delegate may only vote for Curve DAO Ownership and Parameter proposals.

Blacklist

Only Curve DAO should hold power to decide whether or not an entity holding a veCRV derivative (bearing full governance rights) is to be excluded from voting.

Whitelist (optional)

To ensure that the veCRV lock mechanism is not bypassed by projects built upon Curve, it was necessary to establish a contract whitelist. To preserve this security feature, first-degree veCRV derivatives (e.g. vlCVX) may inherit the responsibility of the Curve DAO to whitelist second-degree derivatives (e.g. Pirex CVX).

Limit to stacked liquid derivatives (optional)

A limit on the number of governance frameworks may be imposed to future-proof against the exponentially growing complexity and excessive codependency of Curve and its legos. A limit of a maximum of two derivatives stacked upon veCRV is recommended.

Secret ballot 

Since psychological effects during votes (e.g. Bandwagon Effect) can result in a non-insignificant influence on the outcome of a vote (Gasperoni & Mantovani, 2015; Farjam, 2020), it is recommended that preliminary vote results are not visible to DAO participants.

One way to make this possible at present is the “Shielded Voting” feature developed by Snapshot. In the future, it is expected that this will also be available as an on-chain solution on some L2s.

Summary & Outlook

In summary, the current veCRV derivative protocols (Convex, StakeDAO, and Yearn) are consistent with the standards and future developments recommended above. Furthermore, the recommendations in this report could be subject to possible changes or additions which may become relevant in the future, e.g. the topic of account abstraction in Ethereum, which (depending on its implementation) could impact the effectiveness of the veCRV whitelist. With this in mind, we would be pleased to receive any suggestions for changes and would welcome any dialogues on how to address potential future problems.