The Most Popular NFT Standards Make Your Art Publicly Available In Code
In this article we’re going to explore some of the technical nuances of how NFTs work. Together we’ll discover how the current NFT standards do the opposite of protecting your art at the code level, explore some new NFT ideas that could come from this realisation, and learn how to better permission our NFT art going forward.
So what’s an NFT?
Well, obviously it’s a non-fungible token; a block-chain thing that’s unique, one-of-a-kind, with it’s own unique value, properties and ownership.
Ok, but really what is it?
In practice NFTs are functions and data stored in a smart-contract. Some parts of the NFT might also be stored in other places too, like IPFS or a private server.
The NFTs that we’re interested in are the ones that conform to the ERC721 and ERC1155 standards. These are by far the most popular kinds of NFTs and almost all NFTs you find will be either ERC721 or ERC1155 compatible. While these standards differ in implementation, they both provide two core sets of functionalities.
- Functions to control ownership of the token.
- A function to get some data from the token.
For our purposes we’re not interested in the ownership functions. Just remember that these NFTs can be bought and sold on various marketplaces that know how to interact with the ownership functions.
The function that returns data is where we’re going to focus. This is called tokenURI in the ERC721 standard, and just uri in the ERC1155 standard. Our NFT’s image, animation, attributes and any other media will be returned by this function.
Digging in on tokenURI
Lets simplify things by focusing only on ERC721 tokens on the ethereum block-chain. They all have a function called tokenURI that returns the data the NFT points to.
When a website wants to know what the NFT looks like it runs this function. Whatever this function returns will define what the website shows to the user as a representation of the NFT. Often this includes an image or animation.
There are a bunch of keywords in the function definition that define how it behaves. Of particular interest to us is public. Public means that anyone, anywhere can run this function. There are no restrictions as to who can ask for the data that’s used to display what the NFT looks like.
You might be wondering “shouldn’t only the owner be able to run this function? or shouldn’t it be permissioned in some way?” And yes ideally that would be better, but it would make things much more complicated for displaying NFTs on websites, so the standards just make the function public to everyone. These details are often taken for granted by developers without further thought, but they have some strange and serious implications as we’ll see in a moment.
What does running the tokenURI function look like?
We’ll need to know the contract address of the NFT, let’s assume it’s 0x1337d328458b15CbDad00b368ADd0C1422cac687
We’ll also need to know the token id, let’s assume it’s 42 in this case.
Running the function will look like this
The left side is telling our system that we want to use the ERC721 compatible contract at address 0x1337d328458b15CbDad00b368ADd0C1422cac687. And the right side is saying we want to call its tokenURI function with the parameter 42.
This will get us the image and data for the NFT we’re interested in; token 42 from the contract at 0x1337d328458b15CbDad00b368ADd0C1422cac687.
Turning our knowledge in on itself
While we’ve kept things pretty simple up to this point, now we’re going to put it all together and do something novel.
We know how to create our own tokenURI function to display what our NFT looks like.. and we know how to get the data from a tokenURI function to see what that token looks like..
What if we do them both at the same time?
Ok, so this is a bit weird..
When someone runs our tokenURI function, our tokenURI function is going to run the tokenURI function of the contract 0x1337d328458b15CbDad00b368ADd0C1422cac687 using the parameter 42. And whatever image and data gets returned from that contract, our contract is going to return.
We can do this because the tokenURI function is public and anyone can call it at any time, including other contracts within their own tokenURI functions.
So what would our NFT look like on a website?
Exactly the same as the NFT that we’re calling the tokenURI of! With the exception of the contact name, contract address and token id, which are likely to all be different. But the images and data of the NFT will look identical.
Can we take this further?
Sure, what about if we add a function to change the NFT who’s tokenURI we’re running.
We’ve created a couple of variables (data) to store the target contract and target id. And we’ve also created a function called setTarget that anyone can run to update those values.
Now when someone runs our tokenURI function it will run the tokenURI function of whatever our targetContract and targetId point to. Our NFT will look just like that NFT. And if someone runs setTarget and changes targetContract and targetId then our NFT will change in appearance to look like that new NFT.
Our NFT is effectively able to transform to look like other NFTs, using only a couple of lines of solidity.
What would this look like as a serious NFT?
Glad you asked, there’s a long way deeper we can go with things like:
- Allowing each NFT to manage their own targetContract and targetId.
- Supporting ERC1155’s uri function.
- Performing tokenId interpolation from the ERC1155 standard.
- Maybe some cool randomised native on-chain SVG art?
- Maybe even some exclusivity functions when setting NFT targets?
We’ve cooked all that and more into Mimicus Etheriensis (aka Mimic).
Stop by The Mimicologist Guild discord if you’d like to get one on mainnet or testnet to play with.
Can we block our NFTs from being proxied like this?
Sure, if your NFTs are upgradable, or if you’re still building them then it’s actually incredibly easy.
We’ve added a requirement that msg.sender.code.length is equal to 0. This means that if our tokenURI function is run by a user or website then everything works as normal and they’ll receive our image and data. But if tokenURI is run by another contract then we’re telling it to throw a fit and not send them anything.
We could also do something more subtle like this..
What can’t be proxied?
The reason the tokenURI function is so easy to proxy like this is that it’s really not doing much. In most cases there’s nothing dynamic about it and it doesn’t care who’s running it.
As NFTs become more ubiquitous, more interoperable, and the standards become more powerful it’s likely that none of that new functionality will be open to proxying. If an NFT unlocks a website for you, there’s no way to proxy that. If an NFT grants you a vote in a DAO, there’s no way to proxy that either. Not unless the NFT explicitly allows for it anyway.
We’re also likely to see new iterations on the ERC721 and ERC1155 standards becoming more popular. Who knows, maybe this article and the associated code will provide some impetus for that future.
What other uses could this code structure have?
It’s hard to know how people will innovate when a new concept arrives. Often the best uses are not obvious at first.
One application might be for on-chain advertisements where a large set of users hold (or even get paid to hold) an advertisement NFT. The controller of the advertisement NFTs could charge a 3rd party to set all of the advertisements to certain content for a period of time. If the holders of the advertisement NFT like what their NFT is displaying at any given time they can go to market and purchase the actual item.
We’re not sure if this level of decentralisation is really necessary to solve this problem, there may be simpler more centralised ways to do the same thing. But at a minimum it sounds like a great hackathon project!
We hope you’ve enjoyed reading and learned a little too.
— The Mimicologists Guild
Join Coinmonks Telegram Channel and Youtube Channel learn about crypto trading and investing
