Skip to main content
T TON Adoption
Basics GUIDE · 2026

Gas Stations on TON: Battery, Gasless and W5

How USDT moves on TON without holding TON: Tonkeeper Battery, @wallet Gasless flow, W5 sponsored transactions, and how it compares to ERC-4337 paymasters.

Author
TON Adoption Team · research desk
Published
7 min read

If you recently sent USDT through @wallet in Telegram and noticed you did not have a single TON in your main balance, congratulations — you used a gas station. This is one of TON’s most visible UX revolutions of the last two years: users no longer need to hold the network’s “native” coin just to pay a fee. Let us unpack how it works technically, who pays the bill economically, and how safe the model is.

This is written for everyday users who are surprised their transaction went through “without TON”, and for developers thinking about embedding gas abstraction into their own app.

Where the problem comes from

In the classic model of any blockchain, gas is paid in the network’s native coin. On Ethereum that is ETH; on TON it is TON. This creates a familiar UX disaster: a new user installs a wallet, a friend sends them some USDT, the user tries to forward it somewhere — and gets “insufficient TON for fee”. To fix it they have to find 0.5-1 TON, figure out how to acquire it, and only then move their USDT.

For a crypto enthusiast that is forty seconds of annoyance. For the mass audience Telegram is pitching TON to, it is the stop-the-funnel moment of “no, I am done with this”. So the TON ecosystem, especially after @wallet integration and USDT-jetton growth, started building infrastructure that hides gas from the end user.

Three abstraction models

In 2024-2026 three practical approaches emerged on TON:

  1. Battery — the user pre-charges a separate contract balance (with TON, fiat by card, Apple Pay). After that the wallet automatically pulls gas from Battery whenever the main balance has no TON. Pioneered by Tonkeeper.
  2. Gasless — a relayer pays the on-chain fee in TON and reimburses itself directly out of the jetton being transferred. Send 50 USDT and the recipient gets 49.7; the 0.3 USDT covered gas. This is how @wallet handles USDT transfers.
  3. Sponsored transactions via W5/V5 — an open interface at the wallet contract level that lets any third party (an app, a dApp, a corporate sponsor) pay for a user transaction. This is infrastructure, not a product.

Each model solves the same problem through different economics and trust assumptions.

Tonkeeper Battery: a prepaid gas balance

Battery shipped in Tonkeeper in 2024 and quickly became the reference design. The idea is simple: alongside the regular wallet a second contract — Battery — is tied to the user’s address. You top it up with TON directly or buy a “charge” by card through the Tonkeeper UI (Apple Pay, Google Pay, plain card).

When the user sends, say, USDT and the main wallet has no TON, Tonkeeper builds a transaction backed by the Battery contract. Battery attaches the needed TON to the external message and the network accepts it as ordinary gas payment.

Key properties:

  • Prepaid. Battery is a balance you bought ahead of time, not a subscription. $5 covers roughly 100-200 USDT transfers at current gas levels.
  • Markup. Tonkeeper takes a small margin over the TON-denominated gas cost (around 20-30%) — the price of the fiat on-ramp.
  • No key sharing. The user’s signature is still required. Battery is a co-signer that adds TON to the outgoing message but cannot forge it.

Tonkeeper’s economics: margin on fiat→gas conversion plus better retention (fewer users churn over “can’t send” errors).

Gasless: the fee comes out of the jetton itself

The Gasless model is more elegant. The user sends 50 USDT — under the hood the wallet routes the transaction through a relayer service. The relayer:

  1. Attaches its own TON to the transaction to cover gas.
  2. Asks the user’s jetton-wallet for an extra 0.3 USDT (or whatever the current jetton-denominated gas cost is).
  3. That 0.3 USDT is sent to the relayer’s address as the service fee.

The recipient ends up with 49.7 USDT, the relayer with 0.3 USDT, and the network gets its standard TON-denominated gas. The user does not even need to know the chain has a native coin. This model is the foundation of the mass USDT flow in @wallet and in most jetton aggregators.

Technically Gasless requires jetton-wallet support: the contract must parse a “double” transfer (part to recipient, part to relayer) inside a single transaction. With Wallet V5 this became a baseline capability — V5 can sign complex cell structures with multiple outgoing messages.

ModelWho pays gasWhat user pays inBest for
ClassicuserTON directlypower users
BatteryTonkeeper BatteryTON / fiat in advancefrequent jetton senders
Gasless@wallet relayera slice of the jettonnewcomers, single-token users
W5 sponsoredexternal sponsor (dApp, brand)nothing — dApp paysonboarding, marketing

W5 and sponsored transactions

Wallet V5 (a.k.a. W5) is the new standard TON wallet contract, rolled out from 2024-2025. The key innovation for gas abstraction is built-in support for external plugins and relayers.

In V4 the external message format implied the gas payer was the wallet itself. V5 extends the format: TON can be attached to a message by any address (not just the owner), and the payment is accepted. That turns gas stations from “a separate service” into “a built-in feature of the wallet protocol”.

Practical consequences:

  • dApps can pay for onboarding transactions. A TON game can cover the user’s first NFT mint — the user never knows a transaction even happened.
  • Brands and campaigns. A coffee shop runs a promo: “first 100 customers get an NFT coupon, gas on us”. On EVM that needs an ERC-4337 paymaster. On TON it is a few lines in the wallet code.
  • Enterprise use. A company can pay gas for employee wallets without giving them access to the corporate treasury.

The V5 contract also simplifies Gasless: relayers no longer need to rewrite the transfer flow, they just sprinkle TON onto an already-built external message.

Economics: who pays and why

A gas station is a service. A service has a business model. Understanding it helps you judge how durable any given gas station will be.

  • Tonkeeper Battery. Margin on the fiat→gas conversion (20-30%) plus retention. Financially viable at moderate volume.
  • @wallet Gasless. Margin in USDT-jetton (a few cents per transaction). The Telegram wallet has enormous flow, so it works in the black.
  • W5 sponsored for dApps. Marketing budget. Same logic as “free shipping” in e-commerce: the app pays for onboarding, banking on user LTV.
  • External relayers as a service. Several teams (Tonapi, TONX) offer relayer-as-a-service for B2B with a fixed per-tx margin.

Security: the real risks

Gas stations are not a free lunch. Worth knowing:

  1. Outage. If Tonkeeper’s Battery server goes down or @wallet’s relayer is offline, gas abstraction stops working. A user with no TON on the main balance temporarily cannot send anything. Mitigation: keep a 0.5-1 TON cushion just in case.
  2. De-anonymization. The relayer sees which transactions it sponsors. That means @wallet knows who sent USDT to whom and when (obvious, given it is a Telegram service, but worth being aware of).
  3. Upgrade risk. Tonkeeper’s Battery contract is upgradeable. Not a bug — a necessary feature for updates — but it adds a trust point on the Tonkeeper team. The contract is audited regularly.
  4. Relayer front-running. Theoretically a relayer can delay or reorder transactions. In practice this matters less on TON than on Ethereum (no public mempool with predictable gas-priority sorting), but the risk is non-zero.

Comparison with ERC-4337 / paymasters

ERC-4337 is Ethereum’s standard for “account abstraction” and also lets a third party pay gas. The model is inspirational but heavy: it needs an EntryPoint contract, a dedicated bundler infrastructure, and mempool workarounds.

On TON gas abstraction came out simpler, because the architecture never wired in “one gas payer = the sender”. Every external message on TON carries TON as an “attached amount”, and the network does not check whose address attached it. That is the built-in paymaster — no separate standard required.

The downside: there is no direct analogue of social recovery, daily limits, or multi-factor patterns from 4337. That functionality lives in multisig and vault contracts like MyTonWallet Multisig on TON, not in the base wallet format.

The bottom line

Gas stations are the headline TON UX breakthrough that lets the Telegram audience get into crypto without the painful “first acquire some TON” detour. The technical model rests on three pillars: prepaid Battery, Gasless relayers, and W5 sponsored transactions. Each carries its own financial and trust boundaries, but together they cover the vast majority of new-user scenarios.

If you want to go deeper into the V5 wallet itself and whether you should migrate from V4, there is a dedicated piece. The jetton plumbing that all these Gasless fees ride on is covered in the TEP-74 deep dive. And the structure of real TON fees lives in the dedicated fees guide.

Frequently asked

Most likely you used @wallet in Telegram or Tonkeeper with Battery enabled. Those wallets pay the gas for you and bill the fee either in USDT (Gasless) or from your prepaid Battery balance.
On an on-chain Battery contract tied to your address. You top it up with TON or via Apple Pay / Google Pay / card. It is spent automatically on each transaction whenever the main wallet has no TON.
The transaction signature itself stays with you. The sponsor only attaches TON to your transaction and cannot modify it. The real risks are sponsor downtime and de-anonymization (the sponsor sees who pays for what).
The idea is similar — a third party pays gas — but the implementation differs. ERC-4337 requires an EntryPoint contract and bundler infrastructure. On TON the sponsor just attaches TON to an external message; the mechanic is built into the message format and needs no intermediary bundlers.

Related