Stellar is a payments-first network: issuing an asset, moving it across borders and converting it between currencies are protocol features rather than smart contracts you write. Development on Stellar is mostly about using those primitives well, connecting to the fiat world through anchors, and reaching for Soroban smart contracts only when the built-in operations are not enough.
What makes Stellar different
Most chains give you a virtual machine and expect you to build everything in it. Stellar's "classic" protocol ships a fixed set of operations: create accounts, issue assets, set trustlines, make payments, place offers on a built-in order book, deposit into liquidity pools, and route path payments that convert one asset to another in a single atomic transaction. Ledgers close in roughly five seconds, finality is immediate under the Stellar Consensus Protocol (SCP), and fees are a tiny fraction of a cent under normal load.
Since 2024, Soroban adds general-purpose smart contracts written in Rust and compiled to WebAssembly. The two layers interoperate: the Stellar Asset Contract exposes any classic asset to Soroban contracts through a standard token interface, so you do not have to choose between them.
Issuing an asset on Stellar
An asset is identified by a code (such as USDC) plus the issuing account's public key. That pairing is what prevents impersonation: anyone can issue an asset called USDC, but only one issuer is the real one, and wallets should display the issuer or a verified home domain.
- Create an issuing account and a separate distribution account. Keep the issuer's keys offline.
- Configure flags on the issuer:
AUTH_REQUIREDif holders must be approved (common for regulated assets),AUTH_REVOCABLEandAUTH_CLAWBACK_ENABLEDif you need to freeze or recover funds for compliance. - The distribution account opens a trustline to the asset, and the issuer pays the initial supply into it.
- Publish a
stellar.tomlfile on your home domain describing the asset, the organization and its contacts, and link the domain from the issuer account. - Optionally lock the issuer (set its master weight to zero) to fix the supply permanently.
Every holder must also open a trustline before receiving the asset, and each trustline raises the account's minimum balance by one base reserve (currently 0.5 XLM). Sponsored reserves let your application pay that reserve for users, which removes a common onboarding hurdle.
Anchors and the SEP standards
An anchor is a regulated business that takes fiat in and issues an on-chain token, or redeems the token for fiat. Interoperability between wallets and anchors comes from Stellar Ecosystem Proposals (SEPs):
| SEP | Purpose | When you need it |
|---|---|---|
| SEP-1 | stellar.toml discovery file | Any issuer or anchor |
| SEP-10 | Wallet authentication by signing a challenge transaction | Any authenticated wallet-to-anchor flow |
| SEP-12 | KYC data exchange | Anchors with identity requirements |
| SEP-6 / SEP-24 | Deposit and withdrawal (API-based or interactive web flow) | On- and off-ramps in consumer wallets |
| SEP-31 | Cross-border payments between two anchors | Remittance and B2B payouts |
| SEP-38 | Firm and indicative quotes | Payments involving currency conversion |
The Stellar Development Foundation maintains an open-source Anchor Platform that implements most of these, so an anchor typically integrates its banking rails and compliance into that platform rather than writing the protocol layer from scratch. The Stellar developer documentation covers each SEP and the platform in detail.
Soroban smart contracts
Soroban contracts are Rust crates built with the soroban-sdk and deployed with the Stellar CLI. A few design features matter for architects:
- Resource-based fees. You pay for CPU instructions, ledger reads and writes, and transaction size, estimated through simulation before submission.
- State expiration. Contract data has a time to live and must be extended, or it is archived and later restored for a fee. Long-lived contracts need a plan for this.
- Explicit authorization. Contracts call
require_authon addresses, and the host verifies signatures, including for nested contract calls. - Storage types. Instance, persistent and temporary storage have different costs and lifetimes.
Use Soroban for logic the classic protocol cannot express: lending pools, escrow with custom conditions, vesting schedules, or on-chain governance. Do not rewrite a simple payment flow as a contract; classic operations are cheaper and better supported by wallets. If you come from Solidity, the general principles in the smart contract development guide still apply, but the tooling and storage model are different.
APIs and infrastructure
Applications historically read the network through Horizon, a REST API with history and streaming. The Foundation now steers new development toward Stellar RPC for current state and Soroban simulation, combined with an indexer or data pipeline for history. Plan for running or renting both. Wallet signing on the web is commonly handled through Freighter or a multi-wallet kit, and passkey-based smart wallets built on Soroban are an emerging option for consumer apps.
When Stellar is the right choice
Stellar fits payment, remittance, payroll and regulated-asset products where speed, low fees, built-in currency conversion and issuer controls matter more than a large DeFi ecosystem. It is a natural home for stablecoin issuance and for tokenized fund and asset platforms that need clawback and authorization. It is a weaker fit if your product depends on deep composability with Ethereum DeFi, or if your users already live in EVM wallets. For a broad comparison of options see blockchain for finance.
Frequently asked questions
Do I need Soroban to issue a token on Stellar?
No. Classic assets are issued with native operations and trustlines. Soroban is only needed when you want custom contract logic, and classic assets remain usable from Soroban through the Stellar Asset Contract.
What language are Stellar smart contracts written in?
Rust, using the Soroban SDK, compiled to WebAssembly. Other languages that compile to WASM are possible in theory but Rust is the supported path.
Why can't a user receive my asset?
They have not opened a trustline, their account lacks the XLM reserve to add one, or your issuer requires authorization and has not approved them.
Is Stellar suitable for DeFi?
It has a built-in order book, liquidity pools and a growing set of Soroban protocols, but its DeFi ecosystem is much smaller than Ethereum's. Choose it for payments and regulated assets first.