The problem Governable 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 (which represents our low-cost L2) and our DAO treasury/vault is deployed to Moonbase Alpha, which represents our L1.

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.