Stablecoin Token Standards: ERC-20, SPL, Taproot Assets, and RGB Compared

Stablecoins have grown into a $300 billion market, but the token standards underpinning them vary enormously. An ERC-20 USDC transfer on Ethereum operates under completely different rules than a Taproot Assets USDT payment routed over Lightning. Each standard encodes its own assumptions about programmability, privacy, on-chain footprint, and issuer control. For developers, institutions, and users choosing where to hold or transfer stablecoins, understanding these differences is not optional: the token standard determines what the issuer can do to your balance, how much the transfer costs, and who can see it.

This article compares six token standards used for stablecoin issuance: ERC-20 on Ethereum, SPL and Token-2022 on Solana, BRC-20 on Bitcoin, Taproot Assets on Bitcoin and Lightning, the RGB protocol for client-side validated assets, and Spark's BTKN standard built on statechains. For each, we examine the issuance mechanism, programmability features, on-chain footprint, privacy properties, and which stablecoins actually use it.

Why Token Standards Matter for Stablecoins

A token standard defines the interface and rules governing how a digital asset is created, transferred, and managed on a given blockchain. For stablecoins, the choice of standard has direct consequences across several dimensions.

• Issuer control: can the issuer freeze or blacklist specific addresses? Regulators increasingly require this capability for compliance and sanctions enforcement.
• Transfer cost: ERC-20 transfers can cost anywhere from $0.05 to $10 depending on Ethereum gas prices, while Bitcoin-native standards aim for sub-cent fees.
• Privacy: fully on-chain standards expose every transfer to public analysis, while client-side validation models reveal data only to the parties involved.
• Composability: ERC-20 tokens plug into thousands of DeFi protocols immediately, while newer Bitcoin-native standards trade composability for sovereignty.

ERC-20: The Original Stablecoin Standard

The ERC-20 standard, formalized in 2015, defines a common interface for fungible tokens on Ethereum. It specifies six core functions (totalSupply, balanceOf, transfer, transferFrom, approve, allowance) that every compliant token must implement. This uniformity is what allowed the stablecoin ecosystem to scale: wallets, exchanges, and DeFi protocols can interact with any ERC-20 token using the same code.

As of mid-2026, Ethereum hosts approximately $154 billion in stablecoin supply, roughly half the global total. USDT and USDC alone account for the vast majority of this, with DAI, FRAX, and other algorithmic or collateralized stablecoins filling out the long tail.

Programmability and Issuer Controls

Beyond the base ERC-20 interface, stablecoin issuers add custom functions for regulatory compliance. Both Circle (USDC) and Tether (USDT) implement blacklist functionality directly in their token contracts. A privileged admin address maintained by the issuer can add any wallet to an on-chain mapping. Once blacklisted, the token's transfer and transferFrom functions revert, making the balance immovable. Circle's USDC contract uses a dedicated Blacklistable.sol module with role-based access control, while Tether's implementation follows a similar pattern with AddedBlackList and RemovedBlackList events.

This gives issuers powerful, unilateral control. Tether has frozen hundreds of addresses in response to law enforcement requests and sanctions designations. Circle responds primarily to judicial orders and OFAC sanctions lists. The mechanism is transparent: anyone can query the blacklist on-chain, but the decision to freeze is centralized and non-negotiable.

The approve/transferFrom pattern also enables composability with DeFi. A user can approve a lending protocol to spend their USDC, enabling collateralized borrowing, liquidity provision, and automated trading without intermediaries. This programmability is ERC-20's greatest strength: the standard is a building block for an entire financial system.

Limitations

ERC-20 stablecoin transfers consume approximately 65,000 gas units. At a typical base fee of 10 gwei and an ETH price near $2,300, that prices a single transfer at roughly $1.50, whether the amount is $100 or $10,000. During periods of high network activity, fees can spike to $5 or more. Every transfer is also fully visible on-chain: chain analysis firms can trace the complete history of every dollar moved.

The approval footgun: ERC-20's approve function is a known attack surface. If a user approves a malicious or compromised contract for an unlimited token allowance, the contract can drain the approved balance at any time. The token approval model remains one of the most common vectors for DeFi exploits.

SPL and Token-2022: Solana's Stablecoin Stack

Solana uses two token programs. The original SPL Token program provides basic mint, transfer, and freeze functionality. Token-2022 (also called Token Extensions) is a backward-compatible upgrade that adds modular capabilities as extensions, each enabled at the token level by the issuer. As of mid-2026, Solana hosts roughly $12 to $15 billion in stablecoin supply.

The original SPL Token program supports a freeze authority: a designated address that can freeze any token account, preventing transfers in or out. This is the mechanism USDC on Solana uses for sanctions compliance. SPL transfers cost fractions of a cent (typically under $0.001) and confirm in approximately 400 milliseconds, making Solana one of the cheapest and fastest environments for stablecoin payments.

Token Extensions for Compliance

Token-2022 introduces several extensions relevant to stablecoin issuers:

• Transfer hooks: route every transfer through a custom program for allowlist checks, velocity limits, or on-chain fee splits.
• Confidential transfers: use zero-knowledge proofs to hide transfer amounts while preserving the ability to verify total supply. Observers can see that address X sent tokens to address Y, but not how much.
• Transfer fees: the issuer can impose a percentage-based fee on every transfer, collected automatically by the token program.
• Permanent delegate: grants a designated authority the ability to transfer or burn tokens from any account, useful for regulatory seizure requirements.

PayPal's PYUSD, Paxos's USDG, and Circle's EURC all use Token-2022 on Solana. However, one important limitation exists: confidential transfers and transfer hooks cannot be combined on the same token. Encrypting amounts makes it impossible for a hook program to inspect the transfer value, creating a direct conflict between privacy and programmable compliance.

BRC-20: An Experimental Bitcoin Token Standard

BRC-20 tokens use the Ordinals protocol to inscribe JSON data onto individual satoshis. A deploy inscription sets the token name, supply cap, and mint limit. Subsequent mint and transfer inscriptions modify balances. There are no smart contracts: all token logic is defined by the JSON schema, and off-chain indexers reconstruct balances by replaying every inscription in order.

This design has fundamental limitations for stablecoin issuance. Without smart contracts, there is no mechanism for an issuer to freeze or blacklist addresses. Supply is defined at deployment and cannot be adjusted afterward, making it impossible to mint or burn tokens in response to reserve changes. Every operation requires a Bitcoin L1 transaction, meaning transfers are subject to block confirmation times and can cost several dollars during fee spikes.

BRC-20 also creates significant chain bloat. Each mint or transfer inscription occupies witness space, and the protocol has been criticized for generating unnecessary UTXOs. While BRC-20 demonstrated that fungible tokens are possible on Bitcoin without protocol changes, no major stablecoin issuer has adopted it. The standard lacks the compliance primitives, supply flexibility, and cost efficiency that regulated stablecoin issuance demands.

Taproot Assets: Stablecoins Over Lightning

Taproot Assets (formerly Taro), developed by Lightning Labs, takes a fundamentally different approach. It embeds asset metadata inside Taproot outputs using a Merkle-Sum Sparse Merkle Tree (MS-SMT). The on-chain footprint is a single hash commitment in the Taproot output, regardless of how many assets or transfers are packed inside. All asset metadata, proofs of issuance, and transfer history are stored off-chain in repositories called Universes.

In March 2026, Tether launched USDT on Bitcoin's Lightning Network via Taproot Assets, completing a 14-month integration announced at the Plan B Forum in El Salvador. As of mid-2026, the protocol has reached version 0.8.0, with features including static reusable addresses, auditable supply commitments, and multi-path payment support.

How Taproot Assets Minimize On-Chain Footprint

The MS-SMT structure enables efficient proofs of both inclusion (this asset exists) and non-inclusion (no hidden inflation) while guaranteeing supply conservation through cumulative sum commitments. Multiple assets can share a single UTXO, and multiple transfers can be aggregated into a single on-chain transaction. Asset recipients verify their holdings by checking a proof chain back to the genesis transaction, similar to how SPV clients verify Bitcoin transactions.

When combined with Lightning, Taproot Assets enable instant stablecoin transfers routed over existing payment channels. A sender can pay USDT that arrives as USDT on the other end, using Lightning's routing infrastructure for speed and low fees. This creates what Lightning Labs describes as a decentralized FX network: edge nodes can convert between assets, enabling cross-currency payments without centralized exchanges.

Universe trust assumptions: Taproot Assets proofs are stored off-chain in Universe servers operated by issuers or third parties. If a user loses their local proof data and no Universe server is available, they cannot prove asset ownership. Multiple servers can federate in "Multiverse" mode for redundancy, but the system relies on at least one proof repository remaining accessible.

RGB: Client-Side Validation on Bitcoin

The RGB protocol represents the most privacy-focused approach to token issuance on Bitcoin. Rather than publishing token state on-chain for all participants to validate, RGB uses client-side validation: only the parties directly involved in a transaction verify its correctness. State transitions are anchored to Bitcoin transactions through cryptographic commitments, but the contract data itself remains private.

RGB reached mainnet in July 2025 with the release of v0.11.1. The ecosystem includes Iris Wallet on desktop and mobile, developer tooling through RGB Lib and the RGB Sandbox, and an RGB Lightning Node for payment channel integration. In August 2025, Tether announced plans to launch USDT natively on Bitcoin via RGB, with the rollout targeting mid-2026.

Privacy Through Client-Side Validation

In a client-side validated system, the blockchain sees only a standard Bitcoin transaction. There is no visible token identifier, amount, or recipient address on-chain. The sender provides the receiver with a state transition proof, and the receiver validates it against the contract's history, which they request from the sender or a data provider. Chain analysis of the Bitcoin base layer reveals nothing about the RGB asset transfer that was anchored to it.

This privacy model inverts the transparency assumption of ERC-20 and SPL tokens. Instead of every transfer being publicly auditable, RGB transfers are visible only to participants. The tradeoff is complexity: receivers must validate proof chains that grow linearly with the asset's transfer history, and there is no global state that DeFi protocols can query. Composability with other contracts requires explicit data sharing between parties.

Spark and BTKN: Statechain-Based Token Issuance

Spark introduces a distinct token architecture that differs fundamentally from both the smart-contract approach of EVM chains and the commitment-based approach of Taproot Assets and RGB. The BTKN standard enables token issuance on Spark's statechain layer, where transfers occur by rotating cryptographic key shares rather than publishing on-chain transactions.

USDB, issued by Brale (a FinCEN-registered Money Services Business), is the first regulated stablecoin built on this architecture. Each USDB token is backed 1:1 by U.S. Treasury bills and cash equivalents held in segregated, bankruptcy-remote accounts. What makes the architecture unusual is how transfers work: when a USDB balance moves from Alice to Bob, the Spark operators rotate their key shares so that Alice's signing capability is destroyed and Bob's is created. The underlying Bitcoin UTXO never moves on-chain.

This produces zero on-chain footprint for transfers, zero fees for Spark-to-Spark payments, and instant settlement. Users maintain self-custody through a 2-of-2 multisig model with the Spark operators, and can exit to Bitcoin L1 unilaterally using pre-signed exit transactions. The trust model requires that at least one of the Spark operators behaves honestly during each transfer.

Comparison Matrix: Stablecoin Token Standards

The following table summarizes the core properties of each standard across the dimensions that matter most for stablecoin issuance and usage.

Programmability vs Privacy: The Fundamental Tradeoff

The six standards fall along a spectrum defined by a core tension: how much of the token's state is visible on-chain. At one extreme, ERC-20 and SPL tokens publish every transfer, balance, and approval to a public ledger. This enables rich programmability: DeFi protocols can read token balances, enforce collateral ratios, and execute liquidations without permission from the token holder. But it also means every transfer is subject to surveillance, front-running, and sandwich attacks.

At the other extreme, RGB reveals nothing on-chain beyond a standard Bitcoin transaction. The token amount, asset type, and counterparty are all private. But this privacy eliminates the global state that DeFi protocols depend on. You cannot build an automated market maker that reads RGB token balances from the blockchain, because those balances do not exist on the blockchain.

Taproot Assets and Spark occupy middle positions. Taproot Assets store proofs off-chain but anchor supply commitments on-chain, enabling auditability without full transparency. Spark's statechain model keeps transfers entirely off-chain, but the operators can observe transfer metadata. Solana's Token-2022 attempts to bridge the gap with optional confidential transfers, but the inability to combine them with transfer hooks illustrates how difficult it is to serve both privacy and compliance simultaneously.

Compliance Architecture Comparison

For regulated stablecoin issuers, the ability to enforce compliance controls is non-negotiable. The GENIUS Act and similar frameworks worldwide require issuers to implement sanctions screening and asset freezing. How each standard approaches this shapes its viability for institutional adoption.

The Trend Toward Bitcoin-Native Stablecoin Standards

The stablecoin market is experiencing a notable shift. For years, Ethereum and Tron dominated stablecoin issuance almost entirely. But Tether's decision to deploy USDT on both Taproot Assets and RGB signals a strategic bet on Bitcoin-native infrastructure. This is not accidental: Bitcoin offers the largest, most liquid, and most geographically distributed settlement network in crypto.

The appeal of Bitcoin-native stablecoin standards comes from several directions. The Bitcoin stablecoin landscape benefits from Bitcoin's settlement security, its censorship-resistant base layer, and the growing Lightning Network for instant payments. For users in jurisdictions where financial surveillance is a concern, client-side validation (RGB) or minimal-footprint approaches (Taproot Assets, Spark) offer meaningful improvements over the full transparency of ERC-20.

The tradeoff is ecosystem maturity. Ethereum's DeFi ecosystem represents years of battle-tested infrastructure: lending protocols, DEXes, yield aggregators, and bridges that all speak ERC-20 natively. The Bitcoin-native standards are building this infrastructure from scratch. Whether the privacy and sovereignty benefits outweigh the composability gap depends on what the user values most.

Not all Bitcoin-native standards are equal: BRC-20 inscribes token data directly into Bitcoin witness space, consuming scarce block capacity. Taproot Assets and RGB anchor only commitments on-chain. Spark keeps transfers entirely off-chain. The on-chain cost difference between these approaches is orders of magnitude, and matters increasingly as Bitcoin block space demand grows.

What This Means for Developers and Users

Choosing a token standard for stablecoin integration is a decision about which tradeoffs are acceptable. Developers building DeFi applications will continue to default to ERC-20 and SPL tokens, where composability is mature and liquidity is deep. Developers building payment applications, particularly for cross-border payments or emerging market adoption, may find that Bitcoin-native standards offer lower costs, stronger self-custody guarantees, and a more neutral settlement layer.

For users, the practical differences come down to cost, speed, and control. An ERC-20 USDC transfer costs $1 or more and is visible to everyone. A Spark USDB transfer costs nothing, settles instantly, and preserves self-custody. The standards will likely coexist, each serving different segments of the market.

Developers looking to build on Bitcoin-native stablecoin infrastructure can explore the Spark SDK and documentation for statechain-based token integration. For users who want to experience Bitcoin-native stablecoins firsthand, General Bread is a Spark-powered wallet that supports USDB. For a deeper look at how stablecoins compare across chains, see our stablecoin transfer cost comparison tool.

This article is for educational purposes only. It does not constitute financial or investment advice. Bitcoin and Layer 2 protocols involve technical and financial risk. Always do your own research and understand the tradeoffs before using any protocol.