IIP: ###
Title: Add Index Protocol Safe with oSnap
Status: Draft
Author(s): @anthonyb.eth
Reviewer(s): @allan.g , @0x_Dev
Created: 2024-03-10
Summary
This proposal adopts the “Index Protocol Controller Safe” to the Index Coop DAO on Ethereum and Arbitrum One.
Both Safes will be enabled by oSnap, a governance tool developed by UMA, to allow for automatic Safe transaction execution of specific changes to Index Protocol after successful Snapshot votes.
This proposal transfers the Controller role for Index Protocol deployments on Ethereum and Arbitrum to these Safes, giving INDEX voters the power to change the protocol via valid Snapshot votes.
Because security for the Snapshot space is paramount, the Snapshot Admin will be transferred to the Ethereum Index Protocol Controller Safe.
These Safes have already been created, but a successful proposal will be required to adopt them.
Ethereum: eth:0x8eCDB83Ccb1ce979a75908Ae9a044C52fab9fE59
Arbitrum: arb1:0x19Fa8783f2B57F3eC6C9542926A06698e30eF7B4
The Safe will have a threshold of 2-of-4 signers as a fallback. Those signers will be:
| name | address |
|---|---|
| RocketClerk LLC | eth:0x57D0C0f6458284884F0654CAa53811D013bB6f20 |
| Defensible LLC | eth:0x385921c3B8c044885D6DfD67e013567cD010B4AC |
| C-Squared LLC | eth:0x60fAB7c35E3728B46a88f82ddeee46dF1d414A45 |
| Mr. Madila | eth:0xA3EB02Ffa9bF1965629fa2731b16fFEc87b86848 |
Index Coop plans to remove these signers and rely entirely on the oSnap Module after a trial period. Furthermore, Index Coop intends to move all DAO-owned Safes to oSnap. This will occur in a separate proposal.
Abstract
oSnap enables INDEX Snapshot votes to govern changes to Index Protocol. By transferring the Controller role to this Safe and enabling oSnap, the addition or removal of core smart contracts on Index Protocol will be secured by a snapshot vote and executed in a more decentralized and trustless manner.
oSnap secures over $450M 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 is securing $1B of TVS across bridges, prediction markets, and governance tools.
Motivation
Adding oSnap further decentralizes the execution of specific changes to Index Protocol by enabling tokenholders to govern the protocol directly. In addition, UMA is a great partner to Index Coop and is currently being used to facilitate trust-minimized reweighting via UMA’s Optimistic Oracle.
The Safes have already been deployed, and the oSnap module has been added. All that needs to happen is to transfer Controller ownership to the new Index Protocol Controller Safe.
Specification
oSnap is a module added to a Safe with rules for evaluating a Snapshot proposal. The 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 specific changes to Index Protocol can include transaction data with the proposal (details below). Changes to Index Protocol may include adding new smart contract modules or adapters or removing existing smart contracts that constitute the core protocol. After a successful Snapshot vote, the transaction is proposed in Safe (put onchain) and verified by UMA’s optimistic oracle before being executed by the Safe. There will be no changes to Index Coop’s other Safes without a new proposal.
The updated Snapshot flow for proposals that include changes to Index Protocol would be:
- Create Proposal: An oSnap-enabled Snapshot proposal is created. This process is the same as an ordinary Snapshot proposal with the addition of transaction data that will be verified and executed if the proposal passes.
- Vote: INDEX holders vote on the proposal like any other Index Coop Snapshot proposal
- Post Bond: If INDEX holders approve the proposal, 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), posts the bond for DAOs, and covers gas costs for execution (there are no fees to use oSnap).
- Execution: The transactions can be executed if no dispute arises about the proposal’s accuracy during the challenge period.
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 incorrectly disputed proposal can be re-proposed to the oracle for execution without revoting. It is important to note that the dispute resolution decided by UMA token holder votes does not determine if the transactions can be executed; it is only the bond allocation between the proposer and the disputer.
UMA created and continues to maintain 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. 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
Benefits
The benefits of Index Coop adopting oSnap are:
- Controller capabilities, such as adding and removing smart contract modules or adapters for Index Protocol, will be secured in a more decentralized and trustless manner
- oSnap enables INDEX voting to more fully govern Index Protocol and reduce the role of the Safe multi-sigs (though signers - appointed by INDEX vote also - can still act as a fail-safe, if needed).
- Transaction payloads included in proposals that voters approve are trustlessly and permissionlessly executed, increasing transparency and decentralization.
- Automatic transaction execution by UMA bots is faster than waiting for multi-sig signers, and the bot pays the gas costs for execution. These bots pay for the gas cost of the transaction execution instead of the multi-sig signers.
- The UMA team continuously makes frontend improvements based on 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, which is the same interface used by disputers verifying and disputing for other third-party integrations (Polymarket, Sherlock, Cozy, etc.).
- 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.
Drawbacks
While we (at UMA) recognize that oSnap is new to Index Coop, oSnap has been deployed without problems to other ecosystems. We hope to forge a stronger relationship with Index Coop to overcome the unknown nature of the technology and the team supporting it.
It is worth noting that automation tools like this are only as secure as the voting structure and votes themselves. Snapshot configuration now becomes an attack vector for those with authority to make proposals, where previously offchain proposals were still gated by Safe signers. We plan to work with Index Coop to ensure the snapshot strategies are sound and configured correctly for their implementation and Index Coop is comfortable with the steps to include transfers in Snapshot proposals.
Onchain bot proposed transactions may expose the treasury to funds being drained if there is an error in the mechanism or transaction payload approved on Snapshot. The waiting period, challenge period, and the bot proposing transactions directly from Snapshot help alleviate that risk, but it’s challenging to guarantee no such actions can ever occur.
While oSnap has been audited by Open Zeppelin, there may be unforeseen vulnerabilities, as with any system.
Future Implementations
Index Coop intends to add oSnap to other functions of the DAO in the future. Those changes are not a part of this proposal but will be specified in a future proposal after a successful rollout of the oSnap for the Index Protocol Controller Safe.
Vote
For - Transfer Controller ownership to the new Index Protocol Controller Safe with oSnap enabled
Against - No change