FunC Adventure: Chapter 3

In this third installment of our FunC exploration, we’ll delve into the concept of tokens, the necessity of standards, and the specific token standards in TON. We’ll examine how the Jetton standard and the NFT collection standard function at a high level, and highlight some nuanced aspects of their implementation.

As our journey progresses, you come across a monumental edifice, a repository of wisdom… Anticipating your inquiries, the keeper of this repository directs you to the Tokens section.

Understanding Tokens

Cryptocurrency tokens represent units of digital value within a given network. It’s crucial to understand that tokens are not necessarily cryptocurrencies but rather entries recorded on the blockchain, managed through smart contracts. These smart contracts track account balances and enable token transfers between accounts.

While it may seem straightforward to create a smart contract that handles balance storage and token transfers, the challenge arises when every developer designs their own system from scratch. This would complicate integration for applications such as wallets, games, and analytics platforms.

To address this, blockchain networks have established standards developed collaboratively with the community.

The prospect of creating your own tokens for future use in the TON ecosystem prompts you to consult the guardian once more. You inquire: Where can I find the relevant standards?

TEP and Standards

Blockchains typically feature dedicated pages on GitHub or similar platforms where you can propose new standards or modifications. For TON, this is managed through a specific GitHub repository.

It’s crucial to remember that these repositories are not forums for open discussion but rather formal places for submitting and reviewing proposals. Ensure your contributions are well-considered and relevant to the repository’s purpose.

The first standard we’ll examine is the token metadata standard. This standard is essential for applications such as wallets and marketplaces, as it streamlines the process of retrieving and displaying token information. By standardizing how token data is represented, this standard facilitates a consistent user experience across different platforms.

Understanding Tokens in TON

Since tokens are implemented as smart contracts, they can potentially contain errors or vulnerabilities. It is important to thoroughly examine smart contracts before utilizing them.

After exploring Web3 for some time, you may have encountered tokens in various other ecosystems, but TON has distinct differences…

Differences in TON Tokens

The architecture of token smart contracts in TON diverges significantly from that of other networks. Unlike other systems, TON operates asynchronously, follows the actor model for interactions, and uses sharding for scaling.

A major distinction from other networks’ standards is the absence of a single smart contract that handles all functions. For instance, when deploying an NFT collection (which we will explore in more detail later), each item in the collection is managed by a separate smart contract, with an additional contract governing the entire collection.

For example, if you deploy a collection of 10,000 items, you will end up with 10,001 individual smart contracts.

You might wonder why this approach was adopted. In summary:

• Predictable Gas Consumption: This design allows for more predictable gas usage.
• Scalability Considerations: This approach does not inherently scale.

For a comprehensive explanation, refer to the NFT standard documentation.

Types of Tokens

Tokens can be categorized based on their fungibility, which is one way to classify them.

Fungible Tokens are assets that are interchangeable and identical in value. Each token within this category is equivalent to every other token of the same type, making them easily exchangeable. In TON, the standard for fungible tokens is the Jetton.

Non-Fungible Tokens represent assets that are unique and cannot be substituted with another asset. Each non-fungible token is a distinct digital certificate with a mechanism for transferring its ownership. In TON, the standard for non-fungible tokens is the NFT Standard.

Jetton

The standard for fungible tokens is known as Jetton. According to this standard, a Jetton token requires the deployment of two distinct types of smart contracts:

1. Master Contract: This primary smart contract is responsible for minting new Jettons, tracking the overall supply, and providing general information about the token.
2. Contract Wallets: These smart contracts handle the balance of each user’s Jettons.

For instance, if you issue a Jetton with a total supply of 200 tokens distributed among 3 users, you would need to deploy 4 contracts: one master contract and three contract wallets.

To help you grasp the standard and its implementation, I’ve prepared a lesson that covers both the theoretical aspects of the standard and practical examples of implementing the master contract and Jetton wallets.

NFT Standard

NFTs (Non-Fungible Tokens) in TON follow their own specific standard. Unlike fungible tokens, where the Jetton standard applies, NFTs are structured differently: each NFT item and NFT collection is managed through separate smart contracts.

NFTs offer an excellent way to document your FunC journey, but there are a few critical questions to address:

1. How to obtain a complete link to the content when there’s no unified list within the smart contract?
2. How to determine the address of the NFT or Token smart contract and what kind of StateInit allows for this?

Understanding StateInit

To deploy a smart contract on the network, the code and data for the contract are compiled into a StateInit structure. The address of the new smart contract is derived from the hash of this StateInit structure. An external message is then generated with a destination address matching the new smart contract’s address. This message includes the appropriate StateInit data and a non-trivial payload (signed with the correct private key).

In practical terms, this process means we can derive the address of a token’s smart contract by looking at the address where the tokens need to be sent. Essentially, by using the address and wallet code, we can reconstruct the StateInit of the wallet and retrieve the necessary address for the token wallet.

This approach is feasible because hashing functions are deterministic: they produce a unique hash for different inputs, and the same input will consistently yield the same hash.

NFT Item Content

Imagine you need to retrieve the address of a collection item, such as a link to an image. The process might seem straightforward: you use a Get-method to fetch the information. However, according to the NFT standard in TON, this approach will only yield a partial link, known as the individual item content.

To obtain the complete content, follow these steps:

1. Use the get_nft_data() method of the item to retrieve the element index, individual content, and the initialization indicator.
2. Verify if the item is initialized (details on this can be found in Lesson 10, which covers the NFT standard).
3. If the item is initialized, use the get_nft_content(int index, cell individual_content) method of the collection to obtain the full content (complete address) for the specific item.

To clarify the standard further, I have prepared a lesson on this topic.

Conclusion

This series marks the end of our journey through FunC. I will continue to share new lessons on my channel, which may be valuable if you are considering starting development on TON.