# Security Analysis of Arbitrum Staking Proposal (ARDC Security Deliverable) **URL:** \ **Category:** ARDC Security Member\ **Created:** [August 9, 2024, 8:18pm UTC](https://forum.arbitrum.foundation/t/security-analysis-of-arbitrum-staking-proposal-ardc-security-deliverable/26197 "2024-08-09T20:18:15Z")\ **Posts on this page:** 1\ **Showing post:** 2
**Author:** ![Frisson](https://yyz1.discourse-cdn.com/flex029/user_avatar/forum.arbitrum.foundation/frisson/32/2288_2.png) [@Frisson](https://forum.arbitrum.foundation/u/Frisson)\ **Post date:** [August 11, 2024, 8:11pm UTC](https://forum.arbitrum.foundation/t/security-analysis-of-arbitrum-staking-proposal-ardc-security-deliverable/26197/2 "2024-08-11T20:11:27Z")
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](https://forum.arbitrum.foundation/t/response-to-arbitrum-staking-proposal-ardc-research-deliverable/26048/1), 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. --- _[View the full topic](https://forum.arbitrum.foundation/t/security-analysis-of-arbitrum-staking-proposal-ardc-security-deliverable/26197)._