Building on Soroban: Developing in Rust for Stellar

Stellar has been one of the most reliable networks in blockchain for nearly a decade. It processes cross-border payments at scale, settles transactions in under five seconds, and charges fractions of a cent in fees. Major institutions -- from MoneyGram to Franklin Templeton -- use it in production. But until recently, Stellar had a notable limitation: no general-purpose smart contracts. Soroban changes that. Launched on Stellar's mainnet in early 2024, Soroban is a smart contract platform built from scratch with Rust, WebAssembly, and the hard lessons learned from watching Ethereum's ecosystem evolve. Our team recently spent several weeks building with it, and this is what we found.

This post covers our hands-on experience with Soroban: the architecture, the tooling, the differences from Solidity development, and our honest assessment of where the platform excels and where it still has gaps. If you are evaluating Soroban for a project or want to understand what Stellar's smart contract bet looks like from a developer's perspective, this is the guide we wish we had when we started.

Why Stellar Needed Smart Contracts

Stellar was designed as a payments network, not a general-purpose computation platform. Its Stellar Consensus Protocol (SCP) prioritizes safety and liveness for financial transactions, and the network has processed billions of dollars in remittances and stablecoin transfers since 2015. But the crypto landscape evolved. DeFi, tokenized real-world assets, on-chain compliance logic, and programmable financial instruments all require arbitrary computation that Stellar's original transaction model could not support. Projects wanting lending protocols or automated market makers had to leave for Ethereum.

Rather than bolt smart contracts onto the existing architecture as an afterthought, the Stellar Development Foundation built a purpose-designed platform that leveraged everything the industry had learned since 2015. Soroban is a clean-slate design that avoids the historical baggage of the EVM while integrating natively with Stellar's infrastructure for payments, asset issuance, and fiat connectivity.

Architecture: WASM, Storage, and Resource Metering

Soroban contracts are written in Rust and compiled to WebAssembly (WASM). WASM is a portable, sandboxed execution format that provides near-native speed, deterministic behavior, and strong isolation. By choosing WASM over a custom VM, Soroban inherits a mature toolchain and extensive compiler optimizations already supported by major cloud providers.

The execution model is deliberately constrained. Every invocation has explicit resource limits -- CPU instructions, memory, ledger reads and writes, transaction size -- all metered and priced before execution. Soroban uses preflight simulation: you simulate a transaction against the current ledger state to determine exact resource consumption. The transaction either fits the declared envelope or fails before execution. No surprises, no out-of-gas errors mid-execution, no wasted fees.

Storage diverges from established patterns. Instead of Ethereum's single key-value store, Soroban provides three types. Instance storage is tied to the contract instance -- ideal for configuration that persists with the contract. Persistent storage survives independently and can be extended by paying rent -- suitable for user balances and long-lived data. Temporary storage is auto-deleted after a configurable TTL -- useful for session data and caches. This model forces developers to think about data lifecycle upfront, preventing the unbounded state growth that plagues Ethereum.

The Rust Advantage

Rust brings memory safety without a garbage collector, a strong type system that catches bugs at compile time, and performance suited to a constrained blockchain execution environment. In Solidity, integer overflows, uninitialized storage, and reentrancy vulnerabilities have caused billions in losses. Rust eliminates many of these categories by design -- its ownership model prevents dangling pointers, its type system prevents memory access errors, and its strict compiler means that if the code compiles, entire classes of runtime errors cannot occur.

The absence of garbage collection is equally important. In blockchain, every operation must be deterministic and resource consumption precisely metered. Garbage collection introduces unpredictability. Rust's compile-time memory management means resource consumption is consistent, aligning perfectly with Soroban's metering model. That said, Rust has a steep learning curve. Developers from Solidity or JavaScript must internalize ownership, borrowing, lifetimes, and trait-based polymorphism. The Soroban SDK abstracts common patterns, but non-trivial contracts require deep language understanding.

Developer Experience: SDK, CLI, and Sandbox

The Soroban SDK provides procedural macros that generate boilerplate for contract entry points, type conversions, and storage access. A contract starts with #[contract] on a struct and #[contractimpl] on its implementation block. The SDK handles serialization and environment access -- thin enough to understand the underlying mechanics, thick enough to avoid writing raw WASM interactions.

The Stellar CLI manages the full deployment lifecycle: project scaffolding, WASM compilation, binary optimization, testnet and mainnet deployment, function invocation, identity management, and transaction signing. The workflow is stellar contract init, cargo build with the WASM target, stellar contract deploy, and stellar contract invoke. Straightforward and well-documented.

The local sandbox is where Soroban truly differentiates itself. The testing framework lets you write Rust tests that instantiate contracts, call functions, assert on state changes, and verify errors -- all running natively in milliseconds. No blockchain node, no block confirmations, no test tokens. You write a test, run cargo test, and get results instantly. After years with Hardhat and Foundry, the speed difference is immediately noticeable.

Key Differences from Solidity Development

No Reentrancy by Design

Reentrancy -- the most infamous Solidity vulnerability class -- caused the DAO hack and has been exploited dozens of times since. Soroban eliminates it entirely. A contract cannot be called again while a previous invocation is executing, enforced at runtime. An entire category of critical vulnerabilities does not exist.

Explicit Storage and Authorization

In Solidity, storage is implicit and persists forever by default. Soroban's three-tier model forces explicit decisions about every piece of data -- how long it lives, who pays for it, and what happens when its TTL expires. For authorization, Solidity relies on msg.sender, which creates fragile patterns in cross-contract calls. Soroban uses require_auth, checking that a specific address authorized a specific invocation against the transaction's authorization tree. Both changes make contracts safer by default.

Building a Token Contract: Key Concepts

The Stellar ecosystem provides a standard token interface (SEP-41) analogous to ERC-20. A Soroban token stores balances in persistent storage keyed by address. The transfer function reads the sender's balance, verifies sufficiency, decrements it, and increments the recipient's. Before any state change, require_auth verifies the sender's authorization. Allowances use temporary storage with a TTL, so expired approvals are automatically cleaned up -- unlike ERC-20 where they persist forever.

The pieces compose naturally. The #[contracttype] macro generates serialization for custom types. Storage tiers are accessed via env.storage().persistent() and env.storage().temporary(). Events are emitted through env.events().publish(). Error handling uses Rust's Result type with custom enums mapping to on-chain error codes. You get the full power of Rust -- pattern matching, iterators, generics -- not a subset defined by a domain-specific language.

Testing and Debugging

The soroban-sdk includes a test environment simulating the full contract runtime -- storage, authorization, events, and cross-contract calls. You write standard Rust tests with #[test], create a mock environment with Env::default(), and call contract functions directly. Advanced features include env.mock_all_auths() for bypassing authorization in tests, ledger sequence manipulation for time-dependent logic, and multi-contract interaction testing -- all with full IDE debugging support including breakpoints.

Transaction simulation through the Stellar CLI adds production confidence. Before submitting to the network, you simulate against current ledger state and get exact resource consumption, state changes, and return values. If simulation passes, the on-chain transaction succeeds with deterministic resource usage. We found this invaluable during deployment, where failed mainnet transactions cost real money.

Stellar Ecosystem Integration

Soroban contracts interact with Stellar's built-in assets (including USDC), the network's DEX, and the ecosystem of anchors, wallets, and fiat on-ramps. The Horizon API provides REST access for querying state, submitting transactions, and streaming events. Stellar SDKs in JavaScript, Python, Go, and Java let frontends and backends interact with Soroban contracts without Rust dependencies. Anchors -- Stellar's fiat on/off-ramp providers operating in dozens of countries -- provide direct fiat connectivity that most smart contract platforms lack. A DeFi protocol on Soroban can offer real fiat-to-stablecoin conversion, reducing the friction that prevents mainstream adoption.

Performance and Cost

Transactions finalize in five to seven seconds with fees typically under a cent, making microtransactions viable. Resource metering is more granular than EVM gas -- you pay separately for CPU, memory, ledger I/O, transaction size, and state rent. In our benchmarks, a standard token contract on Soroban cost roughly 90% less than Ethereum L1 and was comparable to Arbitrum or Optimism -- but on an L1 network with its own consensus, not a rollup dependent on Ethereum for security.

Where Soroban Shines

• Tokenized assets and financial instruments: Soroban inherits Stellar's regulatory-friendly architecture. Issuing and managing tokenized securities, bonds, or real-world assets is a natural fit.
• Payment applications: Stellar's anchors, stablecoin support (USDC, EURC), and fast finality make it ideal for escrow, conditional payments, payment splitting, and programmable disbursements.
• Cross-border financial products: Stellar already processes international remittances at scale. Soroban adds programmable logic -- automated FX conversion, compliance checks, multi-party approval.
• Lending and credit protocols: The explicit storage model with state rent aligns well with protocols where positions have natural lifetimes and dormant data should not persist indefinitely.
• Enterprise financial applications: Organizations needing on-chain logic with fiat connectivity, compliance tooling, and institutional-grade infrastructure will find Stellar's ecosystem more complete than most alternatives.

Our Assessment: Strengths and Weaknesses

Soroban is not trying to compete with Ethereum as a general-purpose world computer. It is purpose-built for financial applications, and evaluating it requires understanding that scope.

Strengths

• Rust and WASM provide a fundamentally safer execution environment. Entire vulnerability classes are eliminated by the language itself.
• The developer experience is strong -- SDK, CLI, local testing, and documentation are well-designed. The development cycle is fast.
• The three-tier storage model solves unbounded state growth, a problem plaguing Ethereum and other chains.
• Integration with Stellar's payments infrastructure, fiat on-ramps, and institutional relationships provides real-world utility crypto-native platforms cannot match.
• Deterministic resource metering and transaction simulation eliminate the guesswork and wasted fees that are constant friction in EVM development.

Weaknesses

• The ecosystem is young. Auditing tools, battle-tested libraries, and verified contract examples are still maturing compared to Ethereum.
• Rust's learning curve is real. Teams without experience will need significant investment, and hiring Rust developers is harder than hiring Solidity developers.
• DeFi composability is limited -- fewer protocols, oracles, and liquidity pools. If deep composability is critical, Ethereum L2s remain stronger.
• Community and developer mindshare is smaller. Tutorials, Stack Overflow answers, and example repositories are less abundant.
• State rent adds operational complexity. TTLs must be actively managed, requiring monitoring infrastructure that EVM developers are not accustomed to.

When We Would Recommend Soroban

We would recommend Soroban for projects involving financial transactions, asset tokenization, or payment infrastructure -- where the team has Rust expertise. If your product needs fiat connectivity, regulatory compatibility, and low costs more than deep DeFi composability, Soroban is a compelling choice. We would not recommend it today for general-purpose dApps, gaming, or applications dependent on existing DeFi protocols. For those, Ethereum's L2 ecosystem remains the practical choice. This could change as Soroban matures, but as of early 2025, network effects still favor EVM-compatible chains for non-financial use cases.

At Xcapit, we have been building blockchain solutions since 2017 -- from self-custody wallets to DeFi integrations to smart contract audits across multiple chains. If you are evaluating Soroban for a financial product, need help architecting a multi-chain strategy that includes Stellar, or want a team with hands-on Rust and smart contract experience, we would be glad to help. Learn more about our blockchain development services.