Governance: Endgame

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