Skip to main content

Introduction

Tokens exist in two forms on Stellar:

  1. Assets issued by Stellar accounts (G... addresses) and their built-in Stellar Asset Contract (SAC) implementation, and
  2. Custom tokens issued by a deployed WASM contract (C... addresses).

Several factors can help you determine whether to issue an asset on Stellar or create a custom token with a smart contract for your project.

However:

TL;DR​

If possible, we recommend issuing a Stellar asset and using the SAC to interact with that asset in smart contracts or to send to contract addresses. More on why below.

Issuing assets on Stellar​

Stellar has first-class support for asset tokenization — issuing an asset can be done using a built-in transaction without the development of a smart contract.

Stellar’s transactions are fast and cost-effective, making the network great for remittances and micropayments. It also has built-in features for compliance, asset management, and auditing. If you are looking to perform transfers of value, issuing assets on Stellar has all the needed capabilities.

Stellar assets:

note

Note that while these items are also possible with custom smart contract tokens, it is more work to build the token contract rather than using the already-implemented features of Stellar asset tokens.

Assets issued on the Stellar network are accessible to smart contracts with the use of that asset’s Stellar Asset Contract (SAC).

Stellar Asset Contract​

The Stellar Asset Contract (SAC) is compiled into the protocol layer and allows smart contracts to interact with assets issued on Stellar. An instance of the SAC can be deployed for every Stellar asset by anyone who wants to interact with the asset from a contract. The SAC has access to all account balances (for XLM) and trustline balances (for all other assets) balances as well as smart contract token balances.

Read more about the SAC here.

Learn how to deploy a Stellar Asset Contract for an asset in this How-To Guide.

Benefits of the SAC:

  • Compatibility: the SAC benefits from Stellar assets' existing interoperability.
  • Cost and resource efficiency: the SAC is built into the protocol instead of being a contract that runs in a virtual machine. Each function within the SAC will be more resource-efficient than its custom-coded counterpart.
  • Less work: you don’t have to write an entirely new contract. A Stellar asset’s SAC already exists on the network and just needs to be deployed to be used.
  • Customization: Admin addresses can be contracts. Asset issuers can set a different smart contract as an admin for their asset’s SAC. Making the admin another smart contract allows the addition of custom and decentralized logic for the assets admin capabilities, such as authorizing balances and trust lines, minting tokens, etc.

Downside of the SAC:

  • Other than the customization noted above, it is not possible to modify the behavior of Stellar assets or their SAC. If you’re looking to use assets in a way not supported by Stellar assets, you can create your own custom smart contract token using the token interface and all applications that interact with tokens using the token interface will be able to interact with the custom token.

Custom tokens​

If you have a unique use case where the capabilities Stellar Assets are not sufficient, you can create a custom token that implements the token interface. The token interface specifies the functions and events a contract must implement to be compatible with applications that use tokens.

The SAC also implements the token interface and applications that interoperate with the token interface can seamlessly interact with Stellar assets and custom tokens.

note

Smart contracts cannot use Stellar assets unless that Stellar asset has a deployed SAC. Anyone can deploy the SAC for a Stellar asset to its reserved address.

These example scenarios are not possible with the SAC and demonstrate what you could use the token interface for:

  • As the creator of a new token, you decide to implement a feature within your custom token smart contract that enables you to receive a 1% fee from every transaction involving your token. Whenever someone transfers your token to another user, 1% of the transferred amount is automatically deducted and sent to a designated wallet address that you control.
  • You want to develop a factory contract that automates the creation of instances of a specific token. This contract serves as a centralized and standardized way to deploy new token contracts on demand without manual intervention each time a new instance is needed.