How to Issue Tokens on the XRP Ledger: The Operational Guide

XRPL token issuance is a protocol-native operation. No smart contract, no Solidity developer, no audit required. What's required is operational discipline — specifically around account architecture, trust line mechanics, and compliance flag configuration.

Every XRPL token is an IOU — a promise from an issuing address that the token represents something of defined value. Unlike Ethereum ERC-20 tokens, which exist as bytecode in a smart contract, XRPL tokens are recorded directly in the ledger's state data as trust line entries. This eliminates smart contract risk entirely, reduces deployment cost to fractions of a cent, and makes compliance controls native rather than bolted on.

Here is the full operational sequence.

Token Types and Scope

This guide covers fungible tokens — tokens where every unit is identical and interchangeable, like currency, equity shares, or commodity certificates. XRPL also supports non-fungible tokens via the XLS-20 standard (NFTokenMint transaction type), which operates differently and serves a different use case.

Fungible XRPL tokens can represent:

• Fractional ownership of real-world assets (real estate, equipment, commodities)
• Revenue share rights or royalty streams
• Stablecoins pegged to fiat currencies
• Loyalty or access tokens for platform economies
• Governance tokens for decentralized organizations

The XRPL protocol records ownership and enforces transfer rules. What the token represents is defined off-chain through legal agreements, disclosure documents, and platform terms.

Prerequisites and Reserve Requirements

Before creating any wallets, plan your reserve requirements:

• Base reserve: 10 XRP per account (non-spendable, held against reserve)
• Owner reserve: 2 XRP per trust line, offer, or escrow object in the account
• Minimum for two-account setup: ~25–30 XRP across both accounts, plus operational buffer

You'll also need a currency code. Use a 3-character ASCII code (e.g., "PROP", "USD", "GOLD") for most use cases. If you need a longer identifier — useful for institutional naming conventions — use a 40-character uppercase hex string. The hex format allows token names that render as full words in compliant wallet displays.

Two-Wallet Architecture: The Non-Negotiable Starting Point

Every production XRPL token deployment requires two separate wallets. This is not optional. Issuers who skip this step create security and compliance liabilities that cannot be unwound without reissuing from scratch.

Think of this as central bank / commercial bank. The central bank creates money and sets policy; the commercial bank distributes it to the economy. If the commercial bank is hacked, the central bank's ability to create money — and freeze it — remains intact.

Step-by-Step Issuance Sequence

Compliance Controls Available at Issuance

These are protocol-native features. No custom code required:

• RequireAuth: Every trust line must be approved by the issuer before tokens can flow. Essential for securities with KYC/AML requirements.
• GlobalFreeze: Pauses all token transfers globally. Used when regulatory action requires halting trading. Reversible — can be unfrozen.
• IndividualFreeze: Freezes a specific trust line without affecting other holders. Useful for compliance actions against a single counterparty.
• Clawback: When enabled at issuance, allows the issuer to retrieve tokens from any holder account. Used in court-ordered asset recovery or fraud remediation. Must be enabled at account creation — cannot be added later.
• TransferFee: Charges a percentage of each secondary market transfer to the issuer. Revenue mechanism for issuers who want ongoing income from token trading activity.

Distributing to Holders: The Trust Line UX Problem

Every holder must establish a trust line to your issuing account before they can receive tokens. For a sophisticated crypto user, this is routine. For a non-crypto audience — the target market for most RWA tokenization projects — explaining trust lines is a significant friction point.

The solution is pre-configured distribution links. These are XRPL deep links or app-specific URLs that open a wallet (XAMAN, GemWallet, Crossmark) with the trust line details pre-populated. The holder sees a confirmation screen, taps approve, and the trust line is set. No manual entry of issuer addresses or currency codes.

For RequireAuth issuers, you have an additional step: after the holder submits their trust line, you must submit an AuthorizedTrustLine transaction from the issuing account to approve it before tokens can flow. This is where your KYC/AML workflow integrates — only approve trust lines for holders who have passed verification.

Black-Holing: Locking the Supply

If you want to credibly commit to a fixed, immutable supply, you can disable the issuing account's master key via an AccountSet transaction with the DisableMaster flag. This prevents the account from signing any future transactions — including issuing additional tokens.

Once done, this is permanent. The supply is locked forever. This is a significant trust signal to investors but requires absolute certainty before execution. Verify every configuration detail, every flag, and every metadata file before black-holing the issuer.

DEX Listing and Secondary Liquidity

The XRP Ledger has a native order book DEX. The moment your token is issued, it can be traded against XRP or any other XRPL asset. Create offers from the distribution wallet to establish initial pricing. XRPL's auto-bridging will route trades through XRP as a bridge currency if direct pairs aren't liquid — no liquidity pool setup required.

For regulated securities, secondary market trading may have additional constraints. Consult your securities attorney on lock-up periods, transfer restrictions, and whether your chosen regulatory exemption allows secondary trading before registration.