Multi-Token Standard Discussion

zcstarr · June 15, 2021, 9:59pm

Hi all I wanted to start a conversation and gather interest for developing a multi-token standard contract. This would be very similar to the NFT and FT standards that have been developed. The principle motivation would be to be able to give wallet devs, and smart contract developers a standard to build contracts that support different asset classes and that can be batch swapped. This would have a similar impact to erc-1155 and the Ethereum ecosystem.

Summary

Having a single contract represent both NFTs and FTs can greatly improve efficiency as demonstrated by Enjin Coin. The ability to make batch requests with multiple asset classes can reduce a many transactions transaciton to a single transaction to trade around both NFTs and FTs that are a part of same token contract.

Motivation

We already have a standard for NFTs and FTs and have tackled the perhaps trickest issue which is account storage management. This seems like a nice next logical step towards building a great ecosystem that supports the many uses cases of multi-token smart contracts.

Taking a nod from @mattlockyear I’ll lay out the same sort of ground logic that was involved in the NFT Standard discussions.

Goal

Soft consensus here on the interface and high level architecture, then a migration to Github for impls.

Rules of Engagement(shamelessly cribbed from the NFT Standard discussion):

What’s needed:

Bring all ideas to the table
Look at existing patterns and solutions
choose/generate a solution that satisifies the Near ecosystem needs

Here’s what we don’t want

promoting a particular approach
not listening to others
trying to “own” the standard
starting my own standard

Background
EIP-1155 : ERC: Multi Token Standard · Issue #1155 · ethereum/EIPs · GitHub
Example of an NFT Series : GitHub - near-apps/gnr8
Things from the NFT Discussions: Improved NFT Standard · Discussion #171 · near/NEPs · GitHub
Things from the NFT Discussions: NFT Standard Discussion

Discussion Starters

Standard interface for a MultiToken Standard
Deal with storage should we follow the same pattern in NFT and FT standards?
Keep the interface the same or at least 1-1 corresponding with erc-1155 for bridging ?
Suggested architecture and reference implementation that tackles how to:
deal with token type assets FT, NFT, … ?
deal with unique identifiers for token ids across classes/namespacing ?
deal with wallets

These are just a few questions to get the mind going, feel free to comment and drop thoughts and concerns, or things you’d like to see.

jlwaugh · June 18, 2021, 12:32am

Love it!

Hoping to build on the discussion framework you created, I’ll share a few ideas, given my knowledge of existing patterns and solutions.

To choose/generate a solution that satisifies the Near ecosystem needs, we understand our vision of a world where all people have control of their data, money, and power of governance. How can multi-tokens help us achieve that goal? Why are they necessary?

Fungibility is just one spectrum of possible token designs, and I believe combining the interfaces would result in opportunities for adoption by wallets and exchanges. Not only can these more complex structures provide greater accountability for everyone using NEAR apps.

I agree that ability to make batch requests with multiple asset classes is a killer feature, and I’m so excited to explore all kinds of use cases for multi-tokens! For example, reputation is a complex idea requiring many levels to define properly, and nobody has really succeeded in developing a legitimate credit system for the open web. My feeling is it has to be validated on the network of participants representing themselves with accounts.

Responding to your questions:

I think we should follow the same pattern as the NFT and FT standards, although I wonder if there is a need for matching ERC-1155. Considering ERC-20 tokens can be converted into NEP-141 tokens across the bridge, I guess ERC-1155 tokens could also interoperate.
GNR8 is the best reference implementation for a kind of multi-token on NEAR, as far as I know. I’m curious to explore how account storage relates to dealing with unique identifiers of token IDs across classes / namespaces. Everyone has their own settings

One thing I’d potentially bring up is the mysterious ERC-888 standard…

mapping (address => mapping (string => uint)) balances;

This weird loop might be useful in contextualizing systems for imbued value.

zcstarr · June 18, 2021, 5:15pm

This was awesome, the high level bit , with the Fungibility link, I think the paper was interesting. I think it makes sense to view fungibility under the lens of attributes, context, and utility. I like this framework it makes sense. The one thing I think that was still curious about was how much rationality plays into, when the paper gets into pricing. I think it might be too focused on pricing as a component of rational localized information decisions ( i.e. rational preferences for attributes vs macro trends outside of attributes). I think the signals are maybe to noisy for price prediction, though who knows

Tech thoughts: I think the pre-existing standards format makes sense , particularly the NFT Standards pattern, with approvals.

Not sure what the ERC-888 standard adds here is the thought to think about partial ownership of NFTs ? My only concern there would be the increase in complexity perhaps I’d need to give a bit more thought

Thanks again for the thoughts!

zcstarr · June 21, 2021, 5:37pm

Here’s a quick proposal of an interface just to describe what should be supported by a core implementation. I’m spiking ahead here, but nothing has to be set in stone . Here’s what I think might be useful. Feat/initial token by zcstarr · Pull Request #1 · shipsgold/multi-token-standard-impl · GitHub

Here’s a quick summary

multi_transfer -> basic token transfer given a token id and amount
multi_transfer_call -> basic token transfer given token id, amount and call receiver impl
multi_transfer_batch -> transfer multiple tokens of different types and amounts in a single call
multi_transfer_batch_call -> ditto , with a call receiver
balance_of -> return the balance given a tokenId and account_id
balance_of_batch -> return balances given tokenIds and an account_id
total_supply -> return total supply given token_id
total_supply_batch -> return total supply given token_ids

I think the work done for enumeration can be used as an optional implementation that will help fill out the gaps by the simple view methods listed here.

Curious what do you all think? @mikedotexe @mattlockyer I know you all have dug into these quite a bit with the NFT standards any thoughts/suggestions?

riqi · June 23, 2021, 1:45am

Hey, Riqi here from Paras. We run our marketplace before the NEAR NFT standard, so we basically copy the erc-1155 into NEAR ecosystem. Very excited to discuss more this standardization because I think there will be more use-case that is suitable for Multi Token Standard, especially in gaming scene.

I I think we only need to focus on erc-1155 due to its popularity compared to erc-888. I also agree that we need to have NEAR Multi-Token Standard to make sure we have the interoperability with NFTs in EVM-chain.

zcstarr · June 29, 2021, 6:49pm

Should there be a dependency on the existing FT and NFT standards?

I wanted to put in this conversation that happened a little out of band and open the discussion up.

Conversation that happened out of band from riqi

One big thing that we should discuss is probably the pros/cons of creating new standard based on erc1155 (Feat/initial token by zcstarr · Pull Request #1 · shipsgold/multi-token-standard-impl · GitHub) or use current FT/NFT standard in a single contract (Feat/use standard by zcstarr · Pull Request #2 · shipsgold/multi-token-standard-impl · GitHub)

#PR1

Background:
So for the first PR (pointed to by the last commit) I started down the road of kind of duplicating the logic from the NFT and FT contracts, to try and find some overlap. At one point I even had the token data in a single tree map to try and unify the storage concerns. Going down that road, I found myself almost exactly duplicating the logic that was already implemented in NFT and FT. It felt actually not that useful from my perspective. I ended up needing the same implementation specific logic as the actual NFT and FT standards.

I originally assumed I might find some more simplicity or savings, or that I would need different logic than what already existed. This didn’t really seem to be the case too much outside of the storage cost calculations.

The other thing to consider here is that this would be the impl, so the interfaces for someone implementing this on their own would be the same.

Here’s my take on the pros and cons
Pros:

Decoupled implementation from ft and nft, meaning changes in either spec
have no ramifications on multi-token standard
Possibility to have unified data storage for the token a single Lookup or Treemap,
I don’t think that saves a ton of gas.
The ability to do radically different things, i.e. just overall flexibility

Cons:

Decoupled from ft and nft standards, so changes to these standards have to find their way into multi token standard
Duplicate logic , can be mitigated by re thinking maybe some of the standard into some mod that might be useful across standards
Less tried and tested

PR#2
[Feat/use standard by zcstarr · Pull Request #2 · shipsgold/multi-token-standard-impl · GitHub] currently merged into pull/1
[Feat/initial token by zcstarr · Pull Request #1 · shipsgold/multi-token-standard-impl · GitHub]

Background:
In this PR I simply used the pre-existing libraries for FT and NFT and created structure around this to support all the operations, by wrapping around these structures to support development use cases. This means adding some additional structure to smooth out
the way you interact with the contract.

Pros:

The standard will be largely drop-in compatible with the latest versions of the FT and NFT spec
Tried and tested
Terser implementation, easier to dissect if you’re familiar with the existing FT and NFT spec
You essentially can get the same support for all the NFT and FT features fairly easily

Cons:

Tied to the ft and nft spec, so you might have to consider any cascading impact on the multi token standard for changes to
ft and nft.
There are I believe minor storage gains that might be made keeping token ids in one structure, I’d have to measure it out to be certain the difference between 1 map with more data vs 2 maps with less data each.
The coupling might limit the spec from supporting more behavior that’s different from the ft and nft specs.

What are people’s thoughts?

This is just my take, having done a little of the work as a very WIP/POC take, as the PRs are not complete/100% functional yet.

riqi · June 30, 2021, 8:21am

This is basically copying the erc-1155 right, and I really like this approach. I talked with HashRush and OutplayGames and they’re also looking for erc-1155 equivalent on NEAR right now.

Even though it has many duplicate logic from NFT/FT standard, I think there are some use-cases that make erc-1155 a good fit, especially in the gaming scene.

One example is Potion in MMORPG. You might need to bring 1000s of Potion, if we use the current NFT standard, it needs a couple of transactions. Let say the contract can mint 50 NFTs per transaction, we need 20 transactions and that’s gonna be ~60 seconds (3 sec/tx) which is a bad UX.

With that example we have 2 options:

We can use the #PR1 which is based on erc-1155 and is a well-known standard in the ecosystem, we might have the bridge between ETH erc-1155 and NEAR #PR1 later on. Basically NFTs but with supply, minting edition 1 and edition 1000 only in a single tx (Enjin uses this approach)
For some items that have large quantities, we can use FT standard that only has some information/metadata on top of it but developers can just use off-chain metadata for images, etc. (Axie’s SLP uses this approach)

Curious what do you guys think about this.

zcstarr · June 30, 2021, 11:52pm

Even though it has many duplicate logic from NFT/FT standard, I think there are some use-cases that make erc-1155 a good fit, especially in the gaming scene.

I might be missing something.

Both PRs implement the same public interfaces and logically and mostly performance wise the same. I think they would be for the most part erc-1155 compatible interfaces. I noted what’s there, here for ease and what the erc-1155 spec looks like.

It’s probably worth just laying out those traits for discussion to make sure everything is covered and we’re all on the same page and naming makes sense.

The interfaces on hand for the PRs


fn multi_transfer(&mut self,
        receiver_id: ValidAccountId,
        token_id: TokenId,
        amount: U128,
        approval_id: Option<U64>,
        memo: Option<String>
    );
    
fn multi_transfer_call(
        &mut self,
        receiver_id: ValidAccountId,
        token_id: TokenId,
        amount: U128,
        approval_id: Option<U64>,
        memo: Option<String>,
        msg: String,
    ) -> PromiseOrValue<bool>;
    
fn multi_batch_transfer(&mut self,
        receiver_id: ValidAccountId,
        token_id: Vec<TokenId>,
        amounts: Vec<U128>,
        approval_ids: Option<u64>,
        memo: Option<String>,
        msg: String,       
    );
fn multi_batch_transfer_call(
        &mut self,
        receiver_id: ValidAccountId,
        token_ids: Vec<TokenId>,
        amounts: Vec<U128>,
        approval_ids: Option<u64>,
        memo: Option<String>,
        msg: String,
    ) -> PromiseOrValue<bool>;
fn nft_token(self, token_id: TokenId)-> Option<non_fungible_token::Token>;
fn ft_metadata(&self, token_id: TokenId) -> Option<FungibleTokenMetadata>;
fn ft_balance_of(&self, owner_id: ValidAccountId, token_id: TokenId)-> U128;
fn ft_total_supply(&self, token_id: TokenId) -> U128;

//receiver
fn multi_on_transfer(
        &mut self,
        sender_id: AccountId,
        previous_owner_id: AccountId,
        token_ids: Vec<TokenId>,
        amounts: Vec<u128>,
        msg: String,
    ) -> PromiseOrValue<bool>;

//resolver
fn multi_resolve_transfer(
        &mut self,
        previous_owner_id: AccountId,
        receiver_id: AccountId,
        token_ids: Vec<TokenId>,
        amounts: Vec<u128>,
        approvals: Option<Vec<HashMap<AccountId, u64>>>,
    ) -> bool;

ERC-1155

function safeTransferFrom(address _from, address _to, uint256 _id, uint256 _value, bytes calldata _data) external;
function safeBatchTransferFrom(address _from, address _to, uint256[] calldata _ids, uint256[] calldata _values, bytes calldata _data) external;
function balanceOf(address _owner, uint256 _id) external view returns (uint256);
function balanceOfBatch(address[] calldata _owners, uint256[] calldata _ids) external view returns (uint256[] memory);
function setApprovalForAll(address _operator, bool _approved) external;
function isApprovedForAll(address _owner, address _operator) external view returns (bool);

Receiver
function onERC1155Received(address _operator, address _from, uint256 _id, uint256 _value, bytes calldata _data) external returns(bytes4);
function onERC1155BatchReceived(address _operator, address _from, uint256[] calldata _ids, uint256[] calldata _values, bytes calldata _data) external returns(bytes4);

The diff atm I think

balanceOfBatch //trivial
onERC1155Received //trivial everything is batch by default atm trivial
isApprovedForAll  
setApprovalForAll
token-ids are strings vs uint256

Main difference right now is I think token ids and approvals. Token Ids I think from an ecosystem make sense as string, as they can be made erc-1155 directly compatible by implementer, approvals are indeed different, but are more of a philosophical thing I think.

Approval can be written specifically for MultiToken transfer under both implementation strategies. It can also be written to support fts. The approach would be to write an approvals extension for multi token that uses it’s own data structure.

I think the most contentious bit is the setApprovalForAll. It doesn’t really have a parallel currently.

I think perhaps by design. One approach could be to just allow approvals for FTs, with the same pre existing NFT semantics. I think it depnds on where people stand.

What’s the use case for setApprovalForAll vs. setApprovalForSome ?
where some just means given a set of token-ids approve this person to make txs , for fungible tokens this would be without amount specification.

@riqi is this what you were thinking about? Also here how do people feel about setApprovalAll I noticed these kinds of things were taken in a different direction for the NFT standard?

riqi · July 1, 2021, 3:04am

zcstarr:

fn nft_token(self, token_id: TokenId)-> Option<non_fungible_token::Token>;
fn ft_metadata(&self, token_id: TokenId) -> Option<FungibleTokenMetadata>;
fn ft_balance_of(&self, owner_id: ValidAccountId, token_id: TokenId)-> U128;
fn ft_total_supply(&self, token_id: TokenId) -> U128;

These are some key differences between ERC-1155 and the PR. The tokens in ERC-1155 are treated to be more of like an “NFT” with its own metadata standard. I think Semi-Fungible Token is a good way to represent the ERC-1155.

In ETH ecosystem, ERC-1155 is treated as a new asset class, the newly minted ERC-1155 token is not treated as ERC-20 or ERC-721. From the PR, it differentiates the tokens in the contract as either FT or NFT (which has different metadata). So, not sure how we can make the interoperability between ERC-1155 and NEAR Multi-Token Standard later on.

Before we move on to the Approval process, my biggest concern right now is whether we should create Multi-Token Standard that:

Separate its tokens into either FT or NFT
or
Create a new asset class, which is Semi-Fungible Token, just like ERC-1155

zcstarr · July 1, 2021, 5:18am

These are great points. Thanks for clarifying I thought you were thinking more along the lines of the implementation details here orz. I grok what you’re talking about now .

marco-sundsk · July 2, 2021, 4:05am

Thank @zcstarr for telling me this place. As some of you may have noticed, I just created a PR in NEPs for multiple-fungible-token, here.

I am very happy that there is a good place to talk about related things with U guys. I want to take a brief introduction about my PR here for saving your time to read through the whole PR docs.

My PR is actually an extension of NEP-141, you will find they have identical work flow. And The reason why I prefer split it to a new standard, is the change of the interface signature makes it impossible to be backward compatible. That is to say, you can not use this new standard to access current NEP-141 token contract, or using NEP-141 interface to access this MFT token contract. So to avoid confusion, I choose to make it independent.

And the biggest advantage of this MFT protocol, is it can be easily understood and implemented by those who know NEP-141. Futhermore, very few works need to be done if they wanna upgrade their existing NEP-141 contracts to adapt this new protocol and also maintain the whole NEP-141 interface (means they choose to obey both protocols). The backend logic of these two standards are highly similar, so core business logic may be untouched, when they add the new interface support for this MFT protocol to enable accessbility of both protocols.

zcstarr · July 2, 2021, 4:46pm

Multi Token Standard Meeting - 7/7/21 9:30 PM UTC (2:30pm PDT/ 5:30pm EDT)

If you’re interested feel free to drop by additionally here is the location of the full agenda and listing for the meeting. Meeting Agenda.

Location

TBA - day of meeting in the standards discord or ping me for an invite on discord zcstarr

Background

We’re here to discuss what we’d like to have happen with regards to representing semi-fungible tokens. The original thought was that we might create a standard that would be the erc-1155 of NEAR.

What makes ERC-1155 special? ERC-1155 has several features that are of note,approvals, batch transactions, and metadata that is exclusively specified outside of the contract. ERC-1155 relies on events to keep track of things like supply.

What you should bring

Yourself
Openess to ideas
Thoughts on the meeting goals

Agenda

Brief intros - 1-2 minutes
Meeting Goals
Follow up steps

Meeting Goals

Understand the requirements for the multi-token standard. What we’d like to see.
- is it erc-1155 compatibility?
- exchange listability?
- partial ownership of NFTs?
- wallet requirements?
- …
Get clear on the shape of the standard
- Should it be a completely new asset or should it be the composition of the existing standards ft or nft?
Reach soft consensus on this or set a future date for further discussion.

zcstarr · July 10, 2021, 12:05am

Hey all, so we met on 7/7/7 here are the notes .

The overview was pretty positive, most were pro new asset class vs. just composition of FT and NFT. We’re looking to come to consensus next week about it, if you have opinions drop them here. Additionally we have some follow ups about events and event handling. To get a full picture of where we’re at and heading take a peek at the notes on the impl github.

Cheers!

zcstarr · July 15, 2021, 4:19pm

Background

Based on the discussions we had from the meeting. Here is a Core Impl proposal that I think
ticks alot of the discussion boxes. From the previous multi prefix we now have the more terse sft. There is a supply tracking, which deviates from erc-1155, it just seems useful and we can do it. I think simply with an optional supply . The meaning being that if you don’t fill out supply you have no concept of supply for that particular token. ERC-1155 relies on event aggregation to create a supply view.

Approvals in ERC-1155 differ from the ones in the NEAR ecosystem, and it has been mentioned multiple times already that _call convention does exist, and effectively can do the same thing as approvals but better in the sense that you don’t have to approval all your holdings, you can delegate specific amounts.

Core Interface proposal for Semi Fungible Tokens

// TokenId is assumed string 
// Single value transfer
fn sft_transfer(&mut self,
        receiver_id: ValidAccountId,
        token_id: TokenId,
        amount: U128,
        memo: Option<String>
    );
// Single value transfer with call    
fn sft_transfer_call(
        &mut self,
        receiver_id: ValidAccountId,
        token_id: TokenId,
        amount: U128,
        memo: Option<String>,
        msg: String,
    ) -> PromiseOrValue<bool>;
    
fn sft_batch_transfer(&mut self,
        receiver_id: ValidAccountId,
        token_id: Vec<TokenId>,
        amounts: Vec<U128>,
        memo: Option<String>,
        msg: String,       
    );
fn sft_batch_transfer_call(
        &mut self,
        receiver_id: ValidAccountId,
        token_ids: Vec<TokenId>,
        amounts: Vec<U128>,
        memo: Option<String>,
        msg: String,
    ) -> PromiseOrValue<bool>;

fn sft_balance_of(&self, owner_id: ValidAccountId, token_id: TokenId)-> U128;
fn sft_balance_of_batch(&self, owner_id: Vec<ValidAccountId>, token_id: Vec<TokenId>)-> Vec<U128>;

fn sft_total_supply(&self, token_id: TokenId) -> Option<U128>;
fn sft_total_supply_of_batch(&self, token_id: Vec<TokenId>) -> Vec<Option<U128>>;

// receiver for handling _call
fn sft_on_transfer(
        &mut self,
        sender_id: AccountId,
        previous_owner_id: AccountId,
        token_ids: Vec<TokenId>,
        amounts: Vec<u128>,
        msg: String,
    ) -> PromiseOrValue<bool>;

// resolver for handling _call 
fn sft_resolve_transfer(
        &mut self,
        previous_owner_id: AccountId,
        receiver_id: AccountId,
        token_ids: Vec<TokenId>,
        amounts: Vec<u128>,
    ) -> bool;

Core Events

Events are currently being discussed, but the events that we’d probably like are

// TokenId is assumed string
Mint(to:AccountId, amount:Vec<U128>, tokenIds:Vec<TokenId>) // differs from ERC-1155 , ERC-1155 overloads transfer with a from 0x0 address
Transfer(to:AccountId, from:AccountId, amount:Vec<U128>, tokenIds:Vec<TokenId>)
URI(uri: string, tokenID:TokenId);

Let me know what you all think. Does this make sense for a NEP. I feel like the events are a bit out of scope, but I noted them here so we could discuss. The supply issue is a bit of duplicated data, it’s suggested there to make it less painful for contract consumers.

zcstarr · July 24, 2021, 4:49pm

I wanted to drop this here, just for an update on what’s happening. Things are shaping up for the NEP here’s a WIP: Preview, feel free to drop comments etc… as it’s coming together about sections needed etc… . I’m looking to make a PR to NEPs around Tuesday the 27th.

Have a great weekend ya’ll!

Easier readin’

github.com

shipsgold/multi-token-standard-impl/blob/6590b08df1ef58758fee35790731f6ec5a6982a0/NEP.md

- Proposal Name: multi-token-standard
- Start Date: 2021/07/24

# Summary
[summary]: #summary

A standard interface for  a multi token standard that supports fungible, semi-fungible, and tokens of any type, allowing for ownership, transfer, and batch transfer of tokens generally regardless of specific type.

# Motivation
[motivation]: #motivation
Having a single contract represent both NFTs and FTs can greatly improve efficiency as demonstrated by Enjin Coin. The ability to make batch requests with multiple asset classes can reduce a many transactions transaciton to a single transaction to trade around both NFTs and FTs that are a part of same token contract.

Having this will also increase Near's ability to work interoperably with other chains. This will reduce the complexity required to represent these emerging asset classes.


Prior art:
- EIP-1155 : https://github.com/ethereum/EIPs/issues/1155

- This NEP derives some examples and format from: https://github.com/near/NEPs/pull/21

This file has been truncated. show original

zcstarr · July 28, 2021, 4:14pm

Filed the initial NEPs in NEP format feel free to comment.

github.com/near/NEPs

Multi Token Contract Standard

opened 04:08PM - 28 Jul 21 UTC

zcstarr

WG-contract-standards

### Summary A standard interface for a multi token standard that supports fung…ible, semi-fungible, and tokens of any type, allowing for ownership, transfer, and batch transfer of tokens generally regardless of specific type. This standard aims to make it possible to represent these multi tokens in a way that allows these tokens to be represented across chains. ### Motivation Having a single contract represent both NFTs and FTs can greatly improve efficiency as demonstrated by Enjin Coin. The ability to make batch requests with multiple asset classes can reduce a many transactions, transaction to a single transaction to trade around both NFTs and FTs that are a part of same token contract. Moreover, this flexibility has led to building proper infrastructure for ecosystems, that often have to issue many tokens under management such as games. Finally on other chains, such as Ethereum it would be nice to be able to bridge a token contract from near to ETH or to other chains. Having a multi token standard that can represent many different classes of tokens is highly desirable ### Background - Current NEP PR: - PR #245 - Prior art: - EIP-1155 : https://github.com/ethereum/EIPs/issues/1155 - This NEP derives some examples and format from: https://github.com/near/NEPs/pull/21 - Example of an NFT Series: https://github.com/near-apps/gnr8 - Things from the NFT Discussions: https://github.com/near/NEPs/discussions/171 - Things from the NFT Discussions: https://gov.near.org/t/nft-standard-discussion/853 - Discussions out of band: - https://gov.near.org/t/multi-token-standard-discussion/2917 - https://github.com/shipsgold/multi-token-standard-impl/tree/main/meetings - WIP/impl: - https://github.com/shipsgold/multi-token-standard-impl/tree/feat/initial-token - https://github.com/shipsgold/multi-token-standard-impl/pull/1 ### Core Trait ``` pub trait MultiTokenCore { /// Basic token transfer. Transfer a token or tokens given a token_id. The token id can correspond to /// either a NonFungibleToken or Fungible Token this is differeniated by the implementation. /// /// Requirements /// * Caller of the method must attach a deposit of 1 yoctoⓃ for security purposes /// * Contract MUST panic if called by someone other than token owner or, /// * If using Approval Management, contract MUST nullify approved accounts on /// successful transfer. /// * TODO: needed? Both accounts must be registered with the contract for transfer to /// succeed. See see https://nomicon.io/Standards/StorageManagement.html /// /// Arguments: /// * `receiver_id`: the valid NEAR account receiving the token /// * `token_id`: the token or tokens to transfer /// * `amount`: the token amount of tokens to transfer for token_id /// * `memo` (optional): for use cases that may benefit from indexing or /// providing information for a transfer fn mt_transfer( &mut self, receiver_id: AccountId, token_id: TokenId, amount: U128, memo: Option<String>, ); /// Transfer token/s and call a method on a receiver contract. A successful /// workflow will end in a success execution outcome to the callback on the MultiToken /// contract at the method `mt_resolve_transfer`. /// /// You can think of this as being similar to attaching tokens to a /// function call. It allows you to attach any Fungible or Non Fungible Token in a call to a /// receiver contract. /// /// Requirements: /// * Caller of the method must attach a deposit of 1 yoctoⓃ for security /// purposes /// * Contract MUST panic if called by someone other than token owner or, /// if using Approval Management, one of the approved accounts /// * The receiving contract must implement `mt_on_transfer` according to the /// standard. If it does not, MultiToken contract's `mt_resolve_transfer` MUST deal /// with the resulting failed cross-contract call and roll back the transfer. /// * Contract MUST implement the behavior described in `mt_resolve_transfer` /// /// Arguments: /// * `receiver_id`: the valid NEAR account receiving the token. /// * `token_id`: the token to send. /// * `amount`: amount of tokens to transfer for token_id /// * `memo` (optional): for use cases that may benefit from indexing or /// providing information for a transfer. /// * `msg`: specifies information needed by the receiving contract in /// order to properly handle the transfer. Can indicate both a function to /// call and the parameters to pass to that function. fn mt_transfer_call( &mut self, receiver_id: AccountId, token_id: TokenId, amount: U128, memo: Option<String>, msg: String, ) -> PromiseOrValue<U128>; /// Batch token transfer. Transfer a tokens given token_ids and amounts. The token ids can correspond to /// either Non-Fungible Tokens or Fungible Tokens or some combination of the two. The token ids /// are used to segment the types on a per contract implementation basis. /// /// Requirements /// * Caller of the method must attach a deposit of 1 yoctoⓃ for security purposes /// * Contract MUST panic if called by someone other than token owner or, /// if using Approval Management, one of the approved accounts /// * `approval_id` is for use with Approval Management, /// see https://nomicon.io/Standards/NonFungibleToken/ApprovalManagement.html /// * If using Approval Management, contract MUST nullify approved accounts on /// successful transfer. /// * TODO: needed? Both accounts must be registered with the contract for transfer to /// succeed. See see https://nomicon.io/Standards/StorageManagement.html /// * The token_ids vec and amounts vec must be of equal length and equate to a 1-1 mapping /// between amount and id. In the event that they do not line up the call should fail /// /// Arguments: /// * `receiver_id`: the valid NEAR account receiving the token /// * `token_ids`: the tokens to transfer /// * `amounts`: the amount of tokens to transfer for corresponding token_id /// * `approval_ids`: expected approval ID. A number smaller than /// 2^53, and therefore representable as JSON. See Approval Management /// standard for full explanation. Must have same length as token_ids /// * `memo` (optional): for use cases that may benefit from indexing or /// providing information for a transfer fn mt_batch_transfer( &mut self, receiver_id: AccountId, token_ids: Vec<TokenId>, amounts: Vec<U128>, memo: Option<String>, ); /// Batch transfer token/s and call a method on a receiver contract. A successful /// workflow will end in a success execution outcome to the callback on the MultiToken /// contract at the method `mt_resolve_batch_transfer`. /// /// You can think of this as being similar to attaching tokens to a /// function call. It allows you to attach any Fungible or Non Fungible Token in a call to a /// receiver contract. /// /// Requirements: /// * Caller of the method must attach a deposit of 1 yoctoⓃ for security /// purposes /// * Contract MUST panic if called by someone other than token owner or, /// if using Approval Management, one of the approved accounts /// * The receiving contract must implement `mt_on_transfer` according to the /// standard. If it does not, MultiToken contract's `mt_resolve_batch_transfer` MUST deal /// with the resulting failed cross-contract call and roll back the transfer. /// * Contract MUST implement the behavior described in `mt_resolve_batch_transfer` /// * `approval_id` is for use with Approval Management extension, see /// that document for full explanation. /// * If using Approval Management, contract MUST nullify approved accounts on /// successful transfer. /// /// Arguments: /// * `receiver_id`: the valid NEAR account receiving the token. /// * `token_ids`: the tokens to transfer /// * `amounts`: the amount of tokens to transfer for corresponding token_id /// * `approval_ids`: expected approval IDs. A number smaller than /// 2^53, and therefore representable as JSON. See Approval Management /// standard for full explanation. Must have same length as token_ids /// * `memo` (optional): for use cases that may benefit from indexing or /// providing information for a transfer. /// * `msg`: specifies information needed by the receiving contract in /// order to properly handle the transfer. Can indicate both a function to /// call and the parameters to pass to that function. fn mt_batch_transfer_call( &mut self, receiver_id: AccountId, token_ids: Vec<TokenId>, amounts: Vec<U128>, memo: Option<String>, msg: String, ) -> PromiseOrValue<Vec<U128>>; /// Get the balance of an an account given token_id. For fungible token returns back amount, for /// non fungible token it returns back constant 1. fn balance_of(&self, owner_id: AccountId, token_id: TokenId) -> U128; /// Get the balances of an an account given token_ids. For fungible token returns back amount, for /// non fungible token it returns back constant 1. returns vector of balances corresponding to token_ids /// in a 1-1 mapping fn balance_of_batch(&self, owner_id: AccountId, token_ids: Vec<TokenId>) -> Vec<U128>; /// Returns the total supply of the token in a decimal string representation given token_id. fn total_supply(&self, token_id: TokenId) -> U128; // Returns the total supplies of the tokens given by token_ids in a decimal string representation. fn total_supply_batch(&self, token_ids: Vec<TokenId>) -> Vec<U128>; } ``` ### Receiver Trait #### Notes - TokenId is of type String ``` pub trait MultiTokenReceiver { /// Take some action after receiving a MultiToken-tokens token /// /// Requirements: /// * Contract MUST restrict calls to this function to a set of whitelisted MultiToken /// contracts /// /// Arguments: /// * `sender_id`: the sender of `mt_transfer_call` /// * `previous_owner_id`: the account that owned the tokens prior to it being /// transferred to this contract, which can differ from `sender_id` if using /// Approval Management extension /// * `token_ids`: the `token_ids` argument given to `mt_transfer_call` /// * `msg`: information necessary for this contract to know how to process the /// request. This may include method names and/or arguments. /// /// Returns true if tokens should be returned to `sender_id` fn mt_on_transfer( &mut self, sender_id: AccountId, token_ids: Vec<TokenId>, amounts: Vec<U128>, msg: String, ) -> PromiseOrValue<Vec<U128>>; } ``` ### Resolver Trait #### Notes - TokenId is of type String ``` /// Used when MultiTokens are transferred using `mt_transfer_call`. This is the method that's called after `mt_on_transfer`. This trait is implemented on the MultiToken contract. pub trait MultiTokenResolver { /// Finalize an `mt_transfer_call` chain of cross-contract calls. /// /// The `mt_transfer_call` process: /// /// 1. Sender calls `mt_transfer_call` on MultiToken contract /// 2. MultiToken contract transfers token from sender to receiver /// 3. MultiToken contract calls `mt_on_transfer` on receiver contract /// 4+. [receiver contract may make other cross-contract calls] /// N. MultiToken contract resolves promise chain with `mt_resolve_transfer`, and may /// transfer token back to sender /// /// Requirements: /// * Contract MUST forbid calls to this function by any account except self /// * If promise chain failed, contract MUST revert token transfer /// * If promise chain resolves with `true`, contract MUST return token to /// `sender_id` /// /// Arguments: /// * `previous_owner_id`: the owner prior to the call to `mt_transfer_call` /// * `receiver_id`: the `receiver_id` argument given to `mt_transfer_call` /// * `token_ids`: the `token_ids` argument given to `mt_transfer_call` /// * `approvals`: if using Approval Management, contract MUST provide /// set of original approved accounts in this argument, and restore these /// approved accounts in case of revert. In this case it may be multiple sets of approvals /// /// Returns true if tokens were successfully transferred to `receiver_id`. fn mt_resolve_transfer( &mut self, sender_id: AccountId, receiver_id: AccountId, token_ids: Vec<TokenId>, amounts: Vec<U128>, ) -> Vec<U128>; } ``` ### Storage Management Trait #### Notes This is semi necessary for ft token types to be able to refund users for storage of many different token types like gold/silver... this might be slightly out of scope ``` pub trait StorageManagement { // if `registration_only=true` MUST refund above the minimum balance if the account didn't exist and // refund full deposit if the account exists. fn storage_deposit( &mut self, token_ids: Vec<TokenId>, account_id: Option<AccountId>, registration_only: Option<bool>, ) -> StorageBalance; /// Withdraw specified amount of available Ⓝ for predecessor account. /// /// This method is safe to call. It MUST NOT remove data. /// /// `amount` is sent as a string representing an unsigned 128-bit integer. If /// omitted, contract MUST refund full `available` balance. If `amount` exceeds /// predecessor account's available balance, contract MUST panic. /// /// If predecessor account not registered, contract MUST panic. /// /// MUST require exactly 1 yoctoNEAR attached balance to prevent restricted /// function-call access-key call (UX wallet security) /// /// Returns the StorageBalance structure showing updated balances. fn storage_withdraw(&mut self, token_ids:Vec<TokenId>, amount: Option<U128>) -> StorageBalance; /// Unregisters the predecessor account and returns the storage NEAR deposit back. /// /// If the predecessor account is not registered, the function MUST return `false` without panic. /// /// If `force=true` the function SHOULD ignore account balances (burn them) and close the account. /// Otherwise, MUST panic if caller has a positive registered balance (eg token holdings) or /// the contract doesn't support force unregistration. /// MUST require exactly 1 yoctoNEAR attached balance to prevent restricted function-call access-key call /// (UX wallet security) /// Returns `true` iff the account was unregistered. /// Returns `false` iff account was not registered before. fn storage_unregister(&mut self, token_ids:Vec<TokenId>, force: Option<bool>) -> Vec<bool>; fn storage_balance_bounds(&self, token_id:TokenId, account_id: Option<AccountId>) -> StorageBalanceBounds; fn storage_balance_bounds_batch(&self, token_id:Vec<TokenId>, account_id: Option<AccountId>) -> StorageBalanceBounds; fn storage_balance_of(&self, token_id:TokenId, account_id: AccountId) -> Option<StorageBalance>; fn storage_balance_of_batch(&self, token_ids:Vec<TokenId>, account_id: AccountId) -> Option<StorageBalance>; } ``` ### Metadata Trait ``` pub struct MultiTokenMetadata { pub spec: String, // required, essentially a version like "mt-1.0.0" pub name: String, // required, ex. "Mosaics" pub symbol: String, // required, ex. "MOSIAC" pub icon: Option<String>, // Data URL pub base_uri: Option<String>, // Centralized gateway known to have reliable access to decentralized storage assets referenced by `reference` or `media` URLs // supports metadata_uri interface that interpolates {id} in the string pub reference: Option<String>, // URL to a JSON file with more info pub reference_hash: Option<Base64VecU8>, // Base64-encoded sha256 hash of JSON from reference field. Required if `reference` is included. } pub struct MultiTokenExtraMetadata { pub title: Option<String>, // ex. "Arch Nemesis: Mail Carrier" or "Parcel #5055" pub description: Option<String>, // free-form description pub media: Option<String>, // URL to associated media, preferably to decentralized, content-addressed storage pub media_hash: Option<Base64VecU8>, // Base64-encoded sha256 hash of content referenced by the `media` field. Required if `media` is included. pub copies: Option<u64>, // number of copies of this set of metadata in existence when token was minted. pub issued_at: Option<String>, // ISO 8601 datetime when token was issued or minted pub expires_at: Option<String>, // ISO 8601 datetime when token expires pub starts_at: Option<String>, // ISO 8601 datetime when token starts being valid pub updated_at: Option<String>, // ISO 8601 datetime when token was last updated pub extra: Option<String>, // anything extra the NFT wants to store on-chain. Can be stringified JSON. pub reference: Option<String>, // URL to an off-chain JSON file with more info. pub reference_hash: Option<Base64VecU8>, // Base64-encoded sha256 hash of JSON from reference field. Required if `reference` is included. } /// Offers details on the metadata. pub trait MultiTokenMetadataProvider { fn mt_metadata(&self, token_id: TokenId) -> MultiTokenMetadata; fn mt_extra_metadata(&self, token_id: TokenId) -> MultiTokenMetadataExtra; } ``` PR #245

We have a community meeting to talk about the Neps scheduled for next tuesday
08/04/21 7- 8PM UTC-8 Meeting link to be included here closer to the date.

zcstarr · July 30, 2021, 5:42pm

We’re looking to have a community meeting about the NEP for the standard on the 3rd. Here’s a link to the agenda, if you’d like a meeting invite just ping me on discord zcstarr or check the standards channel day of meeting.

Meeting Agenda

zcstarr · August 5, 2021, 3:03am

Pretty positive meeting about the NEP. Still looking to get a few opinions in on it before fully proceeding. Here’s the latest notes from the meeting.

github.com

shipsgold/multi-token-standard-impl/blob/main/meetings/2021-08-03-meeting-notes.md

### 08-03-21 Multi Token Standard Meeting Notes

#### Attendees

- zcstarr - Ships
- riqi - Paras
- matt - Near

### This meeting want
- Understand if the NEP as is covers the immediate use cases.
- Get clear on the traits for the core implementation
- Reach soft consensus on this to set the stage for impl discussion.

@zane: Welcome! We're just going through multi token standard today
and going through issues and walk through the spec and pause and ask questions around the way. just looking to get clear on the core implementaton and try and reach a soft consensus on this and talk about some implementation details and thoughts.

### NEP PR
@zane: What are we looking for? We're looking to support multi token types such as NFT, Semi Fungible Tokens, Fungible Tokens, and everyting in between and to be able to transfer tokens in bulk and receive tokens in bulk. The impetus is from cross chain compatibility, and some of the use cases that come from video games and happenings, one example of a success story is Enjin coin, and it's popularity on the ETH.

@zane: Alot of the background is covered in the NEPs list, starting at the top we ave the guidelevel explanation of things.

This file has been truncated. show original

zcstarr · August 16, 2021, 8:21pm

Next multi token standards meeting is scheduled for 08/17/2021 7PM PDT. It’s largely a reschedule of the last meeting just to verify feedback. Check the standards channel in discord day of if you’d like an invite. Here’s the agenda for the meeting. See you then.

github.com

shipsgold/multi-token-standard-impl/blob/main/meetings/2021-08-17-meeting-agenda.md

# Multi Token Standard Meeting - Tuesday 08/17/21 2:00 AM UTC (7:00pm PDT/ 10:00pm EDT)

## Location 
TBA

### Background
We're going to discuss the NEP for Multi Token Standard get consensus on it and address outstanding issues. We will set next steps for the NEP and discuss what
we need to settle on for the implementation.

[Prior Meeting Notes](https://github.com/shipsgold/multi-token-standard-impl/blob/main/meetings/2021-08-03-meeting-notes.md)
[Nep Issue](https://github.com/near/NEPs/issues/246)

[NEP](https://github.com/near/NEPs/pull/245)

[Derive or macro rules! or else](https://github.com/near/near-sdk-rs/issues/422#issuecomment-844175394) 


### What you should bring
- Yourself 
- Openess to ideas

This file has been truncated. show original

zcstarr · August 18, 2021, 10:10pm

From the last token meeting 8/17/21 - Overall another great meeting with the community on Multi Token Standard. I think we’re at consensus on the NEP, still circulating the results of this meeting and then going to move forward.

Here’s the meeting notes ! Feel free to drop comments or thoughts

github.com

shipsgold/multi-token-standard-impl/blob/main/meetings/2021-08-17-meeting-notes.md

### 08-17-21 Multi Token Standard Meeting Notes

#### Attendees

- zcstarr - Ships
- riqi - Paras
- irfi - Paras
- mike - Near
- marcos.sun - Ref

### Welcome Intro
**@zcstarr** - Welcome multi token standard meeting, we're going to try and come to some consesnus and just go over all the remaining outstanding questions 
in the meeting and figure what the next steps should be 

**@zcstarr**: what do we think about the NEP? Let's start with Marcos comments 


### Github NEP PR Comments
**@zcstarr**: Marco we agree with all the suggestions to consolidate the functions for hte most part resolving around , 
but we had a question about the need for BaseVec<U8> based memos. https://github.com/near/NEPs/pull/245

This file has been truncated. show original

Topic		Replies	Views
We're working on the Multi-Token Standard and want your feedback! Development	0	162	April 10, 2023
NFT Standard Discussion Standards	13	1439	March 9, 2021
[DISCUSSION] Push A Bridgeable NFT Chain Agnostic Standard Standards	0	398	October 14, 2022
Discussion of Soulbound Token Standard Standards proposals , development	9	823	February 6, 2023
[May Monthly Report] Multi-Token Standard (NEP-245) Fellowships	0	99	June 6, 2022

Here’s a quick summary

Should there be a dependency on the existing FT and NFT standards?

Multi Token Standard Meeting - 7/7/21 9:30 PM UTC (2:30pm PDT/ 5:30pm EDT)

Location

Background

What you should bring

Agenda

Meeting Goals

Background

Core Interface proposal for Semi Fungible Tokens

Core Events

Related topics