Skip to content

Conversation

@janewang
Copy link
Contributor

@janewang janewang commented Jan 7, 2026

No description provided.

@stellar-jenkins
Copy link

@stellar-jenkins
Copy link

@stellar-jenkins
Copy link

@stellar-jenkins
Copy link

3 similar comments
@stellar-jenkins
Copy link

@stellar-jenkins
Copy link

@stellar-jenkins
Copy link

@stellar-jenkins
Copy link

@stellar-jenkins
Copy link

@janewang janewang requested a review from tomerweller January 12, 2026 19:43
@stellar-jenkins
Copy link

@stellar-jenkins
Copy link

Copy link
Member

@leighmcculloch leighmcculloch left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Some thoughts inline, the main one being I think we are introducing the "classic" term here unnecessarily. This change looks like both a refactor and new information about SEP-57.

### What this category encompasses

### TL;DR
All assets issued on the Stellar ledger (by a `G…` address) are **Classic Stellar Assets**. These assets can be represented in two forms:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

issued on the Stellar ledger

The post is using "on the Stellar ledger" as a distinction for assets issued by a G address, but that language is confusing because all types of tokens are issued on the Stellar ledger.

I think the original language doesn't need changing and is more accurate that states that there are assets "issued by Stellar accounts (G... addresses)" and assets issued by Wasm contracts. We can then separate those latter assets into two categories, those that implement SEP-41 and those that implement SEP-57.

Comment on lines +28 to +29
- **Native Classic Asset**
Held in trustlines and transferred via native payment operations.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Native Classic Asset Held in trustlines

The native asset is not held in trust lines. The word native has special meaning, it refers to the native asset that exists at network creation, that every account can hold without the use of a trustline. i.e. the Lumen on mainnet.

native payment operations

I think the term native here is being used to describe the Payment operation and PathPayment operations, but it's confusing because native has special meaning.

to help issuers select the most appropriate model for their use case.

Several factors can help you determine whether to issue an asset on Stellar or create a contract token with a smart contract for your project.
## 1. Stellar Classic Assets (with Built-in [Stellar Asset Contract][sac])
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This page previously didn't require the term "Classic" and did a good job talking about both without needing that term. I think at some point, sometime ago now, we had decided to not use the term. Why are we bringing it back now?

Suggested change
## 1. Stellar Classic Assets (with Built-in [Stellar Asset Contract][sac])
## 1. Assets Issued by `G...` Accounts (with Built-in [Stellar Asset Contract][sac])

### Strengths

- Are compatible with Stellar ecosystem products (such as Stellar wallets) and other ecosystem products (such as exchanges).
- Has the benefits of native Stellar assets (fast, low cost), making these great for remittances and micropayments.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unclear what the intent of the use of the word native here, given its special meaning.

- Has the benefits of native Stellar assets (fast, low cost), making these great for remittances and micropayments.
- Can be used in Stellar smart contracts via SAC with a [SEP-41][sep-41] interface.
- Maintains issuer controls and trustline semantics even when used from contracts.
- Wide ecosystem wallet and indexer support. Classic assets are compatible with Stellar ecosystem products (such as Stellar wallets) and other ecosystem products (such as exchanges).
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For example for how to avoid the word classic, and telling the reader what we mean instead:

Suggested change
- Wide ecosystem wallet and indexer support. Classic assets are compatible with Stellar ecosystem products (such as Stellar wallets) and other ecosystem products (such as exchanges).
- Wide ecosystem wallet and indexer support. Assets issued by `G...` accounts are compatible with Stellar ecosystem products (such as Stellar wallets) and other ecosystem products (such as exchanges).

### Tradeoffs

- Higher execution costs compared to native Classic Asset operations.
- Less widespread ecosystem support compared to Classic Assets.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we be more specific to what the gaps in support are as this is relatively generic statement. Is it primarily exchanges that do not support now?

### What these are

Learn how to deploy a Stellar Asset Contract for an asset in [this How-To Guide](../tools/cli/cookbook/deploy-stellar-asset-contract.mdx).
A **permissioned token standard** for regulated, compliance-aware assets that extends [SEP-41][sep-41] with identity and rules enforcement. T-REX tokens are issued by a deployed Wasm contract (`C...` addresses) and implement compliance logic directly in the contract suite.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
A **permissioned token standard** for regulated, compliance-aware assets that extends [SEP-41][sep-41] with identity and rules enforcement. T-REX tokens are issued by a deployed Wasm contract (`C...` addresses) and implement compliance logic directly in the contract suite.
A permissioned token standard for regulated, compliance-aware assets that extends [SEP-41][sep-41] with identity and rules enforcement. T-REX tokens are issued by a deployed Wasm contract (`C...` addresses) and implement compliance logic directly in the contract suite.


Choose the right token model based on the use case:

- **Classic Stellar Assets (with SAC)**:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
- **Classic Stellar Assets (with SAC)**:
- **Assets Issued by `G...` Accounts (with SAC)**:

to help issuers select the most appropriate model for their use case.

Several factors can help you determine whether to issue an asset on Stellar or create a contract token with a smart contract for your project.
## 1. Stellar Classic Assets (with Built-in [Stellar Asset Contract][sac])
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Something not discussed is customisation through the admin which is a reasonably important feature to consider because it does provide a level of customisation that is meaningful.


### Stellar Asset Contract (SAC)

The Stellar Asset Contract (SAC) is a protocol-level contract that enables smart contracts to interact with assets issued on Stellar.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
The Stellar Asset Contract (SAC) is a protocol-level contract that enables smart contracts to interact with assets issued on Stellar.
The Stellar Asset Contract (SAC) is a contract built-in to the Stellar protocol that implements SEP-41 for assets issued by Stellar accounts (`G...`), and enables smart contracts to interact with assets issued on Stellar.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants