Today is the one year anniversary of the POOL token; we deployed the POOL token on Feb 16, 2021 at 1:00pm PST. Our product has changed significantly in that time, but our governance system has not. It’s important that we evolve governance to ensure the system is secure and that decision making is streamlined. This post intends to shed light on how we can move forward.
PoolTogether exists on multiple chains. Our presence on Polygon is stronger than ever, but governance still resides on Ethereum. The latest version of PoolTogether is more complex from an administration standpoint, so some parameters (but not any deposits) are controlled by a governance multisig. As we look at continued expansion and growth, now is a great time to consider our long-term governance strategy.
It’s important to look at the past and present to better inform our current governance plans. There have been two important phases in governance so far: the creation of the POOL token and the POOL prize pool, and more recently the creation of teams that manage elements of the system.
After reviewing our first two phases of governance, we will make note of any themes or patterns in our behaviour. By recognizing these patterns we can better accommodate them in our future architecture.
Next we will review three ways of approaching future governance: centralized control in one L2, creating islands of control in each L2, and finally a hybrid model of mixed control.
Finally, we will draw conclusions.
PoolTogether began on the Ethereum blockchain. The POOL token was launched on Ethereum on Feb 16, 2021; the token was airdropped to all users and control of all prize pools was handed over to POOL holders. It was an exciting, momentus first step into our decentralized future.
The token was launched without any prescriptive structure. There was no process, only control. Changes could only occur through governance proposals. Proposals required voting.
Immediately, POOL holders recognized the need to vote frequently and saw the cost of gas rising. Only three weeks after the token launch, on March 6, the POOL prize pool was created. Users could deposit their POOL into this new prize pool. The pool delegated the voting power. We created the POOL Pool Snapshot so that POOL token holders could signal their decision for a given PTIP without spending Ether on transaction fees and have a vote cast according to their wishes.
As a non-custodial protocol there is no ability for any person, entity, or POOL token holders to influence user deposits. At times, there are peripheral functions that may need some form of management. On August 21 a proposal was created to start liquidity mining on Polygon. To facilitate this, two teams were established using Gnosis Safe multisigs: the Ethereum Operations Team and the Polygon Operations Team. While they were named similarly, they had very different roles.
Note: there are other teams and working groups, but they do not exert any direct control on the protocol. We will focus on the teams that actively manage the protocol.
The Ethereum operations team is a 2-of-6 Gnosis Safe on Ethereum. Its role is to ensure that the Prize Pools have sufficient LINK to pay RNG costs and that the OpenZeppelin Defender relayers have enough funds to run transactions. The team can act quickly because it is a 2-of-N Gnosis Safe. The budget risk is low, as funds are streamed to the Safe with Sablier. The team continues to operate today, although it has not yet been formalized.
The Polygon Operations Team was a 4-of-7 Gnosis Safe on Polygon. Its role is to custody POOL that was bridged from Ethereum, and to top-up the “faucets” for the Polygon Prize Pools. The faucets “dripped” POOL to users as liquidity mining incentives. The Polygon Operations Team actions were dictated by POOL Snapshot signalling. The Polygon Operations Team has been superseded by the Executive Team.
On October 15 PoolTogether V4 launched across Ethereum and Polygon, and soon after Avalanche. We created an Executive Team by merging both operations teams. The Executive Team was needed because:
- Being a new system, it was imperative that we could quickly adjust parameters in the event of a problem.
- Being a highly configurable system, we wanted to easily tune the system without having to involve governance.
The Executive Team has been officially formalized in terms of its roles, compensation, and member onboarding / offloading. It has been highly successful.
Notably, the Executive Team operates with two roles:
- Governance mandates: the team has been given the goal of balancing prize liquidity, but they are free to determine how they do so.
- Governance orders: the team must act in accordance with POOL Snapshot votes that direct a specific action.
We’ve seen an interesting progression in decision-making.
- Token holders vote on all changes (POOL)
- A team must act according to a Snapshot Signal (POOL Pool multisig vote, Polygon Operations Team, Executive Team)
- A team is given a mandate by governance that they can achieve however they please (Ethereum Operations Team, Executive Team)
Gradually, POOL token holders have been making fewer and fewer direct decisions. This is a good thing. The decisions are being made more and more by teams: multisigs that have been given a limited scope of responsibility or budget. It’s a waste of time and gas to involve POOL holders in every single decision.
However, we have some significant shortcomings:
POOL power does not extend to Avalanche or Polygon
There is no recourse in the unlikely event that the Executive Team goes rogue. If we lose control over the exec team, we do not have a way to transfer control back to POOL voters.
Some Teams are Too Powerful
- The POOL pool has concentrated voting power
- The Executive Team controls V4 parameters and prize liquidity. As the protocol grows this risk will increase.
Decision Making is Complex
One of the most active areas of governance was managing the POOL token emissions. This required constant voter engagement because it involved the treasury. We need to automate processes whenever possible.
Given the above, let’s consider what we want out of an ideal governance system:
- POOL token holder control on all relevant L2s and blockchains
- Teams to manage the system day-to-day
- POOL token holders are the highest power
- Minimize required voter coordination and engagement
If we ensure that POOL token holders can retake control of key systems, then we can delegate more control. The POOL token holders will always be able to recover the system.
By creating more teams and introducing more fluid forms of governance (such as Curve’s emission gauges) then we can minimize voter engagement.
So: we must extend POOL token holder control to all L2s. How do we do that?
There are three variations as I see it:
- We move governance into a single L2. POOL token holders on that L2 vote on concerns across all L2s and chains.
- We create a separate governance system on each L2. POOL token holders on each L2 control their prize pools separately.
- We create a hybrid system. A governance system existing on each L2, but the gov systems can have shared proposals on Ethereum.
Let’s analyze each of them.
In this scenario, we migrate voting and control to a single L2. All proposals and voting would occur on this L2.
Let’s assume, for the sake of argument, that PoolTogether is only deployed to Ethereum L2s. This means that we have secure L1 <-> L2 messaging (barring time delays).
To control prize pools on other L2s, governance would need to create a proposal that sends a message like so:
L2 -> Ethereum -> L2
By virtue of passing through Ethereum, this proposal will be both slow and expensive. We have to be very careful about what we put under its control. The other L2s will need multisig control over any moving parts, or even delegation to a single EOA.
POOL token holders across the other L2s will be excluded from the vote. There is a chance that, with some technical gymnastics, votes can be bridged. However the costs per user would be astronomical.
Because of the limited numbers of POOL token holders that can participate, the system could be more vulnerable to a malicious whale. By reducing broad voting power it becomes much easier to tip the balance of a system.
- It’s simple: voting occurs in one place only
- We can choose the most robust L2
- POOL token holders on the other L2s can’t vote
- Proposals are expensive and slow to execute across L2s
- Whales can manipulate votes
In this scenario we would deploy a separate POOL governance system to each L2. The POOL token holders on each L2 would be in charge of managing their deployments. The POOL token would be the binding force, and users can bridge POOL between their favourite L2s to participate.
POOL token holders would be able to control the prize pools on the L2s that they participate in. They wouldn’t, however, be able to control prize pools on other L2s. The holders would need to split their votes to participate on both.
This approach has a number of problems. Because the POOL token is spread across all L2s it would be possible for a whale to move from L2 to L2 and dominate the vote. This approach also leaves the existing Ethereum goverance system behind and excludes any form of shared governance beyond a social contract.
- POOL holders can participate on the L2 in which they reside
- POOL token holders can only vote on the L2 on which they reside
- Whales can manipulate votes
- Ethereum governance is orphaned. No POOL minting!
- No shared governance between L2s
- No shared treasury
A hybrid governance model combines both models by providing local governance on each L2, but also creating a central form of governance on Ethereum.
L2 Governance would be able to:
- Create L2 proposals to be voted on by L2 POOL token holders
- Create special proposals using an L2 proposal bridge, which would allow token holders to signal back to Ethereum for L1 proposals. The proposal data would be transmitted across the bridge whether or not the vote succeeded; it would simply include the L1 proposal id and the number of yes, no, or abstain votes.
L1 Governance would be able to:
- Create L1 proposals to be voted on by POOL token holders.
- Receive combined yes, no and abstain votes from L2 proposal bridges
- L1 proposals can optionally run transactions on L2s across bridges, so L2 → L1 → L2 governance is possible.
L2 governance would allow L2 POOL holders to combine their votes and send the result to Ethereum.
This governance model has the benefit of allowing POOL token holders to maintain shared control of key elements of the system. Shared control means that all POOL holders are participating in proposals; increasing the security of the system.
- Entire system secured by POOL holders across all L2s
- Legacy governance system can be upgraded
- Allows L2 independence for certain controls
- L1 Governance system would need a long proposal time to allow for L2 proposal bridges to complete. Protocol-wide changes would be slow. For example if L2 proposals take a week to execute, then we may want L1 proposals to take three weeks.
The non-custodial nature of the PoolTogether protocol ensures a base level of security. But as PoolTogether continues to expand to L2s and chains, we need to improve our governance process.
From our history it’s clear that governance is moving towards:
- Relying on the core non-custodial protocol design to ensure security of deposited funds
- Minimize trust by delegating limited responsibility and/or budget to teams
- Signalling direction for teams using Snapshot
- Using on-chain voting only for major decision-making and recovery
- Making the protocol autonomous; automate whenever possible to eliminate human control.
In situations where power is being delegated to teams and individuals, we must ensure there are measures in place for worst case scenarios. Bringing governance to L2s will allow us to meet token holders where they live, and allow them to secure the protocol with their votes.
I believe the hybrid model is the ideal model, and it will allow us to reach across all L2s. Since POOL was launched the governance system has been standardized, so many components can now be pulled off-the-shelf. I believe governance can be multi-chain with a reasonable amount of effort.
All that being said, I invite the community to provide any feedback. I would like to hear any and all perspectives.