TON is The Open Network: infrastructure for accounts, smart contracts and messages whose state is agreed by validators. Telegram is a messaging platform through which people may encounter those applications. A wallet is another component, responsible for presenting balances and authorizing transactions. Keeping those identities separate makes it easier to understand which organization or piece of software is responsible when a payment, application or login behaves unexpectedly.

Names require special care in this archive. Current TON documentation calls the native currency Gram, with ticker GRAM. Blockchain.com's July 2026 support notice describes Toncoin's rename and says existing balances, addresses and transaction history stay unchanged, without a user swap or migration. Historical articles and market-provider records may still say TON or Toncoin. Those labels describe continuity of the native asset; a separately issued token with a matching logo or ticker does not establish that identity.

TON Connect provides a communication interface between applications and compatible wallets. A connection request and a transfer request serve different purposes. An educational interface should explain the particular permission or transaction being requested, rather than treating connection to a familiar messaging app as a guarantee about everything an application might subsequently ask the wallet to do.

The original Telegram project had a specific legal history. The SEC's June 2020 settlement announcement describes the 2019 enforcement action, the March 2020 preliminary injunction and a resolution requiring more than $1.2 billion to be returned to investors alongside an $18.5 million penalty. Telegram and TON Issuer settled without admitting or denying the complaint's allegations. Those proceedings concerned the original offering and distribution scheme; they are not a blanket classification of every later asset or application using the TON name.

A June 2021 open letter from the independent developer community describes maintaining and updating Telegram's original testnet2 after the company's withdrawal, and requests stewardship of the project's repository and domain. It is a contemporary account by participants, while the SEC record documents the enforcement outcome. Today's Telegram Mini App rules establish a later integration relationship. Read these artifacts together without collapsing the original issuer, subsequent developers, current network validators and today's app operators into one interchangeable entity.

A shared technical lineage does not make their contracts, responsibilities or business arrangements identical.

TON organizes work across workchains and shardchains. The masterchain carries network-level configuration, while the basechain hosts ordinary accounts and applications. The sharding design divides account ranges and permits changing how work is distributed as load changes. An individual account still has its own state and transactions. The architectural goal is to distribute processing rather than require every application's entire workload to fit through one permanently fixed execution partition.

A user-visible operation may involve several contracts exchanging messages. An explorer's trace follows the causal chain between those messages and transactions. Imagine a wallet initiating an exchange: seeing the wallet's first transaction is not, by itself, the same observation as seeing the recipient receive the desired output. Following the whole trace reveals where processing continued, failed or generated another message. That distinction matters to support teams and developers interpreting what a completed operation means.

The word infinite in the sharding vocabulary describes the design's expandable partitioning scheme. The documentation also explains finite block capacity and queues between shards. A network's transaction benchmark therefore needs its workload, hardware and completion criteria; a capacity slogan alone cannot establish that every complex application will have the same latency under all conditions.

Jettons are fungible tokens implemented by contracts on TON. Their architecture includes a master contract and separate wallet contracts for holders. Payment integration must establish that an incoming notification comes from the expected wallet associated with the expected master. Looking only at a token's displayed name, a reported balance or a message saying transfer is insufficient: another contract can imitate those superficial details. This is why a native currency and a similarly named Jetton must remain distinguishable in a wallet or encyclopedia.

Fees have multiple components. Storage charges relate to keeping account data, computation charges pay for execution, and message-related charges cover forwarding and actions. Network configuration determines the parameters. For an application performing several steps, the practical question is whether the operation funds all required processing, rather than whether the first screen quotes a small average transaction fee. Reviewing the trace and fee breakdown can explain why a contract interaction costs more than a basic transfer or why a failure still consumed resources.

Telegram's blockchain guidelines require qualifying Mini Apps to use TON for issuing or distributing blockchain assets and TON Connect for wallet interactions. The document distinguishes Mini Apps from ordinary bots without a Mini App component, and it provides specific exceptions and examples for bridging and multichain wallets. This is a concrete distribution policy, not merely an informal endorsement. Developers need to read the actual scope before assuming that every bot or every cross-chain interaction is governed identically.

Telegram Stars are also distinct from the native blockchain currency. Telegram's developer terms prescribe Stars for digital goods and services in the relevant platform flow. A diagram that labels every in-app payment as an on-chain TON transaction would therefore be misleading. Separately, Telegram reserves control over platform access and service changes. An application's smart contracts may remain accessible on a blockchain while its main discovery or user-interface channel changes.

Assessing the ecosystem means examining both blockchain execution and the platform through which users arrive.

TON's official channel describes wallets, in-chat services and blockchain games as ways to introduce Telegram users to blockchain applications. Its ambition of bringing 30 percent of Telegram's users to TON by 2028 is a target in that ecosystem narrative, not an achieved adoption measurement. The channel presents familiar social and gaming interfaces as an introduction to blockchain applications.

Our research approach asks what remains after the introductory incentive ends. Useful follow-up evidence would include returning users, repeat transactions with a stated purpose, support outcomes and independently reproducible activity measurements. Registrations, addresses, game participants and people are different units. Likewise, several messages in one trace can represent one user operation. Record the unit, time window and method alongside any growth chart so a change in counting conventions is not mistaken for growth in actual use.

This chapter documents a substantial distribution opportunity alongside its dependencies. It makes no inference from audience size to a guaranteed token price. A persuasive future update would connect application demand to observable network activity and explain how platform rules, user retention and operational costs affected that result.

TON's Elector contract organizes elections, distributes rewards and handles complaints about validators. Its configuration machinery also makes protocol governance more specific than a general promise of community control. Configuration proposals require sufficient validator voting weight over the prescribed rounds; important parameters can require additional rounds. The documentation records that the Foundation's temporary emergency key was retired on November 22, 2023, at masterchain block 34312810.

That historical recovery mechanism should not be described as a presently active Foundation override. Conversely, retiring one key does not establish that every influential institution or validator has equal practical power.

The masterchain configuration is part of the state used to validate blocks, not merely a settings page maintained by a website. Its parameters govern such matters as validator limits, storage charges, network capabilities and consensus timing. Changes take effect through defined state transitions, and critical parameters have stronger voting requirements. The current documentation identifies configuration parameter 30 with the Simplex-based Catchain 2.0 consensus path and distinguishes it from the legacy path.

When judging a claimed upgrade, the useful evidence is the relevant configuration and implemented behavior, rather than a token holder poll being mistaken for validator approval.

TON's integration guide states that Catchain 2.0 is live on mainnet as of April 9, 2026. It gives an approximate 400-millisecond block interval and a roughly one-second finalization lag. These are different measurements. A wallet can still appear slow if its indexer falls behind or its interface polls infrequently. The guide distinguishes pending, confirmed and finalized results, and describes trace invalidation. It specifically warns that some confirmed balance subscriptions lack an invalidation signal.

Applications handling balances therefore need a deliberate finality policy; showing an early notification is not equivalent to establishing a settled result.

The preceding v2026.04 software release is a separate dated artifact. Its notes include protections against excessive network traffic and external-message overload, alongside fixes and acknowledgments of security contributors. Those operational details matter because a network advertised for mass use must also process hostile or wasteful inputs. A published release establishes what maintainers shipped, not that every operator immediately installed it. Here the subsequent integration documentation supplies the mainnet-state claim.

Keeping the two records separate prevents a common historical error: assigning a protocol activation date solely from the date a downloadable node version appeared.

The single-nominator contract separates a cold owner's control of staking funds from the hot validator key used in operations. The hot key can participate in validation but cannot withdraw the owner's funds. The documented design also gives the owner recovery actions, the ability to replace the validator address and, in extreme circumstances, code-upgrade authority. This is intended for a validator's own stake rather than automatically being a suitable arrangement for many unrelated depositors.

Evaluating a staking service requires its actual contract and authority model; the word noncustodial does not describe every operational power or withdrawal condition.

TON wallet guidelines describe another recovery complication: a signing key can correspond to several wallet-contract addresses. Finding one balance does not prove that an importer has discovered every account the user previously controlled. The guidelines also distinguish TON's mnemonic derivation from BIP-39 despite their shared word list, and advise implementations about ambiguous imports. These are interoperability requirements for wallet developers, not evidence that every existing wallet implements every recommendation.

For the reader, the important distinction is between recovering a key and correctly locating the contracts and assets associated with that key across different wallet versions.

Tonkeeper's Wallet V5 design introduces extension mechanisms, message batching and a route for sponsored transactions. In the described gasless flow, a service pays the network's native fee while charging the user through another asset. Costs move between participants rather than vanishing. Extensions can also change the authorization experience, including recovery or additional authentication arrangements. The repository discusses failure cases and sequence-number races for service operators.

A convenient wallet therefore remains a collection of contracts, permissions and operational assumptions that deserves review, not a universal exemption from native fees or transaction failure.

A smaller proposal by arghaffari shows how much of adoption depends on intelligible records. The August 2025 issue requests a notification to the account whose jettons were burned, so wallets can display the event in their histories. This is a request to improve user feedback, not proof that the proposed message became a universal token standard. It also illustrates a useful distinction between an operation occurring onchain and a person being able to understand it in their wallet.

Open standards discussions can expose that gap before a misleading interface becomes a routine source of confusion.

The GRAM name attracted a recognizable historical-identity argument in the July 2026 r/BingX discussion. AdministrativeBed418 welcomed a return to the project's roots, while Creative-Elephant-37 pointed to the persistence of the old name in everyday habits. These comments establish individual reactions to a rename, not a representative survey of holders. The thread appears beneath an exchange's promotional explanation, which is another reason to distinguish participants' hopes from independent evidence of economic improvement.

Familiarity, distribution and technical usefulness can matter to people without a new ticker itself proving any increase in them.

Developer support has also faced criticism from within the audience the network needs to attract. In an archived Reddit account, subnohmal says an unexplained exclusion from developer chats undermined their willingness to continue building after investing in learning TON. The account is a participant's allegation, not an independently established finding about the Foundation or present moderation practice. Its relevant argument is narrower: documentation and accessible support channels are part of a developer's cost of choosing a platform.

Technical openness alone does not answer whether newcomers can obtain explanations, challenge decisions or maintain an application without personal access to moderators.

The original TON channel's June 10, 2026 notice records a completed name-change vote, open from June 1 to June 8, and reports 81.22 percent support. It sets June 15 at 12:00 UTC for the coordinated rename from Toncoin to Gram. The notice explicitly keeps The Open Network's identity and existing balances, addresses and contracts intact. Its stated change concerns branding, not a replacement asset that holders must claim or bridge.

A separate institutional record shows how that name appears in brokerage distribution. The current 21shares Gram Staking ETP page lists ticker GRAM and ISIN CH1297762812, offering exposure through a bank or broker. It records March 26, 2024 as the product's inception date; that is not the date of the later currency rename. The issuer describes staking yield as accruing to net asset value, with fees and investment risks. Owning this security is different from holding the native currency in a wallet.