Disussion around creating an Sway NFT standard

We already have a topic dedicated to discussion of a standard for Fungible Tokens, so we should also have one to discuss a standard for Non Fungible Tokens (NFT’s). What would the community like to see in terms of a standard, i.e: What’s good about ERC-721? What do you not like about it, or wish it had?
Are there features from ERC-1155 we should incorporate, such as batch-transfers, etc…?

We do have an NFT implementation in the Sway-Applications repo as well: sway-applications/NFT at master · FuelLabs/sway-applications · GitHub


NFT standard you would have to transfer specific IDs.

Not sure how the UTXO model would handle that.

If the FuelVM team is able to build in a native token_id value that can be scraped from the transaction, NFT approvals could be removed.

1 Like

Yeah, currently, only the concept of asset_id is baked in, and this only helps with Fungible Tokens.
NFT’s will almost certainly need to be ledger-based just as they are on Ethereum.

I think asset_id can be used wisely to accommodate NFTs as well! Here’s the idea: for non-fungible tokens, we can take the HASH(ContractId, token_id) and use it as asset_id. This way, we can derive which of the tokens belong to the same ContractId and their individual token IDs. Plus, it also allows the token to be treated the same way as fungible tokens at the UTXO level. Using a hash is a guaranteed way to generate a unique identifier so that it is not accidentally spent like a fungible token.

It sounds like the changes you’re suggesting are protocol-level changes IIUC, as currently the assetId of a token is identical to the ContractId of the minting contract.

As for the hashing, I’m not sure I understand your idea completely. As hashing is a one-way function, how do you “derive which of the tokens belong to the same ContractId and their individual token IDs”? Perhaps I’m missing something though :slight_smile:

Not quite the same thing, but the XOR operation could be used in a tokenId derivation (and is reversible), for example (pseudocode):

token_id = ContractId ^ original_creator_address;
original_creator_address = token_id ^ ContractId

The above example will always allow an NFTs original creator to be recovered without reading storage, perhaps for royalties or something. Of course there would need to be more data included in the token_id derivation to support a creator minting multiple NFTs on a single contract.

1 Like

I like this suggestion a lot, thank you for carrying it across the finish line. I’ll definitely be recycling this idea; I get better every day. I had the property of uniqueness in mind generated from the hash – since we would need to differentiate between the non-fungible tokens belonging to the same contract in the UTXO set. I know that these are protocol level changes, but I would love to work on it if at all possible

To keep iterating: in order to support multiple NFTs in a single contract, we could also add a “nonce” that increments every time an NFT contract mints a token. So we would have:
token_id = ContractId ^ nonce ^ original_creator_address

Meliksah mentioned that it could be a challenge to allow other entities (EOA, Contract) to spend tokens on your behalf if an EOA is in possession of a token. While depositing something directly into a protocol could be an option, there are other scenarios where users might want to hold onto their asset and only have it moved upon certain conditions (like when a valid sale is executed on insert platform here). Does Fuel have UTXO spending conditions similar to Bitcoin?

1 Like

Does Fuel have UTXO spending conditions similar to Bitcoin?

Yes, you can look into the predicate program type for this. The example I linked uses the fuel Rust SDK to implement a native multisig using a predicate, but they are useful for creating arbitrary spending conditions.

As for any proposed protocol changes, you would need to open a new issue in the fuel-specs git repo.

For the current iteration of an NFT standard, we’re working with ledger-based tokens just like ethereum (not because I say so but because that’s what we have in the protocol). However, there’s no reason you couldn’t create new hybrid approaches, for example:

Implement a ledger-based NFT contract MyNFT. Whenever a token is “minted”, have the contract also mint 1 of it’s own Fungible Tokens, which would allow for querying the total number of NFTs in existence by checking the balance of the MyNFT contract (check the number of its own Fungible tokens that it currently owns).
This is a bit contrived, as the minting would be more expensive this way, but is more meant to encourage us to consider new approaches given the tools we have to work with.