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.

Minting & Burning

When issuing an asset in the Stellar Network, a direct link is created between the new asset and the account used to create it, commonly named ‘Issuing Account’. The asset is named with its own code (e.g. BTC) and is always identified by the combination of its code plus the Issuing account address.

Every other account that wishes to transact and hold a balance of said asset has to create a trustline, indicating they trust the Issuing account as the issuer of the asset. When a trustline is live, it may then hold a balance of the token in the account it belongs to. 

As part of the network design, the Issuing account cannot create a trustline to itself, therefore it cannot hold balances of the asset it issues. With this in mind, the process is broken into two very simple steps:

• Mint: By performing an action to send units of the asset from the Issuing account, these units are created and added to the circulating supply.

• Burn: By performing an action that sends circulating units of the asset to the Issuing account, these units are then destroyed and removed from the circulating supply.

Whenever a native operation is used to send asset units to/from the Issuing account, these units are then minted/burned, directly impacting the circulating supply. When combined within a workflow, the following operations can enable different use cases and unique behaviors to be built for any given asset.

Payment

The simplest and most straightforward way of performing a Mint/Burn of an asset is through a payment operation. This is commonly used by the vast majority of Issuers to control the supply within their workflows. 

To mint new units, one needs only to perform a payment with the Issuing account as the source of the payment. When the transaction is then processed, the token units will be added into circulation and sent to the destination account.

Burning supply is achieved by simply inverting the order and performing a payment from any source account to the Issuing account as the destination. As the Issuing account does not hold a balance of its own asset, the amount sent will be removed from circulation.

The payment operation is often suggested along with a second account called ‘Distribution’ as a best practice that is widely adopted by the community, as referred to in the official documentation. Although not so common, other operations can be used to achieve the same results and leverage different use cases.

Claimable Balances

As an alternative to a traditional payment, Claimable Balances break down this process into two steps, allowing for payments to operate under certain pre-conditions.  First, the sender allocates the reserves by creating the claimable balance and setting the conditions for these balances to be claimed by the receiver. These reserves remain allocated according to the conditions set initially and once they’re met, the receiver may then actively claim these balances by performing a ‘Claim claimable balance’ operation.

By using these operations, the Issuer can associate the process of minting and burning supply with the different predicates available as preconditions for the balances to be claimed. This allows for a variety of complex conditionals to be constructed, resulting in very unique use cases. For a detailed overview of claimable balances, one might refer to the Stellar documentation.

SDEX Orders

A powerful approach while not so popular for managing an asset supply, is to use the native Stellar DEX(Decentralized Exchange). By default, all assets create in Stellar classic through the native operations are already integrated with the built-in exchange that runs on-chain.

It works primarily through the usage of buy and sell offer orders that can be created with a simple transaction and, take into account all the authorization mechanisms configured for the assets.

To use the SDEX for minting and burning an asset, the issuer account must open a sell or buy order for its own asset paired with a second asset to create a market.

When one of these orders is met by other accounts and the trade is realized, any amount of assets sent from the Issuer account will be minted, while any amount of assets sent to the issuer account will be burned in the process.

In this process, the asset is only minted/burned when the order is completed and the trade performed, so it can be combined in creative ways, paired with supporting tokens to create more robust use cases involving multiple parties. A very interesting real use case that uses this approach was implemented by the Centre consortium when implementing the USDC in the Stellar Network.

Check out the detailed use case: The Creative Approach for Adding USDC to the Stellar Network.

Liquidity Pool(AMMs)

Similar to the approach enabled by using the DEX, an asset issuer can also use the Stellar Liquidity Pools for managing and distributing an asset supply. Built-in the network, there is an automated market maker(AMM) algorithm for creating liquidity pools.

By performing a simple deposit through a transaction, a user can provide liquidity for a pair of assets, generating a market from which other accounts can swap their own assets. 

An issuer can use the deposit operation to deposit liquidity for its own asset paired with another asset to generate a market through a liquidity pool. Once this operation is executed, the asset is minted in the process and added to the pool.

In the same way, when performing a withdrawal with the issuer account, the liquidity removed from the pool is sent to the issuer account and any supply received from its own asset is burned in the process.

Even though this process is similar to the one achieved with the SDEX, there is a fundamental difference in which moment the supply is created/removed.

While for SDEX offers, the asset is minted/burned whenever an offer is matched with a counter offer and the trade realized, for liquidity pools, the supply will be minted/burned at the moment the liquidity is added or removed from the pool.

For more in-depth information about the AMMs in Stellar, one can refer to the Stellar documentation.

Clawbacks

A key feature for asset issuers, Clawbacks can be enabled through a combination of authorization flags set for the issuer account. Once the necessary configuration is in place, any trustline created will have this feature enabled, allowing for asset issuers to clawback funds from either an account or a pending claimable balance, burning the balance in the process and reducing the circulating supply.

This feature leverages different use cases as the asset issuers can combine it with other features to achieve different results, such as enabling identity-proofed persons to recover an enabled asset in the event of loss of key custody or theft, as well as to respond to regulatory measures. Ultimately, on their own, the clawback operations impact the circulating supply directly by burning the clawbacked units in the process and reducing supply.

Which option should I use?

When talking about asset issuance in the Stellar network, it is recommended to begin with the standard design pattern for an Issuing / Distribution pair of accounts and make use of the ‘Payment’ operation as the simplest and most direct approach to managing an asset supply. One can further learn about this approach by exploring the Token Factory tool. 

As use cases evolve and new business requirements arise, different architectures can be leveraged by combining the different options with the set of features available in the Stellar Network. If you are interested in starting your journey with asset issuance and need technical assistance to design and develop a solution, reach out to Cheesecake Labs.