EQ, UQ және raw: TON мекенжай форматтары және «қайтқан» депозит

Әзірлеуші жаңа әмиян генерациялайды, мекенжайын көшіріп алады, газға деп соған алғашқы 5 GRAM жібереді — ал бір минуттан кейін монеталар жіберуші әмиянға қайтып келеді. Жаңа мекенжайдың балансы: нөл. Ешқандай қате жоқ, ешқандай «reverted» жоқ, транзакция сәтті өтті. Ақша жай ғана… қайтып кетті. TON чаттарында бұл — классика: «өз мекенжайыма жібердім — жетпеді». Әрі себебі әрдайым дерлік біреу-ақ: мекенжай форматтары мен bounceable жалаушасы шатастырылған.

TON мекенжай форматтары — EQ, UQ және raw деген не, bounceable-дың non-bounceable-дан айырмасы қандай және жаңа әмиянға түскен алғашқы депозит неге жіберушіге кері қайтады — бәрін фактілер бойынша талдаймыз. Сонымен қатар мұның бәрін SDK да, нода да көтермей-ақ, ЖИ-агенттен бір-ақ құрал шақырып қалай тексеруге болатынын көрсетемін.

TON мекенжайының үш форматы: raw, EQ және UQ — айырмасы неде

TON-дағы кез келген мекенжайдың астында бір ғана нәрсе жатыр: воркчейн нөмірі және контракт стейт-инитінің 256-биттік хэші. Дәл осы — raw-формат:

0:83dfd552e63729b472fcbcc8c45ebcc6691702558b68ec7527e1ba403a0f31a8

Қос нүктенің сол жағында — воркчейн (әдетте 0 — базалық, -1 — мастерчейн), оң жағында — hex-тегі 256-биттік хэш. Формат адал әрі бір мағыналы, бірақ онда бақылау сомасы жоқ: бір таңбада қате жіберсеңіз, сырт көзге дұрыс болып көрінетін мүлде басқа мекенжай аласыз. Контрактілердің get-әдістері мен төмен деңгейлі құралдар әдетте дәл осы raw-ды күтеді, ал адамдарға оны көрсетпейді десе де болады.

Екінші жазылу түрі — user-friendly: әмияндар мен эксплорерлерден көретін сол 48 таңбалы base64url:

EQCD39VS5jcptHL8vMjEXrzGaRcCVYto7HUn4bpAOg8xqB2N     (bounceable)
UQCD39VS5jcptHL8vMjEXrzGaRcCVYto7HUn4bpAOg8xqEBI     (non-bounceable)

Оның ішіне сол баяғы «воркчейн + хэш» жұбы, оған қоса жалаушалар байты және соңында CRC16-бақылау сомасы енгізілген. CRC қате терілген таңбаны ұстап қалады: бүлінген мекенжай жіберілместен бұрын-ақ валидациядан өтпейді. Ал EQ және UQ префикстері дәл осы жалаушалар байтынан туады.

Бірден түсініп алуға тұрарлық басты нәрсе:

• raw және user-friendly — бір мекенжайды жазудың екі тәсілі.
• EQ және UQ — бір user-friendly мекенжайдың дәл бір ғана жалаушамен ерекшеленетін екі нұсқасы.

Яғни бір әмиянның EQ… және UQ… жазбалары бір raw-хэшті, бір контрактіні, бір балансты көрсетеді. Бұл — екі бөлек әмиян да, екі бөлек шот та емес. Айырма тек жіберуші ниетінің бір ғана битінде.

Bounceable (EQ) мен non-bounceable (UQ): жалауша нені білдіреді

Префиксті дәл сол — user-friendly мекенжай ішіндегі жалаушалар байты айқындайды:

Жалауша	Тег	Префикс (mainnet)	Префикс (testnet)
bounceable	0x11	EQ	kQ
non-bounceable	0x51	UQ	0Q

Тестнет үшін тегке 0x80 қосылады — экзотикалық kQ мен 0Q содан шығады. Бірақ бізді тегтер арифметикасы емес, жалаушаның мәні қызықтырады.

Bounceable (EQ) сөзбе-сөз мынаны білдіреді: «қабылдаушы тарапта бірдеңе дұрыс болмаса — монеталарды маған қайтар». Бұл — смарт-контрактілерге арналған қорғаныс. Ақшаны өңдеуге тиіс контрактіге жіберсеңіз, ал ол қатемен құласа, әлі деплой жасалмаған болса немесе газ жетпесе — монеталардың бос кеңістікте ілініп қалғанын қаламайсыз. Bounce-механизм оларды комиссияны шегеріп, жіберушіге қайтарады.

Non-bounceable (UQ) керісінше: «не болса да жеткіз де қалдыр». Ешқандай қайтару жоқ — монеталар жай ғана мекенжайға түседі.

Адамдар арасындағы күнделікті аударымдарда бұл айырма байқалмайды — бір нақты жағдайға дейін.

Деплой жасалмаған әмиянға түскен алғашқы депозит неге «қайтып кетеді»

Міне, сол қақпан. TON-да әмиян мекенжайы оның контрактісі блокчейнге нақты деплой жасалғанға дейін бар болады. Мекенжай — контракт коды мен бастапқы деректерден (ашық кілттен) алынған детерминистік хэш, сондықтан оны мнемониканы генерациялаған бойда, толықтай офлайн біліп аласыз. Бірақ мекенжай бойынша алғашқы транзакция өтпейінше, аккаунт uninit (инициализацияланбаған) күйінде тұрады: мекенжай бар, ал ондағы контракт коды жоқ.

Енді bounceable-аударыммен не болатынына қараңыз:

1. Сіз осы uninit-мекенжайға EQ (bounceable) форматындағы аударым жібересіз.
2. Желі монеталарды жеткізіп, қабылдаушы контрактіні «шақыруға» тырысады. Оларды қабылдайтын ешкім жоқ — мекенжайда контракт жоқ.
3. Bounce іске қосылады: жеткізу мүмкін болмаған соң, монеталар комиссияны шегеріп, жіберушіге қайтарылады.

Нәтижесі — сол «қайту». Транзакция сәтті өтті, бірақ жаңа әмиянның балансы нөл күйінде қалды, ал ақша қайдан келсе, сонда оралды. Ешкім ештеңе ұрлаған жоқ, желі дәл ойластырылғандай жұмыс істеді — сіз жай ғана bounceable-форматты керек емес жерде қолдандыңыз.

Ал дәл сол аударымды UQ (non-bounceable) форматында жіберсеңіз ше?

1. Желі монеталарды uninit-мекенжайға жеткізуге тырысады.
2. Bounce жалаушамен өшірілген — қайтарудың қажеті жоқ.
3. Контракт әлі деплой жасалмағанына қарамастан, монеталар мекенжайда қалады.

Әмиян толықтырылды. Кейін одан алғашқы шығыс транзакцияны жібергенде, сонымен бірге контракт коды да деплой жасалады — және аккаунт active болады. Осы сәттен бастап ол кез келген аударымды, соның ішінде bounceable-ды да, еш қиындықсыз қабылдайды. UQ ережесі әлі деплой жасалмаған әмиянды тек ең алғаш толықтырғанда ғана маңызды.

Жақсы жаңалық: экожүйе бұл олқылықты пайдаланушының орнына бірте-бірте жауып келеді. v5r1 әмияндары және бірқатар клиент мекенжайды әдепкіде дәл non-bounceable (UQ) түрінде көрсетеді — жаңадан келген адам алғашқы депозитін жоғалтпасын деп. Бірақ мекенжайлармен бағдарламалық түрде жұмыс істей бастасаңыз — бэкендтен, скриптен, ЖИ-агенттен — жалауша үшін жауапкершілік қайтадан сізге ауады.

Алғашқы аударымды қалай дұрыс жіберу керек: EQ емес, UQ

Практикалық ереже бір жолға сыйып тұр:

Жаңа (uninit) әмиянға түсетін алғашқы депозит — әрқашан UQ-ға. Одан кейін қалай болса, солай.

Пайдаланушыға қаражат жіберетін кез келген сервиске арналған кеңейтілген логика:

• Алушының мекенжайы uninit күйінде → UQ-ға (non-bounceable) жіберіңіз.
• Мекенжай active → EQ-ға (bounceable) жіберуге болады.
• Смарт-контрактіге жіберіп жатсаңыз (DEX, жетон-минтер, эскроу) → қате болғанда ақша қайтсын деп EQ.

Мәселе мынада: «көзбен» қарағанда EQ мен UQ префикстің бір ғана таңбасымен ерекшеленеді, ал uninit/active күйі мекенжайдан мүлдем көрінбейді. Екі тексеруді де бағдарламалық түрде жасау керек. Әрі мұнда жобаға @ton/ton тартып, провайдер көтеріп, ұяшықтарды талдаудың қажеті жоқ — екі сұрақты да ЖИ-агенттің өзі шақыратын MCP-сервердің екі құралы жабады.

Әмиянды генерациялау және оны алғаш толықтыру тақырыбы сізге таныс болмаса — бөлек талдау TON-әмиян жасау туралы гайдта бар.

parse_address: мекенжайларды офлайн бір шақырумен түрлендіру және тексеру

parse_address — TONNode-тың офлайн-құралы; TONNode дегеніміз — TON үшін жасалған hosted MCP-сервер. Ол мекенжайды декодтайды, форматтарды қайта есептейді және CRC16-ны тексереді — желіге мүлде жүгінбей: оған нода да, кілт те керек емес, бұл — мекенжай жолының өзімен жасалатын таза математика, сондықтан лезде әрі лимиттерді жұмсамай орындалады.

Ол не істей алады:

• EQ ⇄ UQ ⇄ raw түрлендіруін кез келген бағытта жасау;
• мекенжайдың жарамдылығын тексеру (бақылау сомасы дөп келе ме);
• bounceable жалаушасын және воркчейн нөмірін көрсету.

MCP (Model Context Protocol) — ЖИ-агенттер (Claude, Cursor, ChatGPT/Codex және кез келген MCP-клиент) құралдарды шақыратын стандарт. MCP-сервер клиент конфигіне бір ғана жазбамен қосылады. Оқу құралдарының толық жинағы бар жергілікті тегін нұсқасы:

{
  "mcpServers": {
    "ton": {
      "command": "npx",
      "args": ["-y", "@tonnode/mcp"]
    }
  }
}

Әрі қарай агентке кәдімгі промпт жеткілікті:

EQCD39VS5jcptHL8vMjEXrzGaRcCVYto7HUn4bpAOg8xqB2N мекенжайын алып, оны non-bounceable (UQ) және raw форматтарында көрсет. Бақылау сомасының жарамды екенін тексер.

Агент parse_address шақырады да, сол әмиянның UQ-нұсқасын, raw-хэшін және жарамдылық күйін қайтарады. Base64url-ды қолмен әрі-бері түрлендіру де, 48 таңбада қате жіберу тәуекелі де жоқ.

get_account_state: жіберер алдында әмиянға деплой жасалған-жасалмағанын қалай білуге болады

Мәселе форматпен бітпейді — мекенжайдың қандай күйде екенін де білу керек: active немесе uninit. Бұл — он-чейн сұрақ, оған get_account_state жауап береді. Құрал аккаунттың күйін, жалаушаларын және соңғы транзакция туралы деректерді қайтарады.

Алғашқы аударымды жіберер алдындағы логика:

• get_account_state uninit қайтарды → мекенжай әлі деплой жасалмаған → UQ-ға жібереміз.
• active қайтарды → әмиян деплой жасалған → еш алаңдамай EQ-ға жіберуге болады.

Агентке арналған промпт:

get_account_state арқылы UQCD39VS5jcptHL8vMjEXrzGaRcCVYto7HUn4bpAOg8xqEBI мекенжайына деплой жасалған-жасалмағанын тексер. Күйі uninit болса — алғашқы депозитті UQ-форматта жіберу керегін еске сал.

Тізбек мынадай болып шығады: generate_wallet әмиян жасайды (v3r2/v4/v5r1/highload_v3 нұсқалары) және жасалған сәтте кепілді түрде uninit болатын мекенжай береді — желі ол туралы әлі білмейді. Демек, оған түсетін алғашқы депозит қатаң түрде UQ-ға барады. Жіберер алдында get_account_state мекенжайдың шынымен uninit екенін растайды, ал parse_address дәл non-bounceable көрінісін алғаныңызға кепілдік береді. Толықтырғаннан кейін get_balance шақырып, монеталардың қайтып кетпей, мекенжайға түскеніне көз жеткізген ыңғайлы.

Генерация туралы маңызды тұс: generate_wallet мнемониканы, кілттерді және мекенжайды пайдаланушыға қайтарады — сервер оларды сақтамайды әрі сіздің орныңызға ештеңеге қол қоймайды. Бұл — кастодиалды емес механика, әрі ол свап, кроссчейн және әмиян құралдарының бәріне қатысты.

Шағын терминологиялық нақтылау: GRAM — бұл атауы өзгертілген Toncoin (2026 жылдың маусымында өзгертілді), желінің өзі бұрынғысынша TON деп аталады.

Чек-парақ: TON-да алғашқы депозитті қалай жоғалтпау керек

Жаңа әмиянға жасалатын әр алғашқы аударымға арналған қысқа алгоритм:

1. Мекенжай генерацияладыңыз (generate_wallet немесе өз SDK-ңыз) — оны әдепкіде uninit деп есептеңіз.
2. Күйін тексеріңіз — get_account_state арқылы: uninit немесе active.
3. Егер uninit болса — алушының мекенжайын parse_address арқылы UQ-ға келтіріңіз де, алғашқы депозитті тек соған жіберіңіз.
4. Егер active болса — EQ да болады, ал контрактілер үшін ол тіпті қолайлырақ.
5. Смарт-контрактілерге әрқашан bounceable (EQ) жіберіңіз — ақау болғанда ақша қайтып келсін.
6. Толықтырғаннан кейін get_balance тексеріңіз — монеталар қайтып кетпей, мекенжайға түсуге тиіс.
7. Есіңізде болсын: EQ мен UQ — бір ғана әмиян (бір raw-хэш); сіз мекенжайды емес, жеткізу сәтсіз болғанда не болатынын таңдап тұрсыз.

Екі негізгі тексеру де — parse_address (офлайн) және get_account_state (он-чейн) — өз инфрақұрылымыңызсыз бірден қолжетімді. Тегін Hobby кілтін алыңыз (минутына 60 сұрау, картасыз) да, екі құралды да ЖИ-агенттің өзінен шақырыңыз: https://tonnode.io/dashboard?plan=hobby.

Ал әрі қарай осы схема бойынша сабақтас міндеттерді шешу ыңғайлы: TON-дағы кіріс USDT-төлемдерін ұстау, USDT балансын бір шақырумен оқу немесе контрактінің get-әдісін SDK-сыз шақыру. Мекенжай форматтары — қалғанының бәрі тұрған іргетас: EQ/UQ-мен бір рет айналысып шықсаңыз, «қайтып кеткен» депозит сізді енді ешқашан абдыратпайды.