Governable

Demo

About

The problem it solves There are numerous challenges when it comes to on-chain governance, participation and coordination. Our solution aims to help solve this problem in two main ways: - Reducing costly transactions for protocols and communities on mainnet, and - enabling governance for any ERC20 or ERC721 token, regardless of whether or not it's checkpointed. Traditionally, a governance token needs to have checkpointing built in, whereby checkpoints are created of an accounts balance at specific block numbers during transfers. This not only increases the gas cost of transfers due to additional **SLOAD** and **SSTORE** operations, but it means any token without checkpointing cannot be used for governance. By utilizing Brevis, we can generate historical state ZK proofs to trustlessly determine the balance held by an address at **any** given block **without** the need for checkpointing. Additionally, because this proof is generated offchain, we can perform the voting on a separate chain, such as an L2, where gas costs are significantly lower and, thanks to Wormhole, relay the result of the proposal to mainnet where it can be executed. Brevis is new and has not integrated with most networks, our [L2 Governor is deployed to Sepolia](https://sepolia.etherscan.io/address/0x161303e2d74081df0d918680a7b5bc96090c4802) (which represents our low-cost L2) and our [DAO treasury/vault is deployed to Moonbase Alpha](https://moonbase.moonscan.io/address/0x0591c25ebd0580e0d4f27a82fc2e24e7489cb5e0), which represents our L1.

How it's made

Challenges we ran into The project involves a lot of moving pieces, namely: the ZK circuit+proofs, governance contracts, Brevis's off-chain services, and cross-chain TXs using wormhole. Integrating these disparate elements and testing them presents numerous challenges, especially on a compressed timeline. **Challenge:** The Brevis quickstart guide didn't work in its public form. **Solution:** We worked with the Brevis reps at ETH Denver to fix the guide and submitted a PR to fix the public repo. **Challenge:** The brevis backend was giving an odd error related to a missing trie node when trying to generate a storage slot proof for our application. **Solution:** We worked with the Brevis team and realized this error often is indicitive non-archival node when one is needed. Brevis updated there service to use an archival node. **Challenge** When submitting a storage slot proof to the Brevis backend, we were running into an error of "invalid attestation" even though all our input was correct. **Solution** We worked with Brevis and they updated their SDK to fix our usecase. **Challenge** When requesting our ZKproof on chain after submitting the proof id to Brevis off-chain, the proof wasn't being relayed by Brevis. **Solution** We messaged the Brevis team and they determined that the issue was mpt proof depth being too deep. They quickly updated their service to support our use case. Thank you so much Brevis for the continued support! **Challenge** We were deploying our contract to Moonbean but deployment was consitently reverting. **Solution** We attempted compiling for lower EVM versions but that didn't solve our issue. We found on an online forum that Foundry underestimates gas significantly on Moonbeam, so we trippled our gas and it worked. **Challenge** This is a very significant hackathon project for a team of two to tackle. **Solution** We hacked together a quick UI based on the coinbase boilerplate and graciously were helped a lot by the Brevis team which helped us finish.