DeGo in DeFi
Governance is defined as “the act or process of governing or overseeing the control and direction of something (such as a country or an organisation).” In the context of blockchains, this typically means steering current manifestations and future changes to the underlying protocols.
Blockchain governance has always been a hot and contentious topic both across different blockchains and within each blockchain community. The fundamental dichotomy is on-chain versus off-chain governance i.e. on-chain governance is algorithmically baked into the blockchain’s protocols itself unlike off-chain governance where it is conducted informally outside the blockchain protocols. Tezos is an example of the former whereas Bitcoin and Ethereum fall in the latter category. However, this article is not about blockchain governance. There are opinion pieces on that topic from Vlad Zamfir (1, 2, 3), Fred Ehrsam and Vitalik Buterin, among others.
This article is about technical processes behind Decentralised Governance (DeGo) in Decentralised Finance (DeFi) protocols on Ethereum. We begin by highlighting the broad landscape of leading DeFi protocols on Ethereum and summarise key aspects of some of their current governance processes. We motivate the rationale for gasless voting in this context and describe the technology behind Snapshot which is spearheading adoption in this space. We discuss decentralisation challenges with Snapshot’s current implementation and how those may potentially be addressed using Aragon’s off-chain voting with on-chain execution and our idea of Snapshot over Waku for increasing censorship-resistance of protocol communication.
DeFi is the ecosystem of financial applications being built on decentralised blockchain protocols. This includes instruments such as savings, trading, loans (lending/borrowing), derivatives and insurance. DeFi is differentiated from traditional finance by the following three key factors: (1) Smart contracts codify the rules and execute operations with minimal/no human intervention (2) Transparency in the form of open-source auditable smart contracts and transactions on the blockchain (3) Permissionless participation in creating products, using them, modifying them or composing them.
Maker is the DeFi project behind the popular stablecoin Dai. Compound and Aave are popular DeFi lending platforms. Uniswap, Curve and Balancer are popular decentralised exchanges for tokens. Synthetix is a DeFi project for creation of synthetic assets that track the value of real-world assets. Yearn is a suite of DeFi products that includes lending aggregation, yield generation and insurance. Nexus Mutual is an alternative community-based insurance platform that lets members cover risk on smart contract vulnerabilities. Aragon is a platform for launching and managing Decentralised Autonomous Organisations (DAOs), which powers some of the above-mentioned projects such as Aave and Curve.
Such DeFi projects have governance mechanisms to collectively decide on project operational aspects and proposed protocol changes. Only holders of project-specific governance tokens are allowed to vote in these governance processes. The tokens for the above listed ten DeFi projects are MKR, COMP, AAVE, UNI, CRV, BAL, SNX, YFI, NXM and ANT respectively.
Maker Governance: “MKR holders are responsible for governing the Maker Protocol, which includes adjusting policy for the Dai stablecoin, choosing new collateral types, and improving governance itself.”
Community discussions happen in a Discourse forum. Voting requires Maker (MKR) tokens and takes place on their dedicated Governance Portal.
Executive Votes are used to make technical changes to the protocol such as modifying collateral/vault types, parameters and smart contracts. Governance Polls are conducted typically before Executive Votes to get a rough estimate of voter sentiment. Both these happen on-chain. MKR of voters is locked in the voting contract and voting is weighted by the amount of MKR voting for a proposal.
There is an explicit albeit informal off-chain governance mechanism where the Discourse forum is used for Signal Threads and Informal Polls to signal particular positions on relevant topics and assess community sentiment on such positions off-chain before deciding to move it on-chain. Neither of these require participants to hold MKR tokens or interact with the Ethereum blockchain.
The transition from off-chain Signal Thread to on-chain Governance Poll happens when the thread creator determines that there is sufficient informal community support for the signalled topic and requests one of the elected Governance Facilitators to create a corresponding on-chain Governance Poll.
Compound Governance: “The Compound protocol is governed and upgraded by COMP token-holders, using three distinct components; the COMP token, governance module (Governor Alpha), and Timelock. Together, these contracts allow the community to propose, vote, and implement changes through the administrative functions of a cToken or the Comptroller. Proposals can include changes like adjusting an interest rate model, to adding support for a new asset. Any address with more than 100,000 COMP delegated to it may propose governance actions, which are executable code. When a proposal is created, the community can submit their votes during a 3 day voting period. If a majority, and at least 400,000 votes are cast for the proposal, it is queued in the Timelock, and can be implemented after 2 days.”
Although Compound initially began as a tokenless protocol when their team had administrative privileges over protocol changes, they introduced the COMP governance token this February to transition to decentralised token-holder community governance.
Community discussions happen in a Discourse forum. Voting requires COMP tokens and takes place on their dedicated Governance Portal.
Compound explicitly supports gasless voting and delegation using EIP-712 signatures. This allows a voter or delegate to sign their vote messages off-chain and then have a trusted third-party spend ETH on gas fees to publish transactions containing their votes on-chain for them.
Aave Governance: “The Protocol Governance consists of the decision-making process for the different risk parameter changes, improvements and incentives that constitute the Policies. Future decisions governing the protocol will be enacted through this procedure. The AAVE token empowers holders with the capability to vote on proposals and collectively act as governors of the protocol.”
Aave implements a four-phase governance process: 1) Ideation where community members can initiate a proposal discussion on the Discourse forum and submits viable proposals to the next phase 2) Discussion and Signal Collection where there is further discussion and then evaluation of the community signal on the proposal 3) Approval where the Genesis team will implement/deploy the required smart contracts and submit the proposal/implementation for a AAVE token-holder vote 4) Implementation or Rejection where the proposal is deployed or rejected based on the vote.
Aave governance was released on Ethereum mainnet in September. The first proposal was to migrate from the older LEND token to the new AAVE token for which signalling was conducted off-chain on the Snapshot platform (which we introduce later in this article). The protocol admin keys were handed over to the governance contract in October thus transferring ownership to the token-holder community.
Uniswap Governance: “Uniswap protocol is governed and upgraded by UNI token holders, using three distinct components; the UNI token, governance module, and Timelock. Together, these contracts allow the community to propose, vote, and implement changes to the uniswap protocol. Any addresses with more than 10M UNI delegated to it may propose governance actions, which contain finished, executable code. When a proposal is created, the community can cast their votes during a 3 day voting period. If a majority, and at least 4M votes are cast for the proposal, it is queued in the Timelock, and may be executed in a minimum of 2 days.”
Uniswap implements a three-phase governance process: 1) Temperature Check where community members initiate a proposal discussion on the Discourse forum and then evaluate the signal on the broad proposal from a voting process on Uniswap’s Snapshot space. The potential proposal is considered as having sufficient support for the next phase if at the end of the 3 days, it has a majority vote with a 25k UNI yes-vote threshold. 2) Consensus Check where a formal discussion around the potential proposal happens on the Discourse forum followed by another Snapshot signal polling on specific options (which includes a make-no-change option). A specific option of the potential proposal is considered as having sufficient support for the next phase if at the end of the 5 days, it has a majority vote with a 50k UNI yes-vote threshold. 3) Governance Proposal, where the winning option from the previous phase is codified, audited, proposed (requires 1% of all UNI i.e. 10M UNI) on-chain and then submitted for an on-chain vote on the governance portal. After a seven-day voting period, a passing (requires 4% of all UNI i.e. 40M UNI) proposal’s code is executed after a two-day timelock.
Uniswap supports EIP-712 based offline signatures. It also supports “soft governance” via community discussions for policy-related, meta-governance or off-chain aspects which do not require on-chain voting.
Curve Governance: “The Curve DAO officially launched on August 13th 2020. The DAO will allow liquidity providers to take decisions on adding new pools, changing pool parameters, adding CRV incentives and many other aspects of the Curve protocol. The main purposes of the Curve DAO token are to incentivise liquidity providers on the Curve Finance platform as well as getting as many users involved as possible in the governance of the protocol. Currently CRV has three main uses: voting, staking and boosting. Those three things will require you to vote lock your CRV and acquire veCRV.”
CRV is a utility and governance token on the Curve platform with time-weighted voting and value accrual mechanisms. CRV holders can lock their CRV into the Curve DAO to receive veCRV (voting escrow CRV) tokens required for voting. Longer locking gives more voting power with the minimum locking time being one week and the maximum being four years. The weight of veCRV gradually decreases as they approach their lock expiry.
Informal proposals may be created on the governance forum and signalling evaluated on the Snapshot space. Official proposals are required on the DAO to make binding changes to the Curve protocol and they come in two types: Parameter and Text. Parameter proposals are automatically committed to the DAO three days after a successful vote while Text proposals typically require development from and engagement of the Curve team. Creating a new DAO proposal needs at least 2500 veCRV.
Summary: Governance processes typically involve a combination of three technologies: 1) Discussion forums (e.g. Discourse) where community members informally propose and discuss proposals 2) Signalling forums (e.g. Snapshot) where token-holding community members vote off-chain to indicate their preferences on proposals 3) Voting forums where token-holding community members vote on-chain to formally approve/deny proposal execution.
Discussion forums such as Discourse, Discord, Gitter, Telegram or Slack are existing non-blockchain-specific messaging platforms used by communities across different domains. Voting forums are standard ÐApps that require users to link their crypto wallets (for accessing their governance tokens) and interface with smart contracts on the blockchain. What’s specific and new to the DeFi governance process is the technology behind Signalling forums — specifically Snapshot.
Snapshot is described as: “an off-chain gasless multi-governance client with easy to verify and hard to contest results.” It is an open-source project, driven by Fabien Marino from Balancer Labs, that allows token-based projects to host spaces where they can post proposals for token-holders to vote off-chain without requiring a blockchain transaction i.e. no need to pay gas/transaction fees. Proposals and votes are signed messages stored on IPFS.
Motivation: Ethereum gas prices have hit all-time highs this year and much of that is attributed to DeFi applications. While whales or top token-holders may not be very concerned about rising gas fees, this likely has a tangible impact on the long-tail of small token-holders who may abstain from DeFi governance processes conducted on the blockchain, especially if both token-based signalling and voting happen on it. This limited participation arguably reduces the political decentralisation of the protocol.
While the critical voting phase may necessarily require the decentralisation and censorship-resistant guarantees of a public blockchain like Ethereum today, the relatively less critical, but important nevertheless, prior phase of signalling may be conducted off-chain to allow gasless participation. Snapshot aims to fulfil this need for now.
Besides the ones mentioned earlier, other leading DeFi projects using Snapshot include Yam, Yearn, Balancer, Sushi, Swerve, Pickle, Aragon, mStable and Cream among others. Maker and Compound also appear to be considering the use of Snapshot for signalling.
Architecture: Snapshot has a web client connected to a hub server. The web interface displays spaces for different projects. Space is an individual project’s place for listing proposals for token-based vote signalling. Spaces are created on the web interface using an ENS domain.
Proposals are created on a space by connecting with a wallet (which has that particular project’s tokens), creating a message that has the proposal details: title, proposal text, voting options, start/end times and block number for token holding consideration, and submitting a signed message (currently personal_sign with plans to transition to EIP-712) from the wallet.
Voting on a proposal requires going to the particular project's space, connecting with a wallet (that has that particular project’s tokens), choosing the desired voting option and submitting a signed message from the wallet.
The signed messages of proposals and votes are sent to the Snapshot hub which in turn uploads them to IPFS for decentralised storage. Furthermore, the hub stores an index of IPFS hashes for all proposals and their votes in a database for faster loading of client requests.
Strategies are used to calculate the voting outcome for a proposal. A strategy is a JavaScript function in the web interface that returns a score for a set of addresses. The default strategy is to calculate the balance of that proposal project’s ERC20 token at the specified block number for the voters on that proposal. Performing these calculations off-chain provides more flexibility to experiment with different governance models because it’s faster to iterate with JavaScript strategies than with on-chain smart contracts.
Off-chain signalling is becoming a precursor to on-chain voting in DeFi governance processes. On-chain voting is more trustless and decentralised but it’s also expensive and slow. Signalling is effectively off-chain voting that is free (gasless) and fast. However, the tradeoffs are reduced decentralisation and increased potential for censorship due to off-chain intermediaries.
If these challenges can be sufficiently addressed, we could significantly benefit from free, fast and increased (higher quorum because of lower friction) off-chain voting without compromising the decentralisation guarantees of on-chain execution. Let’s evaluate this in the case of Snapshot.
Currently with Snapshot, if signalled proposals and votes have to be translated into binding on-chain governance changes they would depend on two intermediaries:
1. Trusted Multisigs: Recall that multi-signature wallets (on Ethereum) are smart contract wallet accounts which enforce that a minimum number of signatures (m-of-n) are required to execute wallet transactions. Trusted multisigs, in the context of DeFi projects, are a set of well-respected members of the community who are entrusted with executing the decision of the project’s token-holding community (as indicated by votes) by signing on-chain governance-related transactions corresponding to the winning votes of proposals. These could be project treasury-related transactions or protocol changes.
Trusted multisig is a centralisation risk from a socio-technical perspective. While it is unlikely that multisig holders will risk their social capital to deviate from a community's decisions, it’s theoretically possible that they may override and abuse their power. The probability that m-of-n will collude is low (if m is sufficiently large, e.g. 6-of-9) but is non-zero. In contrast, depending on the size of a project’s community and the distribution of the tokens amongst them, it would require at least an order of magnitude (e.g. 100’s) more token holders to collude towards a proposal outcome.
This dilution of decentralisation may be prevented if we could somehow transfer the actions approved by off-chain votes on to the chain in a trustless manner.
2. Centralised Hub: Snapshot hub is a server used by its web interface to store and retrieve IPFS hashes of signed messages corresponding to proposals and votes. This clearly is a centralisation risk. While this may be mitigated, for example, by running a consortium of servers administered by participating projects, the client-server paradigm inherently has decreased decentralisation and increased censorship potential compared to peer-to-peer (p2p) networks.
This may be addressed by either replacing the hub by a p2p network or removing it entirely by somehow storing/retrieving the proposals and votes directly to/from IPFS. The latter option has been considered possible by linking related IPFS hashes together but the sequential nature of retrieval may make it slow and impractical.
We next discuss potential solutions to address the above two challenges.
Aragon is a leading provider of DAO-related governance products and services infrastructure. This October, Aragon and Balancer Labs announced a collaborative effort to combine Snapshot’s off-chain voting with Aragon DAO’s on-chain optimistic execution capabilities.
Optimistic execution is an on-chain capability that accepts (without verification by on-chain computation) a submitted execution outcome as being correct along with a bonding collateral. If no one challenges the result within a dispute window, it is thereafter considered as binding and final. If someone challenges the result within the dispute window, the execution is performed/verified on-chain and the offending entities, if any, are penalised. (Note that this is conceptually similar to the concept of optimistic rollups.)
In the Optimistic Snapshot proposal, a trusted multisig is replaced by a DAO of project’s token holders. After a Snapshot vote concludes, anyone can submit the vote-approved actions to the on-chain DAO. The DAO imposes a timelock period for disputes before the actions can be executed by an Aragon Agent. Disputes are handled by Aragon Court.
While DeFi protocols evaluate this proposal, it will be interesting to see how it evolves.
Status App combines a privacy-centric messenger with an Ethereum wallet and ÐApp browser. The messenger is powered by a decentralised p2p network which aims for removal of centralised rent-seeking intermediaries, removal of single points of failure and increased resistance to censorship. Messages don’t have only two hops — from the source client to the server and then to the destination client — as is the case in client-server architectures but instead they hop across multiple peers and continue hopping even after reaching their intended recipient because peers do not know who is the intended recipient.
The transport privacy layer of the messenger protocol stack which provides routing, metadata protection, topic-based multicasting and encryption algorithms is implemented by Waku, which is a successor to Whisper. Waku uses the concept of topics to partition its messages where topics are strings derived using specified algorithms and used in “envelopes” which encapsulate encrypted messages along with this topic and time-to-live (TTL).
Waku v2 is evolving to be a generalised messaging layer that any project (besides Status) can adopt for a robust, scalable, privacy-centric and user-incentivised p2p routing protocol. One of the original goals of the Whisper protocol was to facilitate machine-to-machine (M2M) communication in the Ethereum ecosystem among wallets, ÐApps, state channels etc. that would enable multisig transactions, DAO voting, notifications and other related communication to happen off-chain with minimal on-chain interaction. Waku is aiming to deliver this M2M layer.
With Waku, Snapshot hub may be replaced by a p2p network of incentivised nodes across which signed messages of proposals and votes are relayed to IPFS. A further enhancement could be to also deploy a user-incentivised network of nodes to store votes, thus avoiding IPFS. This would be similar to how Status messenger uses History nodes today to store messages for offline clients.
This approach would prevent centralised servers from censoring proposals or votes by selectively dropping them. Moreover, any node could verify proposal outcomes by tallying the votes independently and disputing any on-chain submissions if necessary.
Furthermore, recall that the first phase of governance before signalling is discussion. Waku already powers the Status messenger which supports public channels (besides private and 1:1 chats). Status messenger is also adding community-oriented features such as read-only channels and moderation. In combination with the Status wallet, it will be interesting to consider the bundling of discussion and signalling forums driven by token-holders and powered by privacy-preserving Waku protocol. Community members can discuss governance issues in the messenger forums, signal preferences using tokens in their wallet and finally vote on-chain within the relevant ÐApps. Status App has all these three capabilities today.
Governance of Decentralised Finance (DeFi) protocols covers every protocol aspect such as the deployment of treasury funds towards different efforts, enhancements to design and development, parameters that affect fees & yields, integration with other protocols and even (meta) governance itself. As DeFi protocols gain more traction, their governance arguably becomes more critical, both as a differentiator against competing protocols and perhaps even for their survival.
In this article, we introduced some of the leading DeFi protocols and summarised key aspects from governance processes of Maker, Compound, Aave, Uniswap and Curve. We then motivated the rationale for gasless voting in this context to introduce Snapshot and its architecture. Finally, we discussed decentralisation challenges with Snapshot’s current implementation and how they may be addressed using Aragon and Waku.
An effective governance process aiming for inclusive participation from token-holding community members needs to have a great UX with minimal friction but without giving up decentralisation and censorship-resistance guarantees that form the motivational bedrock of DeFi — Decentralised Governance (DeGo). DeFi needs DeGo.
(Thanks to Barry Gitarts, Fabien Marino of Balancer Labs and Corey Petty for reviewing drafts of this article and providing helpful feedback. Thanks to Alex Howell for the thoughtful illustrations.)
