CIP Draft - Cardano "Smart NFTs"

Most NFT images aren’t stored that way… I was comparing the NFT images now stored on IPFS and the one that would be used by that function.

Yes, then you are right. They are both far from permanent. But then again, who knows how permanent Cardano itself will be?

1 Like

Now you’re becoming philosophical. :sweat_smile:

1 Like

As far as it relates to this standard, we just want a way to ensure all the ipfs hashes that are needed to render an NFT are “knowable”, so that if someone so wishes, they can ensure they stay live.
The problem with allowing arbitrary hashes is that you could add new hashes after the original mint in a non-standard way which was only known to the particular NFT in question - thus obscuring those hashes from someone wishing to preserve the NFT by pinning it. By forcing all hashes to be in the files array, you guarantee that they’re accessible to someone who wants to know them.

It is understood that there’s definitely a demand for fully-on-chain with no ipfs or other external storage - this is another reason to require that Smart NFTs specify which API functions they intend to use in the initial metadata - so that those which make absolutely no use of any off-chain data, can be indicated as such, as this is a desirable feature of an NFT for many.

I’ve had lots of great feedback on this initial draft here and on Twitter, so I’m going to do a significant revision this weekend in response to the feedback, then we’ll be one step closer to an an accepted and implemented standard :slight_smile:


Hello @kieransimkin

It does seem that there is a lot of interest in this. However, there may not be a need to extend/ add anything to 721. I think making a proposal for a completely different standard would be better.

It will allow all those that want to maintain 721 close to industry standards to keep it as is, while new format will allow you to fully explore this format with out having to sacrifice anything to old format or make changes to other CIP 25 additions harder to implement.

Plus you will avoid having your features being shut off. Example:

Your format would allow a viewing application to immediately call API for such NFT. This may pose privacy concerns, since anyone could create such NFT, send it to someone’s wallet and would instantly know when that person opens that wallet because they can monitor that specific API call.

So, any wallet would probably just shut that feature off, or at least give an option to shut it off.

If it was a different standard then 721, then any dApp/ wallet/ website can just choose to not support such feature. While on line viewers or other dApps can choose to support it.

Also, any site that renders the NFT could set up separate limits for this new standard. So, if an NFT is created to attack the rendering site by flooding it with info during the gathering stage, data limits would protect against self DDoS while not affecting regular 721 NFTs.

Having this as a separate standard may allow you to avoid a lot of friction that you would get if you just try to append this to 721.

Very interesting proposal btw. Looking forward to seeing how all this develops. :+1:


Thanks - great feedback.

Regarding the 721 standard - I’m not in favour of creating a new key precisely because I think this is logically an optional extension of the 721 metadata, not an entirely new metadata type - the existing 721 format is kept entirely unchanged and only some additional fields are added - to me that means it’s an extension to the existing 721, not a new one.

The other option is that the “uses” field could be added into a new numbered key of their own - containing only the “uses”, with all the rest of the fields remaining within the 721 metadata key, but I don’t see that it provides any benefit, and only really adds implementation complexity; especially given that I know some places (including my own code, and I believe Blockfrost) - only expose the 721 key by default. You would still have to provide a 721 key anyway for backwards compatibility, so it wouldn’t make sense to repeat the same data in a new key. Also, perhaps a minor point, but still relevant - when dealing with on-chain NFTs, every byte counts, and another key just adds bytes.

I’m not entirely sure if you’re referring to the ERC721 standard when you say “close to industry standards”, as the Cardano CIP 25 version of 721 is already somewhat different (perhaps more mature?) We’re not changing anything in a way that breaks backwards compatibility, so I don’t see it as a problem to add things to a standard - I call that innovating :wink:

All that said, I don’t think it really matters that much either way, and if it makes the proposal more palatable to some people, then generally the path of least resistance is the best one!

Regarding the privacy concern - that is an interesting angle - I don’t think this proposal actually exposes anything that’s not already exposed. The request to query the blockchain for the required data would only be a request from the client to the wallet provider’s backend - so the only way to intercept this would be to either be the wallet provider (in which case you probably already know when they’ve opened the NFT) - or you’d have to be a very sophisticated man-in-the-middle on an unswitched ethernet network.
Also, it’s worth saying that loading NFTs from IPFS (in the way that is already specified in CIP 25) is actually a bigger threat here - if my understanding of IPFS is correct (I’m not an expert) - if I pin a file on my server only, and then reference that IPFS hash from an NFT - my IPFS server will receive a request from the network to provide the pinned file for that hash when the NFT is viewed - it’s effectively an indirect request to me, the NFT creator - so that is probably the route I would go down, rather than trying to intercept some blockchain query between the client wallet and the wallet provider, if I were trying to spy on when people opened my NFTs.

Also worth saying - I would probably argue against wallets running any form of Javascript NFT in-wallet - even if this proposal weren’t on the table. Currently as far as I’m aware no wallets do actually render Javascript NFTs - they show images from IPFS but no Javascript - Just on the basis of principal of minimal surface area, it makes sense to keep user-generated-code out of wallets.

1 Like

It’s a very interesting and promising topic to explore for sure. But I suppose the main question is, what are the security, but perhaps most importantly, permanence implications of this?

Would it make sense to standardise something that has the potential to stop working in the future, due to a possible break in technological backward compatibility?

Approaching this from a creator/collector POV.

While security/privacy could also be a concern, that has already been previously partially addressed in the discussion.

So, what are the implications to the permanence of an NFT that this standard would have if adopted (either, as an extension to 721, or a new standard)?

What’s the likelihood that Javascript itself might change down the line (in decades, not necessarily years) that would render NFTs created on a deprecated API non-functional or partially functional, thus lose a lot of their value/appeal?

From a collector standpoint that’s unacceptable. And at least when it comes to art NFTs the point of view of the collector takes precedence over technical considerations.

As artists, we’ve been thinking and exploring the topic of changing, evolving NFTs for some time. From a technological standpoint, probably the most promising is the approach of Build the Permanent Record | Koii

On Cardano, Artano already has implemented a basic working version of changing NFTs, as early as last summer, in their initial auction. They actually have a Catalyst proposal in Fund 8 to expand the system and make it available to the public Community

If you pose that question, you have to also pose it for the other technologies used right now: Will IPFS still be there in decades? Will JPG/MP4/MP3 still be a widely understood format in decades?

Just looked at one of their iNFTs:
This one is just two different standard MP4s and the logic selecting between them is … Javascript.

You’re right, in a sense I am, had that concern about IPFS since we entered the NFT space early last year.
As I’ve outlined I’m trying to view things from the perspective of the art collector, and prioritise permanence above everything else. It’s hard to imagine that backward compatibility for JPG or PNG won’t be preserved, that’s why I was asking what were the odds that the API involved here would become deprecated (not a developer)? And what would be the result of modifying the existing NFT standard to incorporate this? Not passing any kind of judgment at this point, but trying to examine the issue from all points of view.

From a purely technological point of view, this is of course very promising and exciting.

1 Like

Well, it depends. There are some old image and media formats of the 80s used on Commodores and Ataris that where commonplace back then and for which your image viewer today might not be prepared. But that’s probably still a different case than an Internet full of JPGs and PNGs.

But the same example also shows: There are emulators that emulate these old computers down to every bit of every hardware component, so that you can still enjoy the content produced for them today:

So, if something is successful enough, you will have someone who preserves the ability to view/execute that content. It’s not guaranteed that NFTs in general, Cardano NFTs or a specific flavour of Cardano NFTs will reach this status, though.

But documenting in detail, what is done and how is a good start.


This is absolutely true.

Good things stand the test of time not because they were ahead of their time or cleverly designed for this originally but because enough people maintain the skills to carry the technology into the future by porting the legacy. This is unfortunately also true of many bad things that we bring to the future as technical debt.

Case and point DOS is dead however the dosbox emulator let’s me tinker with games and software from when I was a younger geek decades ago. While that experience is enjoyable for me I have also occasionally needed to use COBOL and IBM mainframes in the 21st century which is something that should have died and stayed dead.

IPFS is technically not actually permanent and was never meant to be used with NFT or even blockchains. However if enough people want the billions of “rare” NFT that are using IPFS currently then I am sure someone will create some kind of “non-fungible-net” in the future that re-distributes all these images and reconstructs the hashes as IPV32 addresses so we can beam them between colonies on other planets and solar systems someday.

If nothing else it’ll be a great joke to perplex people in 2222 similar to how people today traveling in a Tesla might think of the steam powered vehicles of 1822 as a quaint technological achievement.


Please checkout my CIP it might already cover this functionality we might have merging conflicts.
I proposed a way to do this already but instead of using the “uses” key I propose references or refs (or r).

Our proposals share common properties.
Please review this CIP → forum link

Edit: I also added a type for reference here you could simply change that to ‘api’ (which I already included in the definition a while ago) :slight_smile:


The questions about whether Javascript, IPFS etc will become obsolete have already been answered I think - ultimately all NFTs are built on technology which has the potential to become obsolete. IMHO, Javascript is probably no less likely to be around than jpg or png. Also the benefit of having a standard like this, is that even if all the known working implementations of the standard disappear, it can still be reimplemented from scratch based on the standard document itself.

Regarding Artano’s iNFT standard, I’m not really sure what that is - if Artano want to create a new standard for NFTs, I suggest they should draft a CIP as I have done - there’s virtually no information I can find online about this iNFT standard except a forum post mentioning a Catalyst proposal? That doesn’t seem like a serious attempt to create a new standard to me.

1 Like

Hi Jack,
I have had a read of your proposal and I agree it does provide some of the functionality contained here - the problem for us is that it’s too much work to implement - requires a whole new advanced metadata parsing mechanism (beyond the basic JSON parsing mechanism we already use) - Also, having seen some of the metadata disasters that exist out there in the wild, I’m not massively keen on adding any more complexity to the existing metadata JSON standard - people are already having trouble minting their NFTs with correct metadata. This seems to be a problem with Artano’s iNFT standard too - it relies on adding logic functionality to the JSON metadata standard (not that I can find any documentation Artano’s iNFT standard)

To give you an idea of the development time involved - I would probably have to devote at least a couple of weeks of work across our front and back end development teams to support these more complex JSON metadata options - whereas I could add the additional APIs defined here in less than a day’s work - it’s just a lot easier to implement in the renderer, so therefore has much more chance of being adopted by important places like and the popular marketplaces.

I’ve really tried to define the minimum possible specification here, to make it as easy as possible for sites to implement - I imagine there will be a need to continue extending this API as people think of new and exciting things to add - this is really just the starting point - I think people would like a full API to query GraphQL - but again, the reason I’ve not included that in this specification is because it’s quite a big ask for the rendering site to implement that - this initial standard is aiming to be as light-weight in implementation for the site rendering the NFT as possible.

1 Like

I’ve taken all the great feedback on-board and have redrafted this proposal encompasing a number of changes:

  • API updated to be generic and not reference IPFS URLs specifically
  • getTokens() function added to allow “modifier tokens” capability
  • “Renderer” feature added, to give generative NFTs an easy way to completely avoid code duplication.
  • Pagination added to cope with large result sets (and for consistency with CIP30 API)

I’ve now created a pull request for this - you can read the updated draft here.

If there’s any feedback in relation to these updates please do post here and I will make changes as necessary. I am now proceeding to the initial implementation of this standard at Artifct and will update this when I have a reference implementation available for testing.


Hey @kieransimkin, we’ve been building infinite (dynamic/programmable) NFTs since mid-2021 on Artano. Is there anywhere where we can discuss this publicly, such as the NFT guild? Please DM me, so we can continue this conversation, as our metadata already has instructions on how an NFT can change over time.

1 Like

If you’d like to contribute to an open standard, please go ahead and make your standard open so that the rest of the community outside of Artano can benefit from it.

1 Like

It’s not too much work… 90 lines of python. I hope this may help you.

This has now been merged :sunglasses:

Just an update to say that I’m still working on this, and will have some announcements in the coming months about when the first implementation of this standard will be publicly available. Please do continue to provide feedback, as all comments will be read, and where appropriate, suggestions will be taken on-board.