{"id":10994,"date":"2022-11-30T19:45:24","date_gmt":"2022-11-30T19:45:24","guid":{"rendered":"https:\/\/cheesecakelabs.com\/blog\/"},"modified":"2026-06-24T00:24:46","modified_gmt":"2026-06-24T00:24:46","slug":"mint-burn-assets-stellar-network","status":"publish","type":"post","link":"https:\/\/cheesecakelabs.com\/blog\/mint-burn-assets-stellar-network\/","title":{"rendered":"The Different Ways of Minting And Burning Assets in The Stellar Network"},"content":{"rendered":"\n

Designed for asset issuers, the Stellar Network<\/a> 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’. <\/p>\n\n\n\n

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. <\/p>\n\n\n\n

With the new Soroban platform<\/a>, 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.<\/p>\n\n\n\n

In February 2024, Stellar shipped Protocol 20, which activated Soroban \u2014 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.<\/strong><\/p>\n\n\n\n

The Stellar Asset Model: Trustlines and the Issuing Account<\/h2>\n\n\n\n

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<\/strong><\/code>) 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.<\/strong><\/p>\n\n\n\n

Any account that wants to hold or transact in the asset must first create a trustline<\/strong>, 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.<\/p>\n\n\n\n

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.<\/p>\n\n\n\n

Best practice: the Distribution account<\/h3>\n\n\n\n

Most asset issuers operate with a second account between the Issuer and end users \u2014 the Distribution account. The Issuer mints to the Distribution account, which then handles all downstream user-facing operations.<\/p>\n\n\n\n

This separation has two benefits: <\/strong>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.<\/p>\n\n\n\n

\n

Read more: <\/strong>Tokenomics: Find Out How to Issue a Digital Token to Solve Your Business Needs<\/a><\/p>\n<\/blockquote>\n\n\n\n

Five ways to mint and burn on Stellar Classic<\/h2>\n\n\n\n

1. Payment Operations<\/h3>\n\n\n\n

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.<\/p>\n\n\n

Source<\/span>: Issuing Account \u2192 Destination: Distribution Account\nAmount<\/span>: 1,000,000 USDX\nOperation<\/span>: Payment\nEffect<\/span>: 1,000,000 USDX added to circulating supply<\/code><\/span>Code language:<\/span> HTTP<\/span> (<\/span>http<\/span>)<\/span><\/small><\/pre>\n\n
Source<\/span>: Any Account \u2192 Destination: Issuing Account\nAmount<\/span>: 500,000 USDX\nOperation<\/span>: Payment\nEffect<\/span>: 500,000 USDX removed from circulating supply<\/code><\/span>Code language:<\/span> HTTP<\/span> (<\/span>http<\/span>)<\/span><\/small><\/pre>\n\n\n
2. Claimable Balances<\/h3>\n\n\n\n
Claimable Balances break the payment process into two distinct steps, introducing preconditions before the transfer is finalized.<\/p>\n\n\n\n
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 \u2014 they exist but are not yet in the recipient’s balance. Once the conditions are met, the recipient performs a Claim Claimable Balance<\/strong><\/code> operation to receive the funds.<\/p>\n\n\n\n
Conditions can be time-based (CLAIM_PREDICATE_BEFORE_ABSOLUTE_TIME<\/code>, CLAIM_PREDICATE_AFTER_ABSOLUTE_TIME<\/code>), compound (CLAIM_PREDICATE_AND<\/code>, CLAIM_PREDICATE_OR<\/code>), or unconditional (CLAIM_PREDICATE_UNCONDITIONAL<\/code>).<\/p>\n\n\n\n
Use cases where Claimable Balances add value over simple payments:<\/strong><\/p>\n\n\n\n
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.<\/a> The overwhelming majority of Stellar assets use payment operations as the primary mechanism for supply management.<\/p>\n\n\n\n