Create a token with a clear identity

Before you start

Start here. Be able to distinguish a public account address from a private signing secret. If that is unfamiliar, read Wallet Basics first. You need only a notebook; no account, funds or coding tools.

Your outcome: Make an asset specification another person can check. Explain the difference between a token, its issuer and the promise behind it.

Review Wallet Basics · Jump to the guided worksheet · Common problems · What to keep

Words you will use

Fungible

Units of the same asset are interchangeable, like units of the same club credit.

Issuer

The ledger account identified as the source of a token. The account address does not by itself verify a real-world business.

Redemption

What the issuer agrees to give you when you return its tokens. An agreement outside the ledger still needs people to honor it.

Liquidity

Whether you can actually exchange an asset in the available market, at what price and in what quantity.

Outstanding supply

Tokens currently held outside the issuer. This is different from a promised maximum or a marketing allocation.

Know what you are creating

This lesson follows the classic trust-line token model. XRPL also has Multi-Purpose Tokens (MPTs), with different identifiers and capabilities. Choose the standard deliberately and check the intended network and wallet support before following a tutorial. These lessons do not create either kind of token.

Give the token an exact identity

For a trust-line token, record both the currency code and the issuer account. Two tokens called USD from different issuers are different assets. A logo, ticker, website or familiar name cannot replace that pair. Record the network alongside it so a test asset cannot be mistaken for a Mainnet asset.

Separate the jobs

Use a written account map: issuer defines the asset relationship; an operational account handles distribution; treasury holds project funds. Decide who can sign for each account and how authority can be recovered. Separation is an operating design, not an automatic protection supplied by naming an account “issuer.”

Understand the lifecycle

In this model, a holder establishes a trust line and the issuer sends issued currency to that holder. A trust line alone does not distribute tokens. Returning a balance to its issuer reduces the amount outstanding. A trust limit is not a project-wide supply cap, and a supply promise on a website is not ledger enforcement. Explain issuance, redemption and remaining authority before promoting the asset.

Build the club-credit specification

Our fictional neighborhood club wants members to reserve workshop seats with credits. Carry this same project through the course. Labels such as Issuer A are paper labels, not usable addresses. The point is to find missing decisions before anyone creates an asset.

1. Write the user problem: members need a clear record of prepaid workshop credits. Compare a normal membership database first. If only the club can use the records and nobody needs independent transfer or verification, a ledger token may add complexity without solving the problem.
2. Choose the asset model on paper: interchangeable credits suggest a fungible token; one separately identifiable membership collectible suggests an NFT. Record classic trust-line token for this exercise. MPTs are another standard, not a different name for the same setup.
3. Write an identity card: network = Testnet rehearsal; currency = a placeholder pending valid encoding; issuer = Issuer A; distributor = Operations B. For an actual asset, replace every placeholder with the exact supported currency encoding and full public account address. Never copy these labels into a wallet.
4. Write a redemption promise: one credit reserves one eligible seat, subject to the written booking terms. Decide cancellations, expiry, refunds, support and what happens if the club closes. The token protocol does not write or enforce those business terms for you.
5. Separate supply categories. Suppose 100 credits are planned, 60 distributed and 10 later returned to the issuer. With no other issuance, 50 remain outstanding. A further 20 distributed would bring that to 70. A promise of 100 does not itself prevent that next issuance.
6. List the evidence a reviewer needs: exact asset identity; who can issue or change controls; distribution records; redemption terms; any claimed cap mechanism; and what remains unknown. Use lesson 4 to complete the authority section instead of assuming the account cannot change.

Optional: connect the worksheet to a public record

Open a read-only account explorer from the official XRPL explorer list. Confirm its network first, then search an issuer public address supplied by the project. Find the currency and full issuer pair in a token or balance view. Compare with the project own specification character for character. If the view hides the issuer, look for the raw record or choose another read-only view. Do not select Connect or sign a request.

Official XRPL explorer directory · Network amendment references. Merely reading a public record does not need a wallet. Do not enter private or personal information in these exercises.

Common problems and what to check

The token does not appear in a wallet

First check the network and exact asset identity. Display support and ledger existence are different. Do not create repeated trust lines or send money to make a logo appear.

A token exists but nobody can sell it

Creation does not create buyers, a market price or redemption funds. Inspect actual market depth and published redemption terms; never describe an unsupported price as guaranteed value.

The supply claim cannot be checked

Ask whether the number means distributed, outstanding, planned maximum or enforced maximum. Document the specific evidence for each rather than copying a single supply badge.

What to keep before moving on

Save a one-page asset specification with purpose, chosen standard, network, identity, redemption terms, supply calculation and open authority questions. In lesson 2 you will add a separate collectible; do not treat the credit and collectible as the same asset.

Explain your answer without looking at the worked example, then compare. If you guessed, revisit the relevant section. The checkboxes and quiz feedback stay on this page only; keep your project notes yourself.

Check your understanding

Go deeper with official sources

• Fungible token standards
• Trust-line token model

Technical references checked 3 October 2026. Network amendments, wallet support and reserve rules can change. Check current documentation before implementing real transactions.

Keep building