The TON ecosystem is rapidly expanding with all sorts of smart contracts that the wallet needs to interact with smoothly and safely. There are three ways to achieve this:
A: Individual transaction types
Pros: most safe, since the wallet knows all the parameters and understands the potential outcome and can present it to the user.
Cons: this scales poorly for the wallet developers. Wallets need to keep up with all sorts of apps and rush to support growing number of transaction kinds. Unsupported transaction types make users switch to other wallets that support raw tx signing.
B: Structured and extensible message format
Pros: as safe as the (A), but a generalized version that enumerates constraints on the assets that users work with.
Cons: contract writers should adopt and respect the format; it also needs to get extended to new kinds of assets from time to time. This scales very poorly.
C: Signing arbitrary payload
Pros: most flexible option. Unknown payloads still can be signed, albeit with a warning to the users.
Cons: the wallet needs to simulate transaction execution in order to make sense of the effects and present them to the user. In order to not train users to blindly agree to warning message we need to constantly catch up with ecosystem and support most popular cases.
In this PR we are adding support for (C): signing arbitrary payload and stateInit.
We also develop TonApi where we need to index various transaction types. We will reuse that indexing logic to simulate the unsigned transactions and present sensible confirmation info to the user.
The TON ecosystem is rapidly expanding with all sorts of smart contracts that the wallet needs to interact with smoothly and safely. There are three ways to achieve this:
A: Individual transaction types
Pros: most safe, since the wallet knows all the parameters and understands the potential outcome and can present it to the user.
Cons: this scales poorly for the wallet developers. Wallets need to keep up with all sorts of apps and rush to support growing number of transaction kinds. Unsupported transaction types make users switch to other wallets that support raw tx signing.
B: Structured and extensible message format
Pros: as safe as the (A), but a generalized version that enumerates constraints on the assets that users work with.
Cons: contract writers should adopt and respect the format; it also needs to get extended to new kinds of assets from time to time. This scales very poorly.
C: Signing arbitrary payload
Pros: most flexible option. Unknown payloads still can be signed, albeit with a warning to the users.
Cons: the wallet needs to simulate transaction execution in order to make sense of the effects and present them to the user. In order to not train users to blindly agree to warning message we need to constantly catch up with ecosystem and support most popular cases.
In this PR we are adding support for (C): signing arbitrary payload and stateInit.
We also develop TonApi where we need to index various transaction types. We will reuse that indexing logic to simulate the unsigned transactions and present sensible confirmation info to the user.