Telegram Open Network:

Award-winning case

Telegram Open Network (TON) is a new blockchain platform from the creators of Telegram, the main goals of which are to increase the speed of transactions, eliminate vulnerability to hacking, and overcome legal restrictions imposed by some governments.
However, not all development processes are carried out by the in-house team. In order to realize this outstanding project, Telegram invited top developers from around the world to participate in a smart contract development competition.
abstract background image 1

The task was to create one
or more of the following:

  • multi-signature wallet;
  • simple TON DNS Resolver smart contract with automatic registration of new subdomains;
  • synchronous two-party payment channel;
  • simple TON DNS Resolver smart contract with manual registration of new subdomains;
  • asynchronous two-party payment channel.
Serokell got ahead of almost 70 teams and won the first prize in the competition. In the shortest possible time, we developed a fast and reliable solution that was integrated into TON
abstract background image linesTelegram planeabstract background image 2

Serokell developers on the battlefield

Our team submitted two smart contracts for Telegram Open Network: an asynchronous payment channel and a multi-signature wallet.
We started with the research to familiarize ourselves with TON’s technical documentation and the source code. Then, we built a Nix overlay for the TON platform. Using NixOS allows us to make sure the components are reproducible and work smoothly on every OS.
abstract background image 8
Asynchronous payment channel
Multisignature wallet
We have realized a payment channel that allows users to send payments to each other off-chain saving money and time. It is no longer necessary to wait until the new block will be issued, so users can send payments as small and frequent as needed.

This is how the payment channel works:

Two users want to make a series of payments to each other. It is more efficient to perform them through a payment channel rather than on-chain.
In order to use the channel, they need to agree on the shares they have to contribute (which will bind how much each of them can owe to each other in the process), an inactivity timeout, and a misbehavior fine. Then, the payment channel contract is preconfigured and deployed to the blockchain network (by either of the parties or a third party).
Alice100$ + 50$:Bob200$ + 50$:400$Total:ALICEBOB100$ +50$200$ +50$
The contract starts in the “waiting” state: waiting for initial commitments from both parties. Each has to send to the contract the amounts of tokens equal to their shares, plus extra deposits that will be locked in case of a fine. Once both parties contribute their shares, the tokens are locked in the contract and the payment channel is open.
ALICEBOBIOU:10$A → B:10$B → A:0$ALICEBOBIOU:5$A → B:10$B → A:5$
To send a payment to the other, the party prepares a special IOU message. It contains the transaction amount and two values that record how much each of them have transferred to the other so far. The message is signed and transferred over any communication medium. If, at any point, one of the parties disappears, the other has a message signed by them indicating the last fund distribution they have agreed to.
These IOU (I OWE YOU) messages work as keys for the smart contract verifications. Each time the users generate new payments and exchange the amounts, these sums work as a simple confirmation of the mutual debt. And the same figures can perform the role of the unique verifiers for the smart contracts, which must be issued for each operation. Simplicity is the ultimate sophistication.
ALICEBOBIOU:0$A → B:10$B → A:5$ALICEBOBIOU:0$A → B:10$B → A:5$
To close the channel, it is recommended that the users exchange two final IOU messages sending 0 to each other in order to confirm that they are in agreement on final amounts owed to each other. When ready, the first user sends to the contract a payout request and attaches the last IOU received from the other. Then the second user has a fixed amount of time to either confirm that he agrees with the distribution proposed or, if it is not the case, propose another distribution.
Alice100$ - 10$ + 5$+ 50$:Bob200$ - 5$ + 10$ + 50$:95$ +50$205$ +50$
The channel is bi-directional and receiving a payment reduces the debt of the receiver. So as long as the mutual debts are balanced and stay within the allowed bounds the channel can remain open for a prolonged period of time and can be used for transactions multiple times. In any case, since the distribution proposals are supported by IOUs signed by the other party, the payment channel smart-contract will be able to decide on a fair distribution that will guarantee that both parties receive at least as much funds as they expect to receive, based on the incoming payments that they have seen. Feel free to check out our GitHub for more technical information.
The contract was implemented in FunC and, according to the requirements of the competition, the command-line tool for interacting with our contract was entirely in Fift. This innovative submission was granted the first place in the blockchain competition.
abstract background image 4abstract background image 3
Asynchronous payment channel
Multisignature wallet
We also implemented a multi-signature wallet, optional for the competition. Multi-signature means a special type of digital signature that allows two or more users to sign documents together as a group.
This time, we were not obliged to utilize a standard set of tools. We added our own domain-specific assembly language for TVM that was embedded in Haskell. It allowed us to exercise all the power of Haskell’s static types when working with smart-contracts.
Our DSL allows users to implement a Fift contract. The DSL nicely integrates with common Haskell syntax (one can use do-notation and if-then-else conditional statements). After the contract is implemented in the DSL, it can be printed into the Fift assembler and further be passed to the Fift compiler. There are built-in capabilities for:
  • composable serialization;
  • checking current stack type in assert-like style;
  • declaring intermediate procedures (even for polymorphic procedures);
  • introducing type aliases to prohibit occasionally confusing elements on stack;
  • enhanced-type comparison operators (not to confuse operands).
This DSL was created for the purpose of this concrete task, thus only a subset of Fift assembler commands are covered. The DSL has a lot of potential for usability improvements:
  • Automatic stack management (variable simulation);
  • Support of all Fift assembler instructions;
  • Integration with QuickCheck for top-notch property-based testing.
Send$$$:Signatures:2-of-3 signatures neededMULTISIGNATURE TXALICEBOBCAROL
We have managed to implement a prototype of a multisig wallet in less than two weeks according to the contest’s requirements. For more details, have a look at our GitHub.
abstract background image 9abstract background image 10abstract background image 11


Telegram received a solution that allowed them to transfer payments off-chain fast and securely and guarantee their final settlement.
Serokell once again proved that our blockchain team is one of the strongest on the market.
Also, this contest demonstrated that expert outsourcing companies can effectively interact with in-house teams that develop their own product.
We were proud to contribute to the development of a state-of-art digital product that takes cybersecurity to a new level. And we are looking forward to contributing to TON in the future.
Arseniy Seroka
abstract background image 5abstract background image 6abstract background image 7

Let’s Have a Chat

Every project is different. Schedule a consultation to discover the correct technologies and solutions for your idea
abstract background image bottomabstract background image 12abstract background image 13