Soroban, Stellar's smart contract engine

Does Stellar have smart contracts? Yes. Soroban is Stellar’s smart contract platform, and it has run on mainnet since Protocol 20 was voted in on 20 February 2024. It opened fully to users on 19 March 2024 (SDF software versions). Developers write contracts in Rust, compile them to WebAssembly (Wasm) and deploy them to the same Stellar network that has handled payments since 2014. Soroban is not a separate chain or a sidechain.

What makes Soroban interesting is not that it exists (most layer-1s have contracts now) but the design choices behind it. Fees are priced per resource, not as one “gas” number. Stored data pays rent and can be archived. Contract re-entry is blocked. Native assets plug in without wrapping. This guide walks through how Stellar smart contracts work, what they cost, how they differ from Ethereum’s EVM, and what builders in Asia can tap into.

Does Stellar have smart contracts? A short history

For most of its life, Stellar deliberately did without general-purpose contracts. The protocol shipped a built-in order book, multisig, path payments, claimable balances and, from 2021, native AMM pools. That covered payments and simple trading, but nobody could deploy custom logic such as a lending market.

That changed with Soroban. SDF announced a $100M Soroban Adoption Fund in 2022 to seed the ecosystem, and the code spent 2023 on testnet and Futurenet. Protocol 20 reached mainnet on 20 February 2024 after a three-week delay for a bug fix. SDF then opened it in phases: Phase 0 on 20 February, Phase 1 on 27 February and Phase 2, which opened the network for general use, on 19 March 2024 (SDF on the phased rollout). If you read that “Soroban launched in 2023”, that refers to test networks, not mainnet.

A note on naming: SDF’s newer materials increasingly just say “Stellar smart contracts”, and Soroban-RPC was renamed Stellar RPC in 2024. The Soroban name lives on in the soroban-sdk Rust crate and in everyday developer talk, so both terms refer to the same thing.

How Soroban works: Rust, WebAssembly and the host

A Soroban contract is a small Rust program compiled to Wasm. SDF’s overview is blunt that only Rust is supported for now, and contracts cannot use the full Rust standard library. They build on the soroban-sdk crate instead (smart contracts overview). The widget above shows the shape of a minimal contract: a struct, an impl block marked with #[contractimpl], and a function that takes an environment handle plus arguments.

The Wasm runs inside a “host” built into Stellar Core. The host provides storage, cryptography, events, cross-contract calls and authorization, so contracts stay small and expensive work runs as native code. To call a contract you submit a transaction with an InvokeHostFunctionOp. Smart-contract transactions carry exactly one operation, while classic transactions can bundle up to 100.

Testing is a strong point. The SDK ships a local implementation of the host that matches the on-chain environment, so you can debug in a normal IDE and run unit, fuzz and property tests before touching testnet. Authorization is built in as well. A function calls require_auth() on an address, and the host checks the matching signatures. That works for ordinary accounts and, since Protocol 21’s secp256r1 support, for passkey-based smart wallets.

Soroban fees and the resource model

Every Soroban transaction pays two things: an inclusion fee and a resource fee (fees, resource limits and metering). The inclusion fee works like any Stellar fee. It is at least 100 stroops (0.00001 XLM), and when ledgers are full, surge pricing ranks transactions by what they bid. The resource fee is the Soroban-specific part, and it is itemised: CPU instructions, ledger entries read and written, bytes of I/O, transaction size, events and return value, and rent for storage.

Part of that is refundable. CPU, read and write bytes and bandwidth are charged as declared. Rent, events and return value are refunded if unused. In practice you never guess these numbers: you simulate the transaction through Stellar RPC first, and the simulation returns the resource footprint and fee to attach.

In real money this stays small. At our latest check the most common fee charged on mainnet was the 100-stroop minimum, while the median sat around 0.00035 XLM, pushed up by contract calls. As of July 2026, each ledger could hold 1,000 classic operations and 2,000 smart-contract transactions. As with all Stellar fees, the XLM goes into a locked fee pool, not to validators. Our guide to Stellar fees and speed compares this with other networks.

State archival: rent for on-chain data

Ethereum stores contract data forever once someone pays to write it, and every node carries that weight indefinitely. Soroban takes a different approach called state archival (SDF docs). Each piece of contract data has a time-to-live (TTL), counted in ledgers, and staying live costs rent.

There are three storage types. Temporary storage is the cheapest and is permanently deleted when its TTL hits zero, which suits things like price quotes or nonces. Persistent storage suits balances and is archived, not deleted, when it expires. Instance storage holds contract-wide settings and shares the contract’s own TTL. Archived entries cannot be recreated, only restored, so nobody can sneak in a fresh balance where an old one used to be.

Protocol 23 “Whisk” (September 2025) reworked archival so that archived persistent entries listed in a transaction’s restore list come back automatically before the contract runs, and simulation fills in that list for you. The design keeps validator storage lean, but it adds a job for developers: extend the TTL of anything important, or budget for restores.

The Stellar Asset Contract: native assets meet contracts

One headache Soroban avoids is wrapping. On Ethereum, ETH has to become WETH before most contracts can use it. On Stellar every asset, including XLM, has one reserved Stellar Asset Contract (SAC) that implements the standard token interface (SEP-41). SDF’s docs say an asset and its SAC “represent the same asset” (SAC docs). Anyone can deploy the SAC, and it reads and writes the same trustline balances that classic wallets use.

That matters beyond convenience. The SAC respects the issuer’s authorization and clawback flags, which is why regulated issuers can let their tokens into DeFi without losing control. PayPal’s PYUSD, for example, launched on Stellar using the SAC so it works with Soroban from day one; our stablecoins guide covers it in more depth. Our page on tokenized real-world assets explains why that compliance layer attracts fund managers. Protocol 26 (May 2026) went further, letting XLM transfers through the SAC create a recipient account automatically.

Soroban vs the EVM

Developers coming from Ethereum, BNB Chain or other EVM networks will find familiar ideas with different defaults. SDF’s design write-up frames several of them as lessons from Ethereum, including a flat rule: “Don’t allow contract re-entry” (SDF blog).

Two caveats. Blocking re-entry removes one classic bug class, but it does not make contracts safe by default. Logic errors, bad access control and oracle problems remain. And there is no EVM compatibility layer, so Solidity code has to be rewritten. For a broader comparison of Stellar with a payments-focused rival, see XLM vs XRP.

Protocol upgrades since launch, up to P29 and the Bell vote

Validators vote on upgrades, and each one takes effect as soon as the vote passes. Since Soroban went live, the contract platform has changed a lot:

• Protocol 21 (June 2024): secp256r1 signature verification for passkey wallets, plus cost-model refinements.
• Protocol 22 (December 2024): contract constructors and BLS12-381 cryptography.
• Protocol 23 “Whisk” (September 2025): unified events, state-archival changes and parallel contract execution.
• Protocol 25 “X-Ray” (January 2026): BN254 and Poseidon hashing, building blocks for zero-knowledge proofs.
• Protocol 26 “Yardstick” (May 2026): validator-consensus freezing of compromised ledger entries, checked 256-bit maths and SAC improvements.
• Protocol 27 “Zipper” and 28 “Adapter” (July and September 2026): authentication delegation for smart accounts, then externally managed contract executables and sparse-map functions.
• Protocol 29 (1 October 2026): security fixes only, no new CAPs.

Next is Protocol 30 “Bell”, which is not live. Its mainnet vote is scheduled for 23 November 2026, and the dates may change. Bell would add muxed contract addresses, ML-DSA post-quantum signature verification as host functions, and millisecond ledger timestamps (Bell upgrade guide). SDF notes that regular account signatures stay Ed25519 and that Bell does not by itself make ledgers close faster than about five seconds.

Developer tooling and funding

The toolchain is compact. The Stellar CLI builds, tests, deploys and invokes contracts and manages keys and networks. Stellar Lab, SDF’s web tool, can upload, deploy, invoke and simulate contracts on Mainnet, Testnet and Futurenet without any local setup. Stellar RPC is the recommended data API for new builders. Client SDKs cover JavaScript, Python and more, and Stellar Wallets Kit connects apps to Stellar wallets such as Varial (formerly Freighter), LOBSTR and xBull.

For security, SDF signed a two-year partnership with OpenZeppelin running January 2025 to December 2026. It covers an audited Stellar contracts library, 40 auditor-weeks of audits and a bug bounty (SDF announcement). SDF’s Soroban Security Audit Bank matches eligible projects with audit firms for a 5% co-pay, which is refundable if critical, high and medium findings are fixed within 20 business days.

Funding runs mainly through the Stellar Community Fund. Its Build track offers up to $150,000 in XLM per project, and smaller Instawards go out through local ambassador chapters. Community members vote on awards. Recent rounds have paid out roughly $1.2M to $2.2M each. SCF #29, for example, distributed about $2.2M to 39 projects.

Pan-chan says

Start on testnet with Stellar Lab, simulate every call, and only then point the CLI at mainnet. Free testnet XLM beats an expensive lesson.

Security lessons: the YieldBlox oracle incident

Soroban’s most expensive lesson so far did not come from a bug in a core contract. On 22 February 2026 an attacker hit a lending pool run by the YieldBlox DAO on Blend. The pool priced collateral through the Reflector oracle, which drew on a thin USTRY/USDC market on the Stellar DEX. One transaction pushed USTRY’s reported price from about $1.05 to about $106.73. The attacker then borrowed roughly $10.2M in XLM and USDC against the inflated collateral (Blockaid post-mortem).

Once Blockaid had identified the attacker’s wallets, Tier-1 validators coordinated to reject transactions from those addresses, which “quarantined” about 48.07M XLM (about $7.3M). Blockaid was itself involved in the response, so read its numbers in that light. The takeaways for builders are classic DeFi ones: never price collateral off a thin market, use time-weighted or multi-source feeds, and cap exposure to illiquid assets. Our Stellar DeFi guide covers the incident from the user’s side.

Soroban builders in Asia

Asia’s verified Soroban activity is modest but growing. In 2026 SDF and education platform Rise In ran an APAC Stellar Hackathon with up to $60,000 in prizes. It asked teams across Southeast Asia to build DeFi, payments, wallet and on/off-ramp apps on Soroban, with local support and in-person finals in the Philippines, Vietnam and Indonesia (BitPinas). On the institutional side, Singapore’s Marketnode, which received an SDF strategic investment in October 2026, distributes tokenized funds on Stellar to Asia-Pacific investors. Our Asia hub follows the regulatory side market by market.

For a developer in Ho Chi Minh City or Bandung, the practical path is the same as anywhere: learn Rust, ship on testnet, apply to SCF, and get an audit before real money arrives. If you want to understand the network first, start with what Stellar Lumens is and keep our Stellar glossary open for terms like TTL, SAC and trustline.

Keep exploring

🌀 DeFi & dAppsDEX, AMMs, lending and yield on Stellar.Read guide 🏦 RWA tokenizationFunds, Treasuries and credit tokenized on Stellar.Read guide 📘 What is XLMStellar and XLM explained, from history to fees.Read guide 📖 GlossaryForty Stellar terms explained in plain English.Read guide