How Gas Works on Solana and TON (vs Ethereum Native Gas)

Gas is the fee a blockchain charges for computation and block space, and every chain bills it in its own native coin: Ethereum meters each operation in gas units paid in ETH, split since EIP-1559 into a burned base fee and a validator tip; Solana charges a flat base fee in lamports of SOL per signature plus an optional priority fee bid per compute unit; and TON charges its coin, GRAM (formerly Toncoin), as computation gas, as rent-like storage fees on the state a contract keeps, and as forward fees on the internal messages a transaction sets off. The consequence is identical on all three: holding a token is never enough to move it, because the paying account must also hold that chain's native coin. Each chain has an escape hatch — an ERC-4337 paymaster on EVM, and on Solana and TON the fact that the account paying the fee can be a different signer from the user, which lets a relayer sponsor it. WATS is one implementation of that pattern: an ERC-4337 paymaster on the EVM chains, shared by the Chrome extension and the mobile app, so every action there is charged in a single token, ATS, instead of the chain's native gas — which changes the token that pays, not what the chain charges. Solana and TON are fully supported chains in the same wallet; fees on TON are paid in ATS too, while Solana transactions pay their own native fee in SOL.

Ethereum's model: gas paid in the native coin

Every public blockchain has to price its scarce resource — block space and execution — and it does so with fees. On Ethereum and other EVM chains, that price is called gas, and it is always paid in the network's native coin, ETH. Each operation the EVM performs has a defined gas cost — some flat, some scaling with context such as storage writes or calldata size; a simple transfer is 21,000 gas, while a contract call costs more depending on the work it does. Your total is that gas amount multiplied by a per-unit gas price, quoted in gwei (a billionth of an ETH).

Since EIP-1559, that price splits into a protocol base fee that is burned and adjusts with congestion, plus an optional priority fee (a tip) that goes to the validator to prioritise your transaction. The key constraint for users is simple: to move any ERC-20 token, you still need ETH in the same account to pay gas. Hold USDC but no ETH, and you are stuck. For a deeper walkthrough of that mechanic, see crypto gas fees explained. Solana and TON solve the same pricing problem, but with different primitives.

Solana fees: lamports, base fee, priority fees and compute units

Solana denominates fees in lamports, the smallest unit of SOL (one SOL is 1,000,000,000 lamports); a separate, refundable cost is the SOL rent held in token accounts, covered in how to reclaim rent from empty token accounts. Fees have two parts. The base fee is a flat, deterministic charge per signature — as of 2026 that is 5,000 lamports per signature — so a typical single-signer transaction pays 5,000 lamports regardless of what it does. Half of the base fee is burned and half goes to the validator.

The second part is the priority fee, and this is where Solana's compute units (CUs) come in. Every instruction consumes compute units up to a per-transaction limit, and a transaction can bid a price per compute unit — quoted in micro-lamports, a millionth of a lamport — via a compute-budget instruction. Priority fee equals the CU limit you request times that price, and it acts as the tip that gets you scheduled ahead of others when a hot account or the whole network is congested. Unlike Ethereum, the base fee is not a market rate that floats with demand; the market lives entirely in the priority fee.

Crucially, Solana separates the account that signs the meaningful action from the account that pays. The fee-payer is simply the first signer of the transaction, and its SOL balance is debited for the fee. That account does not have to be you — anything you authorise can be paid for by a different signer. That single design choice is what makes relayer patterns possible on Solana.

TON fees: gas, storage and forward fees in GRAM

TON (The Open Network) takes a different shape again, reflecting its actor-model, message-passing architecture where smart contracts communicate by sending messages to each other. Fees are paid in GRAM (see what changed when Toncoin was renamed GRAM) and break into several components. Gas fees pay for computation, metered in gas units much like the EVM. Storage fees are unusual and important: contracts are charged rent over time for the state they occupy on-chain, so an account slowly pays for persisting data rather than paying once.

Then there are forward fees, which cover the cost of sending internal messages between contracts — because a single user action on TON often fans out into a chain of messages, each hop carries a forwarding cost. In practice a wallet attaches some GRAM to a transaction to cover gas plus forwarding, and unused value is typically returned. The upshot is the same familiar friction: to do anything on TON, you need GRAM sitting in the right place. For a side-by-side of the three execution models, see EVM vs Solana vs TON.

Fee-payer and relayer patterns: the paymaster analog

On EVM, the emerging answer to "I have tokens but no ETH for gas" is account abstraction. ERC-4337 introduces a paymaster: a contract that agrees to sponsor the gas for a user's operation, optionally charging them in an ERC-20 token instead. EIP-7702, introduced in the Pectra upgrade, further lets an ordinary externally owned account sign an authorization pointing its code field at a smart-contract implementation and so adopt smart-account behaviour reversibly — the delegation stands until it is repointed or cleared — widening where these patterns apply. ERC-4337 and its EntryPoint contract are strictly EVM standards — they do not run on Solana or TON. If the mechanics are new to you, what is a paymaster walks through them.

Solana and TON reach the same outcome with native primitives rather than a formal standard. On Solana, because the fee-payer is just the first signer, a relayer service can co-sign and pay the SOL fee for a transaction the user authorised, then settle with the user however it likes — including charging them in a different token. On TON, a similar relayer or sponsoring contract can attach the required GRAM and forward the user's intended message, so the user never needs GRAM themselves. These gasless options exist today, with caveats (as of October 2026): on Solana, Solana's own docs list Kora, a fee-abstraction relayer that co-signs as the fee payer so a user can pay in an SPL token or nothing at all, and on TON, wallet v5 supports gasless transfers in which a relayer broadcasts the user's signed message and the fee is paid in a supported jetton such as USDT instead of GRAM. Both depend on the app or wallet integrating a relayer, and neither removes the underlying network fee. WATS Wallet uses neither route: its Solana transactions pay SOL, and fees on its TON transactions are paid in ATS. The label differs — paymaster, fee-payer, relayer — but the function is identical: decouple the token you hold from the native token the chain demands for fees.

Why one fee token across chains is hard

Put these three models together and the multi-chain user's problem is obvious. To be self-sufficient you must maintain ETH on every EVM chain, SOL on Solana, and GRAM on TON — each a separate balance you have to acquire, top up, and watch. Fee sponsorship fixes the "no native coin in this account" problem on a single chain, but a sponsor still needs a way to be reimbursed, and a token on one chain is not natively spendable on another.

That is where a cross-chain token standard matters. LayerZero's OFT (Omnichain Fungible Token) standard, as of 2026, lets a single token maintain one unified supply across many chains rather than relying on wrapped, chain-specific copies. A simpler route to the same outcome is to keep the fee token in one place and let a paymaster do the rest: on EVM networks the user always pays in that one token, wherever it is held, and behind the scenes the sponsor supplies the native coin the chain actually requires. Chains outside that arrangement keep charging their own native fees.

How WATS uses this

WATS applies exactly this pattern. On EVM chains it uses an ERC-4337 paymaster, so every transfer, swap or stake on those networks is charged in one token, ATS, instead of native gas. Solana and TON are fully supported chains in the same wallet — send, receive, swap, bridge, one app and one identity — and fees on TON are paid in ATS too, while Solana transactions pay their own native fee in SOL. Your ATS balance sits on BSC (BNB Chain), so whichever EVM network the transaction runs on, the fee comes out of that one balance. The ATS collected as fees is burned, reducing supply from 100,000,000 toward a 30,000,000 floor. Worth stating plainly, because the mechanics above make it clear: this is not a discount. The chain still charges what it charges; the paymaster just supplies the ETH the network demands and bills you in ATS instead.

So the practical takeaway from three different fee models is a single habit change. If you move regularly between EVM chains, Solana and TON, you can stop topping up ETH on every EVM chain you touch: fund ATS once in WATS, and the paymaster covers the native coin each EVM transaction actually consumes, while fees on TON are paid in ATS too and your Solana activity keeps paying in SOL from the same app. The full mechanics are on the ATS fee page.