We propose adding oSnap, a governance tool developed by UMA, to the Gitcoin Snapshot space and Safe to allow for automatic onchain execution of token transfers and grant funding after successful Snapshot votes.
The current Gitcoin governance flow uses offchain Snapshot voting to approve or deny proposals. However, proposals that are approved must then be repeated onchain with Tally to achieve onchain execution. This repeated vote is an administrative task that wastes the time and gas fees of DAO participants. There have been instances where the revote on Tally did not achieve Quorum and the revote had to be posted again, wasting even more time and gas.
The adoption of oSnap eliminates the need for the redundant Tally revote by automatically executing successful Snapshot votes onchain, thus consolidating the governance process to one gasless vote on Snapshot that results in onchain execution.
oSnap secures over $250M for treasuries including CoW Protocol, Across, Connext and Shapeshift. A dashboard of all oSnap users can be viewed here. oSnap was built by UMA, an experienced leader in optimistic verification. UMA’s optimistic oracle currently secures $450M of TVS across bridges, prediction markets and governance tools.
Adding oSnap aims to streamline the execution of governance decisions, bringing a new layer of efficiency and reliability to Gitcoin requiring minimal effort and no disruption to existing DAO governance systems. On top of these benefits, oSnap is highly aligned with Gitcoin as it is a public good that increases decentralization.
oSnap is a module that is added to a Safe with rules on how to evaluate a Snapshot proposal. oSnap Safe app lets you add oSnap to your Snapshot space and Safe in a few minutes with no developer time required. A video demonstration of the oSnap Safe App can be viewed here.
Once enabled, Snapshot proposals related to the distribution of funds from Gitcoin’s treasury can include token transfers with the proposal. There will be no changes related to proposals not related to treasury distributions, such as social votes relating to governance, removing a director, etc.
The updated Snapshot flow for proposals that include treasury distributions would be:
An oSnap enabled snapshot proposal is created. This process is the same as a normal Snapshot proposal with the addition of transaction data that will be verified and executed if the proposal passes. The Snapshot transaction builder is specifically designed to make it easy to create and verify transaction data for token transfers.
GTC holders vote on the proposal like any other Gitcoin Snapshot proposal
If GTC holders approve the proposal by vote, any address can post a bond (2 WETH) for a challenge period (1 to 3 days) and propose to execute the transactions onchain. UMA has implemented a bot that validates proposals (vote passed, meets min voting period/quorum) and posts the bond for DAOs along with covering gas costs for execution (there are no fees to use oSnap).
If no dispute arises about the proposal’s accuracy during the challenge period, the transactions can then be executed.
In case of a dispute, the proposal is not executed. UMA token holders vote to resolve the dispute, with the correct party rewarded from the opposing party’s bond. This bonding and dispute mechanism punishes incorrect proposers and disputers and incentivizes honest disputes. Any proposal that was incorrectly disputed can be re-proposed to the oracle for execution without requiring revoting. It is important to note, the dispute resolution decided by UMA token holder votes are not deciding if the transactions can be executed or not, only the bond allocation between the proposer and disputer.
UMA created and maintains oSnap as a public good with no implementation or usage fees because we believe decentralized governance tools are critical to the entire Web3 ecosystem. Since UMA is already running robust monitoring across all of our optimistic oracle integrations and can recycle the bonds posted, the additional costs associated with these services are negligible and it is sustainable to continue providing this service for DAOs. If any changes were to be made in the future, we are committed to having existing DAOs not face any changes (aka be “grandfathered in”).
The benefits of Gitcoin adopting oSnap are:
Adding oSnap removes the unnecessary, administrative step of an onchain Tally vote when releasing funds from Gitcoin’s treasury saving Gitcoin DAO voters time and gas fees.
Transaction payloads included in proposals that are approved by voters are trustlessly and permissionlessly executed which increases transparency and decentralization.
Automatic transaction execution by UMA bots is faster than waiting for multi-sig signers along with the bot paying the gas costs for execution.
The UMA team is continuously making frontend improvements as per user feedback and improving open source monitoring infrastructure for oSnap.
UMA has also focused significant resources on monitoring efforts:
The same bot that proposes and executes transactions also automatically disputes inaccurate proposals if the following criteria are not met:
- The proposed onchain transactions match the transactions that were approved in the Snapshot proposal
- The Snapshot proposal passed with the minimum parameters specified (majority in favor, meets minimum voting period and quorum)
- The proposal follows the strategy specified in the Snapshot space.
Proposals are included in the UMA Oracle UI (https://oracle.uma.xyz/) which is the same interface used by disputers verifying and disputing for other third-party integrations (Polymarket, Sherlock, Cozy, and other oSnap integrations).
UMA sponsors a verification program, that pays UMA community members to verify all optimistic oracle assertions So when any transactions are proposed through oSnap, a Discord ticket is automatically created and an experienced verifier from the UMA community completes a multi-step verification process that focuses on areas such as the transaction payload matching the intent of the proposal, verifies transactions do not include interactions with malicious contracts, etc.
While oSnap has been audited by Open Zeppelin, as with any system, there may be unforeseen vulnerabilities.
For - Formalizes the community is “for” adding oSnap to Gitcoin.
Against - Formalizes the community is “against” adding oSnap to Gitcoin.