Building on Stellar Soroban? Grab this security checklist to avoid vulnerabilities

Preparing for a Soroban Security Audit?

You’re in the right place at the right time!

After conducting numerous Soroban security audits, we’ve compiled a straightforward Security Checklist to help you prepare and ensure your project is audit-ready.

What is Soroban?

Stellar is a layer-1, open-source, decentralized blockchain network designed for fast, low-cost transactions.

Soroban is Stellar’s native smart contract platform, built to integrate seamlessly with the Stellar network. It provides a developer-friendly experience with tooling for static analysis, formal verification, and fuzzing to enhance security. Because Soroban is deeply integrated with Stellar, it benefits from the network’s fast transaction finality, low fees, and access to existing on-chain liquidity.

While Soroban offers powerful tools, we’ve observed developers often encounter similar challenges. In this article, we outline the most pressing ones.

Veridise’s auditing experience on Soroban

At Veridise, we’ve conducted numerous security audits for the Stellar Soroban smart contract platform. For example, we’ve audited projects such as 57Blocks, Phoenix DEX, HiYield.

We’ve also audited the Stellar Soroban Core, the implementation of the Soroban smart contract language on top of Stellar blockchain infrastructure.

Additionally, our security analysts have shared insights in earlier articles: 📚 How to develop securely on Soroban? Storage types with unbounded data
📚 Veridise enhances Soroban security: Breaking our Teeth on Stale Dependencies

Security checklist for Soroban

General security recommendations on Soroban

1. Define the expected trust assumptions clearly

If your protocol has centralized actors, consider clearly defining the expected trust assumptions regarding them. This helps auditors focus on identifying unexpected centralization issues, providing more value to your security review.

2. Allocate enough time — critical issues must be fixed before deployment

Keep in mind that audit results may uncover critical issues that need to be addressed before deployment. To avoid delays and prevent introducing new bugs during fix implementations, allocate a proper time buffer in your project roadmap for resolving any issues identified during the audit.

3. Check out “7 essential tips to prepare for a blockchain audit”

Check out our blog article “7 essential tips to prepare for a blockchain audit” where we outline key steps to prepare for an audit. By addressing surface-level bugs within your team beforehand, our security auditors can focus on uncovering deeper, more critical vulnerabilities in your project.

Four Soroban-specific details you should know

When designing Soroban contracts, consider the following:

1. Be careful of accepting Vec<T> and Map<K, V> data types as functions’ inputs!

The Val is a raw value of the Soroban smart contract platform that types can be converted to and from for storing, or passing between contracts. Reference.

When the elements of a Vec<T> or Map<K, V> are transmitted to the Host environment, they are converted to Vals. However, there is no guarantee that these values can be properly converted back to their expected types (T for vectors or K, V for maps). Without proper validation, storing them in the contract can be dangerous, as attempting to retrieve and use them later could halt contract execution.

References here and here.

2. Write fuzzable Soroban contracts

Stellar has been actively developing a framework for fuzzing Soroban smart contracts. Relevant documentation can be found here, and they have built a token fuzzer available in this repository.

To make Soroban contracts more suitable for fuzz testing, consider Stellar’s key recommendation:

The most important thing to know about fuzzing soroban contracts: never call panic! and related functions to handle errors that may occur during normal operation: the fuzzer views panics as bugs. Instead, use the Soroban-specific panic_with_error! macro, which the fuzzer can distinguish from a bare panic!.

For additional tips see the end of this video presentation.

3. Be mindful of contract dependencies

It is common to divide a protocol’s functionality across multiple contracts, creating dependencies among them. If your protocol follows this approach, be cautious when using Soroban’s createimport! macro to import another contract’s binary.

The issue with this macro is that it does not enforce imported contracts to be explicitly listed as dependencies. As a result, a contract (A) might be deployed with an outdated version of another contract (B) it depends on, without raising any errors during testing.

More details on this issue and its mitigation can be found in the Veridise article here.

4. Managing Unbounded Data in Soroban Storage

When developing Soroban smart contracts, ensure that unbounded data is not stored in Instance Storage, as it loads all data with each contract interaction, leading to increased costs and potential DoS vulnerabilities. While Persistent Storage is more suitable for unbounded data, it can also pose risks if data is stored in a single growing structure. Distribute data across different storage slots to prevent reaching maximum ledger entry sizes.

More details on these issues can be found in the Veridise article here.

Enjoy the development!

We hope this Soroban security checklist helps you prepare for a smooth and secure launch. Be sure to check out our other articles on Soroban security best practices:

📚 How to develop securely on Soroban? Storage types with unbounded data
📚 Veridise enhances Soroban security: Breaking our Teeth on Stale Dependencies

Editor: Mikko Ikola, VP of Marketing