defi-wonderland.notion.site Open in urlscan Pro
2606:4700:4400::6812:2009  Public Scan

Form analysis
0 forms found in the DOM

Text Content

Wonderland Governoor

Search
Duplicate


Try Notion

Drag image to reposition


WONDERLAND GOVERNOOR




A TALE OF A DELEGATE

This year, we became a top 5 delegate for Connext DAO, one of the most important
bridging protocols in the space. Our journey saw us delving into a diverse array
of subjects. While some were right up our alley, others, like legal matters,
presented new challenges due to our limited expertise.

The OpenZeppelin Governor, an evolution of Compound’s Governor, has emerged as
the go-to governance contract in the web3 space. Top-tier protocols such as
Uniswap, Optimism, ENS, and more, have adopted it as their primary tool for
consensus and decision-making. Yet, the landscape is changing; Increasing market
complexities and regulatory scrutiny have added layers of sophistication to
organizational processes, signaling that the Governor, despite its widespread
use, may be struggling to keep up with the times.

Let's consider two notable limitations:
DAOs can only set one parameter configuration (like quorum, approval thresholds,
etc.) at any given time.
Users are restricted to delegating their entire voting power to just one
delegate.
Some DAOs are already seeking alternatives. For instance, Arbitrum implemented
two Governors, and Optimism launched an RFP for a new Governor model to
incorporate stakeholder feedback. The current Governor standards, although
effective for simpler scenarios, are showing their age in this fast-evolving
web3 era, having been in place for over three years - practically an eternity in
our world.

Blockchains offer the potential for much finer control than what we experience
in the physical world. Yet, current governance models lack this level of
flexibility. To put it bluntly, the existing Governor standards are falling
short, unable to fully harness the nuanced capabilities of blockchain
technology. Current Governors suck.




INTRODUCING THE WONDERLAND GOVERNOOR

> Kudos, anon. You fell down the rabbit hole of governance and made it this far.
> Are you ready to see what awaits you in Wonderland?

At Wonderland, we thrive on solving puzzles and because of it we’ve decided to
embark on a journey to improve Governors, starting with a first version that
will feature:
Different proposal types: Supporting the addition, removal and management of
proposal types, each with different quorums, approval thresholds and voting
periods.
Smart delegation:
Delegation per proposal type: Users will be able to set different delegates for
each proposal type, allowing more flexibility and specialization of delegates.
Partial delegation: Users will be able to delegate its voting power to multiple
addresses.

This first version should be enough to demonstrate the power of an enhanced
Governor, but if those features aren’t enough, here are some other ideas
floating around for future iterations:
Different vote types: Not all decisions fit the present “yes, no, abstain”
majority voting. We want to allow DAOs to develop voting modules to cater to all
the different decisions, like single/multiple choice voting, commit/reveal
private votes, quadratic voting, etc.
Sub-delegation: With great power comes great responsibility. Delegates and
delegators may want help with their duties for several reasons. If A and B
delegate 50% of their voting power to C, C might, in turn, delegate that
accumulated power to D. This is very helpful for delegates who wish to take a
break.
Resigning from delegation: Being a delegate is a lot of work, and they should be
able to resign from their voting power if they want to stop participating in the
governance or even take vacations.

HOW WOULD IT LOOK?



We'll use OpenZeppelin contracts as the starting point for our project and tweak
the following contracts to add the needed features:
Votes.
ERC20Votes.
Governor.

Votes:
The new contract will now track the delegation information and the snapshots
segmented by proposal types. The delegates for a specific proposal type can be
more than one, and different weights can be assigned according to the percentage
of votes delegated for each of them.
Solidity
Copy
struct Delegatee { address account; uint256 weight; } mapping(address account =>
mapping(uint8 proposalType => Delegate[] delegates)) private _delegatees;
mapping(address delegatee => mapping(uint8 proposalType =>
Checkpoints.Trace208)) private _delegateCheckpoints; mapping(uint8 proposalType
=> Checkpoints.Trace208) private _totalCheckpoints;




ERC20Votes:
This contract will be modified to be compatible with the Votes contract.

Governor:
The new contract will define the different types of proposals that can be
created according to the protocol decision. Created proposals will now require
the proposal type field, and when casting a vote, the voting power will be
queried according to the proposal type parameter. The contract will allow DAOs
to determine how many proposal types they want to support by overriding the
function getProposalTypes() external view returns (uint8[] memory).

The proposalCore struct will now have the proposalType member:
Solidity
Copy
struct ProposalCore { uint8 proposalType; address proposer; uint48 voteStart;
uint32 voteDuration; bool executed; bool canceled; uint48 etaSeconds; }


The decision on the proposalTypes implementation will be up to each protocol
design. This is an example of how a protocol could implement Governor and store
their proposalTypes with a fixed enum:
Solidity
Copy
enum ProposalType { ApproveSpending, GovernanceParameterChanges,
SmartContractUpgrades, PolicyAndRuleChanges, CommunityGrantsAndFunding,
EmergencyActions, ProtocolChanges } // overridden method function
proposalTypes() external view returns (uint8[] memory) { uint8[] memory
proposalTypes = new uint8[](7); proposalTypes[0] =
uint8(ProposalTypes.ApproveSpending); proposalTypes[1] =
uint8(ProposalTypes.GovernanceParameterChanges); proposalTypes[2] =
uint8(ProposalTypes.SmartContractUpgrades); proposalTypes[3] =
uint8(ProposalTypes.PolicyAndRuleChanges); proposalTypes[4] =
uint8(ProposalTypes.CommunityGrantsAndFunding); proposalTypes[5] =
uint8(ProposalTypes.EmergencyActions); proposalTypes[6] =
uint8(ProposalTypes.ProtocolChanges); return proposalTypes; }


If the protocol decides that it wants to have dynamic proposalTypes it could
easily implement a dynamic array of proposals:
Solidity
Copy
// ApproveSpending => 0 // GovernanceParameterChanges => 1 //
SmartContractUpgrades => 2 // PolicyAndRuleChanges => 3 //
CommunityGrantsAndFunding => 4 // EmergencyActions => 5 // ProtocolChanges => 6
uint8[] internal _proposalTypes; uint8 private _proposalNonce; function
proposalTypes() external view returns (uint8[] memory) { return _proposalTypes;
} function addProposalType() external onlyGovernance { _proposalNonce += 1;
_proposalTypes.push(_proposalNonce); }


Delegation flows:



GET IN TOUCH

Thank you for joining Wonderland through out this journey. We are just getting
started. If these issues strike a chord, or you have other challenges you think
we can assist with, let’s chat!