Asset Issuance Stack - Stellar Developer Docs

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 and the linked ecosystem directories.
Implementation detail	Detailed technical instructions live in the Stellar Developer Documentation 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 is automatically compliant with the SEP-41 token interface 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 can add off-chain, per-transaction approval for regulated transfers, and a custom SAC administrator 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 for the maintained side-by-side comparison:

A. Stellar asset (account issued, G…). Behavior 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, and automatically satisfying the SEP-41 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. 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, with identity registry, trusted claim issuers and modular compliance. Reference implementation: the OpenZeppelin RWA token suite and RWA Wizard. 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.

A. Stellar asset
B. Stellar asset + SAC
C. SEP-41 token
D. SEP-57 token

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

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.

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.

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.

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

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 and 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. Example of a contract-based vault: Volta Circuit. 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
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 Curated asset lists: Soroswap Token List · StellarExpert asset-list catalogue
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 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
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 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, SDF 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. Both asset models compared, with trustlines and compliance options. The primary orientation document.
Issuing Assets vs. Creating Custom Tokens. The design decision in Section 1, stated directly.
Guidebook for Asset Tokenization. Commercial overview for legal and business stakeholders.
Tokenized Investment Assets. Asset class context and existing precedents on the network.

Issuance and asset controls

Issue an Asset on Stellar. End-to-end tutorial covering issuer and distributor separation, trustlines, minting and distribution.
Custom SAC administration. How to delegate SAC administration to a G- or C-address and how issuer-account locking interacts with SAC admin authority.
Asset Design Considerations. The four issuer flags in detail, and the transaction-level authorization pattern.
Clawbacks. Operations, regulatory use cases and worked code examples.
Signatures and Multisig. Weighted signers, operation thresholds and alternative signer types.
Volta Circuit. Example of a contract-based vault

Contract tokens

Stellar Asset Contract. How a classic asset becomes usable within Soroban contracts.
Create Contract Tokens on Stellar. The contract token interface, and the event shape difference affecting downstream indexers.
SEP-41 Soroban Token Interface Standard fungible-token interface. Administration is intentionally implementation-specific; mint and clawback methods are not required by the interface.
OpenZeppelin Stellar Contracts. Audited primitives with AllowList, BlockList and Capped extensions.

Metadata, compliance and standards

Publishing Asset Information. Required contents of the information file. A prerequisite for listing.
SEP-1 Stellar Info File The specification for the file hosted at /.well-known/stellar.toml.
SEP-14 Dynamic Asset Metadata Removes the file size ceiling for issuers carrying many tickers.
SEP-46 Contract Meta . Standard for metadata embedded in contract Wasm; useful for contract provenance and interface/source metadata.
SEP-8 Regulated Assets Approval server protocol for per-transaction issuer approval.
SEP-57 T-REX Permissioned tokens with modular compliance, adapted from ERC-3643.
Full SEP index. Including SEP-6, 9, 10, 12, 24, 30, 31 and 38.

Infrastructure, data and tooling

Developer Tools. Index of SDKs, the Stellar CLI, Lab and Quickstart.
Horizon API. Classic ledger data, nearing end-of-life
Stellar RPC. Recommended starting point for real-time network access and smart-contract interaction. Required for contract deployments.
API and RPC providers. Including which providers retain full Horizon history.
Oracle providers. Directory of oracle services operating on the network.
SEP-40 Oracle Consumer Interface The common oracle interface, which makes feeds interchangeable.
Hubble analytics dataset. Full historical network record through BigQuery.
Block Explorers | Stellar Docs Explorer discovery
Soroswap Token List Curated asset lists
StellarExpert asset-list catalogue Curated asset lists

Distribution, security and onboarding

Anchor Platform. For issuers operating their own fiat ramp.
Wallet Integration / Stellar Wallet Kit. Maintained wallet integration options and the multi-wallet Stellar Wallet Kit.
Stellar Anchor Directory. For issuers selecting an anchor partner.
Liquidity on Stellar. Order book, automated market maker pools and path payments.
Soroban Audit Bank. Audit cost support for eligible projects.
Security best practices. 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.