Security Risks for Staking Providers

Over the past eight months, a series of companies have undergone smart contract security audits with Runtime Verification. These companies have something in common: they are staking providers operating in the DeFi ecosystem.

This blog post aims to explain some common mistakes, patterns and aims to create awareness about security threats affecting staking providers and other DeFi projects.

DeFi, a paradise for hackers

Over the past year and a half, DeFi has experienced exponential growth with more than 2.9 million users at the time of writing this blog post, and it doesn't show any signs of slowing down.

Many DeFi projects have been born in the past few years, and with that, a new opportunity for users to play with their tokens and earn money in different ways such as staking, yield farming, providing liquidity, etc.

If we think about it, this scenario is a boiling pot for disaster if projects are not careful with their security. Many projects are created in a rush to get to market and don't consider security one of their main priorities.

Even if that's not the case for most projects, the ratio is high enough to negatively impact how the community (and especially outsiders) perceives the ecosystem. Just think about how many times you have read news about a compromised project on Twitter.

There are many new projects with tons of tokens stored on their contracts, and that’s attractive for anyone with bad intentions. If a hacker finds a way to penetrate the contract through a bug or a vulnerability, it's payday.

Staking providers in the DeFi ecosystem

One of the ways users can make passive income from their tokens is through a staking provider. For those who aren't familiar with the term, staking is the process of actively participating in transaction validation on a proof-of-stake blockchain. A minimum amount of tokens and hardware is often needed to be a validator, making it inaccessible for most users. Staking providers take care of everything, and you, as a user, can stake any amount and get rewarded without worrying about anything else.

Like any other platform, some security risks are involved when using a Staking Provider. Suppose you are a user willing to participate. In that case, your tokens must be deposited in the platform's contract, which translates to losing total control of your tokens for a period of time.

Because of this, projects providing staking services must have security as one of their main priorities. Some ways for projects to ensure a maximum level of security are smart contract audits, testing, formal verification, an in-house security team, and bug bounties. Another way to improve security is to consult different experts and not settle, for example, with just one audit from one company.

Although the more security techniques a project applies, the more protected the project it's going to be; there is no way to guarantee if a code is free of vulnerabilities. For those wanting to go the extra mile to protect their users, insurances against smart contract failures are a good option.

Security recommendations for staking providers

Our team at Runtime Verification has carried out a series of security audits on staking providers such as StakerDAO, StakeWise and Stakefish. Instead of just listing concrete results found during the audits, we are going to explain common mistakes in DeFi projects and staking providers. But first, let's take a look at the methodology approach followed by our team to make the audits as thorough as possible:

• First, the business logic of the contract is rigorously reasoned about, security-critical properties are validated to ensure the absence of loopholes in the business logic and inconsistencies between the logic and the implementation.
• Secondly, the team carefully checks if the code is vulnerable to known security issues and attack vectors.
• Next, a part of the compiled bytecode is symbolically executed to systematically search for unexpected, possibly exploitable, behaviors at the bytecode level as a result of EVM quirks or Solidity compiler bugs.
• To finalize, Firefly, a tool to measure coverage at the bytecode level, is employed in most cases to identify missing test scenarios and improve test quality.

Runtime Verification's team has encountered a series of continuous mistakes and vulnerabilities when conducting audits on staking providers and DeFi projects. For those working on a DeFi project, double-check your code, take a look at the following potential vulnerabilities and how to avoid them:

• The importance of identifying and verifying properties for the LP token's minting/burning mechanism. For example, one desirable property is that the value of the total supply of LP tokens should be less than or equal to the staked assets. As seemingly obvious as it can look, that property could be broken due to logical loopholes or implementation bugs in the minting/burning mechanism. In this concrete case, mathematically formalizing the minting/burning logic and verifying its important properties can reveal hidden flaws that extensive testing can not detect.
• Always rigorously analyze rounding errors in staking reward computation arithmetics. One example would be to mathematically analyze the bounds of rounding errors to see if they can be accumulated to a significant amount over a long period of time, breaking certain critical properties of the system. Another example would consist in analyzing whether it's possible to make "free" money by a repeated action of staking followed by unstaking, exploiting such rounding errors.
• Review the reward distribution mechanism. There are two main categories of how projects can distribute rewards: active and passive distribution. In an active distribution model, new rewards are periodically computed and automatically distributed to users. In contrast, in a passive distribution model, users need to explicitly request to redeem their new rewards. The active distribution model provides a better user experience than the passive model, but the business logic is much more complicated. A sophisticated logic is harder to correctly implement and inherently has more attack surfaces. Finding the right balance between the two is the key to provide a decent user experience within reasonable implementation and maintenance costs.
• Avoid flash loan vulnerabilities. Lately, flash loan attacks are among the most common hacks on DeFi projects. A typical pattern found in a recent series of attacks consists of the following situation: if unstaking assets can cause losing other users' funds in certain corner case scenarios, this could be exploited for flash loan-based price manipulation attacks. Thorough reviews are needed to prevent and make much harder flash loan attacks.

These are just some common mistakes, but there are countless vulnerabilities that a project can face, and its users and the community will cherish any efforts towards improving the overall security. Remember, it's never too late to step up your game.

About Runtime Verification

Runtime Verification is a technology startup based in Champaign-Urbana, Illinois. The company uses runtime verification-based techniques to perform security audits on virtual machines and smart contracts on public blockchains. It is dedicated to using its dynamic software analysis approach to improve the safety, reliability, and correctness of software systems in the blockchain field.