My plan is to create standard on Ethereum which can be plugged to Polkadot network via Moonbeam.
I to start simple so I’m trying to focus on improving the security functions in the ERC721. I would love to chat with people that are skilled in token security so I will get better (and bigger) picture on how to improve token security. GitHub - Defi-Cartel/salmonella: Wrecking sandwich traders for fun and profit is a great example of exploit on ERC20 contract. Unfortunately I don’t have much of a knowledge on the token security side and would love to chat with experts in this case.
The main problem I came into is the lack will to communicate from the NFT platforms side, if they are open to collaborate on new standard, if they are willing to implement the new standard…
Many platforms have their own custom implementation build on ERC721 standard that they are using instead of proposing their custom changes as a new standard.
I have many notes on compatible and backwards-incompatible changes that could be made to ERC-721.
But I have never published them because I’m not sure it’s the right thing for the Ethereum community yet.
One major data point is to look at MetaMask, it took over a year to implement ERC-721 in their application and I’m not sure even ERC-1155 (which is very relevant) is implemented.
So if we fragment NFTs further it may be a disservice to the community.
On the other hand, if we’re making a new NFT on Binance or Tron or whatever, AND they have resources to create a user experience (i.e. not just “please use MetaMask and add a chain”) then yes, I would love to work on that and design it better from the start. People at Binance and TRON don’t return my calls, and I guess they are not interested in this.
One thing is to go please people to implement a new standard, another thing is finding a vulnerability that would affect many people and projects.
That’s why I see a huge potential in improving the security component and create implementation for it.
There are many aspects that are missing in the NFT Standards (talking about the ones that are live - ERC721,ERC1155), but the reason why ERC721 is successful is the simplicity of this standard.
Unfortunately simplicity doesn’t means security, especially as the Ethereum is breaking ATH lately, the security of the space and the standards is becoming MUST feature.
There are so many docs dating to 2018, when the Cryptokitties b00m was strong, but the chain has evolved significantly since 2018. The chain went over numerous Hard Forks since then…
I would love to think outside of NFT as Art use cases, after the Uniswap rolled out V3 and liquidity NFTs there will be golden pot waiting for another exploit to happen sooner or later.
ERC-721 and NFTs were designed, and are primarily used (in quantity of tokens and value of transactions), for healthcare, retail, in-game purchases and enterprise use cases. I am excluding one specific NFT token sale in this analysis until evidence can be provided it was not a shill sale.
Your proposal begin the discussion on security with “security - but I’m not exaclty [sic] sure how the non fungibles can have added security”.
This is not actionable advice.
My experience is that many people want to create applications without hiring developers, and publish standards without making applications. This is wholly backwards.
For example, this thread starts with the motivation that ERC-721 is “lacking security”. I consider this fake news given the above reference in the details.
Going forward, I recommend this could be addressed another way.
The concern “I find missing in both ERC721 and ERC1155 standards”… “no attached hash to the image / multimedia file itself as a proof” is better addressed by going to the Stack Exchange and asking “How do I attach the hash of a multimedia file to a ERC-721 or ERC-1155 token?”
The concern “missing downloadable standard which I define as more of a nice to have feature” is better addressed by creating a concrete token product, creating a good user experience, dealing with the practical considerations of building a thing (typically involving spending money and hiring people) and then making it work. Then after you have solved the problem, come back to the community and show off how well it worked, possibly as a standard.
If it has not yet been discussed, I would add a special need here: some metadata identifying the NFT’s general purpose. This enables users to know if a particular NFT is art, a Uniswap liquidity position, a deed to a home, etc. enabling UX on another generalized NFT exchange to warn what the NFT actually is for.
A list of all of these use-types of NFTs could be maintained, with terminology defined, and even warnings created for certain standard contexts (buy, sell, burn).
@fulldecent thank you for comments. You are totally right, NFTs have wide range of usage. There are many ways how to look at the ERC721 as standard itself and we can meditate on this standard for so long as we can come up with a tons of arguments why this standard is good and why not (pros / cons).
I made this thread in order to gain more attention to NFT Standards when I began my research down the NFT Standards rabbit hole. I’m not Solidity dev so I need to gain more knowledge before committing to creating new standard and proposal.
Things are now more developed than they were 10d ago and I’m sharing updates.
I talked to a bunch of people from the NFT industry and figured out that adding Permits as on-chain messages would make the biggest sense how to increase security. I’m sure that over time we can find more extensions that can be added to the standard and solve issues.
I’m working on proposal which will be extension to both ERC721 and ERC1155 as both have ApprovalForAll function. My proposal is to add Permits as security extension to the standards that are already live. Permits will be used as off chain message signatures that will approve (confirm) purchase of the NFT. Author of the NFT will sign message with his wallet which will trigger sale function. This standard will look similar to ERC712 (EIP2612) but it will be usable for non fungible token standards. This security extension can be used not only in art world of NFTs but it can find usage in other not-only-art industries.
Proposal which will be shared to ethereum/eips GitHub repo as ERC when proposal will be ready which may be soon.
Edit: Proposal may change, the research is ongoing. To keep up with WG visit nftstandards.wtf wiki
I would think more often than not, extensions may decrease the security of the base protocol. Any addition to the standard introduces complexity. Any additional complexity might increase the attack surface.
Sometimes extensions are created specifically to address security concerns and do minimize the attacks possible. The easiest example of this was the safeMath code that prevented over/underflow before 0.8.0.
Sometimes extensions improve security dependent on the use case, an example of this would be contract introspection.
In particular meta transactions are a great feature, but in this case I think they create a new set of security challenges that you must be aware of (domain separation, replay prevention, typed data, separation from standard Ethereum messages etc).
Putting security first while adding extensions is of course a great idea if this is what you mean by “security extension”.
Sorry, I didn’t read any of the written (just first 3-4 lines), but I thought this is important for u to discuss without waiting for me (apologies if someone already mentioned it
Although this is a comic show, but if he really made a new NFT for the same small pic then how did that happen?I think there’s something wrong here
(yes one of the small ones, but clearly who ever paid 69m$ considered himself holding the whole collection even if enlarged or under focus) https://t.co/Vfh9E108SG?amp=1
If the buyer of the artwork doesn’t care, a museum making a consolidated NFT for all it’s pieces( I think this what the big pic with small ones inside it mean, right?) will indeed care if a their managed to steal a piece and sold it with a new NFT.
Hey nginnever, we did more research and came out to conclusion to create Permits NFT Standard. Over the time this idea has evolved from Security issue improvement to more of a UX and cheaper minting experience. Permit would improve UX by removing the need to perform an extra transaction, especially in the context of an escrow-less sales where the seller want to keep ownership until the sale is performed. @Amxx made draft code of a proposal which you can find here.
We would love to hear community input and feedback on this idea.
Really liked the ideas here to enable renting NFTs @peroket and I have been working on an ERC721 extension IERC721Rental that transfers the token’s ownership temporarily to the renter and delegates the rental logic to another contract IERC721RentalAgreement that guarantees that the rental terms are honored.
Just discovered this post. I also want to add my thoughts on the existing EIPs for NFTs, such as ERC721 and ERC1155. Their design logic draws from ERC20 and fungible tokens(FTs). However, through research and practice, we have found that NFTs have more practical value than FTs. NFTs have more use cases and potential. Therefore, 721 and 1155 appear somewhat outdated.
This standard is an extension of ERC-721. Its inspiration comes from the abstraction of real-world asset relationships. It separates the holding right and transfer right of non-fungible tokens (NFTs) and Soulbound Tokens (SBTs) and defines a new role, guard with expires . The flexibility of the guard setting enables the design of NFT anti-theft, NFT lending, NFT leasing, SBT, etc.
By using modern tax theory, various royalty schemes are proposed to better fit the diversity of NFTs and industry development. Through research, most of the royalty schemes can be implemented without any improvements to EIP2981. Better and More Diverse Royalty Schemes