Skip to main content

Assets Overview & Comparison

info

The term "custom token" has been deprecated in favor of "contract token". View the conversation in the Stellar Developer Discord.

This brief compares the three primary tokenization models available on the Stellar network:

  • Stellar Assets (with built-in Stellar Asset Contract),
  • SEP-41 Contract Tokens, and
  • SEP-57 T-REX Tokens for Regulated EXchanges

to help issuers select the most appropriate model for their use case.

Tokenization Model Comparison​

DimensionStellar Asset (with SAC)SEP-41 Contract TokenERC-3643 (T-REX)
Token ModelTrustlines + Operations + SEP-41 via SACSEP-41 interface implemented by a smart contract, fully extensibleSEP-41 with extensible compliance logic
Programmability❌ Protocol-defined✅ Fully customizable✅ Fully customizable + compliance rules
Interaction MethodNative ops (accounts) and contract calls (via SAC)Contract callsContract calls
Admin ControlIssuer flags + optional admin via SACCustom contract logicBuilt-in compliance and rule enforcement
Cost & SpeedVery low (native ops) / Moderate (via SAC)ModerateHigher
EcosystemStellar payments, DEX, and smart contractsStellar DeFi & dApps / Interop with other L1sInstitutional DeFi / Interop with other L1s
Trustline Required✅ Yes*❌ No❌ No
Ledger Storage Fees/Expiry0.5 XLM per trustline, no expiry*Rent and ArchivesRent and Archives
Ideal ForPayments, simple assets (fiat based stablecoins), Stellar smart contracts integrationDeFi and custom tokenomicsInstitutional RWAs with compliance
Source CodeBuilt-in Stellar Asset ContractOpenZeppelin Fungible Token referenceOpenZeppelin T-REX (RWA token) reference
Relevant SEPsSEP-0001 (Stellar Info File)

SEP-0014 (Dynamic Asset Metadata)

SEP-41 (Soroban Token Interface)		SEP-41 (Soroban Token Interface)SEP-41 (Soroban Token Interface)

SEP-0057 (T-REX / Token for Regulated EXchanges)

* Starting with Protocol 26, by assigning a smart contract (C... address) as the owner of a Stellar Asset Contract, balances and transfer rules can be fully managed within the contract. This removes the need for trustlines, as balances are hold in the contract storage.

1. Stellar Assets (with Built-in Stellar Asset Contracts)​

What this category encompasses​

All assets issued by Stellar accounts (G…` addresses) are Stellar Assets. These assets can be interacted with in two forms:

  • Stellar Asset Held in trustlines and transferred via payment operations.

  • Built-in Smart Contract (Stellar Asset Contract) A Stellar Asset Contract (SAC) can be deployed to a contract address for the asset, implementing the SEP-41 token interface so the asset can be used in smart contracts. Anyone can deploy this contract to enable interacting with the asset in smart contracts.

How they work​

  • For protocol-level behavior and trustline semantics, see Asset Design Considerations.
  • Implemented at the protocol level, the Stellar Asset Contract (SAC) provides a smart contract interface that enables Stellar assets to interoperate seamlessly with Stellar smart contracts.
  • Transfers between accounts and contracts using SAC resolve to the same trustline balance updates the Stellar protocol has always used.

Strengths​

  • Has the benefits of Stellar assets (low cost, less computationally expensive), making these great for remittances and micropayments.
  • Can be used in Stellar smart contracts via SAC with a SEP-41 interface.
  • Maintains issuer controls and trustline semantics even when used from contracts.
  • Wide ecosystem wallet and indexer support. Assets issued by G... accounts are compatible with Stellar ecosystem products (such as Stellar wallets) and other ecosystem products (such as exchanges). For example, benefit from anchors, the bridges between the Stellar network and traditional financial systems. Explore the global Stellar anchor directory for further details.
  • Give the issuer granular control over asset management with features that allow the issuer to name the asset, determine access control, limit asset supply, publish asset information, and ensure compliance.
  • Native operations on Stellar Assets emit standardized events through the Stellar Asset Contract, allowing off-chain systems and indexers to observe asset activity in a uniform way. Event semantics are defined at the protocol level according to CAP-0067.
  • Operations on Stellar Assets emit the same standardized events defined by SEP-41, because the Stellar Asset Contract implements the SEP-41 token interface, Payment operations on Stellar Assets surface identical transfer events, allowing off-chain systems and indexers to observe asset activity through a uniform way.
  • By default, the admin of a Stellar Asset Contract (SAC) is the asset issuer (a G... address). However, the admin can be changed to a smart contract. Assigning a contract as the SAC admin enables custom, onchain policy for administrative actions for privileged operations.
  • As accounts must have an active trustline to receive, hold, and transact assets, accounts can choose which asset they receive.

Tradeoffs​

  • Accounts must have an active trustline to receive, hold, and transact.
  • Trustlines cannot be added programmatically through contract invocations, limiting support for assets that rely on bridging or chain abstraction patterns.

When to use​

  • Simple payment rails with optional smart contract integration.
  • Trustline-governed asset flows that also need Stellar smart contract composability

2. SEP-41 Contract Tokens​

What these are​

Fully customizable contract tokens that implement the SEP-41 token standard, with their own storage and logic. Contract tokens issued by a deployed Wasm contract (C... addresses).

How they work​

  • Issued and managed entirely in contract code.
  • Can be held by both G… accounts and C… accounts (no trustlines required).
  • Balances are always stored in contract data entries.
  • Commonly used when custom logic is required:
    • Mint/burn rules
    • Vesting
    • Hooks
    • Custom transfer logic
    • Fee structures

Strengths​

  • Fully programmable token logic beyond what Stellar Asset Contract expresses.
  • SEP-41 standard ensures broad tooling compatibility.
  • Can be integrated into existing applications and DeFi protocols.
  • Some ecosystem wallet support.

Tradeoffs​

  • Higher execution costs compared to Stellar Asset operations.
  • Less widespread ecosystem support compared to Stellar Assets, including centralized exchange support.

When to use​

  • DeFi primitives requiring complex tokenomics.
  • Asset behaviors not representable by Stellar Assets alone.
  • When extending SEP-41 with custom functionality.

3. ERC-3643 / SEP-57 (T-REX) Tokens​

What these are​

A permissioned token standard for regulated, compliance-aware assets that extends SEP-41 with identity and rules enforcement. T-REX tokens are issued by a deployed Wasm contract (C... addresses) and implement compliance logic directly in the contract suite.

How they work​

  • Extend SEP-41 with on-chain identity verification and compliance rules.
  • Enforce transfer restrictions based on identity status and compliance policies.
  • Support role-based access control (RBAC) tailored for institutional use cases.
  • Balances are stored in contract data entries.

Strengths​

  • On-chain compliance.
  • On-chain identity.
  • Role/agent-based structure tailored for institutions.

Tradeoffs​

  • Higher complexity.
  • Higher execution costs due to on-chain compliance and identity checks.
  • Current state:
    • Balance display supported in some ecosystem wallets via SEP-41.
    • Transfers and control functions not yet supported in wallets.
    • Indexer support is not provided out of the box and must be self-implemented.

When to use​

  • Institutional RWAs with strict on-chain compliance requirements.
  • Interoperability with Ethereum’s ERC-3643 ecosystem.

Decision Guide​

Choose the right token model based on the use case:

  • Assets Issued by G... Accounts (with SAC):

    • Simple payment rails or fiat-backed stablecoins
    • Maximum ecosystem compatibility (wallets, exchanges, DEX)
    • Low transaction costs and fast settlement
    • Optional smart contract integration via SAC
    • Regulatory controls through protocol flags

  • SEP-41 Contract Tokens:

    • Custom token logic (transfer fees, vesting, hooks)
    • DeFi primitives and complex tokenomics
    • No trustline requirements
    • Full programmability for innovative use cases
    • Integration with Stellar smart contracts

  • SEP-57 / ERC-3643 (T-REX) Tokens:

    • Onchain compliance and identity verification
    • Institutional-grade access controls
    • Regulatory requirements for Real World Assets (RWAs)
    • Interoperability with Ethereum ERC-3643
Summary: TLDR
  • Stellar Assets are best for simple payments and fiat-backed assets, with optional smart contract interoperability via the Stellar Asset Contract.
  • SEP-41 Contract Tokens are ideal for DeFi and advanced tokenomics requiring full programmability.
  • SEP-57 ERC-3643 Tokens are designed for regulated Real World Assets, offering on-chain compliance and identity with institutional-grade controls.

More Info about Stellar Asset Contract (SAC)​

The Stellar Asset Contract (SAC) is a contract built-in to the Stellar protocol that implements SEP-41 for assets issued by Stellar accounts (G...), and enables smart contracts to interact with assets issued on Stellar.

For any Stellar asset, an instance of the SAC can be deployed (by anyone) to a deterministic, reserved address. Once deployed, smart contracts can interact with that asset using standard contract calls.

The SAC has read/write access to:

  • Account balances (for XLM)
  • Trustline balances (for issued assets)
  • Smart-contract token balances

This allows Stellar assets to interoperate seamlessly with smart contracts.

Benefits of the SAC​

Compatibility
The SAC preserves full compatibility with the existing Stellar asset model, including trustlines and authorization flags. For Stellar DEX, compatibility does not currently exist for SAC, but it does exist for the underlying assets via classic operations.

Cost & Resource Efficiency
Because the SAC is compiled into the protocol (rather than implemented as a user-deployed contract running in a VM), its functions are more resource-efficient than equivalent contract-coded logic.

Minimal Setup
You don’t need to write or deploy a custom token contract. A Stellar asset’s SAC already exists at the protocol level and only needs to be deployed to be used.

Extensible Administration
The asset admin can be a smart contract. Issuers may delegate administrative capabilities—such as authorization, minting, or clawbacks—to another contract, enabling custom or decentralized admin logic without replacing the asset itself.

Limitations of the SAC​

Aside from delegating admin logic, the behavior of a Stellar asset and its SAC cannot be modified. Core asset semantics (balances, transfers, trustlines) are fixed at the protocol level.

If your use case requires token behavior not supported by Stellar assets, you should use a contract token instead.

Contract Tokens​

For advanced or non-standard use cases, you can create a contract token that implements the SEP-41 token interface. This interface defines the required functions and events for compatibility with applications that work with tokens.

Key points:

  • The SAC itself implements the token interface (SEP-41)
  • Applications built against the token interface can interact with both Stellar assets (via SAC) and contract tokens
  • Contract tokens allow full customization of token logic
  • Contract tokens provide the flexibility to implement features not available in Stellar Assets, such as transfer fees, vesting schedules, or custom mint/burn rules
note

Smart contracts cannot use Stellar assets unless that Stellar asset has a deployed SAC. Anyone can deploy the SAC for a Stellar asset to its reserved address.

When You Need a Contract Token (Examples)​

The following scenarios are not possible using the SAC, but can be implemented with a contract token:

  • Transfer Fees
    Implement a token that automatically deducts a 1% fee on every transfer and routes it to a designated address.

  • Token Factory Pattern
    Build a factory contract that programmatically deploys new instances of a token contract, enabling standardized, on-demand token creation.

Issuing assets is a core feature of Stellar: any asset can be tokenized (or minted) on the network and then tracked, held, and traded quickly and cheaply. Assets can represent many things: cryptocurrencies (such as bitcoin or ether), fiat currencies (such as dollars or pesos), other tokens of value (such as NFTs), pool shares, or even bonds and equity. Any Stellar account can issue an asset, and since anyone can set up an account, anyone can issue assets: banks, payment processors, money service businesses, for-profit enterprises, nonprofits, local communities, and individuals. It’s a self-serve process with no permission needed.

Issuing an asset on Stellar is easy and only takes a few operations. However, there are additional considerations you may need to think about depending on your use case, such as publishing asset information, compliance, and asset supply, which we’ll cover in this documentation. Assets on Stellar have two identifying characteristics: the asset code and the issuer. Since more than one organization can issue a credit representing the same asset, asset codes often overlap (for example, multiple companies offer a USD token on Stellar). Assets are uniquely identified by the combination of their asset code and issuer.

Assets issued on the Stellar network are accessible to smart contracts. Every Stellar asset has reserved a Stellar Asset Contract that can be deployed by anyone who wants to be able to interact with the asset from a contract.

Stablecoins​

One major category of assets is the stablecoin. A stablecoin is a blockchain-based token whose value is tied to another asset, such as the US dollar, other fiat currencies, commodities like gold, or even cryptocurrencies. There are two types of stablecoin: 1) reserve-backed stablecoins that must have a mechanism for redeeming the asset backing them, and 2) algorithmic stablecoins that don’t have assets backing them and instead rely on an algorithm to control the stablecoin supply. When discussing stablecoins, our documentation will focus on reserve-backed stablecoins.

Reserve-backed stablecoins are pegged to a real-world asset at a 1:1 ratio. Because the underlying asset is maintained as collateral, users should be able to trade their stablecoin for the asset at any time. Asset reserves can be maintained by independent custodians and should be regularly audited.

Currently, one of Stellar's most significant use cases is the tokenization of fiat currency for processes like cross-border payments. With anchors, users can connect Stellar tokens to existing rails that allow for the deposit of real-world assets in exchange for digital currency and vice versa. Learn more about anchors in our Anchors section.

Treasury management​

When issuing a reserve-backed stablecoin, you must set up its off-chain reserve, which securely stores the asset backing the stablecoin. When users wish to redeem their stablecoin, they can receive an equivalent amount of the underlying reserve asset from the issuer.

Compliance​

As an asset issuer, you may need to comply with regulatory requirements that vary based on jurisdiction. Stellar has built-in features that can help meet these requirements, such as: