The friction stack
Most stablecoin payment architecture on general-purpose chains runs into the same stack of problems:- Users have to hold a second token (ETH, SOL) to pay gas for a transaction that moves stablecoins. An onboarding step that bleeds conversion.
- Even with a second token, the user has to cover gas. This breaks the “send a dollar for a dollar” mental model that merchants and payment apps need.
- Transaction costs fluctuate with network activity. Payroll, treasury ops, and batch settlements can’t plan cost or inclusion.
- Per-transaction limits cap throughput. High-volume USDT flows hit chain-wide contention and degrade alongside unrelated activity.
- Every transaction is publicly observable. Supplier payments, salary runs, and treasury moves leak commercially sensitive data.
How the features compose
Stable addresses each friction with a dedicated mechanism:| Friction | Mechanism | Page |
|---|---|---|
| Separate gas token | USDT0 is the native gas token | USDT as gas |
| User pays gas at all | Governance-authorized waivers cover gas | Gas waiver |
| Cost and inclusion variance | Reserved block capacity for enrolled partners | Guaranteed blockspace |
| Throughput ceiling | Parallelized USDT0 transfer batching | USDT transfer aggregator |
| Public amount visibility | Selective privacy via ZK cryptography | Confidential transfer |
Next recommended
USDT as gas
Understand the asset that replaces ETH for gas and payment at once.
Flow of funds
Trace USDT from on-ramp through on-chain transfer to off-ramp settlement.
Bridging to Stable
See how USDT0 moves onto Stable from other chains.