Toncoin (TON) Price, Charts & Market Data

Telegram originally developed the “Telegram Open Network” and planned the Gram token, but stopped the project in 2020 after a U.S. SEC action and court-approved settlement. The open-source codebase and vision were then continued by an independent community as The Open Network (TON) with Toncoin as the native asset. Today, TON is a community-led blockchain, while Telegram is a separate company.

Telegram now integrates with TON without controlling it. The company operates an in-app Wallet in Telegram that offers two modes: a custodial Crypto Wallet and a self-custodial TON Wallet for on-chain activity on the TON blockchain. Availability and features depend on region and product policy.

Telegram also runs TON-based Ads: advertisers buy channel ads using Toncoin, and eligible channel owners can withdraw 50% of ad revenue (handled via Fragment). This is a platform integration built on TON rather than a governance role in the network.

Fragment is Telegram’s official marketplace for @usernames and related assets; auctions and settlements occur using Toncoin and link to Telegram accounts.

Separately, the TON Foundation is a Swiss non-profit that supports the TON ecosystem; it does not own Telegram or operate the messaging platform.

The Open Network (TON) is an open-source, community-run Layer-1 platform that combines a base smart-contract blockchain with supporting peer-to-peer components and native services. The original technical specification (the TON whitepaper) describes a multi-blockchain design plus a P2P stack and “TON Services” such as DNS, Storage, Sites and Proxy that applications can use within one cohesive network. In this model, TON Blockchain is the core ledger, while the other modules provide name resolution, data storage/serving and traffic routing as part of the same ecosystem.

TON’s codebase and validator software are developed in public repositories; the project operates without a single controlling authority. The TON Foundation is a Swiss non-profit that supports the ecosystem but does not control the technology.

Toncoin (TON) is the network’s native currency. In TON’s design, the native coin pays on-chain fees and is staked by validators to secure the network; the whitepaper (written before the community rebrand from “Gram” to “Toncoin”) outlines the native coin’s roles in metering computation (“gas”) and validator economics. Today, Toncoin is the unit used across the ecosystem, including platform integrations such as Telegram’s TON-based ads. For detailed mechanics of fees and staking, see the dedicated sections in this description.

Toncoin is the native asset that underpins activity on The Open Network. Its uses group into four practical areas:

1) Paying on-chain fees: Transactions and smart-contract execution on TON are paid in Toncoin. Fees cover computation and message routing, and include storage-related charges.

2) Securing the network via staking: Validators stake Toncoin to participate in proof-of-stake validation and earn protocol rewards; delegation is implemented through nominator-pool contracts on-chain.

3) Settling protocol-level services: TON’s built-in services (for example TON DNS, Storage, Sites and Proxy) are part of the network stack. Interactions such as registering or auctioning .ton names, resolving names or operating storage nodes involve on-chain transactions denominated in Toncoin. Detailed mechanics of each service are covered in the TON Services section.

4) Platform and app integrations: Toncoin is accepted to buy Telegram Ads, and eligible channel owners withdraw revenue via Fragment; Fragment’s collectible @username auctions also settle to a connected TON wallet. Beyond Telegram, dApps across TON commonly quote prices and settle payments in Toncoin.

For fee structure see “Which on-chain actions require TON and how are fees calculated…?”; for staking roles and delegation see “How does staking on TON work…?”.

TON is designed as a collection of blockchains that operate in parallel and coordinate through a special chain called the masterchain. Below that sit one or more workchains, each of which can be dynamically sharded into many shardchains. This structure lets TON process activity concurrently while keeping the system consistent.

Masterchain: The masterchain records network-wide metadata and coordination data for the whole system (for example, hashes of the latest blocks from all shardchains). By embedding these references, the masterchain makes those shard blocks canonical, allowing other shards to rely on them immediately in subsequent blocks. Many protocol parameters are also stored as part of the masterchain state.

Workchains: A workchain is a full blockchain within TON that defines its own rules and block format. The whitepaper envisages up to 2³² workchains; in practice, most applications use the “basic workchain” (also called Workchain Zero) where TON smart contracts run and Toncoin transfers occur. Different workchains may exist in future for specialised purposes.

Shardchains (dynamic sharding): Each workchain is split into shardchains, where each shard is responsible for a subset of account addresses. Shards can split when load is high and merge when load is low, providing elastic capacity without manual coordination. Routing between shards and workchains uses TON’s message-passing model, so smart contracts can send messages and value across shards reliably.

How the pieces fit together

• Shardchains produce blocks in parallel; the masterchain then includes hashes of those new shard blocks, which other shards treat as final for follow-on actions.
• The “basic workchain” hosts today’s smart-contract activity and Toncoin transfers; additional workchains could adopt different rules or even a different VM, while the masterchain keeps everything in sync.

On TON, every user account is a smart contract. A “wallet” is simply a minimal contract that holds Toncoin and sends signed messages on the owner’s behalf. The wallet verifies signatures from the user’s key, tracks a seqno (to prevent replays), and executes owner-authorised actions when it receives an external message. In TON’s developer docs this is often phrased as “everything is a smart contract,” including wallets.

Wallet V4 (v4r2): V4 standardised a plugin/extension model: the wallet can authorise trusted companion contracts (“plugins”) to perform specific actions with funds (for example, subscriptions). The V4 repo documents the plugin interface and how wallets install and remove plugins. V4 remains widely used and is supported by major wallets.

Wallet V5 (W5): V5 - commonly referred to as W5 - is the newer wallet-contract standard maintained in the TON core repositories. Key capabilities defined in the spec and code include:

• Multi-send: a single signed order can emit up to 255 outgoing messages;
• Internal as well as external signed actions, enabling relayer patterns (often used for “gasless” flows);
• A generalised extensions mechanism (successor to V4 plugins), including the ability for an extension to block signed actions (useful for 2FA or recovery flows). >The spec and repository also describe how gasless relayers can forward a user-signed message and pay Toncoin fees on submission.

W5 in the wild: Explorers expose an interface tag such as wallet_v5r1, reflecting deployed W5 contracts on mainnet. Wallet apps increasingly default to W5 for new addresses, with fallbacks for V4 where needed.

Because a TON wallet is contract code and data, changing the wallet version (e.g., V4 → W5) changes the contract and therefore the address. Your seed phrase can derive keys for multiple versions, but balances do not “auto-move” - you deploy the new wallet and transfer funds or interact as needed. Some apps let you manage multiple versions side-by-side.

Short answer: TON does not run the Ethereum Virtual Machine. Smart contracts on TON execute on the TON Virtual Machine (TVM), the network’s native runtime. Ecosystem initiatives can add EVM compatibility as separate layers or projects, but this is not part of the base protocol.

TON Virtual Machine (TVM) is a deterministic, stack-based VM used by the masterchain and the basic workchain. It executes contract code, parses inbound messages and persistent data, updates state, and creates outbound messages. Client-side “get-methods” are evaluated by running a local TVM against verified state, which avoids full-node requirements for reads.

Languages on TON:

• FunC – Low-level, C-like language for writing contracts that compile to TVM bytecode; the standard tooling and instruction set are maintained in the official TON repositories.
• Tact – Higher-level language that compiles to TVM via the TON toolchain; official docs cover the language, type system and build flow.

Developer workflow: Many teams scaffold, test and deploy TVM contracts using the official Blueprint environment, which supports projects in FunC and Tact.

About EVM on TON: Where EVM execution is offered in the TON ecosystem (for example, TEVM- or L2-based efforts), it is delivered as an additional compatibility layer and not as TON’s native runtime.

Any on-chain transaction on TON - sending TON or tokens, deploying a contract, or calling a contract - incurs fees paid in Toncoin. Wallets submit an external message to your wallet contract, which then executes and (typically) emits one or more internal messages; each step has fees. Some wallets support “gasless” flows via W5 (a relayer pays on your behalf or fees are covered from the transferred asset), but the network itself still settles fees in TON.

How fees are composed

At a low level, a transaction’s total fee is the sum of several components that reflect execution and messaging across shards/workchains:

• Computation (gas) fee: charged for TVM steps your contract consumes; prices come from on-chain config parameters (masterchain/basechain).
• Action fee: charged for actions performed during the action phase (for example, creating and sending outgoing messages).
• Forwarding fees: paid for delivering messages; depend on the message size in cells/bits and the per-chain forward-price settings defined in the live network configuration. There is a fee for inbound delivery and for each outbound hop.
• Storage fees (“storage rent”): charged for the amount of persistent data your account/contract keeps over time (parameter 18). We explain behaviour and non-payment outcomes in the next section.

Developer-facing tooling and APIs expose these parts directly. For example, estimateFee returns infwdfee, storagefee, gasfee and fwd_fee for the source and destination, which together represent what the sender and the receiver pay for a given message.

A simple transfer, decomposed (conceptual):

• Your wallet’s external message executes (gas fee) → it queues an internal transfer (action fee).
• The internal message is delivered to the recipient (forwarding fee); the recipient pays the inbound part for handling that message, plus any compute to run its wallet code. Exact amounts vary with message size, code paths and current config prices.

Notes for users:

• Fees are calculated automatically by wallets; you’ll see the final amount before confirming. Some wallets also offer “Battery” or similar features to abstract fee payment.
• Developers can programmatically compute forward/compute/storage fees using the official functions that read the live config (e.g., forward-fee and compute-fee helpers).

Storage rent is a time-based fee charged for keeping state on the TON blockchain (wallet/contract code and data). It is denominated in Toncoin and depends on how much state a contract uses (number of cells and bits) and how long it has been stored. Prices come from the network configuration (Config Param 18), with higher rates on the masterchain than on the base workchain. Wallets and SDKs read these values; you do not need to calculate them manually.

When fees are collected: Storage fees are deducted during the Storage phase of any transaction that touches the account. Even receiving a tiny inbound value (e.g., 1 nanoton) triggers payment of the full accrued storage debt since the last payment. Bounced messages also cause the contract to pay its current storage fee. After long inactivity, the next transaction will therefore include a larger-than-usual storage component.

How it’s calculated (developer view): At a low level, the fee is proportional to account.bits bit_price + account.cells cell_price times the elapsed seconds (with cell/bit prices taken from Config 18). TON counts unique cells only (deduplication by hash). Official tooling exposes helpers to compute storage fees directly from live config values.

If the account cannot pay: If a contract’s balance is insufficient to cover accumulated storage rent, the protocol may freeze the contract: its code and data cells are deleted to free resources, while the address and any remaining balance stay in place. The network keeps the hashes of the removed cells so the contract can be recovered later. To unfreeze, send Toncoin to the address (to fund fees) and a message containing the original code and data matching those hashes; the state is then restored.

Edge cases & historical note

• Contracts that have never changed state can enter an “uninit” phase instead of frozen; they can still be restored.
• The original TON whitepaper notes that if no one sends messages to an account, rent is not collected indefinitely; any party may send a minimal message to trigger collection and removal of insolvent accounts (with a small incentive). Modern implementations expose this as the freeze/recover flow described above.

“TON Services” are network-level components that sit alongside the TON Blockchain: a naming system (TON DNS), a content layer (TON Storage), web-style access (TON Sites) and a routing/anonymisation layer (TON Proxy). They run over TON’s P2P stack (ADNL/RLDP) and, where they touch the blockchain (e.g., name records or payments), operations are settled in Toncoin.

TON DNS: TON DNS maps human-readable names (e.g., example.ton) to TON resources: smart-contract addresses and ADNL endpoints used by services such as TON Sites. It is specified as an on-chain, mostly hierarchical system; applications can resolve names to the underlying 256-bit addresses and then connect. Interactions that modify DNS state (registering, extending, or updating records) are on-chain transactions paid in Toncoin.

TON Sites: TON Sites are “pure network services” reachable through TON’s transport (ADNL/RLDP). A user typically runs or connects to a ton-proxy that accepts ordinary HTTP requests locally, forwards them via TON’s network to the service’s abstract address, and returns responses - yielding a web-like experience without relying on the public Internet path to the service. Names are resolved via TON DNS. Publishing or updating the service’s address/records uses on-chain transactions paid in Toncoin; browsing itself is off-chain traffic.

TON Storage: TON Storage provides decentralised file storage accessible through the TON Network (also used for blockchain archival data). The reference storage-daemon and its smart contracts let users pay storage providers and allow providers to withdraw funds by presenting Merkle proofs tied to stored data. Payments and contract interactions are in Toncoin; the actual data transfer occurs over TON’s P2P protocols.

TON Proxy: TON Proxy is the network proxy/anonymiser layer. It hides node identities/IPs and enables access to TON Sites by bridging local HTTP to TON’s transport, improving reachability under filtering or DDoS conditions. Using a proxy or changing proxy settings is off-chain; when services publish or discover proxy “entry” endpoints via registries or DNS, those touches use on-chain mechanisms and therefore Toncoin for the associated transactions.

Roles at a glance:

• Wallets hold users’ keys and ask for approval when a dApp wants to send a transaction or sign data. In Telegram, Wallet in Telegram offers a self-custodial TON Wallet (on-chain keys) and a separate custodial Crypto Wallet; both can appear as connection targets.
• TON Connect is the standard protocol that links dApps to wallets. It defines how apps discover wallets, establish an encrypted session and request actions like sendTransaction or signData.
• Telegram Mini Apps are web apps inside Telegram. They add Telegram UI and authorisation, and can include blockchain actions by integrating TON Connect. Payment flows built into Telegram (Bot Payments / Stars) are separate from on-chain TON transfers.

Connection flow (how users approve actions):

1. The dApp (regular site or Mini App) shows “Connect wallet”. Using TON Connect SDK, it lists supported wallets and detects context (embedded/injected/remote). If the wallet is embedded (e.g., inside Telegram), the SDK uses a JS bridge; otherwise it opens a universal/deep link or QR to the chosen wallet.
2. The wallet and app create a session over a wallet-hosted bridge. Messages are end-to-end encrypted, so the bridge can’t read contents.
3. After connection, the app can request: sendTransaction - the wallet displays the transaction and, if the user approves, signs and submits it to TON; the app receives a result (e.g., BOC/tx hash). signData - ask the wallet to sign text/bytes/cells for off-chain checks or on-chain verification; no funds move.

Using this inside Telegram Mini Apps: Mini Apps load Telegram’s WebApp SDK for in-Telegram UI and authorisation, then add TON Connect for blockchain actions. The result is a seamless flow: open Mini App → connect wallet → approve a TON transfer or contract call → app receives confirmation, while keys never leave the wallet.

Payments: on-chain vs Telegram’s own system:

• On-chain TON payments (e.g., TON/Jetton transfers, contract calls) run via TON Connect and are paid on-chain; fee details are covered in the fees section of this guide.
• Telegram Bot Payments / Stars are Telegram-native checkout flows (fiat providers, Stars for digital goods). These do not require a blockchain transaction and are configured through Telegram’s APIs. Many Mini Apps combine both models depending on the use case.

P2P transfers inside chats (self-custodial TON Wallet): With TON Wallet (the self-custodial option inside “Wallet in Telegram”), you can send Toncoin, jettons and NFTs to a Telegram contact directly from a chat. The app creates an escrow smart contract that holds the assets until the recipient accepts or declines. If accepted, funds move on-chain to the recipient; if rejected or not claimed within 14 days, they are automatically returned to the sender. With W5-enabled wallets, ‘gasless’ transfers are supported: the network fee can be covered from the balance of the transferred token (e.g., USDT), while settlement on chain still occurs in TON.

P2P transfers inside chats (custodial Crypto Wallet): The separate Crypto Wallet Mini App supports instant off-chain transfers between Crypto Wallet users in Telegram, shown as fee-free P2P sends in chats. These do not appear on the blockchain; external deposits/withdrawals are on-chain and incur network fees. Service availability depends on region.

P2P Market (fiat on/off-ramp with escrow): Inside Crypto Wallet, the P2P Market lets users buy or sell supported assets with other users using payment methods the seller accepts. Crypto is locked in escrow until the seller confirms payment, then it’s released to the buyer. A maker fee applies on successful orders, shown in-app for your region.

Ad revenue sharing for channels (paid in TON): Telegram’s Ad Platform sells TON-based ads; advertisers pay in Toncoin. 50% of ad revenue from ads shown in public channels (with eligibility requirements) goes to channel owners. Withdrawals are processed via Fragment, with rewards issued in Toncoin by default; Fragment’s terms note alternative payout methods may apply in some countries.

Practical notes:

• “Wallet in Telegram” presents both modes: TON Wallet (self-custodial, on-chain) and Crypto Wallet (custodial mini-app). Feature sets and access vary by jurisdiction; check the in-app help if a feature isn’t available.
• For fees on on-chain sends (compute/action/forward/storage), see the fees section of this guide; off-chain Crypto Wallet transfers between its users are handled internally and shown in the app history only.

Yes. Tether launched native USD₮ on The Open Network as a TON jetton and lists the official contract on its Supported Protocols page: EQCxE6mUtQJKFnGfaROTKOt1lZbDiiX1kCixRv7Nw2Id_sDs. Tether also announced the launch of USD₮ (and XAU₮) on TON in April 2024. USD₮ is implemented using TON’s fungible token standard (Jettons). You hold a per-user jetton wallet contract that mirrors the jetton master, and transfers are regular on-chain messages. Network fees for any transfer are paid in TON; the stablecoin amount you send is separate from the Toncoin used for fees. If you are unsure whether a token claiming to be “USDT” is genuine, always compare the jetton master address with Tether’s official listing. The TON jetton framework allows anyone to deploy look-alikes, so contract verification matters.

Using USDT in Telegram and TON wallets: In Wallet in Telegram, the self-custodial TON Wallet handles on-chain USD₮ (TON) transfers, while the separate custodial Crypto Wallet supports instant off-chain transfers between its users and a built-in P2P Market. The P2P Market charges makers a 0.9% fee on successful trades. Availability depends on region and integrated providers.

Exchange support (on-/off-ramps): Major exchanges support USDT (TON) deposits and withdrawals, which lets users move USD₮ directly to and from the TON network without bridging. Examples include Binance, OKX, Bybit and KuCoin, each with dated announcements opening USDT on TON. Check the selected exchange’s deposit network before sending.

Bridging stablecoins to or from TON: Cross-chain movement of assets is handled by third-party bridges. TON has ecosystem integrations such as LayerZero/Stargate that enable transfers of supported assets between TON and other chains. Bridging is not part of TON’s base protocol, so it introduces additional trust and smart-contract risk; always use official endpoints and verify the destination asset’s contract.

Practical safety checks:

• Confirm the jetton master for USD₮ matches Tether’s official TON address before interacting.
• Be cautious with “wrapped” or legacy tickers that pre-date native USD₮ on TON; verify what you are receiving and whether it is a bridge token. (Explorers like Tonviewer resolve the official USD₮ jetton at the address above.)

Supply numbers change continuously. For up-to-date total and circulating supply, use our live metrics on this page or a reputable TON explorer.

Issuance (how new TON enters supply): New TON is created by the protocol as proof-of-stake rewards. During each validation round, elected validators lock stake with the on-chain Elector contract; after the round ends, the Elector pays out rewards, which increases total supply. Nominator pools are ordinary smart contracts that aggregate users’ TON and interact with the Elector on their behalf; pools then distribute rewards to participants according to their rules.

Inflation (what determines the rate): Effective inflation is not a fixed schedule; it results from new issuance minus any burns over a period. Validator reward parameters and election cadence are set on-chain and can be changed via configuration/governance. To assess current inflation, compare the minting tracked from Elector payouts with any coins destroyed (see “Burning” below).

Burning (how supply can decrease): There are two ways TON can be destroyed:

1. Protocol- or config-driven fee burns: the network can be configured so that a portion of fees is burned instead of paid to validators. A community proposal to burn 50% of transaction fees was published in 2023; whether and how much is burned is determined by current network configuration, so always verify the live setting.
2. Explicit burns to a sink address: coins sent to the canonical burn address (commonly referenced as burn-address.ton) are irrecoverable and therefore removed from supply. Explorers expose this address and its activity.

Roles and the Elector contract: TON uses proof-of-stake. Validators lock Toncoin and enter elections run by the on-chain Elector contract; elected validators then produce blocks. After a round, the Elector pays rewards on chain. Explorer and SDK interfaces expose Elector get-methods (e.g., active elections, minStake, past rounds and unfreezeAt).

Validators (direct staking): A validator stakes from its control contract to the Elector, runs the validator software, and receives rewards if it remains healthy. The stake becomes frozen for the round and is withdrawable only after the Elector’s unfreeze time for that round. Minimum stake and other parameters are read from Elector state; they are not fixed constants. (Penalties for misbehaviour are covered in the next section.)

Nominator pools (delegation to a validator): Most holders delegate via nominator-pool smart contracts maintained in the official TON repositories. You deposit Toncoin to the pool contract; the pool then stakes with the Elector on behalf of all depositors and later distributes rewards according to pool rules. Withdrawals are requested by sending a simple message (e.g., comment “w”) to the pool contract; funds are released after the relevant validation round completes and the pool has liquidity to honour exits. Standard nominator pools do not offer instant redemption; you typically wait until the end of a cycle. Pool implementations and limits (e.g., maximum nominators) are enforced in the contract.

Single-nominator pools (one delegator, one validator): An alternative “single nominator” design simplifies the pool to a single delegator funding one validator, reducing contract surface area while preserving the same Elector interactions. This pattern is open-sourced and used by some validator operators.

Liquid staking (receipt tokens): TON also provides an official liquid-staking implementation. Depositors receive a jetton (receipt token) that represents their share of the pool and accrues validation rewards; the underlying pool stakes with validators via the Elector. On-chain redemptions still follow validator exit/settlement timings, but receipt tokens can be transferred or traded to obtain liquidity before the pool completes an unbonding cycle. Design and contracts are maintained in the TON core GitHub.

Lockups and unbonding – what to expect:

• Validators: stake is locked for the active round and becomes withdrawable after the Elector’s unfreezeAt for that round. Rewards are claimable from the Elector at or after settlement.
• Nominators in standard pools: exits are queued and processed after a round ends; there is no guaranteed instant exit. Check each pool’s policy for batching and minimums.
• Liquid-staking users: receipt tokens provide liquidity by transfer; burning them for TON follows the pool’s exit rules, which depend on validator cycles.

TON implements slashing to penalise validator misbehaviour detected over a validation round. Two categories are enforced in practice:

• Idle/under-performing - a validator processes too few blocks during a round. Complaints are generated and voted on by other validators (usually automated via mytonctrl), and a fine is applied from the validator’s stake for that round.
• Cheating/equivocation - e.g., producing conflicting messages (forking) detected by the Catchain consensus; such validators are isolated and fined (historically the same penalty as idle, with proposals to increase it).

The process is: after each round, validators audit each other’s performance; valid complaints are voted on and the penalty defined in the network configuration is deducted from the offender’s frozen stake for that round. Operators who don’t use mytonctrl can run the official Punisher script to participate in complaint voting. Slashing parameters are explicitly stored in network config (added via a network update).

Impact on delegators/pools: Nominator pools stake to the Elector on behalf of depositors and then recover funds after the round. If a validator is fined, the amount returned from the Elector for that round is reduced, so delegators share the loss according to pool rules. (Pools “usually” receive more back than they sent; slashing is the notable exception.) Review a pool’s contract/policy before delegating. Validator capital requirements:

• Minimum stake to enter elections: the official validator page states you need at least 300,000 TON to become a validator. In practice, the effective threshold to be elected depends on competition and on-chain parameters for that election.
• Cycle mechanics: candidates lock stake with the Elector for a round; after settlement, stake and rewards are returned on chain.

Hardware & operations (high level):

• The official guidance is to run on high-performance hardware with a high-availability network connection (24/7 uptime and low latency are essential to avoid idle penalties).
• Community runbooks commonly recommend modern multi-core CPUs, ample RAM and fast SSD/NVMe storage; one widely referenced guide suggests 8 vCPUs, 64 GB RAM, ~1 TB SSD and 1 Gb/s connectivity as a practical baseline. Treat these as community recommendations, not protocol rules.
• Most operators use mytonctrl to manage validator nodes, keep software current and automate complaint handling/telemetry.

Key takeaways:

• TON does slash validators for idle behaviour and for cheating (equivocation/forking) detected by Catchain; fines are set in the live network configuration and deducted from the stake used in that round.
• To minimise risk, maintain strong uptime, monitor performance, keep nodes updated, and choose pools/validators with proven operations if delegating.

Jettons (fungible tokens) - standard and model: Jettons follow TEP-74. A Jetton consists of a Jetton Minter (master) contract that defines policy (minting, burning, metadata) and per-holder Jetton Wallet contracts that actually hold balances. Interfaces (e.g., getjettondata, transfer opcodes) are standardised so wallets, exchanges and indexers can interoperate.

Issuing a Jetton (typical flow):

1. Start from a reference implementation (FunC or Tact) and configure metadata (name, symbol/decimals via TEP-64), supply policy, and admin privileges.
2. Deploy the Jetton Minter, passing the chosen Jetton Wallet code as a library cell.
3. Mint by sending messages from the minter to create/credit recipients’ Jetton Wallet contracts; burns are messages to reduce supply. >Official repos provide a production-grade minter and wallet, plus a browser-driven “Jetton Deployer”.

Jetton metadata: Presentation data (name, description, image, decimals) uses TEP-64 Token Data Standard. Creators can store metadata on-chain (cells) or off-chain (URL to JSON). Using the standard fields ensures consistent display across wallets and explorers.

NFTs - standards and contracts: NFTs use TEP-62. Each NFT Item is its own contract; items are typically grouped under an NFT Collection contract that exposes common data and discovery. TEP-62 defines ownership transfer and discovery methods; TEP-64 supplies the metadata schema for both items and collections.

Issuing an NFT collection and items (typical flow):

1. Deploy the Collection with its TEP-64 metadata (name, cover image, base content layout).
2. Mint Items by deploying item contracts that reference the collection; item-level TEP-64 metadata (name, image, attributes) can be set per mint.
3. Transfers are standard TEP-62 messages between item contracts owned by different addresses, which lets wallets and markets handle moves reliably.

Tooling (official and widely used):

• Blueprint - the official all-in-one environment to scaffold, test and deploy TON contracts (supports FunC, Tact and Tolk). It’s the fastest path to stand up Jettons or NFTs and includes testing and scripting.
• Tact - higher-level language with templates, including a TEP-compatible Jetton implementation; docs and the GitHub org provide examples and patterns.
• FunC - low-level language and stdlib for TVM contracts; many reference Jetton/NFT contracts are written in FunC.
• SDKs - TypeScript @ton/ton (ton-core) provides helpers for Jettons/NFTs (e.g., JettonMaster), and TonWeb offers a mature JS library used in many guides and integrations. TonAPI adds REST/SDK access to balances, metadata and transfers.

Good practices:

• Stay within TEP interfaces. If you extend logic (fees, pausing, minter roles), keep TEP-mandated getters and message formats intact so wallets and markets continue to recognise your token.
• Use TEP-64 consistently. Decide upfront whether metadata is on-chain or an off-chain URL and keep the schema stable to avoid broken displays.
• Verify contracts and addresses. Publish minter/collection addresses and code hashes; for fungibles, make the Jetton master address public so users and integrations can validate they’re interacting with the correct asset.

Fragment is Telegram’s official marketplace for collectible usernames and related assets. Sales run either as public auctions or fixed-price deals, and are settled in Toncoin (TON). After purchase, the collectible appears in the buyer’s Fragment account and can be assigned to a Telegram profile, channel or group. Fragment’s help materials describe wallet connection, bidding and post-sale assignment, and confirm that bidding and settlement use Toncoin.

How @username auctions work on Fragment:

• Bidding & settlement: Users log in with Telegram, connect a TON wallet and place on-chain bids in Toncoin; if outbid, funds are automatically returned. Winning a lot transfers the collectible to the winner’s wallet.
• Listing & cancellation: You can list an eligible name and cancel the auction any time before the first bid is placed. Once a bid exists, the auction runs to completion under the stated rules.
• Fees: Fragment states a platform fee (shown on the lot page) applies to completed sales, plus a one-time conversion fee. Treat amounts as platform-provided values that may change; always check the lot’s fee line before listing.
• After the auction: The username collectible can be assigned to a Telegram entity via Fragment; assignment can be changed later by the owner.

Where TON fits: All payments on Fragment are in Toncoin. Separately, Telegram’s ad platform also uses Toncoin for purchasing ads and paying eligible channel owners, with withdrawals handled via Fragment - but ad flows are distinct from username auctions.

TON domain (.ton) auctions:

• Standard & purpose: TON DNS maps human-readable names (e.g., name.ton) to TON resources (contract addresses, ADNL endpoints). The standard is defined in TEP-81.
• How auctions surface to users: Domain auctions are executed by on-chain contracts and are visible in explorers (e.g., Tonviewer “Auctions” pages for specific names). Marketplaces may also surface DNS names as tradable items that reference the underlying contracts. Always verify the domain’s contract address before bidding.
• Paying and finalising: Bids are placed in Toncoin and settled on chain; after the auction ends, ownership of the domain’s contract state is updated to the winner, who can then set records per TEP-81. Tooling and APIs expose DNS ownership and expiry for inspection.

Quick safety checklist:

• Check the official lot URL on Fragment and review fee lines before listing or bidding.
• For .ton domains, confirm the contract address and read TEP-81-compatible records; use a trusted explorer/API to verify current owner and expiration.

The technology behind TON was originally developed at Telegram by Pavel and Nikolai Durov, with plans to launch the Gram token. In May 2020, Telegram publicly announced it was ending its involvement with the project following U.S. SEC action; a court-approved settlement required Telegram and its subsidiary TON Issuer to return funds to investors and pay a civil penalty. The codebase remained open source.

From “Telegram Open Network” to a community-run TON with Toncoin: After Telegram stepped back, independent developers continued the network as The Open Network (TON). Stewardship today sits with the community and the TON Foundation, a Swiss non-profit that supports the ecosystem; the network’s native asset is Toncoin (TON) (not Gram). Telegram does not control the blockchain.

How Telegram relates to TON now? Telegram integrates TON as a platform feature, but remains a separate company:

• Wallet in Telegram offers a self-custodial TON Wallet (keys on the TON blockchain, not held by Telegram) and a separate custodial Crypto Wallet.
• Telegram’s ad platform sells TON-based ads and shares 50% of ad revenue with eligible channel owners; withdrawals are handled via Fragment.
• Fragment runs auctions and sales for collectible @usernames, with settlement in Toncoin.

Bottom line:

• Created by: Telegram’s team (Durov brothers) originated the tech and the “Telegram Open Network” concept.
• Today’s network and coin: continued by an independent community; governed and supported by the TON Foundation; native asset Toncoin.
• Telegram’s role now: integrator and distribution channel, not the network operator or issuer. Telegram products connect to TON but do not control it.