EQ, UQ va raw: TON manzil formatlari va «qaytgan» depozit

Dasturchi yangi hamyon generatsiya qiladi, manzilini nusxalaydi, gaz uchun oʻsha yerga birinchi 5 GRAM ni tashlaydi — va bir daqiqadan soʻng tangalar joʻnatuvchi hamyonga qaytib keladi. Yangi manzilning balansi: nol. Hech qanday xato yoʻq, hech qanday «reverted» yoʻq, tranzaksiya muvaffaqiyatli oʻtdi. Shunchaki pul… qaytib ketdi. TON chatlarida bu klassika: «oʻz manzilimga yubordim — yetib bormadi». Va deyarli har doim sabab bitta — chalkashtirib yuborilgan manzil formatlari va bounceable bayrogʻi.

Faktlar boʻyicha koʻrib chiqamiz: TON manzil formatlari — EQ, UQ va raw nima, bounceable bilan non-bounceable oʻrtasidagi farq nimada va nega yangi hamyonga tushgan birinchi depozit joʻnatuvchiga qaytib ketadi. Shu bilan birga, buning hammasini SDK ham, noda ham koʻtarmasdan, AI-agentdan bitta vosita chaqiruvi bilan qanday tekshirish mumkinligini koʻrsataman.

Uch xil TON manzil formati: raw, EQ va UQ — farqi nimada

TONdagi har qanday manzilning ichida, aslida, bitta narsa yotadi: vorkcheyn raqami va kontrakt steyt-initining 256-bitli xeshi. Bu — raw-format:

0:83dfd552e63729b472fcbcc8c45ebcc6691702558b68ec7527e1ba403a0f31a8

Ikki nuqtaning chap tomonida — vorkcheyn (odatda 0 — bazaviy, -1 — mastercheyn), oʻng tomonida — hex koʻrinishidagi 256-bitli xesh. Format sodda va bir maʼnoli, lekin unda nazorat yigʻindisi yoʻq: bitta belgida xato qildingizmi — koʻrinishidan yaroqli boshqa manzilga ega boʻlasiz. Odatda aynan raw ni kontraktlarning get-metodlari va quyi darajali vositalar kutadi, odamlarga esa uni deyarli koʻrsatishmaydi.

Ikkinchi koʻrinish — user-friendly: hamyonlar va eksplorerlarda koʻradigan oʻsha 48 ta base64url belgisi:

EQCD39VS5jcptHL8vMjEXrzGaRcCVYto7HUn4bpAOg8xqB2N     (bounceable)
UQCD39VS5jcptHL8vMjEXrzGaRcCVYto7HUn4bpAOg8xqEBI     (non-bounceable)

Unda oʻsha «vorkcheyn + xesh» juftligi, bayroqlar bayti va oxirida CRC16-nazorat yigʻindisi kodlangan. CRC terish xatolarini ilib oladi: buzuq manzil hali joʻnatilmasidanoq validatsiyadan oʻtmaydi. EQ va UQ prefikslari ham aynan shu bayroqlar baytidan kelib chiqadi.

Darhol oʻzlashtirib olish kerak boʻlgan asosiy narsa:

• raw va user-friendly — bu bitta manzilni yozishning ikki usuli.
• EQ va UQ — bu bitta user-friendly manzilning roppa-rosa bitta bayroq bilan farq qiladigan ikki varianti.

Yaʼni bitta hamyon uchun EQ… va UQ… bitta raw-xeshga, bitta kontraktga, bitta balansga ishora qiladi. Bu ikkita har xil hamyon ham, ikkita har xil hisob ham emas. Farq — faqat joʻnatuvchi niyatining bitta bitida.

Bounceable (EQ) va non-bounceable (UQ): bayroq nimani anglatadi

User-friendly manzil ichidagi oʻsha bayroqlar bayti prefiksni belgilaydi:

Bayroq	Teg	Prefiks (mainnet)	Prefiks (testnet)
bounceable	0x11	EQ	kQ
non-bounceable	0x51	UQ	0Q

Testnet uchun tegga 0x80 qoʻshiladi — ekzotik kQ va 0Q shundan. Lekin bizni teglar arifmetikasi emas, bayroqning maʼnosi qiziqtiradi.

Bounceable (EQ) soʻzma-soʻz shuni anglatadi: «qabul qiluvchi tomonda biror narsa notoʻgʻri ketsa — tangalarni menga qaytar». Bu — smart-kontraktlar uchun himoya. Agar siz pulni uni qayta ishlashi kerak boʻlgan kontraktga joʻnatsangiz, u esa xatolik bilan ishdan chiqsa, hali deploy qilinmagan boʻlsa yoki gaz yetmasa — tangalarning shunchaki boʻshliqda osilib qolishini xohlamaysiz. Bounce-mexanizm ularni komissiyani chegirib, joʻnatuvchiga qaytaradi.

Non-bounceable (UQ) teskarisini anglatadi: «nima boʻlsa ham yetkaz va qoldir». Hech qanday qaytarish yoʻq — tangalar shunchaki manzilga tushadi.

Odamlar oʻrtasidagi kundalik oʻtkazmalarda farq sezilmaydi — bitta aniq holatgacha.

Nega deploy qilinmagan hamyonga birinchi depozit «qaytib ketadi»

Mana oʻsha tuzoq. TONda hamyon manzili hamyon kontrakti blokcheynda haqiqatan deploy qilinishidan oldin mavjud boʻladi. Manzil — bu kontrakt kodi va boshlangʻich maʼlumotlardan (ochiq kalitdan) olingan deterministik xesh, shuning uchun siz uni mnemonika generatsiyasidan soʻng darhol, toʻliq oflayn bilasiz. Lekin manzil boʻyicha birinchi tranzaksiya oʻtmagunicha, akkaunt uninit (initsializatsiya qilinmagan) holatida boʻladi: manzil bor, undagi kontrakt kodi esa — yoʻq.

Endi bounceable-oʻtkazma bilan nima boʻlishiga qarang:

1. Siz shu uninit-manzilga EQ (bounceable) formatida oʻtkazma joʻnatasiz.
2. Tarmoq tangalarni yetkazishga va qabul qiluvchi kontraktni «chaqirishga» harakat qiladi. Ularni qabul qiladigan hech kim yoʻq — manzilda kontrakt yoʻq.
3. Bounce ishga tushadi: yetkazib boʻlmagani uchun tangalar komissiya chegirilib joʻnatuvchiga qaytadi.

Natija — oʻsha «qaytish». Tranzaksiya muvaffaqiyatli oʻtdi, lekin yangi hamyonning balansi nol boʻlib qoldi, pul esa qayerdan kelgan boʻlsa, oʻsha yerga qaytdi. Hech kim hech narsa oʻgʻirlagani yoʻq, tarmoq aynan moʻljallanganidek ishladi — shunchaki siz bounceable-formatni ishlatmaslik kerak boʻlgan joyda ishlatdingiz.

Xoʻsh, oʻsha oʻtkazmani UQ (non-bounceable) formatida joʻnatsak-chi?

1. Tarmoq tangalarni uninit-manzilga yetkazishga harakat qiladi.
2. Bounce bayroq bilan oʻchirilgan — qaytarish shart emas.
3. Kontrakt hali deploy qilinmaganiga qaramay, tangalar manzilda qoladi.

Hamyon toʻldirildi. Keyinroq undan birinchi chiquvchi tranzaksiyani joʻnatganingizda, u bilan birga kontrakt kodi ham deploy qilinadi — va akkaunt active boʻladi. Shu paytdan boshlab u istalgan oʻtkazmani, jumladan bounceable ni ham bemalol qabul qiladi. UQ qoidasi faqat hali deploy qilinmagan hamyonni eng birinchi marta toʻldirish uchun kritik.

Yaxshi xabar: ekotizim bu teshikni foydalanuvchi oʻrniga asta-sekin yopib bormoqda. v5r1 hamyonlari va bir qator klientlar sukut boʻyicha manzilni aynan non-bounceable (UQ) koʻrinishida koʻrsatadi — yangi boshlovchi birinchi depozitini yoʻqotmasligi uchun. Lekin manzillar bilan dasturiy tarzda ishlay boshladingizmi — bekenddan, skriptdan, AI-agentdan — bayroq uchun javobgarlik yana sizning zimmangizda.

Birinchi oʻtkazmani qanday toʻgʻri joʻnatish kerak: EQ emas, UQ

Amaliy qoida bitta qatorga sigʻadi:

Yangi (uninit) hamyonga birinchi depozit — doim UQ ga. Undan keyin — xohlagancha.

Foydalanuvchiga mablagʻ joʻnatadigan har qanday servis uchun kengaytirilgan mantiq:

• Qabul qiluvchining manzili uninit holatida → UQ ga (non-bounceable) joʻnating.
• Manzil active → EQ ga (bounceable) mumkin.
• Smart-kontraktga joʻnatyapsizmi (DEX, jetton-minter, eskrou) → xato yuz berganda pul qaytishi uchun EQ.

Muammo shundaki, «koʻz bilan» qaraganda EQ va UQ prefiksdagi bitta belgi bilangina farq qiladi, uninit/active holati esa manzilning oʻziga qarab umuman bilinmaydi. Ikkala tekshiruvni ham dasturiy tarzda qilish kerak. Va bu yerda loyihaga @ton/ton ni tortish, provayder koʻtarish va cellʼlarni parse qilish shart emas — ikkala savol ham AI-agent oʻzi chaqiradigan MCP-serverning ikkita vositasi bilan yopiladi.

Agar hamyon generatsiyasi va uni birinchi marta toʻldirish mavzusi siz uchun yangi boʻlsa — TON hamyonini yaratish boʻyicha qoʻllanmada alohida tahlil bor.

parse_address: manzillarni oflayn konvertatsiya qilish va tekshirish — bitta chaqiruvda

parse_address — TON uchun hosted MCP-server boʻlgan TONNodeʼning oflayn vositasi. U manzilni dekodlaydi, formatlarni qayta hisoblaydi va CRC16 ni tekshiradi — tarmoqqa murojaat qilmasdan: unga na noda, na kalit kerak, bu — satr ustida bajariladigan sof matematika, shuning uchun bir zumda va limitlarni sarflamasdan ishlaydi.

U nimalarni qila oladi:

• EQ ⇄ UQ ⇄ raw ni istalgan tomonga konvertatsiya qilish;
• manzilning yaroqliligini tekshirish (nazorat yigʻindisi mos keladimi);
• bounceable bayrogʻini va vorkcheyn raqamini koʻrsatish.

MCP (Model Context Protocol) — bu AI-agentlar (Claude, Cursor, ChatGPT/Codex va istalgan MCP-klient) vositalarni chaqiradigan standart. MCP-server klient konfigidagi bitta yozuv bilan ulanadi. Oʻqish vositalarining toʻliq toʻplami bilan keladigan lokal bepul variant:

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

Keyin agentga oddiy promptning oʻzi yetarli:

EQCD39VS5jcptHL8vMjEXrzGaRcCVYto7HUn4bpAOg8xqB2N manzilini ol va uni non-bounceable (UQ) hamda raw formatlarida koʻrsat. Nazorat yigʻindisi yaroqli ekanini tekshir.

Agent parse_address ni chaqiradi va oʻsha hamyonning UQ-versiyasini, raw-xeshni hamda yaroqlilik statusini qaytaradi. Qoʻlda base64url bilan ovora boʻlish ham, 48 ta belgining birida xato qilish xavfi ham yoʻq.

get_account_state: joʻnatishdan oldin hamyon deploy qilinganini qanday bilish mumkin

Ish format bilan tugamaydi — yana manzil qaysi holatda ekanini bilish kerak: active yoki uninit. Bu esa on-chain savol va unga get_account_state javob beradi. Vosita akkaunt statusini, bayroqlarni va oxirgi tranzaksiya haqidagi maʼlumotlarni qaytaradi.

Birinchi oʻtkazmani joʻnatishdan oldingi mantiq:

• get_account_state uninit qaytardi → manzil hali deploy qilinmagan → UQ ga joʻnatamiz.
• active qaytardi → hamyon deploy qilingan → bemalol EQ ga joʻnatish mumkin.

Agentga prompt:

get_account_state orqali UQCD39VS5jcptHL8vMjEXrzGaRcCVYto7HUn4bpAOg8xqEBI manzili deploy qilinganini tekshir. Agar holat uninit boʻlsa — birinchi depozitni UQ-formatda joʻnatish kerakligini eslat.

Bogʻlama shunday chiqadi: generate_wallet hamyon yaratadi (v3r2/v4/v5r1/highload_v3 versiyalari) va yaratilgan paytda kafolatlangan tarzda uninit boʻlgan manzilni beradi — tarmoq u haqida hali bilmaydi. Demak, unga birinchi depozit qatʼiy UQ ga ketadi. Joʻnatishdan oldin get_account_state manzil haqiqatan uninit ekanini tasdiqlaydi, parse_address esa aynan non-bounceable koʻrinishni olganingizga kafolat beradi. Toʻldirgandan soʻng get_balance ni chaqirib, tangalar qaytib ketmay, manzilga tushganiga ishonch hosil qilish qulay.

Generatsiya haqida muhim jihat: generate_wallet mnemonika, kalitlar va manzilni foydalanuvchiga qaytaradi — server ularni saqlamaydi va siz uchun hech narsani imzolamaydi. Bu — nokastodial mexanika va u svop, krosscheyn hamda hamyon vositalarining barchasiga taalluqli.

Kichik terminologik izoh: GRAM — bu nomi oʻzgartirilgan Toncoin (2026-yil iyunda qayta nomlangan), tarmoqning oʻzi esa avvalgidek TON deb ataladi.

Chek-list: TONda birinchi depozitni qanday yoʻqotmaslik kerak

Yangi hamyonga har bir birinchi oʻtkazma uchun qisqa algoritm:

1. Manzilni generatsiya qildingiz (generate_wallet yoki oʻz SDKʼingiz) — uni sukut boʻyicha uninit deb hisoblang.
2. Holatni tekshiring get_account_state orqali: uninit yoki active.
3. Agar uninit boʻlsa — qabul qiluvchining manzilini parse_address orqali UQ ga keltiring va birinchi depozitni faqat oʻshanga joʻnating.
4. Agar active boʻlsa — EQ mumkin, kontraktlar uchun bu hatto afzalroq.
5. Smart-kontraktlarga doim bounceable (EQ) joʻnating — nosozlik yuz berganda pul qaytishi uchun.
6. Toʻldirgandan soʻng get_balance ni tekshiring — tangalar qaytib ketmay, manzilga tushishi kerak.
7. Yodda tuting: EQ va UQ — bu bitta hamyon (bitta raw-xesh); siz manzilni emas, yetkazib berish muvaffaqiyatsiz boʻlgandagi xatti-harakatni tanlaysiz.

Ikkala asosiy tekshiruv ham — parse_address (oflayn) va get_account_state (on-chain) — oʻz infratuzilmangizsiz, darhol mavjud. Bepul Hobby kalitini oling (60 soʻrov/min, kartasiz) va ikkala vositani ham toʻgʻridan-toʻgʻri AI-agentdan chaqiring: https://tonnode.io/dashboard?plan=hobby.

Keyin esa xuddi shu sxema boʻyicha qoʻshni vazifalarni hal qilish qulay: TONda kiruvchi USDT-toʻlovlarni tutish, USDT balansini bitta chaqiruvda oʻqish yoki kontraktning get-metodini SDKʼsiz chaqirish. Manzil formatlari — qolgan hamma narsa shu poydevor ustida turadi: EQ/UQ bilan bir marta tushunib olsangiz, «qaytib ketgan» depozit endi sizni hech qachon dovdiratib qoʻymaydi.