NFT Fractionalization standard

[0xSeymour]

Summary

We propose the creation of a smart contract standard that enables the fractionalization of NFTs in the TON ecosystem. This contract would allow NFT holders to lock their asset and receive a predefined number of tokens (default n=100) in return. Simultaneously, this creates a pooling mechanism, enabling any participant with the collection's tokens to redeem a chosen NFT from the pool by providing the required number of tokens.

Context

The non-fungible token (NFT) landscape is rapidly evolving. One pressing issue faced by collectors and artists alike is the liquidity and flexibility related to NFT ownership. Fractionalizing NFTs provides an innovative solution, allowing multiple participants to have a stake in a single NFT and potentially democratising the NFT market. Implementing this proposal would not only enhance the functionality of the TON ecosystem but also attract a broader range of users interested in both NFTs and their fractionalization.

Goals

Flexibility: Provide NFT holders with a way to fractionalize their assets.
Liquidity: Enhance liquidity in the NFT market by allowing smaller, fractionalized stakes in high-value NFTs.
Democratisation: Open doors for smaller investors or enthusiasts to have a stake in premium NFTs which they might not be able to afford otherwise.
Streamlining: Create an easy, intuitive process for users to both fractionalize and redeem NFTs from the established pool.

Details

1. Collection pools are not unique. Anyone can create a pool for a specific collection.
2. There are commissions for both pool creation and fractionalization (placing an NFT in the pool).
3. Pools should be created through the pool-master, which only accepts a message if it's signed by the authority key. Fee management is done using this key.
4. Jettons are unique to each pool. Therefore, the name of the Jetton should contain the collection's name and the pool's name.
5. The creator of the pool is not obligated to put his NFT into the pool.
6. The number of jettons that a user receives from the operation is defined when creating a pool.
7. The same amount is required for the reverse operation.
8. Users choose which NFT they receive from the pool during defractionalization.

Deliverables

Smart Contract Development: A robust smart contract that accepts NFTs, locks them, and issues the predefined number of tokens to the NFT submitter.
Pooling Mechanism: An integral part of the contract that facilitates token holders to select and redeem an NFT from the pool.
Documentation: Comprehensive user and developer documentation to facilitate the understanding, deployment, and utilisation of the fractionalization standard.
Testing Suite: A series of tests ensuring the smart contract's functionality, security, and resilience against potential vulnerabilities.

Definition of Done

• Successful Deployment: The smart contract is deployed without any issues and is available for public use.
• No Critical Bugs: After extensive testing, no critical bugs or vulnerabilities remain.
• Clear Documentation: All potential users, both technical and non-technical, can easily understand and use the fractionalization mechanism.
• Achievement of Initial Goals: The primary goals mentioned above have been met to a satisfactory level, as confirmed by key stakeholders

Reward

Considering the potential impact of this proposal on the TON ecosystem, the complexity of the development process, and the value it offers to the community, we suggest a reward of:

A monetary reward of $1200 USD in TON equivalent to cover development, testing, and documentation efforts:

• An optimized smart contract on FunC with tests ($1200)

Total: $1200 + A special edition Standard TON Footstep NFT.

Oriental Release Date

2 weeks

[delovoyhomie]

@petroleumisbooks, indicate in the footstep that the smart contract should be written on Tact and FunC.

[Gusarich]

I’d like to complete it but why Tact?

[aSpite]

I would like to take on this task, but what does it matter in which language the contract will be written? The end user will use it without reviewing the code. After all, we are not writing educational material.

[howardpen9]

LFG

[tactfunc]

How to register or participate this compaign

[aSpite]

I believe that the content of this footstep should be re-filled. This is not the kind of footstep where filling in information with general words using ChatGPT or similar tools is appropriate. Many questions arise here:

1. Is the development of a standard or a contract required? The title mentions "standart," while the content mentions a contract. These are different things.
2. How will the price of an individual NFT in the collection be determined? Or should all NFTs have the same value?
3. The details of token distribution are unclear. Should they all be the same for one collection, or are unique tokens distributed for each NFT?
4. Two individuals have exchanged their NFTs, receiving tokens (let's say 50 each). Can the first person exchange 50 tokens to claim the second person's NFT and vice versa? In other words, who can claim an NFT? Anyone with enough tokens, or only the original taker?

Once these questions are answered, other questions can be asked.

[0xSeymour]

@aSpite, 1. Standard.
2. This is up for the market to decide. Standard allows to set N tokens received in exchange for 1 NFT submitted to the pool.
3. Unique tokens for each NFT.
4. If you have all tokens(that are unique) of a specific NFT, you can claim the NFT.

[aSpite]

1. So, does it mean that first, it's necessary to develop the TEP fully, and only after that, start working on the contracts?
2. Does this mean that each NFT will have its own smart contract to split it? And is it the case that during the transfer of the NFT, the creation of token minter and other contracts will take place?

[0xSeymour]

@aSpite, 1. TEP requires a working contract, not only a concept
2. Vision is to submit NFT to a pool and then to be able to get any NFT from a pool in a exchange for n Fungible Tokens issued to a wallet submitting NFT. Users are indifferent to the technical nuances.

[tactfunc]

@aSpite, 1. Standard. 2. This is up for the market to decide. Standard allows to set N tokens received in exchange for 1 NFT submitted to the pool. 3. Unique tokens for each NFT. 4. If you have all tokens(that are unique) of a specific NFT, you can claim the NFT.

I finished a version with the same token tho.

I putting all the NFTs as the same convert rate.

[delovoyhomie]

The previous reward amount was mistakenly approved. After discussing with the team, a decision has been made to split the reward into two parts:

• An optimized smart contract on FunC with tests ($700)
• The same contract on Tact for mass adoption ($300) + Article about step-by-step development of a Tact contract ($400)

The reward has been updated, and the proposal is approved. Interested parties, come forward!

[yash0501]

Hi @delovoyhomie, I would like to work on the Tact smart contract as well as the article that would be describing the step-by-step development of that contract and its details.

[howardpen9]

Hi, @petroleumisbooks, I've made a POC protocol that you can test on the test-net yourself.

The Protocol is inspired by the idea you gave, and I've used the Tact language to implement it. Since I'm also looking for ideas for my upcoming tutorial for newcomers, I spent the last couple of days working on this.

The core concept is that I don't want to fractionalize in "different Jetton Roots for each NFT item." In all my experience with DeFi, I've always prioritized "Liquidity as the King."

You can check the details of the protocol here:
https://github.com/tactfunc/fractionalized-nft

I've also made a video demo for it. You can check it here:
https://t.me/ton101/803

[aSpite]

The most optimal solution for me is to make minor changes to the token contract, which is written in FunC. It's unclear how to do this if the second requirement is Tact.

I'd also like to ask you about the goals of the step-by-step article on creating a Tact contract. This footstep is aimed at building specific functionality. Why mix development and training?

My proposal is as follows:

Redirect these funds towards creating comprehensive documentation and improving efficiency on FunC. If there are goals to teach people Tact, this can be done after creating the contract on FunC, when someone can rewrite all the changes into this language.

I believe that all of this should be done gradually, and the tasks should not be mixed. This means that if the goal is to write a contract for dividing NFTs, the best approach would be to fully create it in one language, dedicate all efforts to this task, and then easily rewrite it into another language, write articles, and so on.

@petroleumisbooks @delovoyhomie

[Hiyorimi]

@delovoyhomie what do you think about Tact requirement? Can it be given up?

As far as I am concerned, FunC standard will be more efficient in gas spending.

[markokhman]

Hey guys :) A few points I would like to make on this one:

1. Indeed that's a great footstep that is framed by real business needs. Having this open-sourced and executed by a developer from the community will enable much more entrepreneurs and builders for inventing ways to give our ecosystem more business traction.

2. As this one is intended to be reused multiple times and become some kind of a standard - it must be efficient. So let's keep the FunC as the core implementation way. Thanks for updating the original proposal with this.

3. We do need new builders to have practical examples of real business cases built on Tact. Tact is much easier to understand, it's a higher abstraction level and we all will benefit from new builders having fewer barriers while entering. This is why we keep Tact on this

4. As we see now, a pure Tact smart contract will not be as efficient as the FunC implementation. Let's add one more deliverable to this footstep which would be optimizing a Tact contract via embedding FunC code to get efficiency close to the one we have on pure FunC implementation. I would suggest a reward of $300.

P.S. Big thanks for adding the step-by-step tutorial for writing the Tact version of this contract. This will indeed help to educate new builders.

[aSpite]

@markokhman

It turns out that in the end, the total prize associated with the Tact amounts to $300 + $300 + $400 = $1000. I don't consider this to be the right solution.

My proposal:

To change the approach to focus on creating contracts exclusively using FunC, with comprehensive documentation, tests, and other related elements. After completing this, a new footstep can be taken for translating these contracts to the Tact. Additionally, this approach can be applied to regular NFT contracts, tokens, and DNS. Various tutorials, articles, and more can also be added there. There's no need to mix everything together.

This means that the person who creates the contract in FunC (undertaking the majority of the work) would receive $700, and the Tact-related portion would be rewarded with $1000.

I see only harm to the community in this because if such a footstep remains unassigned for several days, it's worth considering why this is happening.

[markokhman]

@aSpite

1. Regarding the reward. To be honest, I don't agree with the majority of the work argument. Tact contract + step-by-step tutorial + optimization - this is a solid scope.
2. Regarding splitting into 2 footsteps. We do such a thing the first time, let's keep the context in one footstep for now. For the future ones - we might separate FunC and Tact ones. I think we will need @petroleumisbooks to better structure Definition of Done and Reward blocks, so they would be clearly showing what this footstep consists of.

[aSpite]

@markokhman

Where is the boundary between the amount of FunC code and Tact code? If we optimize a Tact contract by inserting segments of FunC code, what percentage of the code should be in Tact? It's quite a strange idea.

Moreover, it's essential first to devise a structure and then implement a FunC contract from scratch based on it. Afterward, the remaining task involves rewriting this from FunC to Tact while already having a fully functional contract in FunC.

[delovoyhomie]

@markokhman's proposed reward for the idea along with advanced $300 for improving the Tact contract through the insertion of FunC code, seems unfair. The rewards remain the same.

The executor who decides to fulfill the Takt contract determines the path of the solution themselves - @markokhman suggested using some FunC inserts for optimization purposes. This solution might seem good at first glance, but it is inherently unreasonable to insert "unintelligible" FunC code into the "intelligible" Tact. If the final solution appears comprehensible in addition to being optimized - that's great!

We also appoint you, @aSpite, to write the FunC contract! If the technical requirements are unclear or if there are any questions, feel free to ask them here or message me DM via Telegram.

[Gusarich]

So what's up with this Bounty?

[aSpite]

@delovoyhomie,

Repository: https://github.com/aSpite/shardify
Audit (all issues are resolved): https://drive.google.com/file/d/17pM3JkYU9-pT1gs8XYccpe5RG_FD5CoT/view?usp=drivesdk