What is a jetton and how it works: 2026 guide

A jetton is the fungible-token standard on TON, and architecturally it differs from the familiar ERC-20 in a meaningful way. Understanding that difference is the key to why USDT on TON moves faster and cheaper, why DEX swaps route through a pTON wrapper, and why fake jettons are a real threat rather than a theoretical risk. This article unpacks the jetton standard at a level useful to a technically curious reader — no code, but the correct mental model.

Why TON needed its own token standard

When the TON team designed the ecosystem, they faced a fundamental Ethereum constraint: ERC-20 stores every holder’s balance in one dictionary. Every USDT, USDC, or any ERC-20 transfer mutates the same contract. If a million users transfer simultaneously, they contend for one slice of state — no parallelism, no horizontal scaling.

TON was designed for sharding from day one — horizontal splitting of the chain into parallel chains. For sharding to deliver, token operations must be parallelisable. So the jetton standard was specified — formalised as TEP-74: instead of one contract per token, a hierarchy of contracts where every holder owns their own mini-contract.

Architecture: jetton-master plus jetton-wallet

Any jetton on TON is a two-tier system of contracts.

Jetton-master. The parent contract. It stores:

• Metadata: name, ticker, decimals, logo URL.
• Total supply.
• Mint logic (creating new tokens) and burn logic (destroying them).
• Optionally: blacklist, mintability flag, admin permissions.

Jetton-wallet. A holder’s wallet contract. Each user has their own jetton-wallet for every jetton they hold. It stores:

• The user’s balance of this specific jetton.
• The owner address (the user’s TON address).
• The address of the parent jetton-master.
• A pointer to the next jetton-wallet in the chain (used for optimisations).

When you receive USDT for the first time, the network deploys a USDT jetton-wallet for you. That is a one-time operation costing a few cents in TON. Afterwards transfers between your jetton-wallet and the recipient’s jetton-wallet do not touch the jetton-master at all — the two contracts talk directly, which is what gives TON the parallelism.

Transfer flow: what happens when you send USDT

Imagine Alice sends 10 USDT to Bob.

1. Alice initiates a transaction from her TON wallet, calling transfer on her USDT jetton-wallet.
2. Alice’s jetton-wallet checks: enough balance? valid signature?
3. Alice’s jetton-wallet reduces its own balance by 10 USDT and sends an internal message to Bob’s jetton-wallet saying “credit 10 USDT”.
4. Bob’s jetton-wallet (if already deployed) increases its balance. If not yet deployed, the network deploys it on the fly — that is why the first transfer to a fresh address is more expensive.
5. Bob’s jetton-wallet sends a notification to Bob’s owner address so his wallet UI shows the updated balance.

The jetton-master is not involved in a normal transfer — it only runs for mint, burn, or admin operations. That is precisely why TON sharding is efficient: transfers between unrelated address pairs are parallelisable.

Gas: why the first transfer costs more

Exact numbers in 2026 float, but the order of magnitude looks like this:

Part of the gas is included as a forward_fee — a prepayment for downstream messages in the chain. This guarantees the transaction reaches completion rather than hanging halfway.

TEP-74 and its extensions

TEP stands for Telegram Open Network Enhancement Proposal — the analogue of EIP in Ethereum. TEP-74 specifies the baseline jetton standard: which methods a jetton-wallet must support, which messages it must accept, and the ABI for minter/transfer/burn.

Extensions:

• TEP-89. Discoverable Jettons — a standard way for applications to fetch metadata.
• TEP-95. Extended metadata (off-chain storage for logo and description).
• Custom jettons. Many projects layer additional logic on top of TEP-74: vesting, snapshot drops, rebase. The standard does not forbid this.

USDT from Tether on TON is a TEP-74-compliant jetton with an additional blacklist function (address freeze).

Verifying jetton authenticity

Because anyone can issue a token with the USDT ticker and the Tether logo, authenticity verification is a practical skill.

1. Match the jetton-master address. The official USDT-on-TON address is published on tether.to. Tonkeeper, MyTonWallet, and tonviewer.com flag verified jettons with a checkmark and an explicit source.
2. Do not trust “gifts” from unknown addresses. Fake jettons are airdropped at scale to fresh wallets. Their only purpose is to lure the user into a phishing swap.
3. Ignore message comments attached to transactions. The comment field on a jetton transfer can contain anything, including links to scam sites.
4. On DEX swaps, only pick verified pairs. STON.fi and DeDust filter pools; third-party aggregators do not always.

pTON: why DEXes wrap native TON

Technically native TON is not a jetton. A TON address does not have a jetton-wallet contract because TON is held directly in the main balance cell of the wallet smart contract. Convenient for users, but a problem for DEXes: a liquidity pool needs to call uniform methods (jetton.transfer, jetton.balance_of and friends) on both assets.

The solution is pTON (proxy TON) — a jetton wrapper of native TON deployed by STON.fi and DeDust. Pools store pTON, not native TON. When a user swaps TON for USDT:

1. The wallet converts native TON to pTON through a special contract.
2. The pool swaps pTON for USDT using the standard AMM logic.
3. The user receives USDT on their jetton-wallet.

The reverse direction (USDT to TON) works symmetrically. For the user this is invisible — the wallet shows a plain “swap TON for USDT”. But if you inspect the transaction on tonviewer, the appearance of pTON in the trace is normal, not an attack.

Jetton vs NFT

Alongside TEP-74, TON has TEP-62/64 — the NFT-item standard. Architecturally similar (an NFT-collection plays the role of jetton-master, an NFT-item plays jetton-wallet), but the semantics differ:

• A jetton is fungible, divisible, has decimals.
• An NFT-item is unique, indivisible, has an index inside a collection.

That is why Telegram upgraded gifts are technically implemented as NFTs, not as jettons: each gift is unique, not “one unit among many”.

Key takeaways

• A jetton is not “a token in one contract” but a hierarchy: one jetton-master plus many jetton-wallets, one per holder.
• The architecture enables parallelism and scales horizontally, at the cost of a one-time deployment fee for the recipient’s jetton-wallet on first receipt.
• pTON is a technical wrapper used by DEXes, not a separate token in the user’s wallet view.
• Jetton authenticity is verified by the jetton-master address, not by ticker or logo.

A natural follow-up for the technically curious is a read on FunC and Tact — the smart-contract languages of TON, in which these contracts are actually written.