How to Test a Jetton After Launch on TON Mainnet

When you launch a Jetton on TON mainnet, the contract is no longer just code in a repo — it’s a live asset that real people can trade, store, and lose money with. Jettons are the fungible token standard on TON (similar to ERC-20 on Ethereum), defined by the TEP-74 standard and implemented through a master contract plus per-user wallet contracts.

Even if you did your homework on testnet, post-launch testing on mainnet is critical. In this article we’ll walk through how to test a newly launched Jetton in production: what to check, how to structure the work with your testers, and how to turn testing into a growth loop rather than pure cost.

1. What are we actually testing on mainnet?

On mainnet, your goal is not just “does the contract work” but:

Correctness – transfers, balances, supply, allowances (if any) behave exactly as designed.
Integrations – wallets, explorers, and DEXes all display and handle your Jetton correctly.
Economics – fees are sane, liquidity behaves as expected, users don’t get rekt by UX traps.
Safety – no obvious permission issues, minting rules, or admin powers that can be abused.

Because TON is a high-throughput L1 with low fees and deep Telegram integration, users tend to move fast and touch your token from many interfaces: mobile wallets, Telegram mini-apps, DEXes and bots.

That’s why your mainnet test plan must go beyond “unit tests + one swap on a DEX”.

2. Prepare your testing environment

Before you and your QA team hit mainnet:

Use small, sacrificial balances

Fund a few wallets with small amounts of TON and your Jetton.
Assume every TON you send into testing is potentially gone forever.

Pick a set of wallets and explorers
At minimum, test with:

2–3 popular wallets (e.g., Tonkeeper, Telegram’s TON wallet / TON Space, other ecosystem wallets).
1–2 block explorers that support Jettons.

Prepare tracking & communication

GitHub Issues, Notion, or a Telegram group with pinned formats.
A simple bug/feedback template (who, what, how to reproduce, tx link, screenshot).

3. Core test area #1: Transfers & balances

This is the “heartbeat” of your Jetton. If transfers or balances are off, nothing else matters.

Scenarios to test:

Simple transfer

Send a small amount of Jetton from Wallet A to Wallet B.
Verify:

balances in both wallets,
balances in the explorer (by checking user jetton-wallet contract),
any “excess TON” behavior is as expected (no weird extra refunds).

First-time receiver

Send Jetton to an address that hasn’t interacted with the Jetton before.
Check that the jetton-wallet contract is deployed correctly and the balance shows up.

Too little / too much

Try sending more Jetton than you own → ensure transaction is rejected or fails clearly.
Try sending tiny fractions according to your decimals (e.g., 0.000001) and see how wallets display it.

Multiple sequential transfers

Do several transfers in a row to see if balances and explorers keep up and no state desync appears.

4. Core test area #2: Wallet & explorer display

TON’s Jetton standard defines how to retrieve metadata like name, symbol, decimals, and total supply from the master contract.

You want to confirm that ecosystem tools interpret this correctly.

Check in each wallet + explorer:

Name and symbol

No broken characters, no random truncation, no collision with other tokens.

Decimals & formatting

Amounts look natural to humans.
1 Jetton is displayed as “1”, not “0.000000000001” or “1000000000000”.

Icon & metadata

If your Jetton includes an icon / metadata URI that wallets use, confirm it loads and caches correctly.
Check light/dark themes if relevant.

Network separation

Wallet clearly labels the token as mainnet, not testnet or some custom network.

If any wallet shows your Jetton incorrectly, capture:

wallet version,
screenshots,
address of the master contract,
and open communication with the wallet team if needed.

5. Core test area #3: DEX interaction & liquidity

Most Jettons live or die on DEX liquidity. On TON, DEXes like STON.fi and others use AMM pools and natively support Jettons.

If you created a pool for your Jetton:

5.1 Swaps

Test with very small amounts first:

Swap TON → Jetton

Compare expected amount in UI vs actual received.
Check slippage, price impact, and fees.

Swap Jetton → TON

Again compare UI vs on-chain result.
Ensure the transaction doesn’t unexpectedly fail due to low liquidity or tight slippage.

Repeat for different trade sizes to see how the curve reacts and how the UI explains it.

5.2 Liquidity provision (LP)

Add liquidity

Provide minimum viable liquidity to the pool (Jetton + TON or Jetton + stablecoin).
Verify LP tokens are minted correctly and balances are displayed in the DEX and in the wallet.

Remove partial liquidity

Remove e.g. 25–50% of the position.
Check if the returned amounts match expectations within a small tolerance.

Remove all liquidity

Confirm that withdrawing everything returns LP into your underlying assets, fees included.

If any DEX integration looks broken (wrong decimals, missing token icon, or pool not discoverable), that’s both a UX problem and a trust signal issue.

6. Core test area #4: Fees and gas behavior

Toncoin is used for transaction fees and for deploying contracts, including Jetton wallet contracts per user.

You want your Jetton to feel “cheap but predictable”.

Test:

Baseline fee per action

Transfer Jetton between two active wallets.
Note how much TON is spent for a typical transaction.

First interaction fee

Send Jetton to an address that hasn’t used this Jetton before.
See how much additional TON is consumed for creating that wallet-contract.

Low-TON edge cases

Try making a transfer when your address has barely enough TON for the fee.
Try when it has not enough TON.
Observe error messages in UI and behavior on-chain.

Excess TON refunds

In some flows, “excess” TON is sent back to the sender or a specified address after fees.
Check that refund logic matches your expectations and doesn’t confuse users.

7. Core test area #5: Edge cases, UX, and safety

Here you’re testing the whole user experience, not just the smart contracts.

Error messages

Not enough TON for gas.
Not enough Jetton balance.
Wrong address format.
Are the errors understandable to a non-developer?

Token confusion

Are there other Jettons with a similar name/symbol that can confuse users?
Does your branding make your Jetton easy to identify?

Admin powers & permissions

Who can mint or burn? Is that visible somewhere for users?
Are there functions that can freeze balances or seize funds?
Is there a plan for renouncing or handing over those powers, if needed?

Upgrade / migration plan

If a critical bug is found, how will you migrate users to a fixed Jetton?
Are you transparent about that in docs or announcements?

8. Organizing a tester squad

If you have a community or internal QA team, structure their work:

Create a “Testing campaign” issue with:

clear checklist (transfers, wallets, DEX, fees, UX),
instructions on how to report,
links to the Jetton contract and DEX pools.

Use a bug report template:

environment (wallet, platform, network),
steps to reproduce,
expected vs actual behavior,
tx link + screenshots.

This keeps feedback structured and makes it easier to spot patterns.

9. Incentivizing testing (without turning it into a farm fest)

Testing on mainnet is risky and costs real fees, so it’s reasonable to reward testers from a dedicated allocation of your Jetton:

a small pool for test tasks (checklists, multi-wallet scenarios);
a separate pool for bug bounties, especially for critical or security-related issues.

Some guidelines:

Reward quality, not just clicks – require real tx links and proof.
Keep the rules public and simple.
Never promise price or “guaranteed profit”: this is not financial advice and markets are wild.

Your testing program should feel like a collaboration, not a pump-and-dump scheme.

10. Conclusion

A Jetton that’s already live on TON mainnet is a production-level financial asset. The TEP-74 standard gives you a solid technical base, but only real-world testing across wallets, explorers, DEXes, and user flows will show whether your token is truly ready for users.

Be systematic:

test transfers, balances, fees, and DEX behavior;
verify integrations;
treat UX and safety as first-class citizens;
organize your testers and reward them fairly.

Do that, and your Jetton stops being “just another token” and becomes a reliable building block in the TON ecosystem.

🇷🇺

Заголовок:
Как тестировать Jetton после запуска в основной сети TON (mainnet)

Когда вы запускаете Jetton в основной сети TON, это уже не просто код в репозитории — это живой актив, с которым реальные люди хранят и двигают деньги. Jetton — это стандарт взаимозаменяемых токенов в TON (аналог ERC-20 в Ethereum), описанный в стандарте TEP-74 и реализованный через пару контрактов: master-контракт и отдельные wallet-контракты для пользователей.

Даже если вы хорошо потестили всё в testnet, пост-релизное тестирование в mainnet — обязательный этап. В этой статье разберём, как тестировать только что запущенный Jetton в бою: что проверять, как работать с тестерами и как сделать так, чтобы тесты были не просто расходом, а вкладом в рост проекта.

1. Что именно мы проверяем в mainnet?

В основной сети цель уже не просто «контракт не падает», а:

Корректность — переводы, балансы, эмиссия/сжигание, разрешения (если есть) работают по задумке.
Интеграции — кошельки, блок-обозреватели и DEX-ы правильно отображают и обрабатывают ваш Jetton.
Экономика — комиссии адекватные, ликвидность ведёт себя ожидаемо, UX не подставляет юзеров.
Безопасность — нет очевидных проблем с правами, минтом, админскими доступами.

TON — это высоконагруженный L1 с низкими комиссиями и глубокой интеграцией в Telegram, поэтому пользователи взаимодействуют с вашим токеном из разных интерфейсов: мобильные кошельки, мини-приложения, DEX-ы, боты.

Поэтому план тестирования в mainnet должен быть шире, чем «юнит-тесты + один свап на DEX».

2. Подготовка среды для тестирования

Перед тем как вы и команда QA пойдёте в mainnet:

Небольшие боевые балансы

Заведите несколько кошельков с небольшими суммами TON и вашего Jetton.
Считайте эти TON «сожжёнными на тесты» — так психологически проще.

Набор кошельков и обозревателей
Минимум стоит протестировать:

2–3 популярных кошелька (Tonkeeper, встроенный TON-кошелёк/TON Space в Telegram, другие кошельки экосистемы).
1–2 блок-обозревателя, которые поддерживают Jetton.

Трекинг и коммуникация

GitHub Issues, Notion или чат в Telegram с закреплёнными форматами.
Шаблон отчёта/багрепорта (кто, что делал, как воспроизвести, ссылка на транзакцию, скрины).

3. Ключевое направление #1: переводы и балансы

Это «сердцебиение» вашего Jetton. Если тут что-то сломано, всё остальное уже не важно.

Сценарии для проверки:

Обычный перевод

Отправить небольшое количество Jetton с кошелька A на кошелёк B.
Проверить:

балансы в обоих кошельках,
балансы в блок-обозревателе (адреса jetton-wallet контрактов),
поведение с возвратом «excess TON» (чтобы не было неожиданных возвратов/лишних транзакций).

Первый получатель

Отправить Jetton на адрес, который раньше с этим Jetton не работал.
Убедиться, что jetton-wallet контракт развернулся, а баланс появился.

Слишком мало / слишком много

Попробовать отправить больше токенов, чем есть на балансе → транзакция должна предсказуемо падать.
Попробовать отправить очень маленькую долю токена (по вашим decimals) и посмотреть, как это отображается в кошельках.

Несколько переводов подряд

Сделать серию переводов и проверить, что состояния и отображение нигде не «заедают».

4. Ключевое направление #2: отображение в кошельках и обозревателях

Стандарт Jetton описывает, как из master-контракта получать метаданные токена: имя, символ, decimals, total supply и т.д.

Нужно убедиться, что экосистема это читает корректно.

В каждом кошельке и обозревателе проверьте:

Имя и символ

Нет кривой кодировки, странной обрезки, схожести с чужими токенами.

Decimals и форматирование

Числа выглядят по-человечески.
1 токен отображается как «1», а не «0.000000000001» или «1000000000000».

Иконка и метаданные

Если вы используете иконку/URI, который подхватывают кошельки — убедитесь, что всё грузится и кэшируется.
При возможности — проверьте и светлую, и тёмную тему.

Сеть

Кошелёк явно показывает, что это mainnet, а не testnet или «кастомная сеть».

Если какой-то кошелёк отображает ваш Jetton криво — фиксируйте:

версию приложения,
скриншоты,
адрес master-контракта,
и связывайтесь с командой этого кошелька.

5. Ключевое направление #3: DEX и ликвидность

Для большинства Jetton всё крутится вокруг ликвидности на DEX. В TON есть DEX-ы (например, STON.fi и др.), которые используют AMM-пулы и поддерживают Jetton по стандарту.

Если вы уже создали пул:

5.1 Свапы

Начните с очень маленьких сумм:

TON → Jetton

Сравните ожидаемое количество в UI и фактическое полученное.
Обратите внимание на slippage, price impact и комиссии.

Jetton → TON

Та же проверка: UI vs результат по факту.
Убедитесь, что транзакция не падает из-за низкой ликвидности или слишком жёсткого slippage.

Повторите с несколькими размерами ордеров, чтобы увидеть поведение кривой и то, как DEX объясняет это пользователю.

5.2 Ликвидность (LP)

Добавление ликвидности

Внести минимальный объём (Jetton + TON или Jetton + стейбл).
Проверить выпуск LP-токенов и их отображение в DEX и в кошельке.

Частичный вывод

Забрать, например, 25–50% позиции.
Проверить, что полученные суммы ожидаемы (с учётом комиссий и движения цены).

Полный вывод

Вывести 100% ликвидности и убедиться, что все средства вернулись корректно.

Если DEX показывает странные decimals, не подхватывает иконку или пул вообще не виден — это и UX-проблема, и удар по доверию к токену.

6. Ключевое направление #4: комиссии и gas

Toncoin используется для оплаты комиссий и развёртывания контрактов, включая jetton-wallet контракты пользователей.

Задача — чтобы с вашим Jetton было дёшево и предсказуемо работать.

Проверьте:

Базовая комиссия за действие

Перевод Jetton между уже активными кошельками.
Зафиксируйте типичный расход TON.

Первая активация

Отправка Jetton на адрес, который раньше его не получал.
Посмотрите, насколько дороже обходится создание jetton-wallet контракта.

Крайние случаи с низким балансом TON

Попробовать провести операцию при почти нулевом балансе TON.
Попробовать сделать действие при явно недостаточном балансе.
Посмотреть, какие сообщения выдаёт интерфейс и что происходит на чейне.

Возвраты “лишнего” TON

В некоторых сценариях «excess TON» возвращается отправителю или на указанный адрес.
Убедитесь, что логика возврата соответствует вашей модели и не путает пользователя.

7. Ключевое направление #5: крайние кейсы, UX и безопасность

Здесь вы проверяете уже не только смарт-контракт, а общее ощущение продукта.

Сообщения об ошибках

Недостаточно TON на комиссии.
Недостаточно Jetton для перевода.
Неверный адрес.
Понятны ли тексты обычному юзеру, который не программист?

Путаница с токенами

Есть ли другие Jetton со схожим названием/символом?
Насколько легко визуально отличить ваш токен?

Админские права и разрешения

Кто может минтить/жечь токен? Понятно ли это хотя бы из документации?
Есть ли функции, позволяющие замораживать балансы или забирать средства?
Есть ли план по отказу от лишних полномочий (или их передаче DAO/мультисигу)?

План миграции

Если найдёте критичный баг, как будете мигрировать пользователей на новый Jetton?
Есть ли базовое описание этого плана в документации/анонсе?

8. Как организовать команду тестеров

Если у вас есть комьюнити или внутренняя QA-команда, структурируйте их работу:

Создайте issue “Testing campaign” c:

чеклистом (переводы, кошельки, DEX, комиссии, UX),
правилами, как оставлять отчёт,
ссылками на master-контракт Jetton и пулы на DEX.

Используйте шаблон багрепорта:

окружение (кошелёк, платформа, сеть),
шаги для воспроизведения,
ожидаемый vs фактический результат,
ссылка на транзакцию + скриншоты.

Так фидбек будет структурированным, а вам проще будет находить паттерны и приоритизировать правки.

9. Вознаграждение за тесты (и как не превратить всё в фарм)

Тестирование в mainnet стоит реальных денег, поэтому логично вознаграждать тестеров из заранее выделенного пула Jetton:

отдельный пул под чек-листы и задачи (серия тестов, мульти-кошельковые сценарии);
отдельный пул под bug bounty, особенно за критические и security-баги.

Несколько простых правил:

Вознаграждайте качество, а не количество кликов — просите реальные ссылки на транзакции и нормальные описания.
Держите правила публичными и максимально простыми.
Не обещайте «гарантированный заработок/доход» — это не инвестсовет, рынок живёт своей жизнью.

Хорошая программа тестирования должна ощущаться как совместная работа, а не как очередной «фарм ради токенов».

10. Итог

Jetton, запущенный в основной сети TON, — это уже не тестовый токен, а полноценный финансовый инструмент. Стандарт TEP-74 даёт вам технический фундамент, но только живое тестирование во всех реальных сценариях (кошельки, обозреватели, DEX-ы, пользовательские флоу) покажет, насколько ваш токен готов к массовому использованию.

Будьте системны:

проверяйте переводы, балансы, комиссии и поведение на DEX;
уделите внимание интеграциям;
относитесь к UX и безопасности как к ключевым требованиям;
грамотно организуйте и мотивируйте тестеров.

Так ваш Jetton перестанет быть «ещё одним токеном в списке» и станет надёжным кирпичиком экосистемы TON.

studio.rubeton.app