Skip to main content

Tokenization Model Comparison on Stellar

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 Classic Assets (with built-in Stellar Asset Contract),
  • SEP-41 Contract Tokens, and
  • Regulated SEP-57 Tokens (Tokens for Regulated EXchanges / T-REX)

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

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

What this category encompasses​

All assets issued on the Stellar ledger (by a G… address) are Classic Stellar Assets. These assets can be represented in two forms:

  • Native Classic Asset
    Held in trustlines and transferred via native payment operations.

  • Built-in Smart Contract (Stellar Asset Contract)
    A Stellar Asset Contract (SAC) can optionally be deployed to a contract address for the asset, implementing the SEP-41 token interface so the asset can be used 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 native Stellar assets (fast, low cost), 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. Classic assets are compatible with Stellar ecosystem products (such as Stellar wallets) and other ecosystem products (such as exchanges).
  • 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 Classic 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.

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 Soroban composability

2. SEP-41 Contract Tokens​

What these are​

Fully customizable contract tokens native to Soroban 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
  • Contract tokens can be held by both G… accounts and C… accounts.
  • Balances are always stored in contract data.

Strengths​

  • Fully programmable token logic beyond what Classic Assets + SAC can express.
  • SEP-41 standard ensures broad tooling compatibility in Soroban.
  • Can be integrated into existing Soroban applications and DeFi protocols.
  • Some ecosystem wallet support.

Tradeoffs​

  • Higher execution costs compared to native Classic Asset operations.
  • Less widespread ecosystem support compared to Classic Assets.

When to use​

  • DeFi primitives requiring complex tokenomics.
  • Asset behaviors not representable by Classic 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.

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.

Tokenization Model Comparison Table​

DimensionStellar Classic Asset (with SAC)SEP-41 Contract TokenERC-3643 (T-REX)
PlatformStellar Ledger + SorobanSoroban on StellarSoroban on Stellar
Token ModelTrustlines + native ops + SEP-41 via SACSEP-41 interface implemented by a smart contract, fully extensibleSEP-41 with extensible compliance logic
Programmability❌ Protocol-defined / SAC interface not updatable✅ Fully customizable✅ Fully customizable + compliance rules
Interaction MethodNative ops (accounts) and contract calls (via SAC)Contract callsContract calls
Compliance ControlProtocol flags + optional admin via SACCustom contract logicBuilt-in compliance and rule enforcement
Identity ModelOff-chain identity + optional contract logicProgrammable identityProgrammable identity with on-chain enforcement
Cost & SpeedVery low (native ops) / Moderate (via SAC)ModerateHigher
EcosystemStellar payments, DEX, and SorobanStellar DeFi & dApps / Interop with other L1sInstitutional DeFi / Interop with other L1s
Trustline Required✅ Yes❌ No❌ No
Ideal ForPayments, simple assets (fiat based stablecoins), Soroban 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)

Decision Guide​

Choose the right token model based on the use case:

  • Classic Stellar Assets (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 advanced Soroban applications

  • 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

Conclusion​

  • Classic 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​

Stellar Asset Contract (SAC)​

The Stellar Asset Contract (SAC) is a protocol-level contract that 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 Soroban smart contracts.

Benefits of the SAC​

Compatibility
The SAC preserves full compatibility with the existing Stellar asset model, including trustlines, authorization flags, and the Stellar DEX.

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 Classic 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.