In short: Stellar smart contracts run on Soroban, a platform that handles permissions, data storage and assets differently from Ethereum. A security audit on Stellar has to check those platform rules as well as the application's own code. Several of the findings from Certora's Stellar audits sit between components: a bridge transfer accepted on one chain and rejected on the other, or messages that can no longer be executed after a bridge changes messaging provider.

A transfer leaves an EVM chain and the bridge accepts it. On Stellar, the matching inbound message fails. The transfer was valid, and the funds are now stranded between two chains. In one bridge audit, Certora found that this could happen because the EVM-side and Stellar-side contracts applied rate limits differently.

Findings like this one come from how Stellar is built. Soroban, Stellar's smart contract platform, runs contracts written in Rust and compiled to WebAssembly, and the Stellar network itself provides authorization, contract storage, contract-to-contract calls and native asset handling through the Soroban SDK. Each of these behaves differently from its EVM equivalent, so an audit has to cover the platform's execution model along with the business logic built on it.

Certora is one of eight audit firms in the Stellar Development Foundation's Soroban Security Audit Bank, which funds audits for projects backed by the Stellar Community Fund. The patterns below come from that work, across bridges, oracles, tokens and access control.

This is the first article in Certora's series on auditing smart contracts chain by chain. Canton is next.

How is authorization enforced in Soroban contracts?

Authorization is handled through the Stellar host and the contract's own access control logic. The Soroban SDK provides require_auth and require_auth_for_args, which allow contracts to require authorization from a specific address. Authorization also extends across contract calls through Soroban's authorization model.

When auditing Soroban smart contracts, a key security question is whether authorization checks protect the operations that require them.

This becomes particularly important for privileged functions such as changing configuration, updating trusted addresses, managing roles, minting or burning assets, or changing implementation parameters.

For contracts that interact with other contracts, authorization also needs to be considered across the complete call path. A security boundary can depend on which contract is making a call, which arguments are being authorized, and which assumptions are made about the caller.

How does Soroban's storage and TTL model affect security?

Smart contracts maintain state using Stellar's contract storage model. Contract data can use Temporary, Persistent, or Instance storage, each with different lifetime and archival behavior. Persistent and instance entries can become archived when their TTL expires.

This makes storage behavior part of the security model, not just a resource management concern. A protocol may rely on stored configuration, oracle parameters, permissions, or other state that needs to remain available throughout the lifetime of the application.

For example, in a Stellar oracle review, we examined how oracle configuration and deployment state were stored and managed. More generally, security reviews need to consider whether critical state can expire, whether its lifetime is consistent with the intended use of the contract, and whether the application handles archival correctly.

A storage entry expiring is not necessarily a security issue by itself. The security impact depends on what the application relies on that state for and what happens when it is no longer available.

What are the security risks of cross-contract calls in Soroban?

A Stellar application is often several contracts calling each other: a bridge, a token, an oracle, a router. Each one can be correct on its own while the combination is unsafe. An audit checks the assumptions each contract makes about the others.

Soroban contracts can invoke other contracts, and authorization can propagate through those calls. That lets teams build a protocol from separate modules, and it also makes each module's security depend on the others.

For example, a bridge may depend on a messenger contract to authenticate inbound messages, while the bridge itself validates the source chain and trusted remote address. The security of the resulting system depends on these checks remaining consistent across the entire call path.

A similar issue can arise when contracts make assumptions about the behavior of external contracts. An operation that is safe in isolation may have different consequences when its result, caller, or execution context is controlled by another contract.

How should audits handle Stellar Asset Contract accounting?

Stellar smart contracts can interact with the Stellar Asset Contract, which provides a host level implementation for Stellar assets. Stellar recommends using Stellar assets where possible, partly because they are integrated with the existing Stellar ecosystem and the Stellar Asset Contract is implemented in the host.

The distinction between Stellar assets and contract based tokens is important when reviewing accounting and asset flows.

An audit needs to establish where balances are maintained, which contract is authorized to mint or burn assets, and how those operations affect the application's accounting.

For bridge systems, this becomes a cross system invariant. For example, a bridge may need to maintain a relationship between assets locked on one chain and assets minted on Stellar. Small differences in fee handling, rate limits, message validation, or token amounts can break that relationship.

In one bridge review, inconsistent rate limit handling between the EVM and Soroban implementations could allow a transfer to be accepted on one side while the corresponding inbound message failed on the other side. The result was that an otherwise valid transfer could become stranded.

What does cross-chain security require for Soroban bridges?

Cross-chain applications introduce another layer of trust. A Stellar contract may depend on an external messenger or gateway to deliver messages from another network.

The security model therefore depends on more than validating that a message was delivered by an authorized messenger. The message may also need to contain the expected source chain, trusted remote address, payload, and other protocol specific information.

Messenger upgrades and migrations are another important consideration.

For example, a bridge supporting both Axelar and LayerZero needs to account for differences in how those systems represent source addresses. A configuration that is valid for one messenger may not be valid for another. During a messenger migration, this can result in previously submitted messages becoming unexecutable if the trusted remote configuration does not account for both systems.

A cross-chain audit therefore holds the source chain, the messenger, the destination contract and the protocol configuration to the same set of assumptions, and looks for the places where one of them drifts.

What invariants should a Soroban audit check?

An invariant is a property that must hold at all times, whatever users or other contracts do. "Wrapped tokens can only be created through authorized bridge operations" is one. Writing a protocol's security requirements as invariants lets auditors check the system as a whole, which is where bugs caused by interactions between contracts show up.

Examples for a Stellar bridge or token protocol include:

• Only authorized messengers can deliver inbound bridge messages.
• The source address of a cross chain message must match the configured trusted remote.
• Wrapped token supply changes only through authorized bridge operations.
• Fees and net amounts remain correctly accounted for.
• Rate limits are applied consistently across chains.
• Privileged configuration changes are restricted to authorized roles.
• Paused execution paths cannot be used to perform operations that should be disabled.

These properties are especially important for protocols where several contracts collectively maintain the same economic state.

An individual function may appear correct while the system as a whole violates an invariant through the interaction of multiple functions or contracts.

How should Soroban contracts be tested and verified?

Stellar provides a local testing environment based on the same contract host implementation used on chain. The Soroban SDK also supports unit testing, debugging, fuzzing, and property testing.

For security-critical contracts, testing should cover both expected behavior and the properties that must remain true under unexpected inputs and execution paths.This includes authorization boundaries, state transitions, accounting, failure cases, contract interactions, and protocol invariants.

Formal verification can provide an additional layer of assurance where important properties can be expressed and checked systematically.

What should a team building on Stellar prepare before an audit?

A Soroban audit covers the application logic and the places where Soroban departs from the EVM: authorization, storage lifetime, contract-to-contract calls and native assets. Teams that write down their protocol's invariants before the audit starts give reviewers a precise target: who can change configuration, which state must never expire, how token supply on Stellar relates to assets held on other chains. The more contracts and chains an application connects, the more of its risk sits in the hand-offs between them, where one small inconsistency can change how the whole system behaves.

Further reading

• Roadmap to a Soroban Security Audit, Certora's preparation guide for teams
• Certora's public audit reports, including Stellar smart contract audit

Frequently asked questions

What is a Stellar smart contract audit? A security review of contracts built on Soroban, Stellar's smart contract platform. It checks the application's logic and how that logic uses Soroban's authorization, storage, cross-contract calls and asset handling.

How is auditing Soroban contracts different from auditing Ethereum contracts? Soroban contracts are written in Rust and compiled to WebAssembly, and the Stellar host provides authorization, storage with expiry, and native assets through the Stellar Asset Contract. An auditor has to check how a protocol uses each of these, on top of the risks that apply on any chain.

What is TTL in Soroban, and why does it matter for security? TTL (time to live) is the number of ledgers before a stored entry expires. Temporary entries are then deleted, while persistent and instance entries are archived until restored. If a protocol's configuration, permissions or oracle parameters expire while still needed, the protocol can stop working as intended.

What is the Soroban Security Audit Bank? A Stellar Development Foundation program that provides security audits for projects funded through the Stellar Community Fund. Projects pay a 5% co-payment upfront, refundable if they fix all critical, high and medium findings within 20 business days, and can receive follow-up audits at $10M and $100M in total value locked. Program details.

Does Certora audit Stellar smart contracts? Yes. Certora is one of eight firms in the Soroban Security Audit Bank and has audited Stellar bridges, oracles, tokens and access control systems. Public reports are on the Certora reports page.