The participants discussed the DeBot contest proposal and TIP-3 managing, outlined their ideas and goals.
The idea of the contest: to set a task for the participants so that they show not only their abilities to develop DeBot, but also their ability to evaluate third-party work on creating DeBots. Thus, a competent jury group can be formed from the winners of this contest.
Pavel P offered to extend the DeBot contest for 2 weeks, and Mitja, in turn, offered to write solutions for external architecture.
Mitja also decided to speak out about the culture of the Russian-speaking Free TON community: “If someone needs something, he takes his own, instead of, for example, going and offering something, contributing someone else’s code, a ready-made contract. We need to work in this direction. This will significantly speed up the development process”.
Ivan Kotelnikov summed up the discussion by sharing his vision of the DeBot contest criteria: “They have to work, demonstrate some kind of clear working use case, so that the repositories are well designed. And there are additional options: you need to comment on each other”.
The idea of the contest: there is a TIP-3 standard with a fairly concise description, a minimalistic interface that intentionally does not allow you to do some things. This can be done via the contract management and the contestants are encouraged to practice. Participants can apply different user cases, including logic in different versions.
Alexander Hramcov added that it is also possible to apply Solidity implementation, which can also work according to the TIP-3 standard. Aleksandr Hramcov added that the Solidity implementation can also be applied, which can also work according to the TIP-3 standard.
Roman Nguyen believes that the interface must be common, otherwise the wallets will simply not be able to support TIP-3.
Mitja believes that there is a specification for TIP-3 and any changes to the interface should be approved at meetups, via proposals. This is exactly what TON Labs is going to practice — there are two changes in the plans.
When asked why Solidity should not be used, Mitja answered brusquely: “Because TIP-3 Solidity does not exist, there is only a semblance”.
Alexander Gramtsov noted that there is already a solution to the problem of using solidity. The wallet owner can set up a callback in the wallet, and this callback will be called by the token receiver to send a notification.
“The contract will have a subsidiary token contract,” explains Aleksandr Hramcov. — In this token contract, a callback must be configured to obtain the necessary information: balance, owner, token type. The pool receives a notification from its wallet with the full data”. However, this function is optional because it requires additional gas costs.
Ivan Kotelnikov clarified whether it is possible to make the implementation of solidity and c++ identical at the API level? Mitja is confident that they should be compatible: “You will not deploy the same token with different contracts. It is important that they have the ability to be composable in terms of contracts, the interfaces that will work with them — DEX, some DeFi contract … For example, you write a DeBot that works with all TIP-3 tokens, you have to support a certain number of interfaces, this should work with both solidity tokens and c++ — any variants of them”.
Boris Ivanovsky outlined his TIP-3 standard concept — this is a type of wallet that deploys its own contract for each user. He agrees that storing data in separate contracts is a more efficient and secure method than mass access with public keys to a single contract.
A little bit about analytics
Nikita submitted his proposal for the TIP-3 competition, knowing about some of the shortcomings of these tokens, for example, that it is impossible to get the balance from another contract. He believes that instead of a contract that will generate a TIP-3 token, it is better to make an off-chain solution that everyone will need: “Because there is no analytics in TIP-3 tokens, they are completely decentralized. No one can see from which wallets what goes where, how often users use these tokens. Those who will issue their own token – shop, bank, gambling — they all need analytics”.
Pavel P and Mitja assured that there is already such a tool. Mitja added “ ” A lot of design is tied to TIP-2, TIP-3. This kind of approach is called a hashcode contract. And you can use the hash to find all the tokens that have been issued, and analyze the messages”.
There is also an API — GraphQL, or you can view the information you are interested in on ton-explorer.
The contest dates have not yet been determined. Further discussion of ideas should be continued on the forum.