The TON Enhancement Proposal (TEP) 74 introduces a comprehensive standard for fungible tokens, commonly referred to as Jettons, within the Telegram Open Network (TON). Authored by EmelyanenkoK and Tolya and activated on March 12, 2022, this proposal aims to provide a unified interface for the creation, transfer, and management of fungible tokens, enhancing interoperability and functionality across the TON ecosystem.
Overview of the Jetton Standard
The Jetton Standard proposes a detailed framework for the lifecycle of fungible tokens on TON, covering aspects from minting and burning to transfers and wallet interactions. By establishing a set of required contract interfaces and internal message handlers, TEP-74 ensures that Jettons can be seamlessly integrated into wallets, exchanges, and other token-centric applications.
Key Components of the Jetton Standard
The standard delineates the structure and functionality of two primary contract types: the Jetton Master Contract and the Jetton Wallet Contract. Each plays a distinct role in the Jetton ecosystem:
Jetton Master Contract: Acts as the central authority for a specific Jetton type, managing minting permissions, tracking total supply, and providing Jetton metadata.
Jetton Wallet Contract: Represents individual holders’ balances, facilitating transfers between wallets and interactions with the Jetton Master.
Enhanced Security and Flexibility: The separation of the Master and Wallet contracts allows for more secure and flexible token management.
Interoperability: Standardized interfaces and internal message formats facilitate interoperability among various TON platforms and applications.
Comprehensive Functionality: The standard covers a wide range of functionalities, including minting, burning, and transferring tokens.
Challenges:
Complexity: The decentralized nature of wallet contracts adds complexity to Jetton management and transfer processes.
Adoption: Ensuring widespread adoption of the standard by all ecosystem participants is crucial for its success.
Implementation and Use Cases
TEP-74’s implementation guidance, including example contracts and deployment tools, provides a solid foundation for developers to create and manage Jettons. The standard supports a wide range of applications, from digital currencies and utility tokens to governance tokens for decentralized autonomous organizations (DAOs).
Future Directions and Unresolved Questions
While TEP-74 lays the groundwork for fungible tokens on TON, future enhancements may focus on addressing unresolved questions such as the implementation of “safe transfer” mechanisms and the potential integration of external message tokens. These developments will further solidify TON’s position as a versatile and scalable blockchain platform.
Conclusion
TEP-74 represents a significant milestone in the standardization of fungible tokens within the TON ecosystem. By providing a clear and comprehensive framework for Jetton creation, transfer, and management, this proposal paves the way for the development of a rich and diverse token landscape on TON. As the blockchain continues to evolve, the Jetton Standard will undoubtedly play a pivotal role in fostering innovation and enhancing the utility of the TON network.
The TEP-74 proposal introduces a standardized interface for fungible tokens, also known as Jettons, within the TON blockchain ecosystem. This standardization is a significant step towards enhancing interoperability and simplifying the management of tokenized assets on the network. By defining clear protocols for Jetton transfers, ownership queries, and common information retrieval, TEP-74 aims to streamline the creation, distribution, and utilization of digital assets on the TON blockchain.
Professional Insight:
The establishment of a fungible token standard within TON, akin to Ethereum’s ERC-20, provides a foundation for developers to build a wide array of decentralized applications (DApps) and financial instruments. The decentralized nature of jetton-wallet contracts for each owner underpins a scalable architecture that inherently supports TON’s sharding capabilities, ensuring efficient processing and distribution of the network’s computational load.
Technical Considerations:
Jetton-Wallet Contract Structure:
The proposal’s emphasis on individual jetton-wallet contracts for each token owner offers a robust model for asset ownership. This design choice not only facilitates precise tracking of ownership but also optimizes the gas consumption for transactions, making the system economically viable for widespread adoption.
Transfer and Burn Mechanisms:
The inclusion of transfer and burn message handlers in the jetton-wallet contract specification is crucial for enabling flexible asset management. These functions allow for the direct and secure transfer of assets between owners and the removal of assets from circulation, which are essential features for managing token economies.
Professional Questions:
Interoperability with Existing and Future Standards:
How does TEP-74 ensure compatibility with existing digital asset standards on TON and plan to accommodate future standards? Specifically, how will this standard interact with non-fungible tokens (NFTs) and other specialized token types that may emerge?
Scalability and Sharding Considerations:
Given TON’s focus on scalability through sharding, what mechanisms are in place within TEP-74 to optimize the distribution of jetton-wallet contracts across shards? How does the standard address potential challenges related to cross-shard transactions and asset tracking?
Security and Risk Management:
What security measures are recommended or mandated by TEP-74 to protect against common vulnerabilities in token contracts, such as reentrancy attacks or unauthorized access? Additionally, how does the standard propose to manage the risks associated with the burn function, ensuring that asset destruction is intentional and irreversible?
Future Extensions and Functionality:
Are there plans to extend TEP-74 with additional functionalities, such as delegated spending (analogous to ERC-20’s approve and transferFrom mechanisms) or advanced tokenomics features (e.g., staking, yield farming)? If so, how will these extensions be introduced to ensure backward compatibility and minimal disruption to existing Jetton implementations?
TEP-74 represents a foundational step towards creating a robust digital asset ecosystem on the TON blockchain. By establishing clear standards for fungible tokens, the proposal not only facilitates the development of diverse DApps and financial services but also contributes to the overall scalability, security, and efficiency of the network. As the TON ecosystem continues to evolve, ongoing refinement and expansion of the Jetton standard will be essential to unlocking the full potential of decentralized finance and asset management on the platform.
Hi, guys! I am glad my prior work on “sharded smart contracts architecture” was useful for TEP-74 as I see link to my presentation in “Prior art” section: https://www.youtube.com/watch?v=svOadLWwYaM
I think this approach is also useful for at least “limit order protocol”.
Hello, I think Jetton may have the following problem with token transfer: For example one user wants to transfer Jetton tokens to another user whose owner is another smart contract. The transfer is done in three transactions:
The first transaction is a tokenTransfer message that is sent to the sender’s wallet, where he sends the necessary data such as the recipient’s address, the number of tokens to be transferred, etc.
The second transaction is sending a transferInternal message to the recipient’s wallet.
The third transaction is sending a tokenNotification message to the address of the owner of this wallet (the recipient’s address).
Actually the problem may be the following: when the contract receives a tokenNotification message from the wallet contract and for some reason wants to roll back this transaction (for example, in the code that is responsible for processing the tokenNotification message, there are some checks that have not been passed), then he will be able to cancel only the transaction with the tokenNotification message (that is the third transaction), but the token transfer itself was in the second.
