• Back in Q1 of 2018, the Telegram Open Network (TON) secured USD 1.7bn in funding from private investors. However, if TON is not able to live up to its promise and issue the first TON tokens (i.e., Gram) by October 31st 2019, the capital raised will be returned to investors.

  • The launch of the Telegram Open Network marks the birth of the 5th generation of blockchains, with features such as dynamic sharding, “tight-coupling” for blockchain interoperability, and multichain networks (both homogeneous and heterogeneous).

  • Telegram has an estimated user-base of ~500 million users. This broad user-base could immediately turn TON into one of the largest blockchains.

  • However, unlike Libra, there are several key differences between the two very ambitious projects:

    • While Libra’s vision is to reinvent how money circulates across the globe, TON attempts to improve the entire blockchain stack radically.

    • From an economic perspective, TON’s Gram is a utility token or crypto-asset subject to price fluctuations (in fiat). On the other hand, Libra offers a fairly stable alternative owing to its full collateralization with traditional assets.

  • Furthermore, there are a lot of unanswered questions that must be raised, partially owing to the chosen development strategy and a resulting lackluster public scrutiny.

    • Is the proposed scaling strategy going to work and seamlessly intertwine with a radically reinvented general architecture?

    • Can the proposed combination of stakeholders in the byzantine fault-tolerant Proof of Stake consensus mechanism avoid the centralization of its actors?

    • Will TON be able to attract a sufficiently large ecosystem of developers?

With the original launch date coming closer and closer, an in-depth look and summary of the TON project appear essential. In its 524-page whitepaper, TON describes itself as a 5th generation blockchain: a blockchain that is supposedly superior because of its tightly-coupled sharding network with a Byzantine Fault Tolerant Proof of Stake (BFT PoS) consensus mechanism.

This report takes the following structure to shine some light on this potentially game-changing blockchain. After a general introduction to the overall scope and the current status of the project, the three elements of a “5th generation blockchain” are assessed in greater detail. Subsequently, TON will be compared to Libra, and remaining open questions are going to be listed before the report concludes on the exploration of the Telegram Open Network.

1. General introduction

TON is intended not merely to be a blockchain. Instead, the crypto project to gather USD 1.7bn from private investors - more than one-fifth of all funds raised in 20181- wants to build a whole ecosystem around it’s 2.

1.1 The TON Ecosystem

Overall, the TON ecosystem will supposedly comprise of nine different elements, which revolves around its blockchain of blockchains. This obvious centerpiece will be complemented by:

  • State-channel platform: a platform that is initially used for micropayments and off-chain value transfers, including payment for various TON services.

  • A Domain Name System (DNS): a predefined service to generate domain names in a human-readable format (c.f. chapter 4.3.1).

  • A queryable distributed hash-table: this Kademlia-like distributed hash table plays a key rule to locate other nodes in the network (c.f. chapter 3.2).

  • Many additional services: various interfaces for application interaction on browsers and smartphones.

  • A proxy to hide IP addresses of users and nodes for purposes such as privacy and preventing the threat of DDoS attacks (c.f. chapter 4.1.11).

  • A peer-to-peer network: a network user to access the Telegram Open Network, sending transactions, and receiving updates for specific components of the blockchain (e.g., shards) (c.f. chapter 3).

  • A distributed database to store information: it stores copies of blocks and snapshots of data, along with arbitrary files, with a torrent-like approach (c.f. chapter 4.1.8).

  • an interface for external integration of TON: this interface serves to integrate on-chain applications, built on the TON, to integrate into other applications (the most evident being Telegram Messenger (c.f. chapter 4.3.19).

To facilitate the understanding of this set-up, Chart 1 (displayed below) displays the respective interactions between each of these ../components.

Chart 1 - Description of TON: Telegram Open Network


The interface for external integration is of particular interest, as TON is created by Telegram. The integration of non-custodial TON “light wallets” (c.f. Telegram Investor Primer) into the Telegram Messenger could thus quickly build a significant user-base for the platform, comparable even to the previously assessed Libra. While there are no official figures about the current user base of Telegram, an estimation by Binance Research points to a current likely upper bound of 500 million users3.

The intention to integrate the Telegram Chat with TON is clearly stated in an early litepaper, distributed to initial investors (i.e., Telegram Investor Primer):

“Telegram-TON integration will provide a clear path to cryptocurrencies for millions of people. Telegram Messenger will not only serve as an example of the possibilities offered by integrating with TON, but will also add unique features to the TON platform, leveraging Telegram’s massive user base and developed ecosystem4

1.2 Turning whitepaper pages into code

As of today, there has not been much information on who exactly is attempting to make this ambitious product suite available to the general public. Based on data collected by Binance Research, at least thirteen other programmers have been working on TON, in addition to the two brothers Nikolay and Pavel Durov.

There is not much known about the team, which makes it difficult to judge their prior engagements and track records in cryptography and distributed systems. Nonetheless, there exists circumstantial evidence that indicates that many TON engineers have already been working for Telegram5.

As a result, the same engineers6 are likely to have derived Telegram’s encryption protocol: the MTProto. Instead of using a well studied, provably secure encryption protocol, the MTProto is a “homebrewed” encryption protocol. This very unusual strategic decision, in turn, violates against the first rule of cryptography, which strongly recommends to “never roll your own crypto”.

While this principle is probably taught in every introductory lesson to cryptography7 and generally considered best practice8, Nikolay Durov has a strong academic track record in a field closely related to cryptography. So far, Telegram has not been subject to any real security leaks, there are, however, already several identified theoretical weaknesses and potential attack vectors9.

The next subsection will discuss the current status of the Telegram Open Network, along with its native cryptocurrency: Gram.

1.3 Current status of TON & GRAM

On September 7th 2019, the source code for the TON blockchain was released. Since then, it has been possible to run a full node, validator node, and use the block explorer of the testnet10. Other than that there is (1) a general whitepaper on the Telegram Open Network, (2) a whitepaper on the blockchain, (3) a whitepaper on the virtual machine, (4) a whitepaper on the language used by TON’s smart contracts and a last whitepaper, supposedly describing the details of the consensus mechanism that has been announced, yet not published.

Not regarding the fact that the eventual 5 billion Grams do not yet exist, some of the early investors started trading their Gram placeholder tokens. Curiously, the leaked simple agreements on future tokens (SAFTs)11 explicitly state that the sale of Gram placeholder tokens is not allowed and will forfeit any future claims to Gram.

If the terms of the SAFT are thus upheld, this could imply that neither the old nor the new owner has any longer a claim towards Grams. Irrespectively, it is, of course, possible - but unlikely - that special agreements between the initial investor and Telegram have been agreed upon which would allow for an early sale.

An important point to notice is that the initial offering was conducted under an exemption for security issuance (i.e., Rule 506C of the US Security and Exchange Commission (SEC)) that is essentially building on the fact that all purchasers are accredited investors. While this is generally easy to ensure in a restricted, private sale to wealthy individuals, it is much harder to ensure in a public sale.

The trades themselves have been executed in two different forms. Some individuals were trading IOUs over the counter (OTC), and others were trading placeholder tokens, issued by the exchange Liquid in cooperation with GramAsia12.

  • The OTC traded IOUs are essentially informal agreements between two parties stating that one party owes the other a debt for something it has already received (i.e., “I owe you”). These trades are entirely based on trust put into a reputable individual (i.e., the seller).

  • Fundamentally, platforms offering an IEO of these placeholder tokens (e.g., Liquid) are no different than that. The main distinction is that the counterparty of the trade (i.e., the seller) is an exchange platform instead of a private individuum. Investors bought a token that will be used to allocate Grams to placeholder token owners.

According to publicly available information, the earliest investors were already able to sell potential Grams at a premium of almost 1000%.

Unlike early investors, recent buyers now have to worry about three things:

  1. Gram might not be issued at all: the mainnet may not launch before October 31st.

  2. The trusted counterparty of the trade might decide to not follow through with the delivery of Gram.

  3. The counterparty of the trade might not be able to follow through, because they acted against the terms and conditions declared in the SAFT13. The next section will discuss in-depth characteristics of 5th generation blockchains, relying mostly on the information provided in the detailed whitepaper of the Telegram Open Network.

2. Under the hood of “5th-generation” blockchains

2.1 Overview of the different generations of blockchains

The “generation” of a blockchain can be assessed by two overarching criteria: the deployed consensus mechanism and the addition of at least one new element. A preliminary overview could hence take the following shape, depicted in table 1.

Table 1 - Key characteristics of each blockchain generation


Main consensus

New elements

Key blockchains

1st generation




2nd generation


Smart contracts

Ethereum 1.0

3rd and 4th generations

PoS, dPoS, BFT PoS

Blockchain interoperability (with loose coupling) Multichain networks (heterogeneous)

Ethereum 2.0 (tentative), Bitshares, EOS, Polkadot, Cosmos

5th generation


Sharding (dynamic) Blockchain interoperability (with tight coupling) Multichain networks (homogeneous and heterogeneous)


Consequently, TON will not only support sharding but a whole utility suite that incorporates elements from previous blockchain generations.

2.2 General utility

Like most of the programmable blockchains, the Telegram Open Network will support a virtual machine (i.e., Telegram Virtual Machine) that will run on nodes and allows for the execution of smart contracts. Similar to Ethereum, this allows for distributed, “sandboxed” execution environments.

The smart contract language itself (i.e., Fift) is a stack-based general-purpose language, similar to Forth. Fift is compiled into bytecode and executed on the TVM. Being a mixture of an interpreter and a compiler, Fift is some hybrid language, which most likely does not require a lot of hardware support. Curiously, Fift uses a special notation (i.e., Reverse Polish notation) that is not widely used by many programmers.14

In an apparent attempt to reverse this trend and foster a respective programming community, Telegram has started to announce programming competitions. Its most recent is targeted towards implementing several smart contracts, TVM improvements, and offers Telegram blockchain bug bounties. While Fift may still be an unusual choice, there might eventually be also several alternatives15. TON intends, after all, to support multiple other languages, as long as they will have static types and support algebraic data types.

TON’s general architecture is unique and very catered towards supporting scaling. With the far-fetched goal of being able to support , TON does not only set an extremely ambitious goal post but seems to exceed industry demand by 1000 orders of magnitude. In comparison, one of the busiest payment networks worldwide, Visa, averages out on 1,700 transactions per second16.

However, it is worth mentioning that a) TON intends to scale upon demand and will not attempt to start with millions of transactions and b) wants to have more use cases than financial transactions. Irrespectively, chart 2 illustrates the divergent ambitions quite clearly.

Chart 2 - (Projected) capacity of tx per second of various databases (in thousands)


Source: Binance Research

2.3 Consensus finding

All previously mentioned elements are complemented and rooted in the consensus mechanism. A mechanism that has to support scaling and, as synchronous consensus mechanisms require timing margins of safety, slowing down state agreements, be asynchronous.

For this reason, an asynchronous Proof of Stake (PoS) variant has to be deployed17. The TON whitepaper lays out the decision-making process behind the choice and compares delegated PoS to the chosen Byzantine Fault Tolerant (BFT) version of PoS. Unfortunately, the whitepapers lack detail in describing the actual implementation thereof:

“Some subjects have intentionally been left out of this document. One is the Byzantine Fault Tolerant (BFT) protocol used by the validators to determine the next block of the masterchain or a shardchain; that subject is left for a forthcoming document dedicated to the TON Network.”18

As this forthcoming document has not yet come forth, the only details provided of the deployed consensus mechanism are in a general chapter on validators (TON whitepaper 2.6.7 ff.) and a high-level assessment that compares practical BFT to delegated Proof of Stake (see section 2.8.4 of the TON whitepaper).

As the deployed consensus mechanism is one of the most critical components of any blockchain, this lack of detail is concerning. The details of the implementation would be particularly interesting, as this would be the first project to operate BFT on a permissionless network19.

While permissioned blockchains can be operated via some proof-of-authority mechanism, permissionless blockchains typically require an economic incentive system. The related work on Casper, the proof-of-stake implementation of the permissionless blockchain Ethereum has, for example, been continuing for already more than two years and is still not concluded20.

Other than that, especially three elements are worthy of a closer inspection, as they are the key differentiating factors between TON and similarly ambitious projects. These distinct, yet very interlinked factors are:

  • the support for both heterogeneous and homogeneous blockchains.

  • sharding on demand.

  • a tight coupling of blockchains.

The next subsection describes sharding and these sub-elements in-depth, with an application to the Telegram Open Network.

2.4 Sharding

2.4.1 General overview of sharding

The high-level idea of sharding is to split databases (which includes distributed databases, i.e., blockchains) into multiple, independently valid pieces: shards. The database is thus primarily split into rows, not columns. As a result, every shard consists of all the required data.21

Sharding can be either done according to a predefined structure or dynamically, where transactions on shards (in TON called “messages”) can initiate events on other shards. Ton opts for the latter variant.

Generally speaking, TON opts to consequently shard the entire database until the account-basis. All singular shards are then constantly rearranged in a bottom-up fashion to eventually form blocks in up to 2^60 shardchains, which are the shards of up to 2^32 workchains ultimately validated in one masterchain.

Chart 3 - Stylized structure of the TON blockchain network


Source: Binance Research

As a result, the masterchain contains hashes of all masterchain, shard- and workchain blocks.

It defines some global properties that must be adhered to in all shards thereof, creates settlement finality by using a BFT PoS consensus mechanism and keeps track of information such as the active validators and their current stakes.

Workchains are only “virtual” blockchains, as they are a collection of underlying shardchains.

2.4.2 Multivariate blockchains and a tight coupling thereof

Consequently, every workchain can contain local rules that may govern the format of account addresses, transactions, virtual machines, native cryptoassets, and the like. Workchains are therefore heterogeneous (i.e., different), while shardchains are homogenous (i.e., equal).

The “tight-coupling” of the TON blockchain network describes a scenario where multiple homogeneous shardchains of heterogeneous workchains can interact with each other seamlessly. This feature is crucial to maintain interoperability and support a vibrant network of purpose-built blockchains. It can be facilitated by standardizing the format of the interactions and the location of input/output queues thereof.

The tight coupling of blockchains also sets the foundation for a “mesh network” for fast transactions - the Instant Hypercube Routing (c.f. 2.4.20). The idea of hypercube routing has already been explored academically, yet was until now never implemented in a blockchain.22

At the prospective launch of the masterchain, there will be only one workchain, the Telegram Open Network workchain. It will use Fift to write smart contracts, TVM to execute them, and uses Grams as a native asset thereon.

Workchains will be created by submitting a particular transaction to the masterchain. As a means to prevent Sybil attacks, masterchain transactions have significant transaction costs and must be approved by a supermajority of validators (i.e., 2⁄3rds of all validators).

2.4.3 Integrating sharding and consensus

With a better understanding of the blockchain network architecture, it is possible to revisit the previously introduced consensus mechanism.

There are four different actors involved in the validation of transactions, all depicted in table 2.

Table 2 - Stakeholders in the blockchain network



Economic incentive



Full node

Validation reward

Validate blocks


Full node

Partial payout of slashed stake of false validators

Masterchain tx to publish invalidity proofs



Partial payout of validation reward

Provide validator with capital



Partial payout of validation reward

Point out shardchain block candidates

The most important actors, validators, can become a validator by locking Gram in a smart contract address. With initially lower loads it is expected that 100 validators (later up to 1000) are elected via a smart contract that takes into account multiple factors, such as all submitted stakes and the maximum acceptable load per validator (c.f. Chapter 2.6.7).

The global set of validators validates blocks on the masterchain. The global set of validators is, however, split into multiple validator task groups in a pseudorandom deterministic fashion to match the number of shardchains.

As validators must operate full nodes tracking the complete state of the respective shardchain, it is necessary to inform them before the validation period. This allows them to set up a full node. Otherwise, the load would be too high for validators.

After the currently projected one-hour long validation period, validators are reallocated to a new shardchain.

Once a block candidate gathered 2/3rds of all votes, it is eligible for commitment as the next shardchain block. This is supposedly done in the adapted BFT PoS fashion. After “(almost) all” (not described in detail) shardchain blocks have been finalized, a new masterchain block can be submitted that includes all shardchain block hashes.

To facilitate the work of validators and decrease the often-mentioned risk of an increasing centralization in a PoS-based consensus system, multiple other actors are involved.

  • So-called “Fishermen” can publish a masterchain transaction that includes an invalidity proof and the respective Merkle tree hash to receive a partial payout of slashed stake of false validators.

  • “Nominators” can vote for a validator by providing the validator with some of the Gram denominated capital that is required as stake. By acting accordingly, they are made accounfor the validators’ decision: they may receive a part of the validation reward, but may also lose a part of their capital in case the validator’s stake is slashed. These actors are comparable to miners organizing in a mining pool.

  • The last actor group are the so-called “Collators” who may point out shardchain block candidates to receive a partial amount of the validation reward.

It is to be seen whether the above set-up is indeed sufficient to avoid an even further centralization of the ~ 1000 validators. This will most likely also depend on the actual implementation and the distribution of partial payouts.

Either way, the respective set-up is likely to facilitate block validity and is somewhat similar to set-ups of validators and inspectors commonly found in permissioned networks such as Corda and potentially found in permissionless networks like Ethereum 2.0.

3. TON vs. Libra Blockchain

3.1 General analysis

There is an obvious comparison to be made between TON and Libra (as a blockchain). Both are created by a parent company with a significant user base. Both want to leverage that user base for adoption. Both have significant assets to support the production of their new products. Both are ambitious, visionary projects. Both are clashing with the original Bitcoin ideology, due to fears of being too centralized. However, there are many differences between the two projects and their general strategy.

While both projects are visionary, Libra attempts to create a new use case for money, while TON aims to radically advance the entire blockchain stack.

The two projects showed very different approaches in their attempt to engage with a broader audience. The results of this diverging strategy are already visible in, for example, the respective Github repositories23. According to publicly available data from Github, Libra has 80 direct contributors and more than 22,000 external contributors, while TON presumably has 15 contributors and 8 known external contributors. The same trend holds when assessing already developed third party services24. This may also be due to the fact that the Libra source code is well documented, whereas hardly any documentation exists for the Ton testnet.

In an apparent attempt to foster the adoption of TON, Telegram recently started a coding challenge that awards up to USD 400,000 to the winner. The winner has to build at least one multi-signature contract, suggest improvements for a Fift compiler and find issues and fixes of the TON testnet25.

In terms of prospective go-live dates, the two projects also diverge. While TON has to be released before the 31st of October 2019, there is no such explicit deadline for the release of Libra. Nonetheless, it is generally expected that Libra will be launched in 202026.

The next subsection discusses the economic analysis of both Libra and Gram, the token of the Telegram Open Network.

3.2 Economic analysis

The initial price of Grams sold in the two private sales was defined in a USD denominated cost function27. The average price of Grams sold in the first round is set at 0.38 USD, while the price of the second round rose to 1.33 USD. Another cost function defines the primary market price for additional Grams issued in the future (c.f. appendix 4.4.).

The current market price for Gram (i.e., the latest price paid on Liquid) is set at 4 USD. As the original supply of Gram is set to 5 billion units, the respective total market capitalization is set at 20 billion USD. Staking rewards will lead to an annual inflation rate of 2%, or 400 mn USD per year, at the current valuation.

Unlike Libra, Gram is not a currency, but a utility token. Therefore, there is no reason for the price of Gram to be fixed at a certain level. The respective secondary market value will thus fluctuate according to supply and demand. Nonetheless, a Ton Reserve may repurchase Grams to reduce the total circulating amount and thus attempt to increase the price.

As Gram is a utility token, it can also be used for several use cases:

  • Staking requirements: it is required to stake Gram to validate blocks.

  • Transaction fees: to submit a transaction to the masterchain and Ton workchain a Gram-denominated fee is due. Other workchains might instead require transaction fees denominated in their “native cryptoasset”.

  • Gas payments: in a similar fashion to Ethereum, interacting with a smart contract requires the payment of processing fees due in Gram.

  • Storage payments: when storing something in persistent storage, a fee accrues in Gram.

Because the use cases of Gram and Ether are reasonably similar (especially in Ethereum 2.0), it is possible to deduce a likely legal classification of Grams. Adopting the position of the SEC, Ether is likely to not classify as a security “when putting aside the fundraising”.28 This would render Ether a crypto asset29.

As the fundraising of TON was covered via an SEC exemption and Grams have similar use cases as Ether, Grams are thus likely to be classified as crypto assets.

This classification may create short-term benefits for TON, as the respective legislation is often-times still absent or only just being created. Subsequently, short-term opportunities for regulatory arbitrage may exist. Furthermore, regulation is likely to eventually be tailored to crypto-assets, potentially bridging fundamental gaps between existing regulations and new asset properties.30

On the other hand, Libra has a much more restrictive use-case: it is to be used as a currency and aims to remain price-stable. It is projected to realize that goal by collateralizing it with fiat currencies, and short-term government debt securities and its exact reserve breakdown were released recently31.

3.3 User analysis

Due to the lack of official up to date figures, Binance Research had to make an educated guess about the current user base. By using an official figure from March 2018 and statements made by Pavel Durov, it is possible to estimate the current amount of users. The respective figure is treated as a likely upper bound.

Table 3 - Methodology for estimating Telegram users








Total users

March, 2018



Daily user growth

Telegram Investor Primer - "at least 500 000 new users join Telegram daily"

February, 2018



Daily user growth

Pavel Durov, Telegram - "I see 3 milliuon new users signed up for Telegram within the last 24 hours"

March, 2019



Daily user growth

Chosen as lower bound for daily growth

Sep, 2019



Days with known growth

Roughly 520 days have passed after the statement about the official statement about Telegram reaching 200 mn users was released.

Sep, 2019



Total users added

Calculating "520 x 500 000" leads to 260 mn users.

Sep, 2019



Upper likely bound

Adding 260 000 000 suspected new users to 200 000 000 initial users leads to 460 000 000 users. Accounting for an increasing influx due to increased network effects and accepting some level of inaccuracy inherent to such educated guesses leads to an upper likely bound of 500 000 000 users.

Sep, 2019

According to the methodology presented in Table 3, Telegram has approximately 500mn users. Facebook alone, on the other hand, reportedly has 2.4 billion of users, which represent approximately 5 times as many as Telegram32.

4. Open questions

The team working on TON, under the lead of Nikolay Durov, has to come up with some answers to currently still open questions.

Can they launch before October 31st?

First and foremost - can they ship before October 31st and implement all the technical features laboriously described on over 500 whitepaper pages in a bulletproof manner?

Will they be able to build a developer community around TON?

Unlike other popular blockchains (e.g., Polkadots or Selenia), the development has been taken place in a completely isolated manner. While some code has been released publicly on Github, its development thereof remains in a silo and intransparent. As a result, it is difficult to understand design and architecture decisions which may make it harder to identify potential attack vectors.

At the same time, several entrance barriers for developers have been well defined and can pose a severe challenge to the adoption of new blockchains. In the case of TON, some of the multiple challenges are, a currently very unpopular and poorly documented programming language, a very small developer community and an overall new architecture, which is hard to understand for external parties.

Not only is the existing developer community small, but also does circumstantial evidence point towards a clear regional dominance33. As TON intends to be a new global standard, a more diverse community could be helpful.

Instead of a wide, open community that may benefit by network effects and saliently participate in a governance process, there is thus a risk of TON having a small and homogenous (i.e., centralized) developing scene.34

Additional technical questions

As of now, it remains unclear to Binance Research to what extent transactions could be private. Could Pederson-Commitments be implemented to reduce the need for data storage35? Is the infinite sharding paradigm going to work? Superquadratic sharding is, after all, only one out of several well-known problems of sharding and has been so for a substantiated amount of time. Lastly, the jump towards millions of transactions per second seems hard to reconcile with practical reality (even Alibaba merely has peaks of hundreds of thousands TPS) and a distributed consensus of nodes that are potentially spread globally.36

5. Conclusion

If successful, the Telegram Open Network will make considerable advancements in the area that has been the most significant pain point for the blockchain ecosystem: scaling of a decentralized database. In combination with a permissionless BFT PoS mechanism, the infinite sharding paradigm would solve many scalability issues. However, TON still raises multiple concerns.

Like most PoS based blockchain networks, TON appears to be vulnerable to centralization. The small and homogeneous developing scene could aggravate this tendency.

Considering the amount and sheer scale of the problems that may be solved by TON, open development of the source-code would also be more than warranted. While the whitepaper documentation is very extensive, it appears to predominantly be a logically consequent set-up. It is, however, not describing the actual implementation thereof. An openly developed source-code would allow anyone to validate their claims and point out potential security loopholes. The absence of any such communication is a clear warning sign. On the other hand, this could also represent a working style; a preference rooted in the core development team.

Lastly, it could be possible that the TON developing team might be forced to launch a minimum viable product. The easiest way to make compromises in such a distributed system is to replace essential elements such as the consensus mechanism with a centralized administration37.

Irrespectively of any concerns, one thing rises above: Telegram has something each project in the crypto-ecosystem desperately seeks: users.

If TON eventually launches along with a user-friendly Telegram Messenger implementation, Telegram users will likely adopt, consciously or not, TON and its underlying crypto asset: Gram. This possibility, by itself, would certainly be enough incentive for any developer to dig into the TON ecosystem, and jump over any initial entrance barrier.

In case this scenario occurs, blockchain will enter into its next generation and become a real backend technology ready to power many decentralized applications for millions of users.


  1. Based on calculations by Binance Research, TON raised 21.8% of all funds raised during 2018.

  2. See https://test.ton.org/ton.pdf.

  3. Also refer to Chapter 3.3. of this report.

  4. For further information on the (leaked) primer please refer to: https://drive.google.com/file/d/1ucUeKg_NiR8RxNAonb8Q55jZha03WC0O/view

  5. This is true for the individuals listed by ICOholder.

  6. While this may be a simplification, it is true for at least Nikolai Durov who was one of the main authors behind MTProto.

  7. This is, for example, the case in Dan Boneh’s Cryptography course at Stanford. For more information on why this is violating best practice of cryptography see for example: [1],[2],[3].

  8. Less colloquially, this is known as Kerckhoff’s principle.

  9. For known issues of Telegram’s encryption protocol see, for example: [1] [2] [3].

  10. https://test.ton.org/testnet/last

  11. Coindesk obtained parts of the original SAFT’s: https://www.coindesk.com/alive-thriving-and-totally-unauthorized-inside-the-underground-market-for-telegrams-cryptocurrency

  12. Updated: Liquid cancelled its sale of Gram token in the beginning of 2020.

  13. For further information see Coindesk (2019).

  14. A closer inspection is required for a full analysis of Fift. This assessment is predominantly based on previous assessments of Forth, such as: [1], [2], [3].

  15. Three types of programming languages are mentioned in the whitepaper: “A Java-like imperative language”, with each smart contract being similar to a separate class, a lazy functional language (such as Haskell) or an general-purpose functional language (think of ML).

  16. Visa states VisaNet handles around 150million transactions per day, which translates into 1736 transactions per second. Source available here: https://usa.visa.com/run-your-business/small-business-tools/retail.html On another occasion they apparently updated their figures to indicate that they could support up to 56 000 transactions per second. Source available here: https://usa.visa.com/about-visa/visanet.html

  17. For further information on asynchronous consensus and BFT please refer to: http://pmg.csail.mit.edu/papers/osdi99.pdf

  18. It is possible that the respective quote was not deleted from a previous version. A paper on the TON Network does exist after all. It is anyhow curious to see the high level of detail for minor added value services and the relatively scarce documentation for the crucially important BFT PoS consensus mechanism.

  19. The permissioned blockchain Hyperledger Sawtooth, for example, already makes use of pBFT.

  20. While the Github repository on Ethereum/Casper was already opened in 2014 the first commit only occurred in 2017.

  21. In order to find answers to frequently asked questions in regards to Sharding please view: https://github.com/ethereum/wiki/wiki/Sharding-FAQ

  22. To the best of Binance Research’s knowledge. Some previous explorations of the idea are as follows: V. Buterin briefly explored Hypercube Routing [1], academic papers have been published [2], [3], [4].

  23. The Libra repository has many more pull requests and an open issue tracking. For more information please refer to: https://github.com/libra/libra and https://github.com/ton-blockchain/ton.

  24. There are only a handful of third-party services for TON. Binance Research is aware of an API for a wallet, Go and Python wallet wrappers, another Python litecoin client and a block explorer API.

  25. Details for the coding challenge are available in respective Telegram groups such as “Telegram Contests”.

  26. Further information available here: https://www.engadget.com/2019/06/18/facebook-calibra-libra-cryptocurrency-digital-wallet/

  27. The cost of the n-th Libra is: p(n) ≈ 0.1 · (1 + 10−9 )^n

  28. The general framework of Hinman (2018) was confirmed by SEC Chairman Clayton in March, 2019.

  29. ECB (2019 & 2019). “There is currently no universally agreed definition of what constitutes a crypto-asset but the ECB has defined it for its own analytical purposes as “a new type of asset recorded in digital form and enabled by the use of cryptography that does not represent a financial claim on, or a liability of, any identifiable entity.”

  30. For further information, please refer to ECB Occasional paper #223.

  31. For further information, please see: https://www.reuters.com/article/us-facebook-libra-basket/u-s-dollar-to-be-main-currency-underpinning-facebooks-libra-spiegel-idUSKBN1W522K

  32. For further information, please refer to: https://www.bloomberg.com/graphics/2019-facebook-libra-world-banking/

  33. This conclusion is based on circumstantial evidence from the Telegram group “TON Research” where Russians seem to be the dominant faction.

  34. Also see C. Weck (2019) in a medium article that started a conversation on open questions of TON.

  35. Visit Binance Academy to learn more about MimbleWimble. https://academy.binance.com/blockchain/what-is-mimblewimble

  36. For further information see Hackernoon (2017).

  37. This point has been brought up by D. Gerard (2019) in a blogpost.