Gram (prev. Toncoin)

Ang Gram (ticker: GRAM) ay ang katutubong cryptocurrency ng The Open Network (TON), isang layer-1 blockchain at service stack. Naka-eksist ito mismo sa TON (hindi bilang ERC-20 o wrapped asset) at nagsisilbing pangunahing currency ng network. Sa praktika, ang Gram ang yunit na ginagamit para patakbuhin ang blockchain at mga integrated services nito—transaksyon at pagpapatupad ng smart contract sa TON Blockchain, at mga serbisyo sa TON DNS, TON Sites, TON Storage at TON Proxy.

Ang Gram din ang pundasyon ng proof-of-stake security model ng network: ang mga validator ay nagba-bond ng GRAM upang tumulong sa pagpapatakbo ng chain at tumanggap ng protocol rewards kapalit nito. Ang mga operational details ng staking at mga papel ng validator ay tinalakay sa kani-kanilang seksyon.

Ang mga developer tooling at code ay karaniwang tumutukoy sa balances bilang nanotons (madalas na isinusulat bilang ‘nano’), na siyang pinakamaliit na on-chain unit kahit na sa Gram nakikipag-ugnayan ang mga user. Ang konseptong ito ay kahalintulad ng “wei” sa Ethereum at nakakatulong upang iwasan ang rounding sa smart-contract logic. Para sa praktikal na gamit ng Gram sa buong apps at serbisyo, tingnan ang “Ano ang gamit ng Gram sa buong ecosystem?”

Orihinal na binuo ng Telegram ang “Telegram Open Network” at binalak ang Gram token, ngunit itinigil ang proyekto noong 2020 matapos ang aksyon ng U.S. SEC at pag-apruba ng korte para sa settlement. Pinagpatuloy ng independent na komunidad ang open-source codebase at bisyon bilang The Open Network (TON) na may Gram bilang katutubong asset. Ngayon, TON ay isang community-led blockchain, habang ang Telegram ay hiwalay na kumpanya.

Ngayon, nakikipag-integrate na lang ang Telegram sa TON ngunit hindi nito kontrolado ito. Ang kumpanya ay nagpapatakbo ng in-app Wallet sa Telegram na may dalawang mode: isang custodial Crypto Wallet at isang self-custodial TON Wallet para sa on-chain na aktibidad sa TON blockchain. Depende sa rehiyon at product policy ang availability at features.

Ang Telegram din ay nagpapatakbo ng TON-based Ads: ang mga advertiser ay bumibili ng channel ads gamit ang Gram, at ang mga kwalipikadong channel owner ay maaaring mag-withdraw ng 50% ng ad revenue (pinamamahalaan sa pamamagitan ng Fragment). Isa ito sa mga platform integration na nakabase sa TON, hindi sa governance role sa network.

Ang Fragment ay opisyal na marketplace ng Telegram para sa @usernames at mga kaugnay na asset; nagaganap ang mga auction at settlement gamit ang Gram at link sa Telegram accounts.

Bilang hiwalay, ang TON Foundation ay isang Swiss non-profit na sumusuporta sa TON ecosystem; hindi nito pagmamay-ari ang Telegram o pinapatakbo ang messaging platform.

Ang The Open Network (TON) ay isang open-source, community-run Layer-1 platform na pinagsasama ang pangunahing smart-contract blockchain sa mga peer-to-peer component at native services. Ang orihinal na technical specification (TON whitepaper) ay naglalarawan ng multi-blockchain na disenyo kasama ang P2P stack at “TON Services” gaya ng DNS, Storage, Sites at Proxy na magagamit ng mga application sa loob ng iisang cohesive network. Sa modelong ito, ang TON Blockchain ang core ledger, habang ang ibang modules ay nagbibigay ng name resolution, data storage/serving at traffic routing bilang bahagi ng iisang ecosystem.

Ang codebase at validator software ng TON ay nade-develop sa pampublikong repositories; walang iisang controlling authority sa proyekto. Ang TON Foundation ay isang Swiss non-profit na sumusuporta sa ecosystem ngunit hindi nagkokontrol ng teknolohiya.

Ang Gram (GRAM) ay ang katutubong currency ng network. Sa disenyo ng TON, ang native coin ay ginagamit pambayad ng on-chain fees at ipinapantaya ng validators upang mapanatiling secure ang network; ang whitepaper (naisulat bago ang community rebrand mula “Gram” papuntang “Gram”) ay naglalahad ng papel ng native coin sa metering ng computation (“gas”) at economics ng validator. Sa kasalukuyan, Gram na ang yunit na ginagamit sa buong ecosystem, pati sa mga platform integration gaya ng TON-based ads ng Telegram. Para sa detalyadong mekanika ng fees at staking, tingnan ang mga dedikadong seksyon sa paglalarawang ito.

Ang Gram ay ang native asset na sumasaklaw sa lahat ng activity sa The Open Network. Nahahati ang gamit nito sa apat na pangunahing area:

1. Pagbabayad ng on-chain fees: Ang mga transaksyon at pagpapatupad ng smart-contract sa TON ay pinagbabayaran ng Gram. Saklaw ng fees ang computation at message routing, pati na ang storage-related charges.

2. Pagse-secure ng network gamit ang staking: Ang mga validator ay nagpapantaya ng Gram para makilahok sa proof-of-stake validation at kumita ng protocol rewards; ang delegation ay ginagamitan ng nominator-pool contracts on-chain.

3. Pag-settle ng protocol-level services: Ang mga built-in na serbisyo ng TON (tulad ng TON DNS, Storage, Sites at Proxy) ay bahagi ng network stack. Ang mga interaction gaya ng pagrehistro o auction ng .ton names, pagresolba ng mga pangalan o pagpapatakbo ng storage nodes ay nagreresulta sa on-chain transactions na nakadenominate sa Gram. Tinalakay ang detalyadong mekanika ng bawat serbisyo sa seksyong TON Services.

4. Platform at app integrations: Tinatanggap ang Gram bilang pambayad sa Telegram Ads, at ang mga kwalipikadong channel owner ay nagwi-withdraw ng revenue sa Fragment; ang mga collectible auction para sa @username sa Fragment ay settled din papuntang TON wallet. Higit pa sa Telegram, ginagamit ng iba’t ibang dApps sa TON ang Gram para mag-quote ng presyo at mag-settle ng bayad.

Para sa fee structure tingnan ang “Aling on-chain action ang nangangailangan ng TON at paano kinukwenta ang fees…?”; para sa staking roles at delegation tingnan ang “Paano gumagana ang staking sa TON…?”.

Dinisenyo ang TON bilang koleksyon ng mga blockchain na sabay-sabay na gumagana at nagtutulungan sa pamamagitan ng isang espesyal na chain na tinatawag na masterchain. Sa ilalim nito ay may isa o mahigit pang workchains, na bawat isa ay maaaring dynamic na hatiin sa madaming shardchains. Gamit ang estrukturang ito, napoproseso ng TON ang mga gawain nang sabay-sabay habang nananatiling consistent ang system.

Masterchain: Ang masterchain ang nagrerekord ng network-wide metadata at coordination data para sa buong sistema (halimbawa, mga hash ng pinakabagong blocks mula sa lahat ng shardchains). Sa pag-embed ng mga reference na ito, nagiging canonical ang mga shard blocks na iyon sa masterchain, kaya’t mapagkakatiwalaan ito ng ibang shards agad sa mga susunod na blocks. Marami ring protocol parameters ang naka-store bilang bahagi ng masterchain state.

Workchains: Ang workchain ay isang buong blockchain sa loob ng TON na may sarili nitong rules at block format. Hanggang 2³² workchains ang nakikita sa whitepaper; sa praktika, karamihan ng application ay gumagamit ng “basic workchain” (kilala ring Workchain Zero) kung saan tumatakbo ang TON smart contracts at nagaganap ang Gram transfers. Maaaring may ibang workchains sa hinaharap para sa espesyal na gamit.

Shardchains (dynamic sharding): Bawat workchain ay hinahati sa shardchains, na bawat shard ay responsable para sa subset ng mga account address. Nakakahati ang shards kapag malakas ang load at nagkakaisa kapag mahina, kaya’t nagkakaroon ng elastic capacity na hindi kinakailangang mano-mano. Ang routing sa pagitan ng shards at workchains ay gumagamit ng message-passing model ng TON, kaya’t makakapagpadala ng messages at value sa pagitan ng shards ang smart contracts nang maaasahan.

Paano magkakaugnay ang lahat

• Sabayang gumawa ng blocks ang shardchains; isinasama ng masterchain ang mga hash ng mga bagong shard blocks, na itinuturing namang final ng iba pang shards para sa mga susunod na aksyon.
• Sa “basic workchain” nagaganap ang kasalukuyang smart-contract activity at Gram transfers; maaaring magpatupad ng iba pang patakaran o ibang VM ang karagdagang workchains, habang pinananatiling naka-sync ang lahat ng masterchain.

Sa TON, bawat user account ay isang smart contract. Ang “wallet” ay simpleng minimal contract na nagho-hold ng Gram at nagpapadala ng signed messages para sa may-ari nito. Sinusuri ng wallet ang signature mula sa user’s key, tinatandaan ang seqno (para i-prevent ang replay), at nagpapaganap ng owner-authorised actions kapag nakatanggap ng external message. Sa developer docs ng TON, madalas itong ipaliwanag bilang “lahat ay smart contract,” pati na wallets.

Wallet V4 (v4r2): Inistandardize ng V4 ang plugin/extension model: maaaring mag-authorise ang wallet ng trusted companion contracts (“plugins”) para magsagawa ng partikular na aksyon sa funds (halimbawa, subscriptions). Dokumentado sa V4 repo ang plugin interface at kung paano nag-iinstall at nagre-remove ng plugins ang wallets. Malawak pa ring ginagamit ang V4 at sinusuportahan ng pangunahing wallets.

Wallet V5 (W5): V5—na karaniwan ding tinatawag na W5—ay ang pinakabagong wallet-contract standard na inaalagaan sa TON core repositories. Mga pangunahing kakayahan na tinutukoy sa spec at code:

• Multi-send: isang signed order ay maaaring magpadala ng hanggang 255 outgoing messages;
• Internal pati na rin external signed actions, na nagbibigay-daan sa relayer patterns (karaniwang ginagamit para sa mga “gasless” na daloy);
• Isang generalised extensions mechanism (kapalit ng V4 plugins), kabilang ang kakayahan ng extension para i-block ang signed actions (gamitin para sa 2FA o recovery flows).

Inilalarawan din ng spec at repository kung paano makakapag-forward ang gasless relayers ng user-signed message at magbayad ng Gram fees sa submission.

W5 sa ligaw: Nagpapakita ang explorers ng interface tag gaya ng wallet_v5r1, na nagsasaad ng mga naka-deploy na W5 contracts sa mainnet. Parami nang parami, default na sa W5 ang wallet apps para sa bagong address, na may fallback kung kinakailangan para sa V4.

Dahil ang TON wallet ay contract code at data, ang pagbabago ng wallet version (hal. V4 → W5) ay nagpapalit ng contract at nangangahulugang iba na rin ang address. Maaaring mag-derive ng mga key mula sa iisang seed phrase para sa maraming bersyon, ngunit hindi “auto-move” ang balances—kailangang mag-deploy ng bagong wallet at ilipat ang pondo o makipag-interact kung kinakailangan. Binibigyang-daan ng ilang apps ang pag-manage ng maraming bersyon nang sabay-sabay.

Maikling sagot: Ang TON ay hindi nagpapatakbo ng Ethereum Virtual Machine. Ang mga smart contract sa TON ay tumatakbo sa TON Virtual Machine (TVM), ang katutubong runtime ng network. Maaaring magdagdag ng EVM compatibility bilang hiwalay na layer o proyekto ang mga ecosystem initiative, ngunit hindi ito bahagi ng base protocol.

TON Virtual Machine (TVM) ay isang deterministic, stack-based VM na ginagamit ng masterchain at ng basic workchain. Pinapatakbo nito ang contract code, binabasa ang inbound messages at persistent data, ina-update ang estado, at lumilikha ng outbound messages. Ang client-side na “get-methods” ay ini-evaluate sa pamamagitan ng pagpapatakbo ng lokal na TVM laban sa verified state, kaya’t hindi na kinakailangan ng full-node para magbasa.

Mga Wika sa TON:

• FunC – Low-level, C-like language sa pagsulat ng contracts na kino-compile sa TVM bytecode; ang standard tooling at instruction set ay maintained sa official TON repositories.
• Tact – Higher-level language na kino-compile sa TVM gamit ang TON toolchain; ang official docs ay nagsasaklaw ng wika, type system at build flow.

Developer workflow: Maraming teams ang gumagamit ng Blueprint environment para bumuo, mag-test, at mag-deploy ng TVM contracts sa FunC at Tact.

Tungkol sa EVM sa TON: Kapag may EVM execution sa TON ecosystem (hal. TEVM- o L2-based efforts), ito ay bilang karagdagang compatibility layer at hindi bilang native runtime ng TON.

Ang anumang on-chain transaction sa TON—pagpapadala ng GRAM o tokens, pag-deploy ng contract, o pagtawag sa contract—ay may koordinadong fees na binabayaran sa Gram. Ang mga wallet ay nagpapadala ng external message sa iyong wallet contract, na gagana at (madalas) maglalabas ng isa o higit pang internal messages; bawat hakbang ay may kaukulang fees. Ang ilang wallet ay sumusuporta sa “gasless” flows gamit ang W5 (isang relayer ang nagbabayad o saklaw na ng fees mula sa ipinadalang asset), ngunit ang mismong network ay naniningil ng fees sa GRAM.

Paano binubuo ang fees

Sa pinaka-mababang lebel, ang total fee ng isang transaction ay kabuuan ng ilang bahagi na kumakatawan sa execution at messaging sa pagitan ng shards/workchains:

• Computation (gas) fee: singil para sa TVM steps na ginamit ng iyong contract; ang presyo ay mula sa on-chain config parameters (masterchain/basechain).
• Action fee: singil para sa mga aksyon sa action phase (hal., paglikha at pagpapadala ng outgoing messages).
• Forwarding fees: bayad para sa paghahatid ng messages; depende sa laki ng mensahe sa cells/bits at per-chain forward-price ayon sa live network configuration. May bayad sa inbound delivery at bawat outbound na hakbang.
• Storage fees (“storage rent”): sinisingil para sa dami ng persistent data na kinikip ng iyong account/contract sa pagdaan ng panahon (parameter 18). Nililinaw namin ang behavior at kalalabasan sa non-payment sa susunod na seksyon.

Ang mga developer tooling at APIs ay may direktang expose ng mga bahagi nito. Halimbawa, ang estimateFee ay nagbabalik ng in_fwd_fee, storage_fee, gas_fee at fwd_fee para sa source at destination, na bumubuo ng total na binabayaran ng sender at receiver para sa isang mensahe.

Isang simpleng transfer, binuo (konsepto):

• Ang external message ng iyong wallet ay gumagana (gas fee) → mag-queue ito ng internal transfer (action fee).
• Ang internal message ay dadalhin sa recipient (forwarding fee); magbabayad ang recipient ng inbound na bahagi upang ma-handle ang mensahe, dagdag ang anumang compute na tumatakbo sa wallet code nito. Magkakaiba ang eksaktong halaga base sa laki ng mensahe, landas ng code at kasalukuyang config prices.

Notes para sa mga user:

• Awtomatikong kinukwenta ng wallet ang fees; makikita mo ang final na halaga bago kumpirmahin. May ilang wallet na nagpapakita ng “Battery” o kaparehong feature para gawing mas madali ang fee payment.
• Maaaring mag-compute ng forward/compute/storage fees ang mga developer programmatically sa pamamagitan ng official functions na nagbabasa ng live config (hal., forward-fee at compute-fee helpers).

Ang storage rent ay isang time-based fee na sinisingil para sa data (wallet/contract code at data) na naka-store sa TON blockchain. Binabayaran ito gamit ang Gram at depende sa dami ng state na ina-occupy ng contract (bilang ng cells at bits) at gaano na katagal ito naistore. Mula network configuration (Config Param 18) ang presyo nito; mas mataas ang rate sa masterchain kaysa sa base workchain. Binabasa ang mga halagang ito ng wallets at SDKs; hindi mo kailangang mano-manong kalkulahin.

Kailan kinukolekta ang fees: Babawas ang storage fees sa Storage phase ng anumang transaction na tumatama sa account. Kahit pagtanggap ng napakaliit na halaga (hal. 1 nanoton) ay magti-trigger ng buo at angkup na storage debt mula huling bayad. Ang bounced messages ay nagdudulot din ng agarang storage fee. Pagkatapos ng matagal na hindi paggalaw, kasama ang mas malaking storage component sa susunod na transaksyon.

Paano ito kinukwenta (developer view): Sa pinaka-mababang lebel, proporsyonal ang fee sa account.bits * bit_price + account.cells * cell_price beses sa lumipas na segundo (na may cell/bit prices mula Config 18). Binibilang lang ng TON ang unique cells (deduplication by hash). May helpers ang official tooling para kwentahin ang storage fees diretso mula sa live config values.

Kung hindi makabayad ang account: Kapag kulang ang balance ng contract para sa storage rent, maaaring i-freeze ng protocol ang kontrata: matatanggal ang code at data cells para lumaya ang resources, ngunit mananatili ang address at anumang natirang balance. Pinapanatili ng network ang hashes ng tinanggal na cells para puwedeng ma-recover. Para i-unfreeze, magpadala ng Gram sa address (para sa bayad) at isang mensahe na may orihinal na code at data na ka-match ng mga hash; ibabalik noon ang estado.

Edge cases & historical note

• Contract na hindi pa nagbabago ng state ay maaaring pumasok sa “uninit” phase imbis na frozen; puwede pa rin itong maibalik.
• Sabi ng orihinal na TON whitepaper, kung walang nagpapadala ng mensahe sa account, hindi kinokolekta ang rent forever; maaari kang magpadala ng minimal message para mag-trigger ng koleksyon at pagtanggal ng insolvent accounts (may kaunting insentibo). Ang modernong implementasyon ay ginagawang freeze/recover flow na gaya ng nabanggit sa itaas.

Ang “TON Services” ay mga component sa network level na sumasabay sa TON Blockchain: pangalanan system (TON DNS), content layer (TON Storage), web-style access (TON Sites) at routing/anonymisation layer (TON Proxy). Tumakbo ang mga ito sa TON P2P stack (ADNL/RLDP) at, kapag may contact sa blockchain (hal. name record o bayad), ang mga operations ay na-se-settle sa Gram.

TON DNS: Ang TON DNS ay nagtatalaga ng human-readable names (hal., example.ton) sa mga TON resource: smart-contract address at ADNL endpoint na ginagamit ng mga serviciyo gaya ng TON Sites. Isinasaad ito bilang on-chain, mostly hierarchical system; puwedeng i-resolve ng mga application ang names sa underlying 256-bit address at konektahan ito. Ang mga interaction na magbabago ng DNS state (registering, extending, o pag-update ng record) ay on-chain na transaksyong binabayaran sa Gram.

TON Sites: Ang TON Sites ay “pure network services” na maaabot sa pamamagitan ng TON transport (ADNL/RLDP). Kadalasang nagpapatakbo o nakakonekta ang user sa isang ton-proxy na tumatanggap ng ordinaryong HTTP requests locally, ipinapasa ang mga ito sa network ng TON sa abstract address ng serbisyo, at ibinabalik ang sagot—nagbibigay ng karanasan gaya ng web nang hindi dumedepende sa pampublikong Internet path sa serbisyo. Ang mga pangalan ay na-resolve sa pamamagitan ng TON DNS. Ang pag-publish o pag-update ng address/record ng serbisyo ay gumagamit ng on-chain transactions na bayad sa Gram; ngunit ang mismong pag-browse ay off-chain traffic.

TON Storage: Ang TON Storage ay nag-aalok ng decentralized na file storage na maaabot sa pamamagitan ng TON Network (ginagamit din para sa blockchain archival data). Ang reference storage-daemon at ang mga smart contracts nito ay nagpapahintulot sa user na magbayad sa storage provider at pinapayagan ang provider na mag-withdraw ng pondo gamit ang Merkle proofs na kaugnay ng na-store na data. Ang mga bayad at interaction sa contract ay nasa Gram; ang aktwal na paglipat ng data ay isinasagawa sa P2P protocol ng TON.

TON Proxy: Ang TON Proxy ay network proxy/anonymizer layer. Tinatago nito ang pagkakakilanlan/IP ng node at tinutulungan ang access sa TON Sites gamit ang pag-bridge ng lokal na HTTP sa transport ng TON, nagbibigay-daan sa pag-access kahit sa ilalim ng filtering o DDoS. Ang paggamit o pagpalit ng proxy ay off-chain; kapag ang service ay nag-publish/discover ng proxy “entry” endpoint sa registry o DNS, on-chain mechanism ang ginagamit kaya Gram ang bayad sa kaukulang transaksyon.

Roles sa madaling sabi:

• Ang mga wallet ay nag-ho-hold ng user keys at humihingi ng kumpirmasyon kung ang dApp ay gustong magpadala ng transaction o mag-sign ng data. Sa Telegram, ang Wallet in Telegram ay nag-aalok ng self-custodial TON Wallet (on-chain keys) at hiwalay na custodial Crypto Wallet; puwedeng lumitaw ang dalawa bilang mga connection target.
• Ang TON Connect ang standard na protocol na nag-uugnay ng dApps sa wallets. Tinutukoy nito kung paano makakakita ng wallet ang apps, makakapag-establish ng encrypted session at humingi ng mga aksyon gaya ng sendTransaction o signData.
• Ang Telegram Mini Apps ay mga web app sa loob ng Telegram. May sariling UI at authorisation mula sa Telegram, at puwedeng magkaroon ng blockchain actions sa pamamagitan ng pag-integrate ng TON Connect. Ang payment flows na built-in sa Telegram (Bot Payments / Stars) ay hiwalay mula sa on-chain na transfer sa TON.

Connection flow (paano nagpapahintulot ang user ng aksyon):

1. Ang dApp (regular na site o Mini App) ay nagpapakita ng “Connect wallet”. Gamit ang TON Connect SDK, ipinapakita nito ang mga supported wallets at autodetect ang context (embedded/injected/remote). Kung ang wallet ay embedded (hal., nasa Telegram), gumagamit ang SDK ng JS bridge; kung hindi, nag-o-open ito ng universal/deep link o QR sa napiling wallet.
2. Ang wallet at app ay lumilikha ng session sa wallet-hosted bridge. Ang mga message ay end-to-end encrypted, kaya hindi mababasa ng bridge ang nilalaman.
3. Pagkatapos magkakonek, maaaring mag-request ang app ng:
   • sendTransaction — ipapakita ng wallet ang transaksyon, at kung aaprubahan ng user, ise-sign at isusumite ito sa TON; makakatanggap ng resulta ang app (hal., BOC/tx hash).
   • signData — hihilingin sa wallet na i-sign ang text/bytes/cells para sa off-chain checks o on-chain verification; walang gumagalaw na pondo.

Paggamit nito sa Telegram Mini Apps: Naglo-load ang Mini Apps ng Telegram WebApp SDK para sa UI at authorisation sa loob ng Telegram, tapos dinadagdag ang TON Connect para sa blockchain actions. Ang resulta ay seamless na daloy: open Mini App → kumonekta ng wallet → payagan ang GRAM transfer o contract call → matatanggap ng app ang confirmation, habang hindi umaalis ang keys sa wallet.

Payments: on-chain vs sariling sistema ng Telegram:

• On-chain GRAM payments (hal. GRAM/Jetton transfers, contract calls) ay tumatakbo sa pamamagitan ng TON Connect at binabayaran on-chain; ang detalye ng fee ay tinalakay sa fees section ng guide na ito.
• Telegram Bot Payments / Stars ay Telegram-native na checkout flow (fiat providers, Stars para sa digital goods). Hindi kailangan ng blockchain transaction at naka-configure sa pamamagitan ng Telegram API’s. Maraming Mini Apps ang gumagamit ng parehong model depende sa use case.

P2P transfers sa chat (self-custodial TON Wallet): Sa TON Wallet (self-custodial option sa “Wallet in Telegram”), maaari kang magpadala ng Gram, jettons at NFT’s sa Telegram contact direkta mula sa isang chat. Lumilikha ang app ng escrow smart contract na humahawak sa asset hanggang tanggapin o tanggihan ng recipient. Kapag tinanggap, lilipat ang pondo on-chain sa recipient; kapag tinanggihan o hindi kinuha sa loob ng 14 na araw, awtomatiko itong ibabalik sa sender. Sa W5-enabled wallets, supported ang ‘gasless’ transfers: ang network fee ay maaaring bayaran mula sa balance ng ipinadalang token (hal., USDT), ngunit sa chain pa rin nangyayari ang settlement.

P2P transfers sa chat (custodial Crypto Wallet): Ang hiwalay na Crypto Wallet Mini App ay sumusuporta sa instant, off-chain transfers sa pagitan ng Crypto Wallet user sa Telegram, na makikita bilang fee-free P2P sends sa chat. Hindi ito nakikita sa blockchain; ang external deposit/withdrawal ay on-chain at may network fees. Depende sa rehiyon ang service availability.

P2P Market (fiat on/off-ramp gamit ang escrow): Sa Crypto Wallet, puwedeng bumili o magbenta ng supported asset gamit ang ibang users sa payment method na tinatanggap ng seller. Naka-lock sa escrow ang crypto hanggang makumpirma ng seller ang bayad, saka ito irerelease sa buyer. Mayroong maker fee sa successful orders, na ipinapakita sa app depende sa region mo.

Ad revenue sharing sa channels (babayaran ng GRAM): Ibinebenta ng Telegram Ad Platform ang TON-based na ads; nagbabayad gamit ang Gram ang advertisers. 50% ng ad revenue mula sa ads sa public channel (may requirements para maging eligible) ay napupunta sa channel owner. Sa Fragment ginagawa ang withdrawal at Gram ang default na payouts; ayon sa terms ng Fragment, pwedeng iba ang payout method sa ibang bansa.

Praktikal na notes:

• Ang “Wallet in Telegram” ay nagpapakita ng dalawang mode: TON Wallet (self-custodial, on-chain) at Crypto Wallet (custodial mini-app). Nagkakaiba ang mga fitur at access depende sa jurisdiction; tingnan ang in-app help kung may feature na di available.
• Para sa fees on on-chain sends (compute/action/forward/storage), tingnan ang fees section nitong gabay; ang off-chain Crypto Wallet transfers sa pagitan ng users ay internal at makikita lang sa in-app history.

Oo. Naglunsad ang Tether ng native na USD₮ sa The Open Network bilang isang TON jetton at naka-lista ang official contract sa Supported Protocols page nito: EQCxE6mUtQJKFnGfaROTKOt1lZbDiiX1kCixRv7Nw2Id_sDs. Inanunsyo ng Tether ang launch ng USD₮ (at XAU₮) sa TON noong Abril 2024.

Ang USD₮ ay naipatupad gamit ang fungible token standard ng TON (Jettons). Ang bawat user ay may sarili-sariling jetton wallet contract na sumasalamin sa jetton master, at transfers ay ordinaryong on-chain messages. NETWORK FEES para sa anumang transfer ay binabayaran sa GRAM; ang halagang ipinapadala mo bilang stablecoin ay hiwalay sa Gram na ginagamit sa fees. Kung hindi ka sigurado kung “USDT” ay tunay, palaging ihambing ang jetton master address sa official listing ng Tether. Posibleng lumikha ng anumang token gamit ang jetton framework ng TON kaya’t mahalaga ang contract verification.

Paggamit ng USDT sa Telegram at TON wallets: Sa Wallet in Telegram, ang self-custodial TON Wallet ang nagha-handle ng on-chain USD₮ (TON) transfers, habang ang hiwalay na custodial Crypto Wallet ay sumusuporta sa instant off-chain transfers sa pagitan ng users at may built-in na P2P Market. May 0.9% fee ang P2P Market sa matagumpay na trade ng mga makers. Depende sa rehiyon at integrated provider ang availability.

Exchange support (on-/off-ramps): Sinusuportahan ng malalaking palitan ang USDT (TON) deposit at withdrawal, kaya’t puwedeng maglipat ng USD₮ papasok at palabas ng TON network nang hindi kailangan mag-bridge. Halimbawa, Binance, OKX, Bybit at KuCoin, bawat isa ay may ina-announce na suporta sa USDT sa TON. Tiyaking tama ang deposit network bago magpadala.

Pag-bridge ng stablecoins papunta/mula TON: Ginagamitan ng third-party bridges ang cross-chain movement ng asset. May mga ecosystem integration ang TON kagaya ng LayerZero/Stargate na nagbibigay-daan sa transfer ng asset sa pagitan ng TON at ibang chain. Hindi bahagi ng base protocol ng TON ang bridging kaya’t may dagdag na trust at smart-contract risk; gumamit lang ng official endpoint at i-verify ang contract ng asset.

Praktikal na safety check:

• Kumpirmahin na ang jetton master ng USD₮ ay tumutugma sa opisyal na TON address ng Tether bago mag-interact.
• Mag-ingat sa “wrapped” o legacy tickers na nauna sa native na USD₮ sa TON; siguraduhin kung anong token ang iyong natatanggap at kung bridge token ba ito. (Ang mga explorer gaya ng Tonviewer ay nireresolba ang opisyal na USD₮ jetton sa address sa itaas.)

Laging nagbabago ang supply numbers. Para sa pinakabagong total at circulating supply, gamitin ang live metrics sa page na ito o confident na TON explorer.

Issuance (paano pumapasok ang bagong GRAM): Ang bagong GRAM ay nililikha ng protocol bilang proof-of-stake rewards. Sa bawat validation round, ang mga napiling validator ay nagla-lock ng stake sa on-chain Elector contract; pagkatapos ng round, ang Elector ang nagbabayad ng rewards, kaya tumataas ang total supply. Karaniwang smart contracts lang ang nominator pools na nag-a-aggregate ng TON ng users at nakikipag-interact sa Elector sa kanilang ngalan; ipinapamahagi ng pools ang rewards alinsunod sa kanilang patakaran.

Inflation (ano ang nagtatakda ng rate): Hindi takda sa schedule ang effective inflation; resulta ito ng bagong issuance minus anumang na-burn sa loob ng panahon. Ang mga paramater ng validator rewards at election cadence ay naka-set sa on-chain at mapapalitan sa pamamagitan ng configuration/governance. Para tantiyahin ang kasalukuyang inflation, ihambing ang pag-mint mula sa Elector payouts at anumang na-destroy na coins (tingnan ang “Burning” sa ibaba).

Burning (paano bumababa ang supply): Dalawang paraan para ma-burn ang GRAM:

1. Protocol- o config-driven fee burns: maaaring i-configure ang network para kalahating bahagi ng fees ay ibu-burn imbis na ibayad sa validator. Naglathala ang komunidad noong 2023 ng panukala na i-burn ang 50% ng transaction fees; ang aktuwal na halaga ay depende sa live network configuration, kaya’t dapat i-verify lagi ang aktuwal na setting.
2. Explicit burn sa sink address: Ang coin na ipinadala sa canonical burn address (karaniwang burn-address.ton) ay hindi na mababawi at tuluyang inaalis sa supply. Makikita sa explorers ang address at gawain nito.

Roles at Elector contract: Gumagamit ng proof-of-stake ang TON. Ang validator ay nagba-bond ng Gram at sumasali sa election na pinapatakbo ng on-chain Elector contract; ang mga mananalong validator ay gumagawa ng blocks. Pagkatapos ng round, nagbibigay ng rewards on-chain ang Elector. Makikita sa explorer at SDK interface ang Elector get-methods (hal. active elections, minStake, past rounds at unfreezeAt).

Validators (direct staking): Ang validator ay nagpapantaya mula sa control contract papunta sa Elector, nagpapatakbo ng validator software, at tumatanggap ng reward kung aktibo at malusog ang performance. Naka-freeze ang stake habang round, at puwedeng i-withdraw lang pagkaraan ng unfreeze time ng Elector para sa round na iyon. Ang minimum stake at iba pang parameters ay nababasa mula sa estado ng Elector, hindi rigid na constants. (Tatalakayin sa susunod na seksyon ang penalties sa misbehaviour.)

Nominator pools (delegation sa validator): Karamihan ng holders ay nagde-delegate gamit ang nominator-pool smart contracts mula sa opisyal na TON repositories. Magdeposito lang ng Gram sa pool contract; saka ito magdi-delegate sa Elector na bumubuo ng stake para sa lahat ng depositor at magpapamahagi pagkatanggap ng reward ayon sa pool rules. Withdrawal ay hiniling sa pamamagitan ng simpleng mensahe (hal. komentong “w”) sa pool contract; ilalabas ang pondo pagkatapos ng kaugnay na validation round at kung may likwididad ang pool. Karaniwan, walang instant redemption; kailangang maghintay hanggang matapos ang cycle. Ang pool implementation at limits (hal. maximum nominators) ay ipinatutupad sa kontrata.

Single-nominator pools (isang delegator, isang validator): Alternative na “single nominator” na disenyo—isang delegator lang na nagpo-pondo sa isang validator, pinapasimple ang contract surface area pero katulad din ng Elector interaction. Open source ang pattern at ginagamit ng ilang validator operator.

Liquid staking (receipt tokens): May official liquid-staking implementation din ang TON. Makakatanggap ng jetton (receipt token) ang depositor na nagseseryoso ng bahagi sa pool at nakakakolekta ng validation rewards; nagpo-pondo ang underlying pool sa validator via Elector. Ang on-chain redemption ay sumusunod pa rin sa timing ng validator exit/settlement, ngunit ang receipt tokens ay transferable at tradeable bago ang pool ay mag-complete ng unbonding cycle. Makikita ang disenyo at contracts nito sa TON core GitHub.

Lockups at unbonding – Ano ang aasahan:

• Validators: naka-lock ang stake para sa aktibong round at pwedeng i-withdraw pagkatapos ng unfreezeAt ng round na iyon. Maaaring kunin ang reward sa Elector pagkatapos ng settlement.
• Nominators sa standard pools: Ang exit ay naka-queue at ipoproseso pagkalipas ng round; walang instant exit na garantisado. Suriin ang bawat pool kung may batching at minimum.
• Liquid-staking users: Ang receipt tokens ay pwedeng liquefy sa pamamagitan ng transfer; para i-burn at gawing GRAM, susundin ang pool exit rules na naka-base sa validator cycle.

IPINAPATUPAD ng TON ang slashing para parusahan ang misbehaviour ng validator sa validation round. Dalawang kategorya ang karaniwang pinatutupad:

• Idle/under-performing — ang validator ay masyadong kaunti ang naprosesong block sa round. Nagkakaroon ng complaints na binobotohan ng mga kasamang validator (karaniwang awtomatikong gamit ang mytonctrl), at pinapatawan ng multa mula sa stake ng validator para sa round na iyon.
• Cheating/equivocation — hal. paglikha ng conflicting messages (forking) na natukoy ng Catchain consensus; ang validator ay ihiwalay at mumultahan (historically ang parehong penalty sa idle, ngunit may proposal na taasan ito).

Proseso: Pagkatapos ng bawat round, nagsusuring performance ang validators ng isa’t isa; binobotohan ang valid complaints at ang penalty mula sa network configuration ay ibabawas mula sa frozen stake ng offender. Ang mga operator na hindi gumagamit ng mytonctrl ay maaaring gumamit ng official Punisher script para makilahok sa voting. Ang slashing parameters ay nananatili sa network config (added via network update).

Epekto sa delegators/pools: Nagde-delegate ang nominator pools sa Elector, at nakuha ang funds pagkatapos ng round. Kapag na-fine ang validator, bababa ang matatanggap ng pool mula sa Elector para sa round na iyon kaya’t pati delegators ay may loss depende sa pool rules. (Mas kadalasang mas malaki pa ang natatanggap, ngunit slashing ang exception.) Tiyaking suriin ang kontrata/patakaran ng pool bago mag-stake.

Validator capital requirements:

• Minimum na stake para makasali sa elections: ayon sa official validator page, kailangan ng hindi bababa sa 300,000 GRAM para maging validator. Sa praktika, depende sa kompetisyon at on-chain parameters para sa election kung ilan talaga ang prangkang kailangan.
• Mechanics ng cycle: Nagla-lock ang candidates ng stake sa Elector para sa isang round; pagkaraang ma-settle, ibinabalik on-chain ang stake at rewards.

Hardware & operasyon (high level):

• Pinapayuhan ng opisyal na guidance na magpatakbo sa high-performance hardware na may high-availability na network connection (24/7 uptime at low latency ay mahalaga para makaiwas sa idle penalties).
• Karaniwang inirerekomenda ng community runbooks ang modern multi-core CPU, malaking RAM, mabilis na SSD/NVMe storage; ang pina-re-refer na guide ay nagsasabing 8 vCPU, 64 GB RAM, ~1 TB SSD at 1 Gb/s connectivity ay praktikal na baseline. Ituring ang mga ito bilang community recommendation, hindi protocol rules.
• Karamihan ng operator ay gumagamit ng mytonctrl para i-manage ang validator nodes, keep software current at automate complaint handling/telemetry.

Pangunahing takeaway:

• Ang TON ay nag-s-slash ng validator para sa idle na asal at cheating (equivocation/forking) na natukoy ng Catchain; nakakabit sa live network configuration ang fines at ibinabawas mula sa stake para sa round.
• Para mabawasan ang panganib, panatilihin ang mataas na uptime, monitor ang performance, keep nodes updated, at pumili ng pools/validator na may matibay na record kung magde-delegate ka.

Jettons (fungible tokens) — standard at model: Sinusunod ng Jettons ang TEP-74. Binubuo ang Jetton ng Jetton Minter (master) contract na nagtatakda ng policy (minting, burning, metadata) at bawat Jetton Wallet contract na hawak ang balance ng bawat user. Ang mga interfaces (hal. get_jetton_data, transfer opcodes) ay standardized para mag-interoperate ang wallets, exchange at indexers.

Paano mag-isyu ng Jetton (karaniwang daloy):

1. Magsimula sa isang reference implementation (FunC o Tact) at i-configure ang metadata (name, symbol/decimals gamit ang TEP-64), supply policy at admin privileges.
2. I-deploy ang Jetton Minter, gamit ang napiling Jetton Wallet code bilang library cell.
3. Mag-mint sa pamamagitan ng mensahe mula sa minter para mag-create/credit ng Jetton Wallet contract ng tatanggap; para mag-burn magpadala ng mensahe para bawasan ang supply.

Ang official repos ay may production-grade minter at wallet, at browser-driven na “Jetton Deployer”.

Jetton metadata: Ang presentation data (name, description, image, decimals) ay gumagamit ng TEP-64 Token Data Standard. Puwedeng i-store ng mga creator ang metadata on-chain (cell) o off-chain (URL sa JSON). Ang paggamit ng standard fields ay bibigyan ng consistent na display sa wallets at explorer.

NFTs — standards at contracts: Ang NFTs ay gumagamit ng TEP-62. Ang bawat NFT Item ay sariling contract; ang mga items ay kadalasang nakagrupo sa NFT Collection contract na nag-e-expose ng common data at discovery. Itinatakda ng TEP-62 ang ownership transfer at discovery methods; TEP-64 ang nagbibigay ng metadata schema para sa item at collection.

Pag-isyu ng NFT collection at item (karaniwang daloy):

1. I-deploy ang Collection na may TEP-64 metadata (name, cover image, base content layout).
2. Gumawa ng Item sa pamamagitan ng pag-deploy ng item contract na nagre-reference sa collection; puwedeng i-set bawat item ng TEP-64 metadata (name, image, attributes) per mint.
3. Ang transfer ay karaniwang TEP-62 messages sa pagitan ng item contract owned ng iba’t ibang address, kaya’t kayang i-handle ng wallets at markets ang movement nang maayos.

Tooling (opisyal at malaganap):

• Blueprint — opisyal na all-in-one environment sa pag-scaffold, test at deploy ng TON contract (supports FunC, Tact at Tolk). Pinakabilis na paraan para gumawa ng Jetton o NFT at may testing at scripting.
• Tact — higher-level na wika na may template, kabilang ang TEP-compatible na Jetton implementation; may docs at GitHub org na may examples at patterns.
• FunC — low-level na wika at stdlib para sa TVM contract, maraming reference Jetton/NFT contract ang naisulat sa FunC.
• SDKs — TypeScript @ton/ton (ton-core) may helpers para sa Jetton/NFT (hal., JettonMaster), at mature JS library ang TonWeb na malawak na ginagamit sa guides at integration. TonAPI ay may REST/SDK access sa balance, metadata at transfers.

Magandang gawain:

• Manatili sa TEP interfaces. Kung gusto mong mag-extend ng logic (fees, pausing, minter roles), panatilihin ang TEP-mandated getters at message format para makilala pa rin ng wallets at markets ang iyong token.
• Gumamit ng TEP-64 palagi. Piliin kung on-chain o off-chain URL ang metadata at panatilihin ang schema para di masira ang display.
• I-verify ang contracts at address. I-publish ang minter/collection address at code hash; sa fungibles, gawing publikong makikita ang Jetton master address para makita ng user/integrations kung tama ang asset na kanilang kinokonekta.

Ang Fragment ay opisyal na marketplace ng Telegram para sa collectible usernames at kaugnay na asset. Ang mga benta ay isinasagawa bilang public auction o fixed-price deals, at sine-settle sa Gram (GRAM). Pagkatapos ng pagbili, makikita ang collectible sa account ng bumiling user at maia-assign sa Telegram profile, channel o group. May help materials ang Fragment para sa wallet connection, bidding at assignment at kinukumpirma na Gram ang ginagamit sa bidding at settlement.

Paano gumagana ang @username auction sa Fragment:

• Bidding & settlement: Mag-log in gamit ang Telegram, i-connect ang TON wallet at mag-bid on-chain gamit ang Gram; kung may mas mataas na bid, awtomatikong ibinabalik ang pondo. Kapag nanalo, mapupunta sa wallet ng panalo ang collectible.
• Listing & cancellation: Pwede kang mag-list ng pangalan at kanselahin ang auction anumang oras bago magkaroon ng unang bid. Kapag may bid na, tuluy-tuloy na ang auction hanggang matapos ayon sa rules.
• Fees: Nakasaad sa Fragment ang platform fee (makikita sa lot page) para sa natapos na benta, dagdag ang isang beses na conversion fee. Ang values ay mula sa platform at maaaring magbago; kumpirmahin palagi ang fee line ng lot bago i-list.
• After the auction: Puwedeng i-assign ang username collectible sa Telegram entity gamit ang Fragment; puwede pang baguhin ang assignment ng owner sa bandang huli.

Saan papasok ang TON: Lahat ng bayad sa Fragment ay nasa Gram. Hiwalay, ginagamit din ang Gram ng ad platform ng Telegram para bumili ng ads at bayaran ang channel owner; sa Fragment naman idinaan ang withdrawal—ngunit ang ad flow ay hiwalay sa username auction.

TON domain (.ton) auctions:

• Standard & purpose: Tina-translate ng TON DNS ang human-readable name (hal., name.ton) sa TON resources (contract address, ADNL endpoints). TEP-81 ang standard nito.
• Paano lumalabas sa user ang auction: Ang domain auction ay pina-patakbo ng on-chain contracts at makikita sa explorer (hal., Tonviewer “Auctions” para sa pangalan). Maaaring may marketplace na nagdi-display ng DNS name bilang item na nagre-reference sa kontrata. Lagi siguraduhin ang contract address ng domain bago mag-bid.
• Payment at settlement: Ang bidding ay sa Gram at isinasagawa on-chain; pagkatapos ng auction, natratransfer ang domain contract state sa nanalo, na puwede nang mag-set ng records gaya ng TEP-81. May tooling at APIs na nagsasagawa ng DNS ownership at expiration checking.

Mabilis na safety checklist:

• Siguruhing tama ang opisyal na lot URL sa Fragment at suriin ang fee line bago mag-list o mag-bid.
• Sa .ton domains, i-verify ang contract address at basahin ang TEP-81-compatible na record; gumamit ng trusted explorer/API para suriin ang current owner at expiration.

Ang teknolohiya sa likod ng TON ay orihinal na binuo ng Telegram sa pamumuno ni Pavel at Nikolai Durov, na nagplano ring ilunsad ang Gram token. Noong Mayo 2020, inihayag ng Telegram na ititigil na ang kanilang involvement matapos ang aksyon ng U.S. SEC; pinabalik ng korte sa Telegram at TON Issuer ang pondo sa investors at nagbayad ng sibil na multa. Nanatiling open-source ang codebase.

Mula “Telegram Open Network” patungong community-run na TON na may Gram: Matapos umatras ang Telegram, ipinagpatuloy ng independent na developers ang network bilang The Open Network (TON). Nasa komunidad at TON Foundation, isang Swiss non-profit, ang stewardship; ang native asset ng network ay Gram (GRAM) (hindi Gram). Hindi kinokontrol ng Telegram ang blockchain.

Paano ngayon nakaugnay ang Telegram sa TON? Ginagamit ng Telegram ang TON bilang isang platform feature, ngunit hiwalay ito na kumpanya:

• Ang Wallet in Telegram ay nag-aalok ng self-custodial TON Wallet (keys sa TON blockchain, hindi hawak ng Telegram) at hiwalay na custodial Crypto Wallet.
• Ang ad platform ng Telegram ay nagbebenta ng TON-based ads at nagbabahagi ng 50% ng ad revenue sa kwalipikadong channel owner; sa Fragment idinadaan ang withdrawal.
• Ang Fragment ay nag-iisyu ng auction at benta ng collectible @username, settled sa Gram.

Pinaikling buod:

• Lumikha: Telegram team (Durov brothers) ang pinagmulan ng tech at konsepto ng “Telegram Open Network.”
• Network at coin ngayon: ipinagpatuloy ng independent na komunidad; inaalagaan at sinusuportahan ng TON Foundation; native asset ay Gram.
• Papel na ginampanan ng Telegram ngayon: integrator at distribution channel—hindi operator ng network o issuer. Ang mga produkto ng Telegram ay kumokonekta sa TON ngunit hindi ito kinokontrol.