The Different Ways of Minting And Burning Assets in The Stellar Network

Designed for asset issuers, the Stellar Network features an easy process of creating and managing an asset. By default, it provides a set of ready-to-use features that serve as building blocks, allowing for the entire lifecycle of an asset to be managed directly through native operations, also known as ‘Stellar Classic’. 

Core to this process is the management of the circulating supply of an asset by minting and burning. This can be achieved in different ways by combining these native operations and enabling various use cases to be implemented. 

With the new Soroban platform, the network capabilities will be leveraged even further through smart contracts and an extra layer of programmability. For the purpose of this article, we’ll focus on the different ways to manage an asset’s circulating supply using only native operation on Stellar Classic.

In February 2024, Stellar shipped Protocol 20, which activated Soroban — the network’s smart contract platform. Soroban does not replace the Classic operations. It adds a programmable layer on top of them, enabling regulated issuers, DeFi protocols, and stablecoin infrastructure to embed compliance logic, multi-sig controls, and composability hooks directly into the mint/burn process. In 2026, asset issuers on Stellar have two distinct toolsets.

The Stellar Asset Model: Trustlines and the Issuing Account

Before getting into minting and burning mechanics, it is worth establishing how the Stellar asset model works, because everything downstream depends on it. When you create an asset on Stellar, two things define it: an asset code (e.g. USDX) and the address of the Issuing account. The combination of these two identifiers is the asset’s unique fingerprint. Two accounts cannot issue assets with the same code, each issuer’s token is distinct.

Any account that wants to hold or transact in the asset must first create a trustline, an explicit declaration that they trust the Issuing account as the authority behind the asset. This trustline creates a slot in the account’s ledger entry for that asset and sets a balance limit. Without a trustline, an account cannot receive the asset.

The Issuing account itself cannot create a trustline to its own asset. This is the design constraint that makes the supply model work: the Issuing account is the source and the sink. Units sent from it are created. Units sent to it are destroyed.

Best practice: the Distribution account

Most asset issuers operate with a second account between the Issuer and end users — the Distribution account. The Issuer mints to the Distribution account, which then handles all downstream user-facing operations.

This separation has two benefits: the Issuing account’s private key can be kept in cold storage (since it only needs to sign minting transactions), and operational errors in the distribution layer cannot directly compromise the issuance mechanism.

Read more: Tokenomics: Find Out How to Issue a Digital Token to Solve Your Business Needs

Five ways to mint and burn on Stellar Classic

1. Payment Operations

The simplest and most widely used approach. To mint, the Issuing account sends a payment to any account with a trustline. To burn, any account sends a payment back to the Issuing account.

Source: Issuing Account → Destination: Distribution Account
Amount: 1,000,000 USDX
Operation: Payment
Effect: 1,000,000 USDX added to circulating supplyCode language: HTTP (http)

Source: Any Account → Destination: Issuing Account
Amount: 500,000 USDX
Operation: Payment
Effect: 500,000 USDX removed from circulating supplyCode language: HTTP (http)

This is the right starting point for most issuers. It is auditable, straightforward to implement in any Stellar SDK, and well-documented in the official Stellar developer guides. The overwhelming majority of Stellar assets use payment operations as the primary mechanism for supply management.

2. Claimable Balances

Claimable Balances break the payment process into two distinct steps, introducing preconditions before the transfer is finalized.

The sender (in minting scenarios, the Issuing account) allocates reserves by creating a claimable balance and specifying the conditions under which it can be claimed. The reserves are held in escrow on the ledger — they exist but are not yet in the recipient’s balance. Once the conditions are met, the recipient performs a Claim Claimable Balance operation to receive the funds.

Conditions can be time-based (CLAIM_PREDICATE_BEFORE_ABSOLUTE_TIME, CLAIM_PREDICATE_AFTER_ABSOLUTE_TIME), compound (CLAIM_PREDICATE_AND, CLAIM_PREDICATE_OR), or unconditional (CLAIM_PREDICATE_UNCONDITIONAL).

Use cases where Claimable Balances add value over simple payments:

• Token vesting: Allocate supply to team members or investors with time-based unlock conditions. The tokens exist on-chain and are auditable, but cannot be claimed before the vesting date.
• Regulated airdrops: Mint tokens to a claimable balance with an expiry. Recipients who do not claim before the expiry date lose their allocation, and the issuer can reclaim the reserves.
• Conditional distributions: Any scenario where you need to confirm eligibility before the recipient can access funds, without requiring off-chain coordination to time the payment.

3. SDEX Orders

Stellar’s built-in decentralized exchange (SDEX) allows any two assets on the ledger to be traded against each other. By placing buy and sell orders on the SDEX using the Issuing account, minting and burning can be tied directly to market activity.

When the Issuing account places a sell order for its own asset (selling asset X for asset Y), and that order is filled by another account, the amount of asset X sent from the Issuing account is minted into circulation. When the Issuing account places a buy order for its own asset (buying asset X with asset Y), and that order is filled, the asset X received by the Issuing account is burned.

This approach is less common than payment operations, but it enables use cases where supply expansion or contraction is tied to market demand rather than issuer discretion. A commodity-backed token, for example, might use SDEX orders to allow the market to naturally govern circulating supply against a reserve asset.

All asset authorization flags configured by the issuer apply to SDEX orders as well, assets with authorization required for transfers will still enforce those requirements when trades are executed.

4. Liquidity Pools (AMMs)

Stellar’s automated market maker functionality allows any two assets to be pooled for trading, with liquidity providers depositing both assets in exchange for pool shares.

For issuers, liquidity pool operations can serve as another mechanism for supply management: when the Issuing account deposits its own asset into a liquidity pool alongside a reserve asset, those units are minted into circulation and placed in the pool. When the Issuing account withdraws its share of the pool, the returned units of its own asset are burned.

This is relevant for issuers building DeFi-adjacent products, stablecoins that need trading depth on Stellar’s native exchange, or tokenized assets that want to offer on-chain liquidity without routing through a centralized order book.

5. Clawbacks

Clawbacks are a special operation that must be enabled at asset creation time via an authorization flag (AUTHORIZATION_CLAWBACK_ENABLED). Once enabled, the Issuing account can retrieve and burn asset units from any account or pending claimable balance — without the account holder’s consent.

Issuer enables: AUTHORIZATION_CLAWBACK_ENABLED at asset creation
Operation: Clawback
Source: Issuing Account
From: Any account holding the asset
Amount: Specified amount
Effect: Amount burned from the target account, removed from supplyCode language: JavaScript (javascript)

Clawbacks are a compliance instrument. The use cases are explicitly regulatory:

• Sanctions enforcement: If a holder is identified as a sanctioned entity, the issuer can claw back the funds.
• Error correction: If tokens were sent to a wrong address due to an operational error, the issuer can recover and reissue them.
• Regulatory order compliance: In jurisdictions where regulators can order asset freezes or seizures, clawbacks provide the technical mechanism to comply.

The trade-off is real: enabling clawbacks on an asset changes its trust model. Users who value full self-custody should be aware that clawback-enabled assets can be retrieved by the issuer. For regulated stablecoins and security tokens, this capability is often required. For decentralized or community assets, it would undermine the trust model entirely.

Read more: How we created a payment system to aid refugees, in partnership with SDF and Aid Organizations

Which approach should you use?

Start with Classic Payment operations if you are issuing a straightforward asset, your compliance requirements are managed off-chain, and you want the fastest path to a production deployment. The vast majority of Stellar assets are issued this way, and the infrastructure is mature.

Add Claimable Balances when your distribution model requires preconditions: vesting, eligibility checks, time-locked airdrops.

Enable Clawbacks if you are issuing a regulated asset in a jurisdiction that requires enforcement capabilities. Make this decision at issuance time, and it cannot be added after the fact.

Use Soroban smart contracts when you need programmable issuance logic: multi-sig minting, oracle-verified reserves, on-chain compliance hooks, or composability with DeFi protocols. The $100M Soroban adoption fund has supported over 160 projects, including documentation, SDKs, and community support are well-developed.

Use SACs if you have an existing Classic asset that you want to make composable with Soroban contracts without reissuing it.

At Cheesecake Labs, we are a Stellar Development Foundation partner with production deployments in stablecoin infrastructure, anchor platforms, and tokenized asset systems, including work with MoneyGram International on Stellar-based cross-border payment infrastructure. Talk to our blockchain team about building on Stellar.