How Assets Are Issued on Stellar: Trustlines, Flags, SAC

The Stellar asset model

A Stellar asset has two identifying parts: an asset code and the issuing account. Codes can be up to 4 or up to 12 alphanumeric characters, and they overlap freely, so the issuer is what makes an asset unique. There is no create operation; an asset comes into existence when its issuer first pays it to someone.

The documentation is direct about the overlap: "Since more than one organization can issue a credit representing the same asset, asset codes often overlap." On 2 October 2026, Horizon returned at least 200 assets with the code USDC. Only one is Circle's.

Code formats are Alphanumeric 4 (one to four characters) and Alphanumeric 12 (five to twelve); liquidity-pool shares are a third type identified by pool ID. SDF recommends ISO 4217 codes for currencies and ISIN numbers for securities, so interfaces can sort and display them sensibly.

Stellar also supports a second model: contract tokens, deployed as Wasm contracts implementing the SEP-41 interface, with balances in contract storage and no trustlines. SDF's comparison recommends classic assets for payments and fiat-backed stablecoins, and contract tokens where custom logic such as vesting, transfer hooks or fee structures is needed. USDC, EURC and AQUA are all classic assets.

Issuing and distribution accounts

Best practice is two accounts. The issuing account creates the asset and holds its settings; the distribution account receives the initial supply and handles day-to-day transfers. Keeping them separate limits the damage if the hot account is compromised and makes supply easier to audit.

The reasoning in SDF's asset design guide is about blast radius. The distribution account is "hot": some service holds its key. If that were also the issuing account, an attacker could mint without limit and redeem the new tokens with an anchor that cannot cover them. With separate accounts, a compromised distribution account can be frozen and replaced without changing the asset's identity.

A quirk follows from the model: an issuing account cannot hold a balance of its own asset. Tokens sent back to the issuer are burned. Circle's USDC issuer illustrates the security side in practice. On 2 October 2026 Horizon showed its master key at weight 0, four other signers at weight 1, and every threshold at 2, so any change needs two of four keys.

Trustlines

A trustline is an account's explicit opt-in to hold a particular asset. It stores the balance, an optional limit, liabilities from open DEX offers and authorisation flags. No account can receive an issued asset without one, so nobody can airdrop a token into a wallet that has not accepted it.

Each trustline is a subentry that adds one base reserve, 0.5 XLM, to the holder's minimum balance; a pool-share trustline adds two. The reserve is returned when the trustline is removed, which requires a zero balance. The full reserve arithmetic is in Stellar fees explained.

Circle's USDC had 2,465,497 authorised trustlines and about 257.6M USDC held on them on 2 October 2026, per Horizon. That figure covers classic balances only; USDC held inside contracts is recorded separately.

Authorisation flags and clawback

Issuers control access with four account flags: AUTH_REQUIRED (approve each holder), AUTH_REVOCABLE (freeze holders), AUTH_CLAWBACK_ENABLED (burn tokens from holders) and AUTH_IMMUTABLE (lock the other flags forever). They are set with set_options and applied to individual trustlines with SetTrustLineFlags.

Flag (bit)	What it lets the issuer do	Notes
AUTH_REQUIRED (0x1)	Approve each trustline before it can hold the asset	Used for KYC-gated assets
AUTH_REVOCABLE (0x2)	Revoke authorisation, freezing a balance and cancelling its offers; or reduce it to "maintain liabilities"	Circle's USDC issuer has this set
AUTH_CLAWBACK_ENABLED (0x8)	Burn tokens from trustlines and claimable balances	Requires REVOCABLE; applies only to trustlines created afterwards
AUTH_IMMUTABLE (0x4)	Nothing; it stops the other flags being set and the account being merged	A public commitment

Authorisation has two levels. AUTHORIZED allows full use; AUTHORIZED_TO_MAINTAIN_LIABILITIES lets an account keep or cancel existing offers and withdraw from pools, but not send or receive. Regulated issuers use this to approve transfers one at a time with an authorisation sandwich: a single transaction that authorises sender and recipient, executes the payment, then drops both back to the limited state. Because operations in a transaction are atomic, the approval covers that payment only.

Clawback, added by CAP-35 in Protocol 17, was designed for securities rules that require issuers to reverse mistaken or fraudulent transfers. Two safeguards limit it. It only applies to trustlines created after the issuer sets the flag, so existing holders are not changed retroactively. And an issuer can clear clawback on a specific trustline but never set it again; the holder would have to open a new trustline. When checking an asset, the issuer's flags tell you exactly which powers it kept.

Fixing the supply

An issuer can make further issuance impossible by setting its master key weight to zero with no other signers, after distributing the full supply. This locks the account permanently: no more minting, but also no changes to home domain, flags or anything else. For assets with a SAC, the contract admin must also still be the issuer.

SDF's guide flags the trade-off in a warning box: locking means "you'll never be able to do anything with it ever again". AQUA is an example of a locked issuer. On 2 October 2026 Horizon showed the AQUA issuer with its only signer at weight 0 and all thresholds at 0, and none of the authorisation flags set: no new AQUA can be minted by that account, and nobody can freeze holders. See what is the AQUA token for its supply schedule.

The SAC caveat matters. If the asset's Stellar Asset Contract admin had been moved from the issuer to another address with set_admin, that admin could still mint even with the issuing account locked. A truly fixed supply needs both checks.

home_domain and stellar.toml

An issuer links its account to a website by setting home_domain (up to 32 characters). Wallets then fetch https://domain/.well-known/stellar.toml, defined by SEP-1, and check that the asset is listed under CURRENCIES with the same issuer. Because only the domain owner can publish that file, the link runs both ways.

SEP-1 sets the mechanics: the file must be served with Access-Control-Allow-Origin: * so browsers can read it, should use a text/plain content type, and may be at most 100KB. SDF's issuer guide says the file "is not a step you can skip" and lists what exchanges and wallets expect:

• ACCOUNTS: every Stellar account the organisation controls;
• DOCUMENTATION: legal name, website (on the same domain), logo and contact details;
• CURRENCIES: per asset, the code, issuer, description, and whether supply is fixed (fixed_number), capped (max_number) or dilutable (is_unlimited);
• For backed assets: is_asset_anchored, the underlying asset, and redemption_instructions;
• For anchors: the URLs of their SEP-6, SEP-24, SEP-10, SEP-12 and SEP-31 servers, as covered in Stellar anchors explained.

What this proves is limited. It proves the domain owner claims the asset. It does not prove reserves exist, or that the organisation is reputable. Circle's USDC issuer points to circle.com and AQUA's to aqua.network, which is meaningful because those domains are already known. A new asset pointing at an unfamiliar domain has verified only that someone registered the domain.

The Stellar Asset Contract

Every classic asset has a reserved contract address where a built-in Stellar Asset Contract (SAC) can be deployed by anyone. The SAC implements the SEP-41 token interface, so Soroban contracts can hold and move the asset, while the underlying balances stay in the same trustlines. It is an interface to the asset, not a wrapped copy.

The SAC docs stress that "an asset on Stellar and its Stellar Asset Contract represent the same asset". Transfers between G-accounts update trustlines exactly as a payment would; balances held by contracts live in contract storage. Issuer controls carry over: AUTH_REQUIRED applies to contract holders via set_auth, revocation needs AUTH_REVOCABLE, and clawback from a contract balance requires the flag to have been set when that balance was created. Circle's USDC SAC, for example, sits at CCW67T…MI75.

The issuer becomes the SAC's initial admin, and can hand that role to a contract, which lets a protocol enforce custom on-chain policy for minting or freezing. Since Protocol 26 (CAP-73), a contract can also create a missing trustline with the SAC's trust function, though the account holder must still authorise it; see Stellar's 2025–2026 upgrades. One gap remains: the SAC exposes no order-book functions, so DEX trading still happens through classic operations, as described in the Stellar DEX explained. For SEP-41 tokens and contract design more generally, see Soroban smart contracts.

The takeaway

Stellar's asset model puts the important facts on the issuer's account where anyone can read them: who signs, which flags are set, and which domain claims responsibility. Before holding an asset, check the issuer rather than the code, read its flags to see whether it can freeze or claw back, and confirm the stellar.toml on a domain you recognise. Those three checks would have filtered out most of the lookalike tokens on the network. The same reasoning applies to stablecoins and to tokenised real-world assets, where the issuer controls are the point.

Sources: Stellar developer docs (Assets; Asset Design Considerations; Publish Information About an Asset; Assets Overview & Comparison; Stellar Asset Contract; Clawbacks; Accounts; Lumens); SEP-1 v2.7.0; CAP-35 and CAP-73; Horizon mainnet account and asset data for the USDC and AQUA issuers, 2 October 2026.