Why Toncoin → Gram Needs No Swap: a Technical Deep Dive

One of the most common questions after the Toncoin → Gram rebrand announcement on June 1, 2026, is: why isn’t a swap required?

Unlike Matic → POL (swap required), CRO → new CRO (swap required), FTM → S (swap required), Toncoin turns into Gram automatically, with no token migration from one contract to another. This piece explains why that is, at the level of TON’s technical design.

Native coin vs Token: the key distinction

Every blockchain has two asset types:

Native coin (gas token)

• BTC in Bitcoin, ETH in Ethereum, SOL in Solana, TON/Gram in TON
• Stored as balance: uint64/uint128 field in account state
• No contract address — it’s a protocol-level concept
• Used to pay gas (fees)
• To rename = a protocol hard-fork (if semantics change) or a metadata update only (if display changes)

Token (contract-based)

• USDC on Ethereum (ERC-20 contract), USDT-TON on TON (jetton), Matic on Ethereum (was ERC-20)
• Stored as mapping(address => balance) inside a smart contract
• Has a contract address (for TON — jettonMaster address)
• To rename = metadata update on the smart contract (if metadata mutable) or new contract + swap (if immutable)

Matic → POL required a swap because Matic was an ERC-20 contract with immutable metadata. A new POL contract had to be created and a swap collected.

Toncoin → Gram requires no swap because Toncoin is a native coin, not a contract. The rename happens only in the UI layer.

What’s a Toncoin/Gram balance, actually?

Looking at any TON account via the RPC API (e.g. runGetMethod or getAccountState), you get something like:

{
  "address": "EQAB...",
  "balance": "1234567890",       // ← this is nanoTON (now nanoGRAM)
  "lastTransactionId": { ... },
  "code": "...",                  // smart-contract code
  "data": "...",                  // smart-contract data
  "frozen": false
}

The balance field is uint128 in nano units. 10^9 nano = 1 TON (now 1 GRAM). No “TON” or “Gram” string anywhere. It’s just a number.

When your Tonkeeper shows “1.0 TON,” it:

1. Pulls balance from the API
2. Divides by 10^9 (decoding)
3. Appends the string “TON” (now “GRAM”) from its local metadata
4. Displays “1.0 TON” (now “1.0 GRAM”)

Same goes for Tonviewer, exchanges, aggregators — each with its own local metadata.

What happens during the rebrand

Technically — nothing at the protocol level. Every platform just changes its local-metadata constant from “TON” to “GRAM.”

It’s a distributed process:

• Tonkeeper team updates the mobile app → users see “GRAM”
• Bybit team updates the listing UI → traders see “GRAM/USDT” instead of “TON/USDT”
• CoinMarketCap team updates the database → researchers see “GRAM” in charts
• DefiLlama team updates the TON protocol name in their database

And so on. Each platform autonomously decides when to update. It’s not a coordinated event — it’s a distributed metadata refresh.

Is it hard, technically?

Technically — trivial, a string in config.

In Tonkeeper, for instance, there’s probably a constant like:

const NATIVE_COIN_SYMBOL = 'TON';  // ← becomes 'GRAM'

In a Bybit listing card:

symbol: TON  # ← becomes GRAM
display_name: Toncoin  # ← becomes Gram

The hard part isn’t engineering — it’s timing/coordination: getting all platforms to switch in sync needs comms effort. Durov gave a 3-week transition window — enough for major platforms.

Historical data

A subtle point: historical “Toncoin” data on CoinGecko, CoinMarketCap, TradingView, etc. is the same asset as today’s “Gram.” Platforms usually:

1. Rename the primitive (asset entry) from “Toncoin” to “Gram”
2. Keep “Toncoin” as a search alias
3. Preserve all historical data (price chart, volume, market cap)

So your TradingView “TON/USDT” chart continues showing the full history — just renamed to “GRAM/USDT.”

Jettons like USDT-TON, NOT, DOGS, etc.

All these jettons are independent smart contracts on TON. Their metadata (name, symbol, icon) lives in the jetton-master contract via get_jetton_data().

Each issuer decides independently:

• Tether (USDT-TON) — unlikely to rename; USDT is a stable brand
• Notcoin (NOT) — unlikely
• DOGS — unlikely
• Tonstakers (tsTON) — may rename to tsGRAM
• bemo (bemoTON) — may rename to bemoGRAM
• Hipo (hTON) — may rename to hGRAM

Each is an independent decision, unrelated to the native rebrand.

Code/SDK implications for developers

If you use TON Connect or TON SDK

Nothing to change in code. The SDK works with:

• Address (EQ.. / UQ.. format)
• Amount in nanoTON / nanoGRAM (bigint)
• Transaction format (boc, cell)

None of these contains the string “TON.” For example:

// Before and after the rebrand — identical code
const result = await tonClient.sendTransaction({
  to: 'EQAB...',
  amount: toNano('1.0'),  // 1 TON = 1 GRAM, same function
  payload: ...,
});

toNano('1.0') returns 1000000000n — that’s nanoTON/nanoGRAM, the same thing.

If you use string-based ticker matching

// Before rebrand:
if (token.symbol === 'TON') { ... }

// After rebrand your bot may break if the API now returns 'GRAM':
if (token.symbol === 'GRAM') { ... }

// Best practice — support both, or use a contract-address/native flag:
if (token.symbol === 'TON' || token.symbol === 'GRAM') { ... }
// or
if (token.isNative) { ... }  // protocol-level flag

This is the only place where code can break during the rebrand — if you hardcoded the symbol string. Audit your code.

What it would look like done Matic-style

Hypothetically: if Telegram had decided to create a new GRAM jetton instead of renaming the native, a swap would be required:

1. Deploy a GRAM smart contract as a jetton
2. Every Toncoin holder burns their TON and mints GRAM
3. Exchanges list GRAM as a jetton
4. Native TON remains in circulation, splitting liquidity

This would be much worse for users:

• Gas costs on the swap
• Some users would never swap and effectively lose tokens
• Split liquidity (TON and GRAM on DEXes)
• All DeFi positions would require migration

Durov and the team picked the cleanest path: no swap, just rename the metadata.

Technical FAQ for power users

Does the nano unit change?

No. It was nanoTON = 10^-9 TON, now nanoGRAM = 10^-9 GRAM. Same unit, renamed.

Does gas pricing change?

No. Gas is computed in nano units; prices in protocol config are unchanged.

Does the address format change?

No. EQ/UQ formats remain, raw format (0:abc…) remains.

Does the BOC format change?

No. Cells, slices, addresses — all the same.

Does the validator set change?

No. That’s a separate process (Telegram became the largest validator on May 4 as part of MTONGA step 3, before the rebrand).

Does the protocol version change?

No. The current network configuration version continues.

What about RPC methods like runGetMethod?

No change. The RPC API returns the same data structure.

What about TON Connect?

No change. The protocol works with addresses and transactions, not tickers.

What changes vs what doesn’t

Bottom line

The Toncoin → Gram rebrand is technically trivial as far as the blockchain itself is concerned. No contract deployments, migrations, or swaps. It’s a metadata update in the UI layer, distributed across platforms with a 3-week transition window.

The hard part is coordination: getting every wallet, exchange, and aggregator to switch in sync. But that’s an off-chain task per team, not an on-chain operation.

For holders: do nothing, change nothing, swap nothing. Just watch the UI shift from “TON” to “GRAM” over the next 2–3 weeks.

Further reading:

• Main Toncoin → Gram explainer
• What is a jetton and how it works
• TON sharding inside
• What is TON: the complete guide