Official Rules

Each Participant needs to meet the Participant Eligibility Rules, the Application and Evaluation criteria, as well as the General Rules (altogether known as “Official Rules”).

Structure

The Soroban Security Audit Program (the “Program”) is structured to enhance the safety and security of Soroban ecosystem projects. Managed by the Stellar Development Foundation (“SDF”), the Program schedules audits for projects and covers up to 100% of the audit cost (see details of co-payment here) with reputable audit firms and strategically allocates them to high-impact projects building on Stellar. Projects undergo a rigorous assessment and auditing process, ensuring robust security, mitigating risks, and fostering trust within the Stellar ecosystem.

Approved Audit Firms

The following audit firms have been pre-approved by the Stellar Development Foundation to participate in the Soroban Security Audit Bank. Additional audit firms coming soon.

• Certora: Specializes in Web3 security providing both audits and formal verification of smart contracts based on mathematical reasoning of code.

• OtterSec: Provides comprehensive blockchain security audits with collaborative approaches; known for securing over $36B in total value locked (TVL).

• Runtime Verification: Offers formal methods and runtime verification techniques to enhance blockchain system safety and reliability.

• Veridise: offers rigorous smart contract and audits backed by deep blockchain security expertise and advanced in-house tooling.

Program Phases

Phase	Description	Duration
Intake & Eligibility	Projects submit audit requests based on clearly defined eligibility criteria.	-
Readiness Review	Each project undergoes a mandatory readiness assessment by a security expert, including threat modeling.	<1 week
Audit Scheduling	Audits scheduled with pre-approved audit firms based on importance, ecosystem impact, availability, and readiness.	1 week
Pre-Audit Preparation	Participants are encouraged to perform self-administered code and security checks with recommended tooling.	2-3 weeks
Audit Execution	Audits conducted by pre-approved audit firms.	1-6 weeks
Post-Audit Resolution	Participants receive a private audit report detailing vulnerabilities and address these promptly.	1-4 weeks
Verification and Follow-Up	Security experts verify remediation; additional audits or formal verification for high-value projects.	2-3 weeks

Phase 1: Intake & Eligibility Submission

Projects interested in participating must submit an audit request using a provided intake form. This intake form is provided to SCF-funded projects which have reached testnet stage or are already on mainnet. This form will detail the division of audit costs between SDF and the projects, and will require detailed information about the project, including:

• Project description and purpose

• Smart contract and technical architecture details

• Development status and GitHub repositories

• Previous security practices or audits

Use the Audit Readiness Checklist and make sure your submission meets all the criteria to pass Readiness Review.

Phase 2: Readiness Review

Upon receiving the intake form, the project will undergo a thorough Readiness Assessment, including:

• Eligibility assessment

• Threat modeling to identify potential security risks

• Assessment of the completeness of provided documentation

• Codebase maturity and review of initial security measures implemented

This phase is expected to take less than one week, after which the project will be informed of its eligibility and readiness status.

Phase 3: Audit Scheduling

If a project passes the readiness review, it moves into audit scheduling. Multiple quotes from pre-approved audit firms will be gathered based on the project's scope and complexity. Audits are then scheduled based on SDF's discretion depending on the best fit considering:

• Expected scope

• Strategic ecosystem impact

• Project readiness

• Audit firm availability

• Project’s preference (if expressed in submission form)

Scheduling decisions are communicated clearly to the participating project.

Phase 4: Pre-Audit Preparation

Participants are expected to use self-service security tooling and internal testing to identify and fix vulnerabilities prior to the external audit. The project team should perform:

• Automated testing with recommended security tools

• Internal code reviews

• Initial remediation of obvious vulnerabilities

This pre-audit phase spans approximately two to three weeks and does not delay audit scheduling.

Phase 5: Audit Execution and Audit Fees

The chosen audit firm performs a comprehensive security audit of the project's smart contracts and related infrastructure. This phase involves:

• Manual code reviews and automated tooling

• Penetration testing and stress testing

• Identification of critical, high, medium, and low vulnerabilities

While SDF covers most of the audit costs, there are cases in which an upfront co-payment from a project to SDF is required. As an example, for the Initial Audit, a project is required to provide a co-payment of 5% of Initial Audit costs to SDF, payable prior to commencement of the audit. However, if a project successfully addresses all identified critical, high, and medium vulnerabilities within 20 business days (verified by SDF with the Audit Firm), this co-payment of the Initial Audit will be fully refunded. Subsequent audits also require co-payment by the project. See details here.

The duration of the audit phase typically ranges between one to six weeks, depending on the complexity of the project.

Phase 6: Post-Audit Resolution

After an audit is complete, projects receive a private, detailed report outlining identified vulnerabilities. To qualify for the refund of the 5% co-pay required for the Initial Audit, projects must promptly address these issues within the stipulated timelines, ideally resolving critical, high, and medium vulnerabilities within 20 business days. The audit firm verifies remediation measures undertaken by the project.

Phase 7: Public Disclosure of Audit Results

Upon successful resolution and verification, the final audit report is published publicly by the audit firm. This provides transparency and assurance to the broader Soroban community regarding the security status of the project.

By participating, projects agree to all phases of this structure, committing to transparency, timely remediation of vulnerabilities, compliance with co-payment obligations, and maintaining the highest security standards to safeguard the Soroban ecosystem.

Audit Co-Payment System

To ensure accountability and efficient resource allocation, projects may be required to co-pay for audits based on their TVL (Total Value Locked) or equivalent traction milestones:

Audit Stage	Traction Threshold	Co-Payment %	Description
Initial Audit	None for priority categories	5% with potential refund*	Covers initial audit to ensure baseline security for newly developed protocols.
Growth Audit	>$10M TVL or equivalent	0%	Focused on scaling projects with moderate traction to validate ongoing security. May include more extensive auditing (e.g. formal verification)
Scale Audit	>$100M TVL or equivalent	0%	Targets high-value projects nearing maturity to ensure robust security measures. May include more extensive auditing (e.g. formal verification)
Pre-Traction Follow Up Audits	N/A	20% for the pre-traction follow-up audit, 50% for the second pre-traction follow-up audit	If additional audits are needed in addition to the Initial Audit and the project hasn’t achieved traction required for Growth and Scale Audit yet, SDF partly covers the first two follow-up audits.

*If the project is able to successfully address all critical, high, and medium issues identified by the Audit Firm within 20 business days, the 5% co-payment of the Initial Audit will be refunded back to the project.

Participant Eligibility

In order to be eligible for an audit, projects must meet the following criteria:

• Projects must have been funded by SCF. Companies with other commercial grants from the SDF are not eligible for participation in the audit bank.

• Projects must pass KYC and sanction checks.

• Projects must be in an eligible priority category or meet non-priority traction criteria.
• Projects must have completed the development of the code portions within the audit scope, be nearly mainnet-ready, and require an audit within 4-6 weeks.

• Projects must have conducted extensive tests on their code and deployed it on testnet for validation.

• As part of their application, projects must submit the results of one of the “self-service tooling” options to include a list of all identified vulnerabilities and a remediation plan for fixing identified critical, high, and medium severity vulnerabilities prior to audit start.

• Projects must include a STRIDE threat model for the project as part of their application.

• Projects must be able to be responsive during the entirety of the audit.

• Projects must be able to cover co-pay depending on their audit stage.

Eligible Categories

Projects must demonstrate increased risk or the potential for a significant impact on the ecosystem.

Priority Categories:

• Financial Protocols: Protocols managing on-chain value, as they are prime targets for malicious actors.

• Widely Used Applications: Applications using stellar smart contracts that are expected to have large-scale adoption ($1M+ TVL, 100K+ active users), where vulnerabilities could undermine user trust.

• Infrastructure Contracts: Oracles, vaults, account abstraction contracts, or similar components that are widely integrated across multiple services.

• Yield-Bearing Token Protocols: Protocols representing real-world value through smart contracts.

Non-Priority Categories Criteria:

Projects outside of priority categories must reach a threshold of 10K MAA, $100K in TVL or transaction volume to potentially qualify for an audit post-launch, but must obtain review panel approval first.

Eligibility Examples

Example 1: A financial protocol managing $500K TVL would qualify for an audit due to its high-risk nature and ability to significantly impact the ecosystem if compromised.

Example 2: An escrow account project with <$100K TVL would only qualify once it surpasses the $100K TVL threshold for non-priority categories, and there is a by the review panel-accepted reason to do so (e.g. this project is adopting a use case where the consequence of a breach or vulnerabilities can be medium or high without audit, and would result in the loss of user funds)

General Rules

1) Publicity

By applying to the Soroban Security Audit Bank Program, Participants consent to the use of their personal information by the SDF and third parties acting on behalf of SDF. Such personal information includes, but is not limited to, Participant’s name, likeness, photograph, opinions, comments, and hometown and country of residence (“Participant Profile”). Participant Profiles may be used for advertising and promotional purposes and in any existing or newly created media, worldwide without further payment or consideration, or right of review, unless prohibited by law. The duration of this consent is for a period of three years following the time of audit completion of the last Soroban Security Audit payment. This consent applies, as applicable, to all members of the Participant that has been selected for the Soroban Security Audit program.

2) Disclaimers & Limitations of Liability

‍In addition to the disclaimers, limitation of liability, and indemnities agreed to in the main SDF Terms of Service, Participants also specifically agree to release and hold harmless SDF and its respective affiliates, employees, and agents from any and all liability or any injury, loss or damage of any kind arising from or in connection with SDF and its promotion, or any Awards granted in connection with SDF.

3) General Conditions

SDF reserves the right, in their sole discretion, to cancel, suspend and/or modify the Soroban Security Audit Bank, or any part of the Official Rules for any reason.

The Soroban Security Audit Bank is governed by the SDF Terms of Service and the Official Rules. If there is any conflict or inconsistency between the SDF Terms of Service and the Official Rules, the Official Rules will prevail. If there is any discrepancy or inconsistency between the terms and conditions of the Official Rules and disclosures or other statements contained in any Soroban Security Audit Bank materials, including but not limited to the Soroban Security Audit Bank Submission form, and/or the Stellar.org website, then the Official Rules shall prevail.

The terms and conditions of the Official Rules are subject to change at any time, including the rights or obligations of the Participants and SDF. SDF will post the terms and conditions of the amended Official Rules on the Stellar.org website. To the fullest extent permitted by law, any amendment will become effective at the time specified in the posting of the amended Official Rules or, if no time is specified, the time of posting.

SDF’s failure to enforce any term of the Official Rules shall not constitute a waiver of that provision. Should any provision of the Official Rules be or become illegal or unenforceable in any jurisdiction whose laws or regulations may apply to a Participant such illegality or unenforceability shall leave the remainder of the Official Rules, including the Rule affected, to the fullest extent permitted by law, unaffected and valid. The illegal or unenforceable provision shall be replaced by a valid and enforceable provision that comes closest and best reflects the SDF’s intention in a legal and enforceable manner with respect to the invalid or unenforceable provision.

4) Data Privacy

SDF collects personal information from Participants when they enter the Soroban Security Audit Bank. The information collected is subject to the privacy policy located here: https://www.stellar.org/privacy-policy

5) Contact

If you have any specific questions or concerns you can also email SDF at [e-mail].