# Multitoken Standard (NEP-245) Action Plan
###### tags: `near-contract-standards`

## Problems

+ Some projects are blocked and don't have a time to drive the standard.
+ The [NEP-245](https://github.com/near/NEPs/pull/245) was already created 2 years ago! But was never finalized.
+ Projects don't have resources to engage and follow the NEP process.
+ Other projects didn't want to wait for standards and move their own way (OFP).
+ Lack of leader who will handle and push the work to the end.

### Context

A version of the Multi Token is already used by
+ Open Forest Protocol
+ Tenamint (@UncleTony)
+ Ref
+ NEAR Horizon encounter many projects that asked for Multitoken Standard

## Finalize Multitoken standard

MT group chat: https://nearbuilders.com/tg-multitoken

### Recap of discussion to date

https://nearbuilders.com/slides-multitoken

“Review the status of the NEP, reference implementation, incomplete discussions, and come up with the strategy on how to resolve the outstanding issues, and then push it - update the NEP and test it with reference implementation. I can also recommend inviting other parties (wallet builders, explorer builders, defi and nft marketplace builders) to battletest the final design”

I’m reaching out to @UncleTony whom worked on it previously to see if he can add support.

@MarcoSun80 wrote:

> “Looked into the NEP-245 md file in the master branch (https://github.com/near/NEPs/blob/master/neps/nep-0245.md), it seems the file has missed description about Enumeration, approval, and Metadata sections. I am gonna add those things according to the content in this one (https://github.com/near/NEPs/tree/master/specs/Standards/Tokens/MultiToken), and then invite guys from pagoda and mynearwallet team to comment on the NEP md file next week.
My strategy is to process the NEP md file first, ensure most of the parties agree on it. And then move to the code implementation.”

Copied from: https://t.me/c/1968603478/17

Problems seem to me to be the following:
- Bridging solutions have no means of porting ERC-1155 semi-fungible tokens to NEAR. Fungible tokens can be imported via NEP-141 and non-fungible tokens via NEP-171. But no standard exists for SFTs that is recognized and implemented by indexers & marketplaces.
- Gaming & GameFi projects need seamless interoperability between various kinds of assets, which ERC-1155 enables on EVM. There is no standardized solution for this currently.

Existing solutions/proposals suggest a new contract standard, similar to what is currently implemented in NEP-245. My concerns are the following:
- I don't think that designing a clone of ERC-1155 on NEAR is the right approach. NEAR differs from Ethereum and other EVM chains in some key ways, with which we are all familiar. Standards have been built and implemented on NEAR that have built on ERC-20 and ERC-721 concepts, but are necessarily different and in some cases improved. Creating a new kind of contract on NEAR mirroring ERC-1155 would not integrate well with the existing ecosystem without overwhelming adoption, which I believe to be unlikely.
- Existing proposals, while lacking necessary requirements, demonstrate significant duplicate code with the existing NFT standard, in many cases everything is exactly the same just with mt_ instead of nft_. This I think is an indicator that the majority of the required functionality can be accomplished using existing tooling and extensions.
- It seems that there isn't a consensus on how SFTs should be treated by wallets and marketplaces. Are they more like NFTs, or more like FTs? Should all dApps be required to support them? But I think it boils down to this question: **What are semi-fungible tokens?**

> DISCLAIMER I have never written an ERC-1155 contract (I wrote some ERC-721 once upon a time). But I have researched and believe I understand the spec and how it is used. My observation is that it is a fungible token with attached metadata. As someone pointed out in the builder group call today, SFTs can function like shares, e.g. fractions of an NFT (or company, etc). So they are not traditionally fungible in that they don't function as a currency, but they are fungible in that they are interchangeable units. If we are continuing the company analogy, an NFT might be the company itself (which is fractionalized via SFTs), as well as the land that the company office sits on, and a piece of art on the wall.

> I'm trying to explain why I consider SFTs to resemble fungible tokens in their purpose and therefore propose the idea of extending the existing FT standard to incorporate the requirements of SFTs (basically, metadata), rather than creating an entirely new contract standard.

> Then there is the separate (I think) question of nesting multiple FTs and NFT collections within a single contract. This was another innovation of ERC-1155 which has been implemented independently in various popular NFT contracts on NEAR (e.g. Few and Far, Paras, Keypom), but has not yet been standardized. I think the community would benefit tremendously from the standardization of this concept but I think this has to be a separate discussion and separate NEP or we will be stuck for months.

## Implementations

* initial PoC implementation in [near-sdk-rs](https://github.com/near/near-sdk-rs/pull/950) (note: we consider removing it from that repo).
* https://github.com/ref-finance/ref-contracts/blob/main/ref-exchange/src/multi_fungible_token.rs
* OFP
* Tenamint
* Ample
* https://eips.ethereum.org/EIPS/eip-1155 (the Ethereum version)

## Plan

- [ ] Ken from NEAR Horizon to provide more feedback
- [ ] Respond for the open comments
- [ ] Compare implementation from OF and Tenamint and Ref.
- [ ] Create a new PR with more information, justification for the nep-245,
- [ ] including the comparison between the implementations with motivation why we should use a specific version.
- [ ] collect considerations and document them.
- [ ] Look and integrate or reject https://github.com/near/NEPs/pull/421
- [ ] Make sure the reference implementation is updated and validated.
- [ ] Once the new PR is proposed, we need a check from wallets.
- [ ] Review from the listed projects (we need review from all OFP, Tenamint, Ample and hopefully from Ref).

Ken is able to pick up and address the comments.

### Possible incentives

- hackathon
- DevHub

See -> https://hackmd.io/@robert-zaremba/rJQllimkp