Tonkeeper 2.7: signing arbitrary transactions

Tonkeeper 2.7: signing arbitrary transactions

Tonkeeper Team

Today we are releasing Tonkeeper 2.7 and make a breakthrough in security for all our users. We introduce safe support for signing an infinite range of transactions, which opens up integration with all the dapps in the TON ecosystem.

When a dapp asks you to sign an arbitrary transaction code, Tonkeeper intelligently analyzes what the transaction will do and presents you with an accurate and easy to understand summary. This way you can safely work with any dapp, without the risk of having your assets stolen or damaged.

We also re-architectured the transaction history to make it faster and more accurate. Our mission is to make TON more accessible to users and developers. This release makes a big step towards that goal.

The problem: growing variety of smart contracts

TON is designed to deploy arbitrary smart contracts at a massive scale. This gives developers an opportunity to rapidly innovate and deploy apps for millions of users to enjoy right away. At the same time, the wallet is a guardian of the user’s private key and must protect the user against mistakes, phishing attacks or bugs in third party apps.

Our initial approach was to err on the side of caution and add a growing list of supported operations: plain TON transfer, NFT and token transfers, DNS operations. But as TON continued to expand its dapp universe, that strategy proved to not scale very well.

Other wallets offer a way to sign an arbitrary transaction code, but that came with no guarantees whatsoever: you only get to see a disclaimer “you should trust the dapp” and then blindly press the “confirm” button. We think such behavior creates moral hazard: people are trained to ignore warnings and it becomes only a matter of time when someone finds a way to exploit this massively and damage the reputation of the entire platform.

The solution: on-the-fly emulation and annotation

Luckily, we found an elegant way to solve this problem. Last summer we have introduced an API of Events and Actions in our blockchain indexing engine TonApi.io — a poweful annotation system for TON transactions. This API takes a whole chain of related transactions and wraps them in a single human-readable “event”. Today we are using the same system to emulate an entire chain of TON transactions before they are signed.

This gives us a more accurate calculation of the actual fees paid and describes the actions involving your assets, even if a single logical action consists of multiple tiny transactions under the hood.

How will it scale?

We did not simply shift the problem of supporting an ever-growing list of transaction kinds from the app to the server. In fact, there is only one kind of transaction to perform: an arbitrary message sent on behalf of your wallet.

That message triggers a chain of multiple TON transactions spanning a number of contracts. For instance, even a simple fungible token transfer produces five transactions. If that token enters some smart contracts, even more transactions will be created. TonApi breaks down this complexity in common composable actions: “send token”, “receive coins”, “pay fee” etc.

To give useful guaratees to the users we do not need to support thousands of unique operations over hundreds of contracts. Instead, we only need to support a small number of reusable components (tokens, NFTs, auctions) that may be customized and combined.

It is inevitable that sometimes a new kind of asset appears that TonApi does not support yet. In such case the wallet would show a warning to the user and allow to sign the transaction. This behavior is meant for experimental new features and is necessary to help innovation in TON. However, as soon as this kind of asset becomes more popular we would add appropriate annotations to make sure people do not ignore warnings.

How to request a transaction signature

We adopt the same link format adopted by other wallets: ton://transfer with bin and init parameters for the binary payload and "StateInit" structure respectively:

ton://transfer/<address>?bin=<url-encoded-base64-boc>&
                         init=<url-encoded-base64-boc>

https://app.tonkeeper.com/transfer/<address>?
                         bin=<url-encoded-base64-boc>&
                         init=<url-encoded-base64-boc>

Use universal link "https://app.tonkeeper.com/..." to invoke Tonkeeper specifically and offer a nice fallback page for the users who don't have it installed yet.

Future steps

The current solution is already infinitely more secure and friendlier than the alternatives, but we want to make it even better.

First, we would like to work out a way to generalize Events/Actions annotation format to let dapp developers help us annotate their contracts. This way custom auctions, DEXes, staking pool could be annotated.

Second, what we do on the server, we could just as easily perform on the app as well for added robustness. The transaction graph may spans multiple shardchains, so we would still emulate the transaction on the server, collect all the necessary compacy proofs (also known as “merkle proofs”) and send them over to the app. There, we would repeat the emulation, but without the need for full blockchain state as it will be replaced by those compact proofs. Finally, the user will see the fully verified effects of their transaction with full confidence.


Report Page