Add Asset Issuance Stack page to the Tokens section - #2993

---
title: Asset Issuance Stack
---

The document provides an issuer-facing checklist of the key architecture, compliance, custody, infrastructure and integration decisions that should be considered before launching an asset on Stellar. It is a decision framework, not an exhaustive provider directory and not an implementation guide.

| How to use this document |  |
| :-- | :-- |
| Purpose | To help an issuer identify the architecture and infrastructure decisions that need to be made early, and to surface the ones that are difficult or costly to change after launch. It is intended for the teams involved in planning an asset launch on Stellar, including product, engineering, compliance, legal and business leads, and is best reviewed together at the start of integration planning, before technical work begins. Each section states the question, what it depends on, and where the ecosystem currently stands. |
| Not exhaustive | Provider names throughout are illustrative examples of firms with documented Stellar support. They are neither exhaustive nor an endorsement or recommendation. For the maintained lists, see [Developer Tools](/docs/tools/developer-tools) and the linked ecosystem directories. |
| Implementation detail | Detailed technical instructions live in the [Stellar Developer Documentation](/docs/tokens) and in the linked SEP specifications. This document is the decision and checklist layer above them and links directly from each section. |

## Section 1. The primary token architecture design decision

This decision precedes every other item in this document and should be settled before technical work begins. It determines the liquidity venues available to the asset, the breadth of wallet and custodian support, and the range of compliance logic that can be expressed.

### How to approach the decision

**A classic Stellar asset is the faster and simpler route to issuance, but the choice rests with the issuer.** A classic asset is settled at protocol level, requires no bespoke code, is tradeable on the built-in order book and liquidity pools\*, and is generally supported across a broader, pre-existing set of wallets, exchanges, custodians, and other integrations without additional integration work. A contract token offers materially greater flexibility, at the cost of a longer build, an audit requirement, and narrower ecosystem support (support for contract tokens is expanding currently).

A frequent misconception is that a custom contract token is necessary in order to use smart contracts, but it is not. A classic Stellar asset accessed through the [Stellar Asset Contract](/docs/tokens/stellar-asset-contract) is automatically compliant with the [SEP-41 token interface](https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0041.md) and operates inside Smart contracts. The underlying classic Stellar Asset and its SAC are the same asset: G-address balances remain trustline balances, while C-address balances are held in SAC contract storage.

Before selecting a contract token, also consider extensions available to a Stellar Asset. [SEP-8](https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0008.md) can add off-chain, per-transaction approval for regulated transfers, and a [custom SAC administrator](/docs/build/guides/tokens/custom-sac-admin) can delegate privileged SAC actions to a G- or C-address while issuer-account authority remains a separate control path. A SEP-41 contract token is appropriate when the token itself needs custom behavior that the SAC cannot express; SEP-57/T-REX is a standardized SEP-41-based framework for permissioned RWAs with pluggable identity and compliance. The consideration that most often points towards a contract token is a compliance rule that the four issuer flags cannot express: a maximum holder count, a jurisdiction-conditional transfer restriction, a lockup period, or on-chain identity attestation. Where none of these apply, the classic route will generally reach production sooner and with fewer dependencies.

**Four pathways are shown below for decision-making, but they are not four independent token types.** A and B are two interaction paths for the same Stellar Asset; anyone can deploy the asset's reserved SAC later, so native issuance does not close the smart-contract path. SEP-8 and custom SAC administration can be layered onto a Stellar Asset where needed. C is a general SEP-41 contract-token model, while D (SEP-57/T-REX) extends SEP-41 with a regulated-asset framework. See [Assets Overview and Comparison](/docs/tokens/anatomy-of-an-asset) for the maintained side-by-side comparison:

- **A. Stellar asset (account issued, G...).** Behaviour enforced at protocol level by the four issuer flags ( Authorization Required controls who may hold the asset; Authorization Revocable allows authorization to be withdrawn/frozen; Clawback Enabled permits eligible balances to be reclaimed; Authorization Immutable permanently restricts future changes to authorization settings), holders opt in through a trustline, no bespoke code. _Fits_ payments, remittances, fiat-backed stablecoins, and any regulated instrument whose transfer rules are a static approve or reject decision. Broadest ecosystem support.

- **B. Stellar asset with the Stellar Asset Contract.** The same asset as A, made callable from Soroban contracts through the protocol-maintained [SAC](/docs/tokens/stellar-asset-contract), and automatically satisfying the [SEP-41](https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0041.md) interface. _Fits_ any option A asset that also needs to be used inside smart contracts, for example as DeFi collateral. This is the default wherever composability was the only reason a contract token was being considered.

- **C. Contract token on the SEP-41 interface (C...).** Balances in contract storage, no trustline, typically built on the audited [OpenZeppelin fungible token](https://docs.openzeppelin.com/stellar-contracts). _Fits_ Custom token behavior beyond SAC capabilities, without requiring the full SEP-57 identity and compliance framework: a transfer fee, a supply cap enforced in code, token factory logic. Support is secured through integration by integration.

- **D. Contract token on SEP-57 / T-REX.** A permissioned security token, per [SEP-57](https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0057.md), with identity registry, trusted claim issuers and modular compliance. Reference implementation: the [OpenZeppelin RWA token suite](https://docs.openzeppelin.com/stellar-contracts/tokens/rwa/rwa) and [RWA Wizard](https://www.openzeppelin.com/news/rwa-wizard-issue-regulated-real-world-assets-on-stellar). _Fits_ compliance rules the issuer flags cannot express: maximum holder count, jurisdiction-conditional restrictions, lockup periods, holding limits, on-chain identity attestation.

### What each capability actually applies to

Capabilities are frequently described as properties of Stellar when they are properties of one architecture. The matrix below states, for each control, which option provides it and by what mechanism.

<Tabs>

<Tab title="A. Stellar asset">

| Capability | How it applies |
| :-- | :-- |
| Holder opt-in | **Trustline required.** The trustline contributes to the holder account’s minimum-balance requirement. Current base reserve is 0.5 XLM. |
| Freeze (authorization control) | Protocol level, per trustline, via **authorization revocable**. |
| Pause | No protocol-level global pause. Issuers can revoke holder authorization individually where the asset flags permit. |
| Clawback | Protocol level, via **clawback enabled**. Applies only to trustlines created **after** the flag is set, and requires **authorization revocable**. Cannot be added retrospectively. |
| Transfer restrictions | Protocol-level holder authorization through issuer flags. [**SEP-8**](https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0008.md) **can additionally provide off-chain, per-transaction compliance approval** without changing the underlying asset model and can be added to an existing Stellar Asset. |
| Identity and allowlisting | Onboarding gate only, via **authorization required**. Identity data moves off-chain through SEP-12, SEP-9 and SEP-10. |
| Upgradeability, audit and code ownership | **No issuer-specific token contract audit**; issuers rely on Stellar protocol audits and production track record. Regulators or counterparties may request evidence of those assessments or additional assurance over issuer-controlled systems. **Authorization Immutable**, if enabled, permanently restricts future changes to the relevant issuer authorization settings. |
| Protocol liquidity and composability | Native order book, AMM pools and path payments\*\*. Not callable from contracts. |
| Wallet, exchange and custodian support | Broad, without bespoke integration. Always confirm the specific asset code with each provider. |

</Tab>

<Tab title="B. Stellar asset + SAC">

| Capability | How it applies |
| :-- | :-- |
| Holder opt-in | **Depends on holder address.** For G-address holders, the balance remains in a trustline and the base-reserve requirement applies. C-address holders can hold the same asset in SAC contract storage with rent/archival costs instead of a trustline. |
| Freeze (authorization control) | Same as A. The SAC honors the trustline authorization state. |
| Pause | No separate SAC-wide pause for the underlying Stellar Asset. A custom admin can govern privileged admin actions but does not rewrite normal transfer semantics. |
| Clawback | **G-addresses: same as A.** For C-address balances, clawback operates on the balance in contract storage; eligibility depends on whether the issuer had clawback enabled when that contract balance entry was created. |
| Transfer restrictions | Same as A. |
| Identity and allowlisting | Same as A. |
| Upgradeability, audit and code ownership | **No audit required for the standard SAC itself.** Any custom contracts or integrations built around the SAC should be reviewed/audited as appropriate |
| Protocol liquidity and composability | Both: native liquidity venues **and** contract composability. This is what the SAC is for. |
| Wallet, exchange and custodian support | Same as A. |

</Tab>

<Tab title="C. SEP-41 token">

| Capability | How it applies |
| :-- | :-- |
| Holder opt-in | **No trustline or trustline base reserve**. Balances are held in contract storage, which is subject to smart-contract state rent/archival costs. |
| Freeze (authorization control) | **Not defined by SEP-41**. Only if written into the contract. |
| Pause | **Not required by SEP-41.** A pausable implementation can be added by custom contract logic. |
| Clawback | **Not required by SEP-41.** An implementation may add custom administrative clawback, forced-transfer or burn logic; such controls must be explicitly designed and secured. |
| Transfer restrictions | **Custom.** Transfer restrictions can be implemented in contract logic and must then be maintained and security-reviewed as part of that implementation. |
| Identity and allowlisting | **Not defined by SEP-41.** Identity, allowlisting or eligibility checks must be implemented separately in contract and/or application logic. |
| Upgradeability, audit and code ownership | **Contract audit required for the deployed implementation and customizations.** Ongoing responsibility for administrator/upgrade controls, contract maintenance, and security. The deployer defines the contract’s administration and upgrade model. **If upgradeability is implemented**, upgrade authority and the ongoing code lifecycle must be governed and maintained by the issuer/deployer. |
| Protocol liquidity and composability | Composable, but no access to the native venues. Liquidity can be provided through contract-based DeFi protocols that support the token. |
| Wallet, exchange and custodian support | Limited. Confirm with the provider **before** the architecture is selected. |

</Tab>

<Tab title="D. SEP-57 token">

| Capability | How it applies |
| :-- | :-- |
| Holder opt-in | **No trustline or trustline base reserve**. Balances are stored in contract data entries and are subject to smart-contract storage rent/archival. Holder eligibility can additionally be enforced through the SEP-57 identity-verification and compliance framework. |
| Freeze (authorization control) | **Defined in the SEP-57 architecture.** Supports address-level freezing, partial-token freezing, and contract-wide pause/unpause functionality. |
| Pause | **Defined by SEP-57.** The interface includes contract-wide pause and unpause operations. |
| Clawback | **Standardized privileged controls include burn, forced transfer, and balance recovery.** Administrative operations are restricted to authorized roles/operators. |
| Transfer restrictions | **Standardized modular compliance framework.** Compliance modules can enforce rules such as jurisdiction restrictions, transfer limits, balance limits, holding periods and investor-eligibility requirements. |
| Identity and allowlisting | **Native**: identity registry, claim topics (KYC, AML, accreditation) and trusted claim issuers. |
| Upgradeability, audit and code ownership | **Audit required for the deployed T-REX implementation, including customized identity and compliance modules.** Ongoing governance of roles, upgrades, compliance logic, and contract maintenance. Same contract-lifecycle considerations as SEP-41, with **additional governance over compliance modules, identity-verification components and privileged administrative roles**. |
| Protocol liquidity and composability | Composable within the compliance rules. No direct access to Stellar’s native order book, liquidity pools or path payments; compliant contract-based DeFi integrations are possible. |
| Wallet, exchange and custodian support | Limited, and additionally dependent on the provider handling permissioned transfers and identity. |

</Tab>

</Tabs>

Notes: _\* **Built-in order book and liquidity pools:** Stellar includes protocol-level liquidity primitives: a shared decentralized order book (SDEX), liquidity pools for automated market making, and path payments that can route conversions through available order books and liquidity pools. Applications and wallets can access these shared liquidity venues without deploying a separate exchange contract, subject to the asset's authorization and trustline requirements. See [Liquidity on Stellar](/docs/learn/fundamentals/liquidity-on-stellar-sdex-liquidity-pools)._

_\*\* **Path payment.** An operation in which the sender pays in one asset and the recipient receives another, with the conversion executed atomically through Stellar’s order books and/or liquidity pools. Path payments can route through multiple intermediary assets and are commonly used for cross-asset payments and settlement. See [Path payments](/docs/build/guides/transactions/path-payments)._

## Section 2. Decisions that cannot be reversed after launch

Some Stellar Asset settings are non-retroactive, and some administration choices can permanently constrain future control paths. Treat the items below as a pre-launch checklist: document the intended holder model, issuer flags, SAC administration and migration path, then rehearse them on Testnet before Mainnet.

### Clawback must be enabled before any trustline exists

On options A and B, the **clawback-enabled** flag applies only to trustlines created after the flag is set, and it requires **authorization revocable** to be enabled as well. That does not change an existing trustline. If settings and holder cooperation permit, a holder can empty and remove an existing trustline and recreate it after clawback is enabled. Otherwise, migration may require reissuance/token swap. Clawback should therefore be decided before distribution whenever it may be required. Separately, **authorization immutable** permanently locks the remaining flags and prevents the issuing account from being merged. See [Control asset access](/docs/tokens/control-asset-access) and [Clawbacks](/docs/build/guides/transactions/clawbacks).

### Migration between asset models is not a configuration change

Changing architecture after launch may require issuing a new asset, migrating every holder and executing a token swap or redemption and reissuance. Before architecture selection, obtain confirmation from the wallets, exchanges and custodians expected in the distribution chain that they support the exact Stellar Asset or contract-token model and required control flows. Network support for XLM does not imply support for a given asset, and support for Stellar assets does not imply support for contract tokens.

## Section 3. The integration stack

Seven layers. Not every issuer requires every component. Section 4 sets out the requirements by asset type.

### Layer 1. Asset and issuance

| Component | Description | Type | Examples and notes |
| :-- | :-- | :-- | :-- |
| **Asset model** | Select Stellar asset + SAC, a bespoke SEP-41-compatible contract token, or a permissioned contract architecture such as SEP-57/T-REX where appropriate. See Section 1. | Protocol/Contract | Classic is the faster route to issuance. Contract tokens suit compliance rules the issuer flags cannot express. |
| **Issuance platform** | Provides investor onboarding, the holder register and lifecycle administration covering subscriptions, redemptions, distributions and corporate actions. Relevant where the asset is a regulated instrument and the issuer does not want to host that infrastructure. | Build or buy | Issuers with an established register and administration capability may issue directly. Examples: Taurus · Anchorage · Fireblocks · Archax · Bitbond · DTCC |
| **Asset metadata** | Publish issuer and asset information through SEP-1 stellar.toml. SEP-1 supports metadata/discovery for Stellar Assets and contract tokens, along with applicable disclosures and attestation references. | Protocol | SEP-14 extends SEP-1 with a dynamic metadata service for issuers that manage more assets than are practical to enumerate in stellar.toml. |
| **Test environment** | Rehearse the exact issuer-flag sequence, signer/threshold configuration, holder authorization and clawback flows, contract administration/recovery, and critical downstream integrations before mainnet. | No cost | Stellar Lab · Quickstart · Testnet. Treat Testnet validation as a deployment rehearsal, especially for non-retroactive or irreversible controls. |

### Layer 2. Keys, custody and account control

| Component | Description | Type | Examples and notes |
| :-- | :-- | :-- | :-- |
| **Issuer key controls** | Stellar accounts use weighted signers and per-operation thresholds. Contract tokens define privileged administration in contract logic. Contract-based multisig vaults can add shared ownership and programmable approval policies for asset management and contract interactions. For SEP-57, administrative functions require an authorized operator; implementations may use RBAC or another access-control model. If using a custom SAC administrator, design SAC-admin authority separately from the issuer account. Define separation of duties, key rotation, emergency controls and recovery deliberately. | Protocol/Contract | SEP-30 provides a standard for multi-party account recovery. Weighted signers and thresholds are native account controls. SEP-57 expects RBAC checks for privileged operators; other contract-token implementations may use different administration models. See [Signatures and multisig](/docs/learn/fundamentals/transactions/signatures-multisig). Example of a contract-based vault: [Volta Circuit](https://www.voltacircuit.com/docs). Confirm current support for the exact asset and required transaction flows. |
| **Institutional wallet / key-management software** | Technical infrastructure for controlling keys and authorizing transactions, including MPC/HSM, cold-storage workflows, approval policies, transaction limits and audit trails. It can support self-custody or a service provider and is not, by itself, a regulatory custody status. | Vendor/self-host | Examples: Anchorage Digital · Utila · GK8 · Blockdaemon · BPV · DFNS · Fireblocks · Taurus · BitGo |
| **Asset controls** | For Stellar Assets, protocol controls include Authorization Required, Authorization Revocable, Clawback Enabled and Authorization Immutable. SEP-8 can add per-transaction approval. Contract tokens use the controls implemented by that contract; SEP-57 standardizes a broader permissioned control framework. | Protocol/Contract | Sequencing: on the classic path, clawback must be enabled before any trustline exists. |

### Layer 3. Custody and safekeeping

| Component | Description | Type | Examples and notes |
| :-- | :-- | :-- | :-- |
| **Digital-asset custody** | Third-party safekeeping/control of the tokenized asset under a custody service relationship. Custody requirements depend on jurisdiction, investor type and internal policy; an institution may self-custody, use institutional wallet infrastructure, or appoint a regulated/qualified custodian. | Custodian / regulated service | Examples: Anchorage · BitGo · Taurus. Confirm jurisdiction, regulatory status, and support for the exact asset code or contract architecture. |
| **Underlying asset custody / safekeeping** | Safekeeping or control of the off-chain asset represented by the token: cash reserves, securities, fund assets, loan documents, commodities or other collateral. | Off-chain institution | The appropriate entity depends on asset class and legal structure: bank, fund depositary, securities custodian, trustee, warehouse/commodity custodian, etc. |
| **Architecture compatibility** | Before launch, confirm that each required custodian can support the exact Stellar asset code or contract architecture, holder model, transfer controls and operational flows. | Due diligence | Do not assume support for Stellar generally means support for a specific contract token or permissioned standard. |

### Layer 4. Compliance and identity

| Component | Description | Type | Examples and notes |
| :-- | :-- | :-- | :-- |
| **Transaction monitoring** | Screening of addresses and flow of funds against suspicious and known illicit-actors. Required by banking partners and listing venues prior to launch. | Vendor | Examples: Chainalysis · Elliptic · Merkle Science · Scorechain |
| **KYC/KYB and identity** | Stellar standardizes the transport of identity data through SEP-12, SEP-9 and SEP-10. The verification provider operates behind that interface. | Standard and vendor | Plan the adapter between the chosen identity provider and the relevant Stellar integration flow. Examples: sumsub |
| **Transfer permissioning** | Stellar Assets can use issuer flags and, where per-transaction approval is needed - SEP-8 with an off-chain approval server. SEP-57 is a distinct contract architecture that extends SEP-41 with pluggable on-chain compliance and identity-verifier contracts. | Protocol and SEP |  |

### Layer 5. Data, oracles and attestation

| Component | Description | Type | Examples and notes |
| :-- | :-- | :-- | :-- |
| **Network access (RPC)** | Stellar RPC is the recommended starting point for real-time network state, recent transactions, transaction submission and smart-contract interactions. Horizon is nearing end-of-life and should generally be treated as a legacy/transitional dependency for curated parsed endpoints that have not yet moved to RPC or an indexer. | Vendor or self-host | RPC is not a full-history indexer: the default retention window is about 7 days. For historical/analytical workloads, use Hubble, Galexie or another indexer/data product. RPC Archive is a newer full-ledger-history option, but currently, only getLedgers supports it. See the maintained [RPC provider table](/docs/data/apis/rpc/providers) |
| **Explorers and analytics** | The means by which third parties verify supply and holder distribution, and by which the issuer produces reporting and reconciliation. Publish a complete SEP-1 stellar.toml and set the issuer account home domain so wallets, explorers and other clients can resolve issuer and asset information. Issuers can also request inclusion in curated ecosystem asset lists to improve discovery and display. There is no protocol-level "legitimacy" flag; explorer presentation and list inclusion are determined by the respective service or list provider. | Largely no cost | Examples: Hubble (BigQuery) · Dune · Allium See [Block Explorers \| Stellar Docs](/docs/tools/developer-tools/block-explorers) Curated asset lists: [Soroswap Token List](https://github.com/soroswap/token-list) · [StellarExpert asset-list catalogue](https://stellar.expert/asset-lists) |
| **Price and NAV oracle** | Publishes market/reference pricing for smart-contract logic, collateralization and application display. SEP-40 defines a common consumer interface for price-oracle feeds; it should not be treated as a generic interface for NAV or proof-of-reserve data. | Vendor | Examples: Chainlink · RedStone · Reflector · Band |
| **Reserve attestation** | The SEP-1 information file carries an attestation-of-reserve reference and collateral address proofs. The level of assurance derives from the party signing the underlying report. | Standard and auditor | [SEP-1](https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0001.md) can publish references and collateral information. This is declarative evidence; it is not automatically an on-chain enforcement mechanism. Examples: Chainlink’s Proof of Reserve (upcoming) |

### Layer 6. Distribution and liquidity

| Component | Description | Type | Examples and notes |
| :-- | :-- | :-- | :-- |
| **Investor-facing wallets** | On classic Stellar a holder requires a trustline to the asset before receipt. Distribution planning should therefore confirm the exact holder model and wallet capabilities. | Ecosystem | For applications supporting multiple wallets, see [Stellar Wallet Kit and the maintained Wallet Integration directory](/docs/tools/developer-tools/wallets) |
| **Fiat on and off ramps** | Anchors bridge cash and the ledger through SEP-6 and SEP-24 for ramps, SEP-31 for corridors and SEP-38 for quotes. Issuers may operate their own using Anchor Platform, or partner. | SEPs and partners | Examples: MoneyGram Ramps · Anclap · Bitso · MyKobo |
| **Settlement leg** | Subscriptions, redemptions, distributions and secondary trades may settle against a separate payment asset such as a dollar- or euro-denominated token. | Ecosystem | Examples: USDC · EURC · other supported payment assets. See [Stellar Lab - Known Assets](https://lab.stellar.org/smart-contracts/contract-list?$=network$id=mainnet&label=Mainnet&horizonUrl=https:////horizon.stellar.org&rpcUrl=https:////mainnet.sorobanrpc.com&passphrase=Public%20Global%20Stellar%20Network%20/;%20September%202015;&smartContracts$contractList$activeTab=known-assets;;) for current Mainnet examples; confirm issuer, contract and provider support before use. |
| **Liquidity venues** | Stellar Assets can use the shared SDEX order book, classic liquidity pools and path payments. Contract tokens are not directly supported by those native liquidity/payment primitives and instead rely on contract-based DeFi venues or integrations. | Protocol and DeFi | Path payments can atomically route conversion through SDEX order books and/or liquidity pools, potentially across multiple hops. Contract-based venue support must be confirmed for the exact token. Examples: Stellar DEX · AMM pools · Blend · Aquarius · Soroswap |

### Layer 7. Assurance and visibility

| Component | Description | Type | Examples and notes |
| :-- | :-- | :-- | :-- |
| **Smart contract audit** | A Stellar Asset or the built-in SAC does not create an issuer-specific token-contract audit scope. Issuers can reference published Stellar network/software security assessments. Custom token contracts, admin contracts and other custom logic should receive security review appropriate to their risk; counterparties or regulators may require independent assurance. | Custom code only | Stellar publishes third-party audits by network-software product/version. Examples of smart-contract auditors: OpenZeppelin · Halborn · Certora · Runtime Verification · OtterSec. |
| **Pre-audit measures** | Building on audited primitives and running static analysis in continuous integration reduces both audit scope and cost. | Engineering practice | See [Security Tools](/docs/tools/developer-tools/security-tools), [SDF Audit Bank](https://stellar.org/grants-and-funding/soroban-audit-bank) (eligibility conditions apply). |
| **Ecosystem visibility** | Accurate listing is the principal means by which institutional allocators identify the asset, and provides the benchmark against which reported assets under management are assessed. | No licence cost / external listing | RWA.xyz issuer onboarding · Stellar directories / ecosystem references · analytics providers. |

## Section 4. Requirements by asset type

Requirements vary by jurisdiction and by the method of distribution. This table represents the starting position for a scoping discussion and does not constitute a compliance opinion. Issuer authority should be designed for the chosen architecture.

| Component | Fiat-backed stablecoin | Tokenized MMF or treasury fund | Tokenized equity | Private credit or debt | Commodity-backed |
| :-- | --- | --- | --- | --- | --- |
| **Issuer key controls (see note)** | Highly recommended | Highly recommended | Highly recommended | Highly recommended | Highly recommended |
| **Asset controls (flags or contract logic)** | Highly recommended | Highly recommended | Highly recommended | Highly recommended | Highly recommended |
| **SEP-1 information file** | Highly recommended | Highly recommended | Highly recommended | Highly recommended | Highly recommended |
| **RPC and data infrastructure** | Highly recommended | Highly recommended | Highly recommended | Highly recommended | Highly recommended |
| **AML transaction monitoring** | Highly recommended | Highly recommended | Highly recommended | Highly recommended | Recommended |
| **KYC at onboarding** | At the ramp | Highly recommended | Highly recommended | Highly recommended | Recommended |
| **Transfer permissioning (SEP-8 or SEP-57)** | Situational | Recommended | **Usually recommended** | **Usually required** | Situational |
| **Transfer agent or investor register** | Rarely | Highly recommended | Highly recommended | Recommended | Rarely |
| **Institutional custody** | Recommended | Highly recommended | Highly recommended | **Required** | Recommended |
| **Price or NAV oracle** | If used as collateral | Situational | Situational | Situational | Situational |
| **Reserve attestation** | Highly recommended | Highly recommended | Recommended | Recommended | Highly recommended |
| **Settlement stablecoin leg** | Not applicable | If settling against an on-chain payment asset | If settling against an on-chain payment asset | If settling against an on-chain payment asset | If settling against an on-chain payment asset |
| **Fiat on and off ramp (anchor)** | Highly recommended | Recommended | Recommended | Situational | Situational |
| **Secondary liquidity venue** | Recommended | Recommended | Recommended | Situational | Recommended |
| **Smart contract audit** | Custom code only | Custom code only | Custom code only | Custom code only | Custom code only |

**Highly recommended**, to be planned from the outset. **Recommended**, expected by most counterparties. **Situational**, dependent on distribution and jurisdiction. **Rarely required**.

**Note on issuer key controls.** Multisig is not mandated by the Stellar protocol and a single master key is technically sufficient. What is required in practice is a deliberate key-control scheme for the accounts holding issuance authority. On the classic path this is implemented through weighted signers and operation thresholds at account level. On the contract token path, minting authority rests with the contract administrator, which may itself be an account or a further contract, and control is exercised through the contract’s administrator or role model.

## Section 5. Reference documentation

The materials below constitute the recommended reading for an issuing partner's technical and compliance teams. Specifications marked Draft may change and should be confirmed before development work is committed against them.

**Start here**

- [**Assets Overview and Comparison**](/docs/tokens/anatomy-of-an-asset). Both asset models compared, with trustlines and compliance options. The primary orientation document.

- [**Issuing Assets vs. Creating Custom Tokens**](/docs/tokens). The design decision in Section 1, stated directly.

- [**Guidebook for Asset Tokenization**](https://stellar.org/resources/guidebook-for-digital-asset-tokenization). Commercial overview for legal and business stakeholders.

- [**Tokenized Investment Assets**](https://stellar.org/learn/tokenized-investment-assets). Asset class context and existing precedents on the network.

**Issuance and asset controls**

- [**Issue an Asset on Stellar**](/docs/tokens/how-to-issue-an-asset). End-to-end tutorial covering issuer and distributor separation, trustlines, minting and distribution.

- [**Custom SAC administration**](/docs/build/guides/tokens/custom-sac-admin). How to delegate SAC administration to a G- or C-address and how issuer-account locking interacts with SAC admin authority.

- [**Asset Design Considerations**](/docs/tokens/control-asset-access). The four issuer flags in detail, and the transaction-level authorization pattern.

- [**Clawbacks**](/docs/build/guides/transactions/clawbacks). Operations, regulatory use cases and worked code examples.

- [**Signatures and Multisig**](/docs/learn/fundamentals/transactions/signatures-multisig). Weighted signers, operation thresholds and alternative signer types.

- [**Volta Circuit**](https://www.voltacircuit.com/docs)**.** Example of a contract-based vault

**Contract tokens**

- [**Stellar Asset Contract**](/docs/tokens/stellar-asset-contract). How a classic asset becomes usable within Soroban contracts.

- [**Create Contract Tokens on Stellar**](/docs/tokens/token-interface). The contract token interface, and the event shape difference affecting downstream indexers.

- [**SEP-41 Soroban Token Interface**](https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0041.md) Standard fungible-token interface. Administration is intentionally implementation-specific; mint and clawback methods are not required by the interface.

- [**OpenZeppelin Stellar Contracts**](https://docs.openzeppelin.com/stellar-contracts). Audited primitives with AllowList, BlockList and Capped extensions.

**Metadata, compliance and standards**

- [**Publishing Asset Information**](/docs/tokens/publishing-asset-info). Required contents of the information file. A prerequisite for listing.

- [**SEP-1 Stellar Info File**](https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0001.md) The specification for the file hosted at /.well-known/stellar.toml.

- [**SEP-14 Dynamic Asset Metadata**](https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0014.md) Removes the file size ceiling for issuers carrying many tickers.

- [**SEP-46 Contract Meta**](https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0046.md) **.** Standard for metadata embedded in contract Wasm; useful for contract provenance and interface/source metadata.

- [**SEP-8 Regulated Assets**](https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0008.md) Approval server protocol for per-transaction issuer approval.

- [**SEP-57 T-REX**](https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0057.md) Permissioned tokens with modular compliance, adapted from ERC-3643.

- [**Full SEP index**](https://github.com/stellar/stellar-protocol/blob/master/ecosystem/README.md). Including SEP-6, 9, 10, 12, 24, 30, 31 and 38.

**Infrastructure, data and tooling**

- [**Developer Tools**](/docs/tools/developer-tools). Index of SDKs, the Stellar CLI, Lab and Quickstart.

- [**Horizon API**](/docs/data/apis/horizon). Classic ledger data, nearing end-of-life

- [**Stellar RPC**](/docs/data/apis/rpc). Recommended starting point for real-time network access and smart-contract interaction. Required for contract deployments.

- [**API and RPC providers**](/docs/data/apis/rpc/providers). Including which providers retain full Horizon history.

- [**Oracle providers**](/docs/data/oracles/oracle-providers). Directory of oracle services operating on the network.

- [**SEP-40 Oracle Consumer Interface**](https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0040.md) The common oracle interface, which makes feeds interchangeable.

- [**Hubble analytics dataset**](/docs/data/analytics/hubble). Full historical network record through BigQuery.

- **[Block Explorers \| Stellar Docs](/docs/tools/developer-tools/block-explorers)** Explorer discovery
- [**Soroswap Token List**](https://github.com/soroswap/token-list) Curated asset lists
- [**StellarExpert asset-list catalogue**](https://stellar.expert/asset-lists) Curated asset lists

**Distribution, security and onboarding**

- [**Anchor Platform**](/docs/platforms/anchor-platform). For issuers operating their own fiat ramp.

- [**Wallet Integration / Stellar Wallet Kit**](/docs/tools/developer-tools/wallets). Maintained wallet integration options and the multi-wallet Stellar Wallet Kit.

- [**Stellar Anchor Directory**](https://anchors.stellar.org/). For issuers selecting an anchor partner.

- [**Liquidity on Stellar**](/docs/learn/fundamentals/liquidity-on-stellar-sdex-liquidity-pools). Order book, automated market maker pools and path payments.

- [**Soroban Audit Bank**](https://stellar.org/grants-and-funding/soroban-audit-bank). Audit cost support for eligible projects.

- [**Security best practices**](/docs/build/security-docs/securing-web-based-projects). Hardening guidance for issuer-operated systems.

_Provider names are illustrative examples of firms with documented Stellar support as at November 2026. The lists are neither exhaustive nor an endorsement or recommendation, and support for the network does not guarantee support for a specific asset. Issuers should confirm directly with any provider that it will support the relevant asset code and establish the required trustline. This document does not constitute legal, regulatory or investment advice._