Почему swap Toncoin на Gram не нужен: техника под капотом

Один из самых частых вопросов после анонса ребрендинга Toncoin → Gram 1 июня 2026 года: почему не требуется swap?

В отличие от Matic → POL (требовался свап), CRO → новый CRO (требовался свап), FTM → S (требовался свап) — Toncoin превращается в Gram автоматически, без переезда токенов с одного контракта на другой. Этот материал объясняет, почему это так, на уровне технического дизайна TON.

Native монета vs Token: ключевое различие

В каждом блокчейне есть два типа активов:

Native монета (gas token)

• BTC в Bitcoin, ETH в Ethereum, SOL в Solana, TON/Gram в TON
• Хранится как поле balance: uint64/uint128 в account state’е
• Не имеет contract address — это protocol-level concept
• Используется для оплаты gas (комиссии)
• Изменить или переименовать = hard-fork протокола (если меняется semantic) или просто metadata-update (если меняется только display)

Token (контрактный)

• USDC в Ethereum (ERC-20 contract), USDT-TON в TON (jetton), Matic в Ethereum (был ERC-20)
• Хранится как mapping(address => balance) внутри smart-contract’а
• Имеет contract address (для TON — jettonMaster address)
• Переименование = metadata-update смарт-контракта (если metadata mutable) или новый контракт + swap (если immutable)

Matic → POL требовал свапа, потому что Matic был ERC-20 контрактом с immutable metadata. Нужно было создать новый контракт POL и собрать через свап.

Toncoin → Gram не требует свапа, потому что Toncoin — native монета, не контракт. Переименование происходит исключительно в UI-слое.

Что такое balance Toncoin/Gram на самом деле

Если посмотреть на любой TON-account через RPC API (например, через runGetMethod или getAccountState), вернётся структура примерно такая:

{
  "address": "EQAB...",
  "balance": "1234567890",       // ← это nanoTON (теперь nanoGRAM)
  "lastTransactionId": { ... },
  "code": "...",                  // smart-contract code
  "data": "...",                  // smart-contract data
  "frozen": false
}

Поле balance — это uint128 в nano-единицах. 10^9 nano = 1 TON (теперь 1 GRAM). Никакой строки «TON» или «Gram» здесь нет. Это просто число.

Когда твой Tonkeeper показывает «1.0 TON», он:

1. Получает balance через API
2. Делит на 10^9 (декомирование)
3. Прикладывает строку «TON» (теперь «GRAM») из своих local metadata
4. Показывает «1.0 TON» (теперь «1.0 GRAM»)

Точно так же делает Tonviewer, биржа, агрегатор — каждый со своими local metadata.

Что происходит при ребрендинге

Технически — ничего на уровне протокола. Каждая платформа просто меняет свою local-metadata constant с «TON» на «GRAM».

Это распределённый процесс:

• Tonkeeper team обновляет mobile app → пользователь видит «GRAM»
• Bybit team обновляет UI листинга → трейдер видит «GRAM/USDT» вместо «TON/USDT»
• CoinMarketCap team обновляет database → researcher видит «GRAM» в charts
• DefiLlama team обновляет protocol-name TON в их database

И так далее. Каждая платформа автономно решает, когда обновить. Это не coordinated event — это distributed metadata refresh.

Это вообще сложно или нет?

Технически — тривиально, на уровне строки в config’е.

В Tonkeeper, например, есть какой-то constant вроде:

const NATIVE_COIN_SYMBOL = 'TON';  // ← меняется на 'GRAM'

В Bybit listing-card:

symbol: TON  # ← меняется на GRAM
display_name: Toncoin  # ← меняется на Gram

Сложность не в технике, а в timing/coordination: чтобы все платформы переключились одновременно, нужен communications-эффорт. Дуров дал 3-недельный transition window — этого достаточно для major platforms.

Что с историческими данными

Здесь есть нюанс: исторические данные по «Toncoin» в CoinGecko, CoinMarketCap, TradingView и др. — это тот же актив, что теперь «Gram». Платформы обычно:

1. Переименовывают примитив (asset entry) с «Toncoin» на «Gram»
2. Сохраняют alias Toncoin для поиска
3. Сохраняют все исторические данные (price chart, volume, market cap)

То есть твой TradingView-чарт «TON/USDT» continues to show all historical data — просто переименуется в «GRAM/USDT».

Что с jetton’ами USDT-TON, NOT, DOGS, и др.

Все эти jetton’ы — независимые смарт-контракты на сети TON. Их metadata (название, символ, иконка) хранится в jetton-master контракте через get_jetton_data() метод.

Каждый эмитент jetton’а решает сам:

• Tether (USDT-TON) — вряд ли переименует, USDT — стабильный бренд
• Notcoin (NOT) — вряд ли переименует
• DOGS — вряд ли переименует
• Tonstakers (tsTON) — может переименовать в tsGRAM
• bemo (bemoTON) — может переименовать в bemoGRAM
• Hipo (hTON) — может переименовать в hGRAM

Это independent decision каждого эмитента, не связанный с ребрендингом native монеты.

Что с code/SDK для разработчиков

Если ты используешь TON Connect или TON SDK

В коде ничего менять не нужно. SDK работает с:

• Address (формат EQ.. / UQ..)
• Amount in nanoTON / nanoGRAM (bigint)
• Transaction-format (boc, cell)

Ни одно из этих не содержит string «TON». Например:

// До и после ребрендинга — identical code
const result = await tonClient.sendTransaction({
  to: 'EQAB...',
  amount: toNano('1.0'),  // 1 TON = 1 GRAM, та же функция
  payload: ...,
});

toNano('1.0') возвращает 1000000000n — это nanoTON/nanoGRAM, одно и то же.

Если ты используешь string-based ticker matching

// До ребрендинга:
if (token.symbol === 'TON') { ... }

// После ребрендинга твой бот может break, если API стало отдавать 'GRAM':
if (token.symbol === 'GRAM') { ... }

// Лучшая практика — поддерживать оба или использовать contract address:
if (token.symbol === 'TON' || token.symbol === 'GRAM') { ... }
// или
if (token.isNative) { ... }  // protocol-level flag

Это единственное место, где код может «сломаться» при ребрендинге — если был хардкодинг строки символа. Аудитьте свой код.

Что было бы если делали как Matic→POL

Гипотетически: если бы Telegram решил создать новый jetton GRAM, а не переименовать native монету, потребовался бы свап:

1. Деплоится smart-контракт GRAM как jetton
2. Каждый держатель Toncoin сжигает свой TON и минтит GRAM
3. Биржи listing GRAM как jetton
4. native TON остаётся в обращении, разделяя ликвидность

Это гораздо хуже для пользователей:

• Расход gas на свап
• Возможные потери tokens у пользователей, которые не сделали свап
• Разделённая ликвидность (TON и GRAM на DEX’ах)
• Все DeFi-позиции require migration

Дуров и команда выбрали самый clean подход: ничего не свапаем, просто переименовываем metadata.

Технический FAQ для опытных пользователей

Изменится ли nano-единица?

Нет. Была nanoTON = 10^-9 TON, стала nanoGRAM = 10^-9 GRAM. Это одна и та же единица, просто переименована.

Изменится ли gas-pricing?

Нет. Gas вычисляется в nano-единицах, цены в protocol config — не меняются.

Изменятся ли address формат?

Нет. EQ/UQ форматы остаются, raw-формат (0:abc…) остаётся.

Изменится ли BOC формат?

Нет. Cells, slices, addresses — все остаются.

Изменится ли validator-set?

Нет. Это отдельный процесс (Telegram стал крупнейшим валидатором ещё 4 мая, как часть шага 3 MTONGA, до ребрендинга).

Изменится ли protocol version?

Нет. Текущая network configuration version продолжает.

Что с RPC-методами вроде runGetMethod?

Без изменений. RPC-API возвращает ту же data structure.

Что с TON Connect?

Без изменений. Protocol работает с addresses и transactions, не с tickers.

Сравнение: что меняется vs что не меняется

Итог

Ребрендинг Toncoin → Gram технически тривиален в том, что касается самого блокчейна. Никаких contract-deployments, миграций или свапов. Это metadata-update в UI-слое, распределённый по платформам с 3-недельным transition window.

Сложность — в coordination: чтобы все кошельки, биржи, агрегаторы согласованно переключились. Но это off-chain задача каждой команды, не on-chain operation.

Для держателя это означает: ничего не делай, ничего не меняй, ничего не свапай. Просто наблюдай, как UI постепенно переходит с «TON» на «GRAM» в течение 2-3 недель.

Дополнительные материалы:

• Главный explainer Toncoin → Gram
• Что такое jetton и как работает
• TON Sharding изнутри
• Что такое TON: полный гайд