One day, cleaning up your garage, you discover an old hard drive. You plug it into your fancy new MacBook and start looking through the files. One of them makes your heart rate go up — it's an archive with your old Ethereal wallet.
Level 1: Wallet
You are a lucky owner of 1,000 ETH and you decide to start a crypto venture fund. Your plan is to invest in promising new projects by buying their tokens.
Since you are a one-person fund, you keep all the assets inside a single hardware wallet. It's very simple and easy to manage. Every time you want to buy a new token or sell an existing one, you can just do it directly.
One day, your best friend tells you the craziest story. She also found 1,000 ETH on an old hard drive and wants to join your VC fund. You agree.
But how do you combine and manage the shared assets? Your friend suggests you could pull the resources into a single wallet and share the seed phrase. But you know it's a bad idea:
There's a higher chance the seed phrase is stolen
You want to both agree on every investment to proceed
Level 2: Multisig
After a bit of research, you decide to create a Gnosis Safe. Gnosis is a smart contract that can hold any assets, just like the regular wallet. But it can also be configured to only accept commands from a list of trusted wallets.
You pool together 2,000 ETH into a safe and set up 2/2 signature scheme. This means that every transaction has to be signed by both your wallets to be executed by the safe.
Your VC fund is growing fast. You discuss every investment opportunity over a text chat or during your morning coffee walks. Approving transactions in Gnosis is a formality, but it feels really good. You both are equal partners.
One day, you get a call from a common friend who also wants to join your fund. He contributes 1,000 ETH to the safe and you add him as a signer (3/3).
Coordination becomes trickier now. Getting 3 people to sign the transaction is harder, sometimes you can't fully agree on the investment, and sometimes one of you is just busy. So you decided to make the Safe 2/3: i.e. as long as two of you agree on a transaction, it goes through.
The buzz about your VC fund spreads fast, and many more people want to join. But using a Gnosis Safe starts being a pain:
Coordination becomes even harder, getting the majority of people to sign a transaction requires a lot of back-and-forth in the group chat. Gnosis UI doesn't have enough context.
Many people who want to join your fund don't have 1,000 ETH to contribute, and Safe doesn't track percentage ownership.
Level 3: Governor
You have a protocol engineer friend who suggests you should set up a "DAO" with a governor smart contract. You investigate this topic and realize that most of your Gnosis Safe scaling problems could be solved with a Governor.
Governor is a smart contract similar to Gnosis Safe. It works like this: a user can create a proposal with some description and a list of transactions they want to be executed. Others can vote on the proposal, and if there are enough votes (quorum) and the number of "for" votes is larger than the number of "against" votes, the governor executes the transaction.
To track the ownership over the VC fund, you release an ERC20 token. The governor only counts votes based on how many tokens users have.
The ERC20 voting token makes your fund ownership liquid: users can sell their shares, or buy a small number of shares. There's a sense of a fair price: the size of your fund's assets divided by the number of ERC20s.
Coordination becomes much easier. All proposals are posted on-chain, so anyone can monitor that data and build UIs, chatbots, and other tools to help them be involved in the decision-making.
It's not all perfect though. Liquid ownership brings a lot of risks. For example, an attacker could flash loan ETH, purchase half of your ERC20 token supply, and vote for a proposal that transfers all fund's assets to their own address.
To prevent these risks, you introduce several on-chain mechanisms. The new rules make your VC less decentralized, but it's a trade-off you are willing to make.
Timelock. After a proposal is accepted, it's sent to a queue. A few trusted addresses can "veto" the proposal before it's executed.
Snapshots. Every time the ERC20 token is transferred, it records the old balance at the transfer time. When the Governor counts votes, it takes historical balance at the time the proposal was made.
Ragequit. When someone disagrees with your VC fund's direction, they can sell their ERC20 tokens back to the DAO for a share of VC holdings.
Code of Conduct. As your VC fund becomes one of the largest funds in the industry, bad publicity can really hurt. So you establish a way to revoke voting rights from wallets that break your CoC.
Your fund grows really fast, but you notice that most token owners don't participate in governance. They just hold the tokens waiting for them to go up.
Level 4: Delegation
To address the participation problem, you enable delegations. Any holder of your fund's ERC20 token can delegate their voting power to another address. They keep the tokens in their wallets, but the Governor is configured to count votes based on delegation, not ownership.
This makes a big difference. People who care about your fund collect voting power and actively vote on proposals with a much bigger impact. Your fund starts resembling a country, but elections happen continuously.
But the existing version of delegation has some shortcomings:
Delegation is all-or-nothing. "Whales" hesitate to delegate their massive bags to any particular person.
There's no way to limit the delegation power to low-risk proposals (e.g. small investments < 10 ETH).
Delegates can’t step down and designate someone else to take their place.
People who want to extract even more value from their ERC20 tokens cause Curve Wars.
Level 5: Liquid Delegation
You decide to make delegation more flexible and address the pain points. This is a modern frontier of technical aspects of governance, only a few DAOs are exploring this space.
First, you make it possible to delegate fractions of one’s voting power. Something like Franchiser could work, but most token holders feel uneasy sending their tokens to smart contracts. So you’ll need to modify the Governor and the ERC20 voting token to support something like this.
Second, you introduce a rules engine layer, for example, Alligator. It allows your token holders to add restrictions to how the delegates can use their votes. The delegates can also subdelegate their votes further to other people or even smart contracts.
Your DAO members can now fine-tune their participation in the DAO, it’s no longer an all-or-nothing.
Acknowledgments and disclaimers
This post was inspired by awesome work from folks at Maker, Compound, OZ, Nouns, and countless others who dare to push the boundaries.
I’m working on a Liquid Delegation protocol together with Agora. We are planning to deploy our liquid delegation protocol for Nouns and Optimism DAOs sometime very soon. If you are interested in working on these problems or using our work, feel free to reach out!
