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.
iIn short
Toncoin/Gram is not a smart contract — it’s part of the TON protocol itself. There is no ‘Toncoin-token’ contract with user balances. Balances live in each account’s state as a field in a protocol-level structure. So a rename doesn’t affect state — only metadata changes in the UI layer of each platform.
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/uint128field 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:
- Pulls
balancefrom the API - Divides by 10^9 (decoding)
- Appends the string “TON” (now “GRAM”) from its local metadata
- 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:
- Rename the primitive (asset entry) from “Toncoin” to “Gram”
- Keep “Toncoin” as a search alias
- 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:
- Deploy a GRAM smart contract as a jetton
- Every Toncoin holder burns their TON and mints GRAM
- Exchanges list GRAM as a jetton
- 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
| Thing | Pre-rebrand | Post-rebrand |
|---|---|---|
| Native unit name | nanoTON | nanoGRAM (same unit) |
| Address format | EQ/UQ/raw | EQ/UQ/raw |
| Block structure | TON v2 | TON v2 |
| Gas pricing | in nanoTON | in nanoGRAM (same) |
| Smart contracts | unchanged | unchanged |
| Jetton addresses | unchanged | unchanged |
| Validator set | Telegram = largest | Telegram = largest |
| RPC API | unchanged | unchanged |
| Wallet UI display | ”TON" | "GRAM” |
| Exchange ticker | TON/USDT | GRAM/USDT |
| CoinGecko entry | Toncoin | Gram |
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:

Top comments (0)