Hi Pradolo, thanks for the comments. Iāll start by responding to your numbered points:
1 - Yes, oSnap is dependent on Snapshot to signal the approval of a DAO vote. However, the existing governance process also relies on Snapshot to signal approval as well. As per the āMoving to Voteā section of the Gitcoin DAO Governance Process v3, after a vote is approved on Snapshot, āNo one person should ever vote NO on Tally as all proposals that make it on Tally are classed as passedā. So whether the execution of a Snapshot approved vote is executed through oSnap (as proposed), or through an onchain Tally vote (current system), both systems rely on Snapshot correctly signaling the DAOās approval.
In the edge case where Snapshot is misreporting vote results, the current system would rely on DAO members to realize this and vote āNoā on Tally against the usual governance flow. With oSnap, proposed transactions based on misreported vote results would require only one disputer to block transaction execution. As described in the Specifications section above, UMA token holders would then vote to redistribute the proposerās and disputerās bond.
2 - oSnap does rely on there being one honest disputer to dispute invalid proposals. Disputing is public and permissionless. Disputes do not require holding any UMA, but do require posting a bond in WETH or USDC. UMA runs bots that dispute invalid proposals and also sponsors a verification program as described in the above proposal. Gitcoin DAO members are welcome to add another layer of protection by monitoring their proposals and disputing invalid proposals (if they are fast enough!). This can be done using the Oracle UI or running a UMA developed monitoring bot.
UMA token holders only vote if there is a dispute on a transaction batch proposed to the oracle for execution. As soon as a proposed transaction batch is disputed, that proposal can no longer be executed no matter how UMA token holders vote to resolve it. The token holder vote only resolves the bonds posted by the proposer and disputer. Dishonest parties lose their bond and honest parties get a portion of the otherās bond. If a valid proposal is disputed, a new transaction proposal can be created using the same Snapshot proposal results. So the dishonest disputer would be continually losing bonds to block a valid proposal. If there is a dishonest proposer who continually submits dishonest proposals, it would be extremely costly as they would be continually losing their bond.
3 - As you mentioned, the multi-sig can be removed from an oSnap enabled Safe. Considering Gitcoin doesnāt have a Safe or multi-sig signers, we propose adding a new Safe with an oSnap module and then incorporating the existing Gitcoin Governor as a module on the Safe. This enables the existing governance system to serve as a fallback and would prevent Gitcoin from needing to add multi-sig signers or introduce centralization into the Gitcoin governance process.
The proposed implementation accomplishes the main goal of removing redundancy in the voting process (voting on both Snapshot and Tally) with no commitment required to be made until a Tally proposal is created for migrating funds to the Safe. This enables a test oSnap proposal and other testing to be completed before migrating funds.
For Tally to serve as an emergency option, it would require an āexec callā within the safe contract. While we expect Gitcoin to not need this fallback, itās important to be transparent about the tradeoff. The other additional complexity, as mentioned above, is assets Gitcoin controls with Snapshot and oSnap would need to be migrated to the Safe.
Proposed Integration Steps:
Setup:
- UMA: Deploy a Safe
- UMA: Add oSnap module to Safe
- UMA: Add existing Gitcoin Governor as a module on Safe
- UMA: Remove all signers from Safe
- Gitcoin: Add the āoSnap by UMAā plugin to Gitcoinās Snapshot space
Note: all UMA steps above could alternatively be completed by Gitcoin with support from UMA.
Testing:
- Gitcoin (optional): Complete test Snapshot proposal with oSnap
Execution:
- UMA: Create a Tally proposal for migrating agreed upon amount to Safe
Please let us know if there are additional questions on oSnap or the proposed implementation.