Security Analysis of Arbitrum Staking Proposal (ARDC Security Deliverable)

[openzeppelin]

Abstract

OpenZeppelin, the Security Member of the ARDC, reviewed the proposed changes of ARB Staking: Unlock ARB Utility and Align Governance in advance of the snapshot vote. This proposal aims to increase participation and delegation in the ARB ecosystem, by implementing liquid staked ARB.

Arbitrum DAO voter participation has been steadily declining post launch. With the recent attempted/successful attacks on other large DAO’s (Compound, etc.), ARB governance is currently at risk of incurring a governance attack, which puts the DAO’s $2b+ treasury at risk. If enacted, this proposal will create a mechanism for ARB holders to stake their tokens into Tally Protocol’s liquid staked ARB token (tARB, recently renamed stARB) to incentivize users participating in governance. This would assist in mending the current issues by creating a financial utility that will stream rewards in the future for holders that are actively participating. To measure such participation, the staking contracts will integrate with Karma, which will keep track of each users Karma Score. Karma Scores will be calculated based on a given users forum activity score, off-chain, and on-chain voting participation. The DAO will define this score requirement for a user to be considered an active delegate, and has rights to block Karma scores, if the score is deemed invalid.

We now share our findings and recommendations below to help improve the security of the design and to better inform Arbitrum delegates on the potential risks that should be carefully considered before moving forward.

Review Summary

Integration Risks With Tally Protocol LST

Tally will create the ARB Staking and tARB token contracts to be integrated into the existing DAO platform. The Initial staking contract supports Uniswap’s Unistaker and Tally Staker. Tally Staker extends upon Unistaker to be customized for Arbitrum’s governance architecture and fee collection mechanism. Such features will include delegate compensation along with a way to add arbitrary fee sources as rewards. Refer to Tally’s introduction article for a more in-depth overview of the protocol.

There are always some risks associated with adding new integrations to an existing protocol. This will increase complexity for the DAO while creating a wider attack surface for malicious actors. It should also be noted that the Tally Protocol LST is a new type of offering to the market and could even have unforeseen risks in the future. Such possibilities are unknown currently due to not having more implementation details or source code. This makes it hard for both the community and our team to further evaluate potential integration risks.

The event in which the tally protocol ever turns awry, a malicious actor could:

• Take full control of the staking contracts
• Steal or temporary/permanent freeze other user funds
• Manipulate the LST prices in their favor
• etc.

All examples would give the malicious actor the ability to then attempt a governance takeover. These may be prevented from an audit however, any that slip through would leave the DAO at risk.

Recommendation:

We recommend that extra precautions should be put in place to help protect the DAO if such event were to happen. It would help in easing any damage to the DAO that could occur due to an attack upon the Tally Protocol. This also goes for any future Integration with other Arbitrum staking systems that could be developed.

General Risks That Come With LSTs

As mentioned above the integration with Tally protocol LSTs adds another layer of complexity to the DAO system. This is due in part to the LST token itself, again broadening the attack surface of the DAO at large. On top of this, an LST tokens value does not always reflect the value of the underlying staked assets. This sort of risk can lead to potential price discrepancies and arbitrage opportunities. It becomes highly possible that during a downturn in the market that the price of the LST token could fall below the price of the underlying asset, potentially incurring a loss for the token holders at the maturity of the staked assets, subsequently damaging the DAO itself. Lastly, upon the initial launch of the LST there will be liquidity risk due to fragmented/limited liquidity in both primary and secondary markets. It should be noted that there is the potential for unfavorable price movements.

Recommendation:

Our recommendation here is again to proceed with caution when moving forward with this proposal. For example, referencing Delphi-Digital response, were as the ARB supply grows and if the quorum increases too quickly w/ token supply. The same issue could arise all over again leading to people not being incentivized to stake/delegate. Moreover, An increase in complexity and attack surface for the DAO opens it up to new ways of being attacked. In addition, with the volatile price movements of LSTs extra care should be taken with launching to help prevent any risks that come with it. This could include, thoroughly fork testing different market scenarios such as initial launch, during a market downturn, etc. Proper market monitoring should be put in place to alert the community to take action if needed. While also ensuring the entire protocol be subjected to a security audit.

Conclusion

We have provided several important security recommendations here that we encourage to carefully consider to enhance the security stance of the system. We are impressed with the level of thoroughness from the Arbitrum community discussing the potential risks of the proposal. We have also highlighted several risks and concerns that Arbitrum delegators should consider in their decisions regarding this proposal. We are more then happy to further discussions and questions in the forum.

For more information on OpenZeppelin’s role as Security Member of ARDC, please visit our Notion homepage.

[Frisson]

Thank you for taking the time conduct a security analysis of ARB staking. On behalf of Tally, I’d like to share a few points in response to your analysis.

@openzeppelin

Such possibilities are unknown currently due to not having more implementation details or source code. This makes it hard for both the community and our team to further evaluate potential integration risks.

The current phase of the proposal is to develop the staking system. The DAO will have the opportunity to evaluate the implementation details and source code of the system once it is complete. As indicated in the proposal, the DAO will vote separately on the implementation of ARB Staking after it has completed development and audit.

@openzeppelin

The event in which the tally protocol ever turns awry, a malicious actor could:

• Take full control of the staking contracts
• Steal or temporary/permanent freeze other user funds
• Manipulate the LST prices in their favor
• etc.

All examples would give the malicious actor the ability to then attempt a governance takeover. These may be prevented from an audit however, any that slip through would leave the DAO at risk.

ARB Staking would be implemented as a proxy contract controlled by the Arbitrum Core Governor, just like the ARB token and the Arbitrum Governance contracts.

ARB staking would have a few administrative functions, controlled by Arbitrum DAO:

• Block incorrect Karma scores
• Change the score provider
• Change the staking fee schedule

stARB (the Tally Protocol LST) would be deployed as an immutable, non-upgradeable contract. The delegation strategies would be assigned by the Arbitrum DAO. The only part of the system Tally manages is the rebalancing of underlying assets.

@openzeppelin

We recommend that extra precautions should be put in place to help protect the DAO if such event were to happen. It would help in easing any damage to the DAO that could occur due to an attack upon the Tally Protocol. This also goes for any future Integration with other Arbitrum staking systems that could be developed.

We agree. We included a budget for $60,000 of audits in the proposal. We’re open to further suggestions of precautions that can be taken from the ARDC and the Arbitrum community.

@openzeppelin

As mentioned above the integration with Tally protocol LSTs adds another layer of complexity to the DAO system. This is due in part to the LST token itself, again broadening the attack surface of the DAO at large. On top of this, an LST tokens value does not always reflect the value of the underlying staked assets. This sort of risk can lead to potential price discrepancies and arbitrage opportunities. It becomes highly possible that during a downturn in the market that the price of the LST token could fall below the price of the underlying asset, potentially incurring a loss for the token holders at the maturity of the staked assets, subsequently damaging the DAO itself. Lastly, upon the initial launch of the LST there will be liquidity risk due to fragmented/limited liquidity in both primary and secondary markets. It should be noted that there is the potential for unfavorable price movements.

The underlying ARB staking contracts, like UniStaker, will not have a withdrawal period. The positions are non-liquid and rewards are dripped continuously over time

stARB does/can have a withdrawal period, configurable by the DAO. The expectation is that it will be very short and is there only to prevent people from abusing the reward mechanism (i.e. staking right before a reward, claiming a chunk of it, and immediately unstaking).If there is a price difference, arbitrageurs can instantly unstake stARB and sell it as ARB to close the price difference. This easy arbitrage opportunity minimizes price discrepancies and makes it difficult for any potential governance attacker to acquire ARB at a discount.

Our recommendation here is again to proceed with caution when moving forward with this proposal. For example, referencing Delphi-Digital response, were as the ARB supply grows and if the quorum increases too quickly w/ token supply. The same issue could arise all over again leading to people not being incentivized to stake/delegate.

Could you expand on this point? We expect the opposite effect. ARB staking rewards participation, making it easier to reach quorum.

Moreover, an increase in complexity and attack surface for the DAO opens it up to new ways of being attacked. In addition, with the volatile price movements of LSTs extra care should be taken with launching to help prevent any risks that come with it.

I believe we’ve addressed most of these concerns above. Are there other classes of attacks that you’re concerned about beyond what has been specifically addressed in this post?

This could include, thoroughly fork testing different market scenarios such as initial launch, during a market downturn, etc. Proper market monitoring should be put in place to alert the community to take action if needed. While also ensuring the entire protocol be subjected to a security audit.

We agree and plan to address all of these items in the ARB staking implementation.

[openzeppelin]

Thank you for the response and clarification on some points of our analysis.

Could you expand on this point? We expect the opposite effect. ARB staking rewards participation, making it easier to reach quorum.

You’re correct that ARB staking is expected to increase participation and make it easier to reach quorum, especially in the short-term. However, our concern is about long-term sustainability and the potential for unintended consequences.

As ARB’s circulating supply increases over time due to token unlocks, the relationship between unlocked tokens, quorum requirements, and active participation becomes crucial. While the staking program aims to boost participation, there’s uncertainty about whether this increase will keep pace with the growing supply. If quorum requirements are not managed actively in relation to the unlocked supply, or if the rate of new active participants doesn’t match or exceed the rate of supply increase, governance could face challenges:

1. Misalignment Risk: The ratio of unlocked tokens to quorum requirements may become imbalanced, potentially making governance decisions either too easy (if quorum is too low relative to supply) or too difficult (if quorum is too high).
2. Participation Gap: Even with increased staking, the growth in active participants may lag behind the growth in token supply, making it progressively harder to reach quorum over time.
3. Governance Efficacy: This potential misalignment could affect the DAO’s ability to make timely and representative decisions, especially if a significant portion of the growing token supply remains passive in governance.

To address this, the DAO should regularly review and potentially adjust quorum requirements in line with both the unlocked token supply and demonstrated governance participation rates.

I believe we’ve addressed most of these concerns above. Are there other classes of attacks that you’re concerned about beyond what has been specifically addressed in this post?

There are no other classes of attacks that we are concerned of at this moment that should be addressed. If any come up at any point in the future we we will make sure to bring them up to continue the discussion.

[dennison]

Thank you OZ team for taking the time to review our proposal! Very much appreciated!

There are a few points that I wanted to emphasis that might help explain how we are thinking about it a bit better.

This is a bit simplified leaving out some details from the proposal but should help show the architecture better.

Staker

The base layer of the protocol is Staker, based on Uniswaps audited UniStaker. Staker works much like Uniswaps Franchiser in that each pool of staked tokens are held in their own special purpose smart contract which can only delegate their voting power. The Staking contract is simple, permissionless, audited and has no special authorities. Optionally it can be deployed to be immutable, or upgradable directly by the ARB DAO. (I’ll refer to it as immutable in this post).

This means that the base layer staking is very safe. Each user owns their own staking vault, and is free to use staker regardless of whether or not they use the Tally Protocol. This allows for maximum flexibility for the DAO and lets others also build yield generating infrastructure for the Arb Token.

The Tally Protocol works by administering it’s own vault, not any other vault. The Tally protocol has no special powers over the staking contract, and has no access to users tokens other than the tokens it manages itself.

This is important because it allows other teams, like @OpenDollar to build their own applications on top of staker and pass on revenue to their users. OpenDollar already has sponsored Delegate Vaults which allows OpenDollar protocol controlled ARB tokens to participate in governance. This would allow their protocol to also stake and pass revenue to OpenDollar. We think this is an effective model to help protocols build businesses.

Tally Protocol

The protocol is a software convenience layer on top of staking designed to make the process of doing the work of selecting delegates (and holding them accountable!) easier for staker.

Again, the Tally Protocol only manages it’s own staked token vault, no one elses.

What the Tally Protocol does that is special, is that it creates a receipt token for the ARB which is staked through it, called stARB, and it returns it to the user.

The underlying tokens that the Tally Protocol have staked on the users behalf are always available to redeem, 1:1 plus rewards, at any time, with no delay or lockup.

This is a very important point. The stARB receipt is functionally equivalent to the underlying token, it can be exchanged at any time. Because of this, there is no risk of a depeg event for the stARB:ARB exchange rate. Any deviation from a 1:1 exchange rate would be instantly arbitraged by 3rd parties staking or unstaking stARB:ARB to capture any deviation in the exchange rate.

Of course this means we need to be very sure that you can always redeem 1:1. To be sure of this we’re doing several things:

Auditing

We will be doing many audits over the course of the lifetime of the Tally Protocol to ensure it’s safe. I myself (Dennison) was an early team member of OpenZeppelin and know how important security is. It’s a top priority.

Simplicity

One of the most powerful tools in security is simplicity. The Tally Protocol itself is very simple, and the contract which manages the token is essentially just a wrapper contract that deposits the ARB token into staker and mints stARB, or takes in stARB, and returns ARB.

The contract is easy to reason about, easy to test, and intentionally designed to be very simple.

To address some of your specific questions:

1. Misalignment Risk: The ratio of unlocked tokens to quorum requirements may become imbalanced, potentially making governance decisions either too easy (if quorum is too low relative to supply) or too difficult (if quorum is too high).

There is no danger of misalignment risk in the protocol as there are no locked tokens.

Holders of stARB have all the same governance rights as ARB holders and the two tokens are effectively identical (except the fact that stARB tokens also earn auto-compounding yield). As there is no lockup period, users are free to move between the two tokens at any time, meaning there is effectively no change in how the tokens interact with governance.

What we do hope happens however is that more token holders participate in governance. If that happens it might be worthwhile revisiting quorum requirements, but keep in mind this is a feature not a bug. There is no leveraged voting power being created here, users are electing themselves to be more active in governance. The delegation strategies the DAO might elect to use in the Tally Protocol are no different than users choosing to delegate their tokens themselves.

Additionally, delegation strategies have no special powers that might present a danger. Token holders are free to change delegation strategies at any time. Poorly implemented delegation strategies do not pose a feedback loop danger, and in the absolute worst case scenario users simply withdraw their tokens, or delegate to themselves.

In essence, the Tally Protocol does not introduce any new variables to the game theory of how ARB governance currently operates. All the expectations we hold to be true in vanilla ARB governance hold true with the Tally Protocol as a governance participant as well.

2. Participation Gap: Even with increased staking, the growth in active participants may lag behind the growth in token supply, making it progressively harder to reach quorum over time.

This is not a concern with either staker or Tally Protocol. All tokens in staking and Tally protocol must be delegated (this is not optional and is core to why staking works: users must do effort to be rewarded such that they are rewarded specifically for their own efforts). This means that increase of tokens staking whether directly, or via the Tally protocol strictly results in an increase of delegated voting power.

In the implementation we are proposing for ARB there are economic incentives to be sure the delegated voter is active as well.

This is actually safer for Arbitrum and ensures that participation in Arbitrum is always high, and grows as more token holders elect to use the staker or the protocol.

3. Governance Efficacy: This potential misalignment could affect the DAO’s ability to make timely and representative decisions, especially if a significant portion of the growing token supply remains passive in governance.

There are no passive tokens in the Tally Protocol or in staking as 100% of staked tokens, whether through the Tally protocol or directly via staker are at a minimum delegated. This means that the efficacy of the DAO is unchanged from todays status quo: either delegates vote, or they don’t. The Tally protocol and staking don’t influence the commitment of our delegates to participate.

In the implementation we are specifically suggesting for Arbitrum there are also requirements that rewards be linked to participation, meaning there is a strong economic incentive to actively participate in governance for both the token holders and their delegate. Staking and the Tally Protocol will substantially works to significantly reduce passive holders and actives the DAO.

Hopefully this helps to address a number of the concerns the OpenZeppelin team has raised and maybe answered a few questions some others might have about the protocol. We’re always happy to talk more about how the protocol works, how it supports a healthy and dynamic ecosystem, and how it drive anti-capture for the DAO.

We’re excited to be able to address all challenging questions about the protocol and look forward to working together with the community.

[havingautism]

very detailed. u guys are really professional