Governance: Endgame

1

Governance: Endgame

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.

Phase I: Early PoolTogether Governance

The POOL Token

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.

The POOL Pool

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.

Phase II: The Introduction of Teams

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.

Ethereum Operations Team

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.

Polygon Operations Team

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.

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.

Patterns in Governance

We’ve seen an interesting progression in decision-making.

  1. Token holders vote on all changes (POOL)
  2. A team must act according to a Snapshot Signal (POOL Pool multisig vote, Polygon Operations Team, Executive Team)
  3. 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.

Extending POOL Control

Given the above, let’s consider what we want out of an ideal governance system:

  1. POOL token holder control on all relevant L2s and blockchains
  2. Teams to manage the system day-to-day
  3. POOL token holders are the highest power
  4. 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.

We Centralize Control on One L2

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.

Pros:

  • It’s simple: voting occurs in one place only
  • We can choose the most robust L2

Cons:

  • POOL token holders on the other L2s can’t vote
  • Proposals are expensive and slow to execute across L2s
  • Whales can manipulate votes

Each L2 Governs Itself

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.

Pros:

  • POOL holders can participate on the L2 in which they reside

Cons:

  • 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

Hybrid Governance

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.

Pros:

  • Entire system secured by POOL holders across all L2s
  • Legacy governance system can be upgraded
  • Allows L2 independence for certain controls

Cons:

  • 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.

Conclusion

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.

11 Likes
2

I have a little bit of an idea. What if we used some form of Optimistic Governance where snapshots can take place on each chain but there is a dispute period that lives on L1. The L1 POOL holders would have the power to cancel a vote during the dispute period if any malicious action has taken place. The snapshot votes would combine to make decisions and approve transactions but Ethereum POOL would have veto power to protect the platform. Maybe this is very difficult to implement but the idea would be based on how UMA’s Optimistic Oracle works to verify price disputes.

If that idea is not feasible my preference would be a hybrid system because I want to see POOL available and usable on as many chains as possible.

4 Likes
3

Once again, a trilemma! Speed, participation, security - pick 2.

Of these, I see speed as the ‘nice to have’, and maybe there are some clever technological tricks available like @TheRealTuna suggested that could address this, but accessibility of the vote and security of the vote are surely the priorities.

4 Likes
4

Great write-up! I’ll summarize some thoughts below.

Seems to me this is largely what we have now, but on an L2. Maybe it eliminates the need for gasless snapshot voting, but that would probably be the only upside. Given that we don’t like the current situation, this is probably a no-go.

This seems the most straightforward solution which can be implemented with a minimum of technical hassle. However, it does definitely not align with the whole concept of a multi-chain protocol.

One scenario of whale manipulation, woudl be where one L2 essentially goes rogue. Imagine we just bridged $250k to fund prize pools on a new chain and governance there is still limited in size. A whale could probably launch a vote to steal those funds and other chains have zero recourse. Obviously issues like this can be mitigated with proper care, but with cryptocurrency being such an adversary environment, implementing a system where we already see so many issues upfront, is probably not the best way forward

I’m inclined to agree that this is the best way forward in a true multi-chain protocol. I am left wondering about the feasibiity of this proposal however? Is this a “let’s do this in a month”-project or a “maybe by the end of the year”-project?

Does this proposal not suffer from the same issue as gPOOL since communication between Polygon and Ethereum is extremely limited and a centralized bridging solution is required? Or are you discounting Polygon as an L2 in this proposal? Can we leverage oracles to bridge votes? Seems to me that on-chain votes on one layer could be bridged to another layer through oracle usage.

We probably need to properly outline which capabilities L2 governance receives and which ones it does not. I can imagine changing prize distributions could be an L2-only proposal because it does not directly affect another chain. However, even something like this would still require thight control of bridged funds because a malicious proposal could result in a loss of funds. Governing mandates, treasury usage ro deploying new smart contracts (such as DPR) should likely be controlled by combined L1 / L2 governance.

4 Likes
5

Super insightful write up, thanks for laying out all the details in such a structured way!

The cons for your first two scenarios are strong. If the biggest downside for the hybrid option is the factor of time, I think we can make up for that with structure, clearly articulated processes and the experience we’ve collected from all the PTIPs so far.

Let’s say sometime this year we’re live on 6 networks in total. Would that mean we’d have to do 6 different votes at the same time while best case everyone would vote on all the chains they’re on?

2 Likes
6

Yes, I think it’s essential that we re-use as much software as possible to speed up development time and minimize auditing costs. The OpenZeppelin governance contracts are a fork of Compound that have received significant improvements. Both OZ Defender and Tally can be used to interface to these contracts. This is why I’ve been thinking in terms of the standard gov system like the one we already have; it’s a lego piece that can be snapped into place. We could theoretically deploy a new gov system to Polygon tomorrow and interact with it via Tally.

While I don’t see Polygon as a true L2, I do include it in this proposal. The validator set for the core consensus also validates bridge transactions, so the security is shared. If the bridge fails the entire chain fails, and $1.2b USDC has been bridged over. At this point I think we should fully commit to it.

Avalanche, however, is a different story. I don’t know of any well-used generalized message bridges. I think Avalanche will have to remain an island for the time being. I have some ideas on how we could extend ourselves, but they are very experimental.

The next chains we deploy to will be Ethereum L2s, so I think we can just focus on them for the time being.

Yes! I think this could be the messiest part. I think the optionality is great, but our focus should be on protocol-wide decisions first. Then people will always know that decisions have to be made by all POOL token holders. It’s simpler.

That being said, gov needs to delegate as much as possible so that we can continue to signal with Snapshot. I imagine we’ll still have a similar process that we do now: teams would be operating under governance orders via Snapshot signalling. The difference being token holders would act as the highest arbitrator if anything goes south.

Yes- everyone would vote on the chains they’re on. However, ideally this will be pretty rare. We’ll still have Snapshot to signal to teams that have been delegated control over certain params.

3 Likes
7

Thanks for writing this up @brendan I’m glad we are continuing to put a high priority on having the best governance.

Overall I like the hybrid approach here but with one change – eliminating chain specific votes.

If we eliminate that element then the hybrid approach essentially becomes our current approach with better execution.

My concerns with chain specific votes are:

  • I think (and hope) the need for them will be very limited to the degree that we can get by without them.
  • I don’t think there is appetite for per chain governance, it takes us weeks to do governance proposals that impact the entire protocol. I don’t see people being engaged enough to want to vote on smaller, chain specific ones. On top of that, just the educational burden and UI implications of having different votes for each chain is a lot.
  • Chain specific governance will introduce new attack vectors.
  • I think it will prove to be a solution to only a short term problem. Inter-chain communication is something that should be only improving in the coming year. We can hopefully rely on the advances of others.

If we take out chain specific votes than the remaining item is:

  • 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.

This is trustless implementation of what we are currently doing. We can still do the things mentioned in the “L1 Governance would be able to:” of the hybrid section.

I also like this approach because it’s an iteration on our current approach. We can:

  • Strive to eliminate any parameter management that is needed (this is happening already with the DPR)
  • Improve the execution of L2 to L1 voting to make it trustless
5 Likes
8

I want to follow-up on this with a more concrete roadmap.

Let’s assume the upgraded system basically does this:

  • Users vote on L2 and L1
  • Votes on L2 are aggregated then bridged to L1 in one tx
  • L1 gov combines L1 votes and bridged L2 votes
  • L1 gov proposal executes txs on L2 across the bridge.

So for now we’ll be using L2 gov just to aggregate votes. In terms of components, we will need:

  • An L2 gov system
  • A custom contract to bridge L2 proposal results to L1
  • Update L1 gov to accept aggregated votes.
  • Extend L1 gov to L2 via bridges.

Let’s analyze each one

L2 Gov System

For this we can use the OZ Governor system off-the-shelf. This means we can plug the system into Tally and the OpenZeppelin Defender product without any changes.

L2 Vote Bridge

Once the proposal has completed on L2, we’ll need to bridge the votes (both yes, nos, and abstains) back to L1. This will need to be a custom contract. It will need to bridge the votes whether or not the L2 proposal succeeded. We’ll need some convention or code that links the L2 proposal to the L1 proposal.

Update L1 Gov to Accept Aggregated Votes

The OZ Governor is compatible with the original Compound Timelock contract, so we can use the Governor code. However, we’ll need to make alterations so that the governor contract can see the L2 aggregate results. Ideally, we can do this in a way that does not disturb compatibility with Tally and OZ Defender.

Extend L1 Gov to L2 via bridges.

Lots of audited code exists to bridge contract messages, whether on Polygon, Optimism or Arbitrum. More will follow.

What would be especially smart here is if we could queue up transactions on L2 and simply transmit a “launch code” from L1 to L2. That way we wouldn’t need to track all of the transaction data across chains, we could just approve of a launch code that would release the transactions in the L2.

Order of Operations

  1. Extend L1 Gov to L2. Since our goal is to enable protocol-wide control on all L2s, this is a natural first step.

  2. Update L1 Gov to accept Aggregate Votes. We need to be able to count votes using custom code; this will enable us to bridge votes from L2.

  3. Create L2 Vote Bridge to push aggregate vote results. Once we have a receiver for votes, we can build the transmitter on the L2 side.

  4. Deploy L2 gov. Once we have a transmitter for aggregate votes, we can run votes and push them across the bridge.

3 Likes
9

You posted while I was drafting a different response! Missed this.

I 100% agree that we should focus on protocol-wide votes. I agree with both yourself and @drcpu that chain-specific votes have a much greater risk profile. I also think that it complicates governance in that it adds too many layers. We start with protocol-wide: that’s the most important control and one we need to dial in.

2 Likes