Matt Corallo followed up on an earlier post on Aug. 25, addressing what stablecoin users increasingly see: apps routing around ETH, SOL, and other non-stablecoin tokens.
A wallet can let someone receive and send USDC without displaying a native-token balance. Behind that interface, an app, paymaster, sponsor, or infrastructure provider still settles the network fee in the asset the chain accepts.
The native-token demand debate turns on who funds execution, manages the fee balance, and absorbs volatility after the user-facing requirement disappears.
The scale of the stablecoin rail makes that question more than a user-experience footnote. Visa’s Onchain Analytics dashboard showed about $1.3 trillion in adjusted stablecoin volume and 230.3 million adjusted transactions over the 30 days viewed on Aug. 27.
Before adjustment, the same window contained about $6.8 trillion and 1.75 billion transactions.
Visa and Allium’s adjusted methodology uses probabilistic labels for more than 3 million addresses, counts only the largest stablecoin transfer within a single transaction, and filters unlabeled addresses that exceed 1,000 transactions or $10 million in rolling 30-day volume.
The data still includes exchange, decentralized exchange, lending, mint-and-burn, and ramp activity. Visa’s “retail-sized” bucket logged about $7.6 billion across 158.8 million adjusted transactions below $250.
Gasless is a change of payer, Ethereum makes the example
Fee abstraction separates three roles that conventional wallets often bundle together: the user authorizes an action, an intermediary funds its execution, and the network charges its native fee.
| Flow | What the user sees | What the network requires | Who fronts the native asset | How the cost can return |
|---|---|---|---|---|
| Ethereum ERC-4337 | A smart-account action without user-held ETH | A native-currency deposit at EntryPoint | A paymaster, app or wallet provider | Developer billing, fiat charges or token payment |
| Coinbase or Alchemy sponsorship | A sponsored transaction or a fee quoted in USDC | Native gas for the onchain operation | Managed paymaster infrastructure | Service fees, monthly billing or token recovery |
| Solana fee sponsorship | A stablecoin transfer without user-held SOL | SOL for the transaction fee | The designated fee-payer account | App subsidy or an offchain charge |
| Solana Kora | A fee paid in an SPL token such as USDC, or no visible fee | SOL for the underlying network fee | The Kora operator | SPL-token payment, policy-based subsidy or service margin |
“Gasless” can be accurate for the customer’s wallet while still being misleading about chain economics.
Ethereum’s documentation notes that reads can be performed without gas, while state-changing contract writes cost gas. Ethereum denominates gas in ETH, burns the protocol-set base fee, and sends the priority fee to the validator.
Under ERC-4337, which introduced account abstraction, users submit operations that a bundler packages into an Ethereum transaction. A paymaster can cover an operation instead of the smart account, but it must maintain a native-currency deposit at the EntryPoint contract. EntryPoint checks whether that deposit can cover the operation’s maximum cost and charges the actual cost against it.
No universal “enough ETH” balance exists for a paymaster. The requirement moves with the operation’s gas limits, maximum fee settings, transaction volume, and the buffer an operator maintains for service continuity.
Coinbase’s ERC-20 gas-payment flow can quote a fee in USDC while the paymaster covers native gas, while Alchemy’s Gas Manager fronts gas and bills separately. The user can remain economically inside the stablecoin while the provider funds and manages native-fee capacity.
At the retail layer, the design reduces the need for users to maintain ETH balances. At the execution layer, it replaces that scattered requirement with managed payer accounts or services whose operators replenish balances and recover costs through token, fiat, or service billing.
Solana changes the signer
Solana’s fee documentation states that every transaction requires a fee paid in SOL. The base fee is 5,000 lamports per signature, split evenly between burning and the validator, while an optional priority fee can raise the total and goes to the validator.
By default, the fee payer is the first signer, but an app can name a sponsor instead. The user signs to authorize the stablecoin transfer and the sponsor signs to authorize the SOL fee.
Solana’s fee-abstraction guide makes the resulting requirement explicit: the sponsor needs SOL for fees, though it does not need to hold the token being transferred. Kora packages that primitive into a service that can fully sponsor fees or accept payment in an SPL token such as USDC.
The user may therefore experience an all-dollar transaction while the Solana transaction fee is still paid in SOL by the sponsor or Kora operator.
The 5,000-lamport base fee also shows why transaction count alone cannot establish large SOL demand. Signature counts and priority fees affect the bill, while service volume and the operator’s funding buffer determine how much SOL a sponsor needs.
Solana’s fee sponsorship, like Ethereum’s paymasters, changes who holds the fee balance. It gives the application control over when the user pays, which asset the user sees, and whether the app subsidizes the cost.
For a sponsor, the user-facing payment asset changes the recovery leg rather than the network leg. The service still needs a funded SOL fee-payer account before submission, while its USDC billing or subsidy policy operates around that requirement. A larger stream of sponsored transfers therefore increases the number of fees the operator must fund, even though signatures and priority settings determine each transaction’s SOL cost.
Native-token demand becomes wholesale
With sponsorship, an app or provider can aggregate the requirement that each active user needs a native-token balance. It may replenish a managed ETH or SOL balance and recover the cost in USDC, fiat, or a service charge.
That architecture can shift operational exposure toward fewer payers as stablecoin adoption grows. Sponsors must manage fee funding, pricing, and abuse controls even though their customers never see a gas balance.
Representative Coinbase, Alchemy and Kora implementations establish how the architecture works, while leaving its market-wide distribution unresolved. Any claim that a handful of providers already dominate Ethereum or Solana gas demand would require payer-level onchain analysis beyond these sources.
Aggregation can also reduce the need for every user to hold a dormant native-token balance. Managed services can replenish balances as needed and recover costs through their own billing models.
Native-asset demand also depends on how many transactions settle, the fees attached to them, execution efficiency, and the balances payers maintain. Value capture depends on what is burned, what validators receive, and whether activity moves to cheaper environments.
Solana activity can grow while SOL value capture remains limited, particularly when stablecoin users need little SOL beyond fees. Ethereum can host a large stablecoin economy while base-chain revenue remains comparatively thin.
Fee abstraction changes the customer for the native asset. ETH and SOL can disappear from the user journey while remaining mandatory at the network layer. The gas bill moves upstream to the companies making stablecoin payments feel like ordinary money, concentrating operational responsibility even as the effect on aggregate token demand remains unmeasured.
