Abstract
OpenZeppelin, as the Security Member of the ARDC, was asked to review the recent Event Horizon proposal that passed its snapshot vote. We have been asked by the DAO to provide security considerations for voters when the proposal reaches its on-chain Tally vote. We have generally formed our review process from DeFi Safety’s scoring process to set expectations for Event Horizon’s security posture and make recommendations to mitigate risk.
In the course of our review, we discussed many of our findings with the Event Horizon team and found their team to be responsive and helpful with our inquiries. We now share our findings and recommendations below to help the Event Horizon team improve their security stance and to better inform Arbitrum delegates on the potential risks that should be carefully considered before moving to an on-chain vote.
Review Summary
Team
The Event Horizon Team first began publishing work in July 2023. They have an active Discord and have been very responsive to user questions there and in other community forums. They have an active documentation site which highlights their projects including DAO token staking. They have also written several blog articles about DAO governance on their blog.
The Event Horizon team has been operating and participating in DAO voting for over a year. They have also recently received large-scale delegations from communities such as Gitcoin. It’s important to note that some of their stated claims of performance in other DAOs is based on voting activity, not total delegations. For example, they claim to be the “10th largest voter in the Uniswap Ecosystem” but they are only the 108th largest delegate listed on Tally. We point out this distinction to ensure that readers do not conflate active voter with total delegation rankings. The Event Horizon team also provided further clarification on the terminology used:
“voter” and “delegate” are clearly completely different terms. The clarification being a highlight that we don’t say “delegate” we say “voter” and voter is different than delegate. Many delegates have never voted. Aave as an example, the vast majority of the largest delegates are not voters. Again, given most large delegates haven’t voted or are “ghost delegates”, “voter” is the salient metric.
Recommendation:
We encourage Arbitrum community members to be familiar with the team behind this proposal and fully understand the context and claims of their past performance.
Code & Documentation
The proposal’s voting system as described needs to aggregate votes and submit them on-chain by the described logic. All of this occurs today off-chain by code that is currently unavailable for scrutiny. The Event Horizon team did inform us that their architecture utilizes the Snapshot and Tally SDK & APIs.
Recommendation:
OpenZeppelin believes strongly in the trust that comes from on-chain deployments and largely eschews projects where the code is not available. We encourage Event Horizon to deploy all of their voting logic on-chain and/or open up their architecture for public scrutiny before it goes live for usage on Arbitrum delegations. The Event Horizon stated their intent to address this recommendation with the following response:
Regarding documentation of off-chain systems, we’ll include it in our public documentation and make it easily visible from our web client.
There is one component that is on mainnet: the required voter pass. It is an upgradeable contract and its source code is hosted here. Relevant addresses are:
- Voter Pass Proxy Contract:
0x4E911626Fa378cC95fB1A26Cc272c070eF79e4b7 - Voter Pass Implementation Contract:
0x68fECD506273714B25B0293F26dC40E5fc041c28 - Voter Pass Owner:
0xFAD69Bd739c64cC8e3f1C3bb3B60fe4f160174Cc
The proposal requires the development of an Arbitrum-specific “franchiser” contract which allows the DAO to control the delegated tokens. Event Horizon references an existing Uniswap version that was reportedly audited by Trail of Bits. That audit report has not been published but the results are reportedly available as GitHub issues here.
Recommendation:
We recommend that the Franchiser contract be subjected to a security audit before being deployed (as is suggested by the Event Horizon proposal). This could be conducted through either the Arbitrum Foundation or with OpenZeppelin directly as a member of the ARDC. In any case, the audit should be completed and published before any delegations are assigned.
Security & Access Control
The currently deployed Voter Pass contract previously mentioned has a single EOA as its owner and is upgradable without a timelock. If the Owner EOA were to be compromised, it could be used to manipulate delegated votes.
Recommendation:
We recommend that Event Horizon use an M-of-N multi-sig for any ownership roles in the Voter Pass contract and any other contracts that impact Arbitrum delegations. We also recommend that the Event Horizon team consider implementing a timelock for upgradable contracts and/or make public commitments for how upgrades will be performed in a safe and transparent manner. Regarding the Multi-sig, the Event Horizon team stated their intent to address this recommendation with the following:
As for the VoterPass ownership - I think that’s a good recommendation. We will change to a Multi-Sig.
As the tokens are to be delegated and not outright transferred, there should be no risk of losing custodial control of the 7M $ARB as long as the Franchiser contract is secure. The worst-case risk aside from Event Horizon’s accounts being compromised, is if Event Horizon acts as a bad-faith delegate and allocates the votes contrary to how they promised.
In these cases, Event Horizon states that an Oversight Committee multi-sig made up of “5 existing, notable delegates” will have ownership control over the Franchiser contract where delegations are received which will enable them to veto votes. However, Event Horizon later stated that this Oversight Committee will only be able to force Event Horizon delegations to abstain from a vote and nothing else.
It’s also important to note that the Event Horizon team states that the Oversight Committee will only have 24 hours to veto decisions “between the closing of the Event Horizon proposal, and the underlying DAO’s proposal”. It could be challenging for a 3-of-5 multisig to identify a vote that should be vetoed and sign a transaction within this 24 hour period, although the Oversight Committee could still enact a veto anytime prior to the the closing of the Event Horizon proposal if a problem was detected early-on.
The current setup in the Franchiser contract allows the Owner role to recall delegations, which may be desirable if the Event Horizon system is ever compromised or the voter pools begin acting in bad-faith. When discussing this mechanic with the Event Horizon team, they stated:
While the proposal doesn’t explicitly state that the DAO can undelegate, we think it’s a useful function to allow the DAO to undelegate through the OC (Oversight Committee) should they wish. The OC would operate through the DAO for this. To clarify: the OC cannot remove delegation per the constraints of the proposal. even though they technically can. a kosher removal of delegation would first have to be approved by the DAO on tally and then can be carried out by the OC
Recommendation:
We recommend that Arbitrum delegates carefully think through the responsibility and powers of the Oversight Committee to manage the delegations to Event Horizon. We recommend a greater time window than 24 hours for the Oversight Committee to make vetos and that the powers to recall delegations also be retained in the Franchiser contract for emergency scenarios. We encourage a careful selection process for delegates to serve on the Oversight Committee to ensure they can actively monitor and manage the delegations assigned to Event Horizon and respond to potential issues.
Overall, it’s important to emphasize that the Oversight Committee serves a critical function of managing the ARB delegations to Event Horizon and would be the DAO’s primary responder to any security or governance issues that might arise. All other access control permissions maintained by the Event Horizon team in other contracts should be protected and restricted to minimize their potential impact over the ARB delegations.
Conclusion
We’ve provided several important security recommendations here that we encourage the Event Horizon team to implement in their system to enhance the system’s transparency and security stance before deploying any contracts to be used for ARB delegations. We have also highlighted several risks and concerns that Arbitrum delegators should consider in their decisions regarding the Event Horizon proposal as well as the selection for the Oversight Committee. We are happy to engage in further discussion and questions in the forum.
For more information on OpenZeppelin’s role as Security Member of ARDC, please visit our Notion homepage.