This article was created in collaboration with Roman Krutovoy and Pavel Shuvalov (TON Foundation), Kirill Emelyanenko and Anatoly Makosov (TON Core), Andrey Tvorozhkov (DTon), Alexey Kostenko and Rostislav Rudakov (TON App), the TokenTable team, Sergey Chikirev (Notcoin), Andrew (DOGS), and others.

In 2024, TON witnessed a wave of massive airdrops that broke records for scale and speed in the crypto industry. Among these, the DOGS token reached more than 10 million on-chain wallets on TON. For comparison, the most distributed airdrop on the Solana blockchain had five times fewer recipients.

Executing such a massive token distribution presented complex technical challenges. The platform faced numerous questions:

• How can TON projects distribute tokens efficiently on a massive scale and in a short timeframe?
• Can TON withstand such an enormous load?
• How should TON projects manage the transaction fees for millions of token transfers?

These questions are crucial for the goal of mass adoption. TON needs to work smoothly at a scale that no other blockchain has reached before.

The journey of mass minting on TON has been anything but ordinary. From the stormy launch of inscriptions in December 2023 to the modern Mintless Jettons approach, it’s a story of sleepless nights, painful lessons, and great progress. How did this journey unfold? Let's explore this story in several parts:

• Introduction: Where did we start?
• Part 1: Inscriptions ("the stress test")
• Part 2: Notcoin and Mass Sender (the "sending" approach)
• Part 3: DOGS and TokenTable (the "claiming" approach)
• Part 4: Hamster Kombat and Mintless Jettons (the "mintless" approach)
• Conclusion: Where are we now?

Introduction: Where did we start?

Nowadays, we are used to huge airdrops in TON, but back in 2023, the situation was very different. How did on-chain token distribution look like back then, and how did it shape the solutions that followed?

Challenge 1: Lack of tools

Before 2024, TON lacked the technical solutions for distributing tokens at massive scale. Highload Wallet could handle up to 254 transactions in one smart contract call, but it wasn’t well-suited for airdrops with more than 100,000 participants. With the need for these tools becoming apparent, TON’s challenge was to offer suitable solutions.

Challenge 2: Network load

TON was designed to handle lots of transactions. Its blockchain can split into smaller parts known as "shardchains" to process more transactions faster. But in real life, unexpected things can happen. You can't fully prepare for the high-load situations in advance—you often have to experience them, identify the problems, and then address them. In 2023, TON had yet to go through such a big test.

Challenge 3: Transaction fees

TON has relatively small transaction fees. But if you want to send a token to millions of users, the total sum can add up. If we let users pay for themselves, that creates another challenge: what if a new user wants to get their token reward, but has no Toncoins yet to pay the fees?

These challenges—lack of tools, managing network load, and transaction fees—showcase the hurdles TON needed to overcome. While the road wasn’t without its obstacles, each challenge presented an opportunity for growth and innovation, laying the groundwork for a more robust ecosystem.

Part 1: Inscriptions ("the stress test")

In November 2023, TON set a world record among blockchains, achieving 100,000 transactions per second. While this demonstrated TON’s scalability, it was achieved in a controlled environment—not on the TON mainnet where all the real user activity happens. Reality soon followed.

In December 2023 the TON ecosystem faced its first major stress test: inscriptions. Though not an airdrop, this "mass minting" situation tested the limits of the blockchain.

What are inscriptions?

The idea came from Bitcoin. Unlike modern blockchains like TON, Bitcoin doesn’t support creating tokens because it lacks smart contracts. So, the users got creative. They suggested adding token information in transaction comments and agreed that these comments represent tokens. They called this concept inscriptions because the data was written or inscribed into the transactions.

That idea took off, and the BRC-20 standard emerged. Later, some people applied its principles to other blockchains, including TON, which led to the TON-20 standard. That might feel counterintuitive: TON has smart contracts and a token standard called Jettons. Was there really a need to create another solution for tokens on TON? Well, blockchain's decentralized and permissionless nature means that "the need" is defined by the users. If people decide that they need something, who is there to stop them?

The inscription hype

So, new TON-20 tokens arrived. To mint them, users sent Toncoin to a minter address with limited token supply, sparking a frenzy. People raced to send as many transactions as possible before the tokens ran out. The result? Over 100 million transactions made by 185,180 unique holders (according to dTON Forum).

TON was designed to handle many transactions, but what if a group of people tried to make as many transactions as possible, pushing the system to its limits? And what if all those transactions went to the same address? It would prevent the blockchain from sharding effectively because all the activity happens in the same shard. Apart from the blockchain itself, what about all the blockchain-based apps that did not expect such a load growth?

The situation became the first massive stress test for the whole TON ecosystem. The hype was huge and unexpected, driven by people outside the TON ecosystem bringing a completely new approach. Nobody saw it coming. Compared to prior network activity, it was a seismic shift:

Challenges exposed

The massive surge in activity led to temporary technical issues that made TON difficult to use for several days. Issues appeared at different levels:

• Blockchain-level issues: The blockchain temporarily stopped creating new blocks due to validator hardware limitations, sharding issues, and other technical challenges.
• API-level issues: API services suffered outages under high load, especially the lightservers hosted by various ecosystem projects.
• App-level issues: End-users experienced delays or failed operations.

Despite these frustrations, the event became a turning point for TON, exposing bottlenecks and sparking improvements that prepared the network for future events like big airdrops in 2024.

Lessons learned

TON gained some critical insights from the inscriptions wave:

• Validator hardware is important. Validators need to meet the requirements to prevent performance bottlenecks.
• Key API services should be more scalable. Unlike the blockchain itself, they suffer under high loads, similar to Web2 services. To fix it, API services should apply the same horizontal scaling that Web2 services use.
• Projects in the ecosystem should support several APIs, not just personal light servers.
• Real-world TPS quite differs from controlled tests. While the 100,000 TPS record showcased potential, this should be taken into account.
• Over 240,000 Toncoin was spent on gas for minting. This should be avoided in future mass-minting events.
• When lots of transactions are sent to a single address, sharding becomes much less effective, as all those transactions are sent to the same shardchain.

The inscriptions mass minting event was chaotic, brutal, and aggressive. It lacked pre-launch coordination or specific optimizations—it was a stress test from the universe. But in hindsight, it was exactly what TON needed to uncover weaknesses and evolve.

Armed with these lessons, TON was better equipped to handle its next major event: Notcoin.

Part 2: Notcoin and Mass Sender (the "sending" approach)

Notcoin at TON Gateway 2023

Notcoin by Open Builders made history as the first TON project to launch an airdrop for millions of users. It also became the first Telegram Mini App game to introduce the clicker mechanic, which later ignited the tap-to-earn trend of 2024.

Tapping on the screen wasn't the only activity in the game, but it provided an incredibly simple starting point. Many crypto projects scare casual users away because they require prior knowledge. Notcoin was the opposite: you could start earning points immediately without training. Combined with a viral mechanic (rewarding users for inviting friends), that turned out to be a recipe for success, getting Notcoin to 35 million players.

After the game was released on January 1, 2024, its popularity exceeded all expectations. The load got so high that the developer team had to take turns sleeping during the first week, dealing with the issues round the clock. As tapping did not require interacting with the blockchain and was processed off-chain, those early issues did not affect TON, only the Notcoin team.

The situation

In May 2024, the time came for the token generation event. Notcoin rewarded its players with NOT, a token implemented as a customized Jetton, a Notcoin Jetton (a fork of the stablecoin contract), used with a library cell to lower the transaction fees.

A widely-used phrase in crypto, adopted by Notcoin

However, only a fraction of 35 million players would claim their tokens on-chain. Some players preferred to claim rewards on centralized exchanges (CEXs), others were banned for cheating, and some didn’t bother claiming the reward. Still, the numbers were huge and TON lacked an efficient technical solution to handle distribution at this scale.

The Notcoin team contacted the TON Core team to explore possible solutions. Together, they decided to develop a new approach with support from the TON API and TON Core teams. The objective was to create a self-hosted service capable of quickly distributing tokens to millions of users while minimizing network load and keeping transaction fees reasonable.

The solution

There are two primary technical approaches for distributing rewards: sending them or making them available for claiming. The former means that the game players provide their wallet addresses and wait for their rewards to come, while the latter means they initiate the transactions themselves. In this case, the first approach was chosen because it generates less transactions and is easier for newcomers. This solution became known as Mass Sender.

It was designed with highload in mind, using optimizations to reduce the number of transactions and limit forwarding messages. For instance, it generates 16 highload wallets (16 is currently set as the maximum number of shardchains) such that each wallet would be in the same shard as a corresponding Jetton wallet. All the recipients are split amongst those wallets based on their addresses. It's faster and easier to send messages within the same shard, so such an architecture reduces the forwarding of messages between different shards.

When Mass Sender sends tokens to its new owners, it monitors message queue sizes in the blockchain shards and automatically adjusts the sending speed. It also allows for manual speed adjustments to prevent overloading the network by accounting for other ongoing activities happening on the blockchain. Its "monitor" feature helps with assessing network activity in real time.

Another important question is: who pays for the transaction fees? The “sending" approach means that the airdrop organizers are initiating the transactions, so they need to pay the gas fees in Toncoin. However, they can require users to reimburse these costs via their app.

But what happens if a user is new to TON and doesn’t have Toncoin? The Notcoin team addressed this by introducing a gamer-friendly solution. Instead of requiring Toncoin, they set a fixed fee of 300 NOT for claiming rewards on-chain. It's easier for gamers, because there's no need to obtain Toncoin; you just receive a smaller amount of NOT. But it was a bit riskier for the Notcoin team: if the price of NOT suddenly dropped, the funds the team got from the gamers would not cover the Toncoin fees needed for sending NOT to those gamers. The team took that risk willingly.

So, how did it go?

After Mass Sender was ready, the Notcoin team deployed it and started distributing the tokens. The process was much smoother than the brutal inscriptions wave. There were some temporary issues with the API services under the heavy load, but the blockchain itself did not stop creating new blocks. Also, the fixed fee model for transaction reimbursement worked well as the token price remained stable enough.

Within 36 hours of listing, 5 million people claimed Notcoins: 1 million received their rewards on-chain through Mass Sender, while 4 million deposited them on CEXs or staked them. It was a resounding success. After this large-scale event, Open Builders continued to use Mass Sender even for smaller tasks.

Lessons learned

• It’s possible to organize a large-scale event without major issues that accompanied the inscriptions wave.
• Mass Sender got battle-tested and proved itself worthy. Now, it could be used for other projects. Since it's a self-hosted tool, theoretically, anybody could deploy and use it. To prevent misuse, such as spamming, the TON API team decided to make it available upon request rather than open-sourcing it. Reach out to the team if you need it for your project.
• Fees can be tricky, especially when reimbursing Toncoin expenses with another token, but it worked out fine this time.

Notcoin became well-known. Its success inspired more startup founders to create a TON-based game, and attracted more users to participate. That "35 million" achievement was soon overtaken.

Part 3: DOGS and TokenTable (the "claiming" approach)

During the summer of 2024, one of the most prominent TON projects was DOGS. Like Notcoin, it was a casual Telegram-based game that promised to launch a token on TON and reward users. But unlike Notcoin, it used different mechanics, like rewarding users based on the age of their Telegram accounts‚ — the older the account, the more points the user got.

DOGS attracted an impressive 50 million users, resulting in a massive airdrop. Around 10 million users claimed their rewards on-chain, while another 10 million opted to receive them via a CEX or the custodial Telegram Wallet.

The situation

The DOGS team tried another solution for on-chain distribution: TokenTable. This project was created by Sign and came from the Ethereum world, starting with EVM and later expanding to the TON/TVM world. Before DOGS, it was used by a smaller-scale AVACOIN project.

TokenTable works differently from Mass Sender. Instead of "sending" all the tokens to the users' wallets, it lets the users "claim their rewards." So, when a user gets the reward, the action is initiated by the user, not the token creator.

And that flips the fee situation. If a user initiates the transaction, it means the user pays for it. TokenTable also gets a fee for its service, charging the user for both things at once. This is the most convenient for the organizer, who doesn't need to pay for the transaction fees or the TokenTable service. Unlike Notcoin, where the team willingly took some risk with the fees, there's no such risk here.

Sign members at TON Gateway 2024

Even though it requires a user to have a small sum of Toncoin for the fees, in many ways, this approach is convenient for the user too. For instance, when an airdrop occurs, users can claim their rewards at their own convenience instead of waiting for the organizer to distribute them. Also, they would need to use a Telegram Mini App by TokenTable for claiming, but that feels seamless when it opens right from the Mini App they used.

TokenTable has been successfully used for smaller TON projects in the past. However, the DOGS hype was so huge that it not only caused API issues, but also a downtime for the blockchain.

Several factors contributed to that situation:

• The record-breaking scale of the airdrop. No blockchain had handled an event of this size before, making the outcome unpredictable.
• There was a validator misconfiguration issue. Before the airdrop, it didn't manifest itself because the nodes dealt with smaller amounts of data.
• Some of the validators didn't quickly apply an emergency update, prolonging the downtime. Additionally, some validators still didn't fully meet the requirements.
• The initial implementation of TokenTable on TVM generated more transactions than necessary. The DOGS event was huge and excessive transactions made the load even higher.
• Some DEXs have a centralized smart contract. When lots of people want to trade the same token, and they all send transactions to the same address, it creates a bottleneck.

The solution

So things were off to a rocky start. The DOGS team and TON Core team implemented two solutions: a short-term fix and a long-term improvement. The short-term one was to fix the node configuration problem and switch from TokenTable to Mass Sender.

Switching the distribution method during an ongoing airdrop is not an easy task. Some participants got their rewards, some didn't, and some started the claiming process but had their transactions reverted. So, the DOGS team had to process a lot of data in a short time to ensure everyone gets their reward and no one gets it twice.

But all that didn't mean that TokenTable was unsuitable for big airdrops. Part of the long-term solution was to improve it. Transitioning from Ethereum to TON is never an easy ride as those blockchains are designed differently, which leaves many EVM developers scratching their heads at first when they try to develop TON projects.

TokenTable has since improved. Nowadays, it creates less transactions, has a new traffic control feature that helps to mitigate claim congestion, and offers optimizations to speed up the transactions. At first, all fees were sent to a single wallet, which became a bottleneck. As we said in the inscriptions section, it's better to avoid a single entry point, and as we said in the Mass Sender section, when the blockchain splits into shardchains, sending messages within the same shard is faster and easier. As such, it's better to have multiple contracts spread across different shards, making sure every user can interact with the contract in their shard and avoiding cross-shard messaging. The team went in that direction, ensuring that each claim's fee is sent to the same shard's fee wallet. Things like that helped improve the speed.

These improvements allowed TokenTable to address its initial challenges and become one of the officially recommended mass minting tools in the TON documentation.

Lessons learned

• Size matters. A solution that works well with small projects may unexpectedly lead to issues when applied to a huge one.
• Being in touch with validators matters. The validators were asked to submit an information form and to follow TON Status updates during tough times.
• Discipline matters. A penalty system was introduced for poorly performing validators.
• DEX architecture matters. Centralized smart contracts can become bottlenecks. The TON 2024.08 update ensured these bottlenecks would only slow themselves down, not the entire network. Developers were encouraged to avoid centralized designs altogether.
• Switching is hard, but possible. Adapting to new distribution methods mid-airdrop isn’t convenient, but it’s possible when necessary.

Following this, Anatoly Makosov from the TON Core team soon announced a new, effective way of distributing tokens. That leads us to the next part.

Part 4: Hamster Kombat and Mintless Jettons (the "mintless" approach)

Hamster Kombat, another game with clicker mechanics, became enormously popular, crossing the 100 million monthly active users mark. It became the most popular TON/Telegram game, and probably the most popular crypto-related game in history.

However, such massive popularity didn’t guarantee that its airdrop would reach the same level in terms of user engagement. When a project becomes this big, many users engage out of curiosity, tapping around briefly without long-term commitment.

Still, it was obvious that the load on airdrop day would be much higher than usual. Instead of just waiting for it, the TON Core team prepared in advance. Part of that preparation was working with validators, ensuring they took care of their hardware and are ready to implement any updates.

But there was also another development—creating a new "Mintless Jettons" standard.

What are Mintless Jettons?

From the users' point of view, it looks very simple. If you have a self-custodial TON wallet and there's an upcoming airdrop with a Mintless Jetton reward for you, all you need to do is provide the wallet address in advance. And on the airdrop day, you’ll see the token in your wallet, next to all the other Jettons you own. Mintless Jettons are an extension of Standard Jettons, so you can interact with them in the same way.

But from the developers’ perspective, it's a bit trickier, but more efficient. While the token can immediately show up in the user's wallet, it's not actually minted on the blockchain yet, as with the "usual" tokens. Instead, it appears on the blockchain (the smart contract gets created) after the user interacts with it.

How does it work?

It's based on the idea of Merkle proofs. To deploy a Mintless Jetton, you need to generate a Merkle tree containing all the airdrop recipients and their respective amounts. Then, you compute the merkle_hash, store it in the Jetton Master contract storage on-chain, and store the Merkle tree data off-chain. Storing just a single hash representing all airdropped amounts means reducing storage requirements, and skipping the minting step lowers the fees.

Key benefits of Mintless Jettons:

• Reducing load
• Reducing costs
• Providing a user-friendly experience

However, this isn’t a perfect solution. One limitation is that Mintless Jettons only work at the moment of token generation. You must finalize the list of recipients in advance—new users who join later can’t be added once the tokens are deployed. So, it’s a great solution for early participants, but not for the latecomers. Therefore, Hamster Kombat didn't limit itself to it. The GigaDrop solution (with a "claiming approach," like the TokenTable) was also used.

Mintless Jettons also require support from the ecosystem. For instance, a TON wallet needs to add support for it to show users their rewards. All key TON ecosystem players supported the technology.

The first test

September 26 was a big day. It was the first real test for the Mintless Jettons, which added to the unpredictability.

The load turned out to be substantial but not record-breaking. It led to some temporary issues, but much less severe than during the DOGS airdrop.

This time, the blockchain kept on working and there was no issue with creating new blocks. The API services were overwhelmed during the peak hours but returned to normal functions the same day. The popular wallet app, Tonkeeper, warned users that the load may temporarily affect their experience, helping manage expectations.

The share of Mintless Jettons turned out to be relatively small compared to the number of airdrop participants. Hence, the new standard helped to some degree, but was not dramatically changing the overall situation.

Lessons learned

• A large number of Telegram Mini App users doesn’t guarantee a proportionate number of airdrop recipients.
• Mintless Jettons do not magically solve everything, but they are helpful and there were no major issues in practice.
• The ecosystem generally learned to deal with airdrops, but API availability is still an issue to some degree.

Conclusion: where are we now

The fastest-growing token in terms of holders wasn’t Hamster Kombat or Notcoin—it was DOGS

Currently, it seems like the tap-to-earn trend and the era of massive airdrops are fading away. There will be new trends in 2025, but that’s a story for another time.

As we near the end of 2024, let’s reflect on this journey by revisiting the challenges mentioned in the introduction: the lack of tools, the load issues, and the uncertainty surrounding fees. What’s the situation now?

A year ago, the TON ecosystem had zero solutions for massive on-chain token distribution. Now, it has several tried-and-tested ones. They are different, so founders can choose the most suitable one for them:

• Mintless Jettons: An open-source solution with the most modern approach that helps with load, cost, and user experience. It requires knowing all the recipients in advance.
• Mass Sender: A self-hosted, access-on-request solution that was successfully used for the biggest airdrops. The airdrop organizer has to pay the transaction fees (but can make participants reimburse them).
• TokenTable: A commercial solution that relies on users claiming the rewards instead of mass sending them. It places the fees on the user.
• GigaDrop: Also a commercial solution with the "claiming" approach. It was successfully used by Hamster Kombat and X Empire.

It's possible to combine the solutions. Someone could start with Mintless Jettons for the initial batch of users and then use one of the other two options for those who didn't share their addresses in advance.

With these tools available, the ecosystem challenge of on-chain token distribution is resolved. Additionally, the situation around fees is much clearer, with solutions offering diverse approaches to cost allocation.

That leaves us with the "load challenge"—what's the current situation with that? Recent airdrops like those for Hamster Kombat, X Empire, and Catizen have generally gone smoothly, proving that TON can handle high loads effectively. Earlier challenges, such as the issues during the DOGS airdrop, exposed bottlenecks that have since been addressed.

Thanks to the airdrops, TON is now stronger than ever. It went head-on into uncharted territory with airdrops of unprecedented scale and eventually became successful in dealing with them. As we enter 2025, the ecosystem is well-prepared for whatever lies ahead.

Let’s see what the future brings.