The Soroban Security Audit Bank, backed by the Stellar Community Fund, provides funding for security audits to eligible SCF-awarded projects building Stellar smart contracts. That's an incredible opportunity. But to make the most of it, you need to arrive audit-ready. A well-prepared codebase means a faster, deeper, and more valuable audit. This guide walks you through each phase of preparation so you can set your project up for success.

1. Design for Security from Day One

"Security starts at the whiteboard, not at the code review" is a traditional maxim of cybersecurity. Before you write a single line of Rust, invest time in these steps:

• Define your invariants. What properties must always hold true in your system? (e.g., "total supply never exceeds X," "only the admin can pause the contract.") Writing these down early gives you a north star for development, testing, and eventually, formal verification.
• Perform threat modeling using STRIDE. The Stellar Development Foundation follows the “STRIDE” framework and requires threat modeling as part of the Readiness Review. STRIDE helps you systematically identify threats such as spoofing, tampering, information disclosure, and denial of service. Stellar provides a full Threat Modeling How-To Guide and a ready-to-use STRIDE template.
• Think outside the block(chain). Over the last year, many of the most successful attacks in crypto were "web2.5" attacks - using traditional web2 techniques to compromise keys. So, it's critical to consider a safe and robust security architecture adhering to the principle of least privilege as well as paying close attention to hot/cold wallet division.
• Beware of resource DoS. An important Soroban innovation is its sophisticated resource model. However, it forces protocol designers and builders to pay close attention to resource utilization as early as possible to avoid denial-of-service (DoS) attack vectors. Consider instance storage limits and avoid unbounded loops. Choose between Instance and Persistent storage deliberately, enforce strict bounds on all user-controlled writes, and account for storage rent costs in your threat model.
• Document your architecture. Capture the high-level logic of operations, trust assumptions, data flows, and the roles of each contract. Reviewers, both internal and external, need this context to evaluate your code effectively. The Audit Readiness Checklist makes it clear: your submission should contain all the context a reviewer needs. 

Need hands-on guidance? Certora’s workshop on Mastering Threat Modeling (April 21, 2026) will dive into the STRIDE framework. And join our next Security Office Hours for Stellar Builders to ask questions in a live session with a Certora security expert.

2. Write Clean, Verification-Friendly Code

How you write your contracts directly impacts how thoroughly they can be tested, analyzed, and formally verified. A few habits go a long way:

• Use standard libraries. Don't reinvent the wheel for common patterns. Look to trusted sources such as the OpenZeppelin Soroban Helpers library to provide well-tested, community-reviewed building blocks.
• Watch for common security issues. Check your code for authorization/authentication issues, integer overflow, arithmetic bugs and rounding errors, improper error handling, and storage key collisions. Perhaps search The Soroban Security Portal’s vulnerabilities list for keywords related to your protocol to learn from earlier projects.
• Keep functions small and modular. Isolate math formulas into their own pure functions with no side effects. This makes logic easier to reason about, test in isolation, and verify with automated tools.
• Avoid circular dependencies between contracts. Clean dependency graphs reduce complexity and make your system easier for auditors to understand.
• Write for verifiability. Patterns like avoiding deeply nested data structures and minimizing use of Option types make your code friendlier to formal verification engines. For a deeper dive, see our blog post: Writing Verification-Friendly Smart Contracts in Rust.
• Broaden your scope. Consider any off-chain code, validate all inputs, and review security best practices for authentication, authorization, secrets management, etc. The Soroban Registry Security Guide is a good reference.

3. Test Rigorously

Auditors are far more effective when they can focus on subtle logic bugs rather than catching issues your own tests should have caught.

• Aim for high test coverage. Use cargo test across your contract modules. Cover not only the happy path, but edge cases and error handling too.
• Fuzz test your contracts. Fuzzing throws randomized inputs at your code to surface unexpected crashes and logic errors. Stellar provides an excellent fuzz testing guide to get you started.
• Run integration tests on testnet. Unit tests are great, but end-to-end testing on a live testnet validates that your contracts behave correctly in a realistic environment, including cross-contract calls, resource management, and transaction sequencing.

4. Run Security Tools Before You Apply

The Audit Bank's Pre-Audit Preparation phase requires you to use self-service security tooling to identify and fix vulnerabilities before the external audit begins. Explore Stellar’s list of recommended Security Tools. When you get one passing, integrate it into your CI/CD pipeline so they run automatically and catch any regressions that could slip in as you make those final fixes:

• Static analysis with tools like Scout, which detects common vulnerability patterns in Soroban contracts.
• Formal verification with Certora Sunbeam, our purpose-built formal verification tool for Soroban. Sunbeam verifies the deployable Wasm bytecode (not the Rust source) so you can be confident the compiled contract upholds the correctness properties you specify. Note that formal verification isn't covered in initial Audit Bank engagements, but it can be provided as part of follow-up “traction milestone” audits.

The goal is simple: fix the low-hanging fruit yourself so your auditors can focus their expertise on the deep, subtle vulnerabilities that even the best automated tools still miss.

5. Submit a Strong Application

When you have received an intake form and you’re ready to apply, make sure to:

• Include all required documentation. Architecture diagrams, threat models, test results, deployment instructions … everything on the Audit Readiness Checklist. Remember: the review panel only considers what's in your submission.
• Define a thoughtful audit scope. Don't limit yourself to just the core contract code. Consider whether cross-chain integrations, off-chain components, governance mechanisms, or admin flows should be in scope. A broader scope means more comprehensive protection.
• Freeze. This should go without saying, but be prepared to keep your codebase untouched during the audit. This minimizes confusion between you and the audit team during the audit and remediation of any vulnerabilities found.
• Request your preferred security partner. During Audit Scheduling, SDF considers multiple factors including an expressed preference for an audit firm. So, you have a voice in who reviews your code.

Once your project is ready, the Stellar Community Fund will email an intake form to eligible SCF-funded projects.

Ready to Build Securely? We're Here to Help.

Certora has been providing security for Stellar since 2023, including Sunbeam for formal verification. Our team brings deep expertise in Rust, DeFi protocol design, and the mathematical rigor of formal methods. Whether you're preparing for your first audit or looking to add formal verification to a follow-up engagement, we'd love to partner with you.

1. Follow the steps above to get your project audit-ready.
2. Bring your questions to our next Security Office Hours for Stellar Builders.
3. Request Certora as your security partner on your Audit Bank intake form.

The Stellar ecosystem is building something extraordinary. Let's make sure it's built on a rock-solid foundation.