Sicherheit Als Ihre Stärke

A secure source of randomness is one of the most critical components of many decentralized applications. However, perhaps surprisingly, there is currently no on-chain source of randomness that is truly trustless. Almost all solutions that have been used in practice are either fundamentally broken or require the participants involved to trust each other or a third party. Why is that?

In this two-part series, we’ll discuss the different attempts to construct a secure source of randomness, and why all currently known solutions have fundamental shortcomings in some aspect.

Recently, there’s been a lot of buzz around a DAO vote of Solend – one of Solana’s largest lending projects. It seeks to enact restrictions on large positions, and to temporarily take control of an existing user’s position in order to liquidate it in a controlled fashion. This can be done by upgrading the smart contract’s code.

But wait! Aren’t smart-contracts supposed to be immutable?

Only in a perfect world. No code is perfect and smart contracts aren’t either, so it can be necessary to change or fix them. This is called a program upgrade.

In this post, we’ll give an overview of one of the most fundamental and yet somehow often-overlooked aspects of the security of a smart contract, namely: Who has the power to initiate program upgrades? How can users be sure that the developers don’t make undesired changes? Or even worse, just run off with their money?

Over the past year and a half, we have spent a lot of time looking at the Solana core code, reporting over 80 bugs of varying severity. This blog post is the first in a series detailing the most interesting vulnerabilities we found and reported in Solana core, hopefully inspiring more whitehats to keep the ecosystem safe. All bugs presented here were responsibly disclosed under the Solana bug bounty program and are now fixed.

In this post, we want to raise awareness about the five most common vulnerabilities in Solana contracts that we keep finding during our audits. We’ll keep the vulnerability descriptions short and concise and provide a simplified example as well as a TL;DR for each vulnerability so that you can easily reference them while coding.