Abstract

NFTs as they are know today are mostly considered as static proofs of ownership of a digital or physical assets. Recently, the emergence of dynamic NFTs (aka dNFTs, NFTs whose metadata can change over time) has been seen as a way for NFTs to bear more real-life value: NFTs evolve as life goes by. However, from the owner point of view, NFTs are still a passive asset: they don’t control how it evolves nor can’t they decide how they should look like.

Because the NFT metadata is actually produced by a function call (the output of tokenURI for instance), we propose to truly see an NFT as a contract call. Following this new approach, we define Programmable NFTs as NFTs where owners can decide which contract call their NFT makes, and Dynamic Programmable NFTs (dpNFT) as Programmable NFTs where the call parameters are dynamic. Especially, they can be the result (the output) of another dpNFT.

In this context, NFTs become a single unit of on-chain computation that can be linked to others, creating a decentralized computation graph. Such graphs can be used for collaborative permission-less scientific research, public policy modeling, and a basic data unit for on-chain dApp.

We would like to thank @Jason Delabays, @Rand Hindi, and the Starkware community for their support and gentle feedback while writing this paper.

Dynamic Programmable NFTs for a Decentralized Intelligence Protocol

From NFTs to Dynamic Programmable NFTs

The ERC721 Standard

NFTs originally appeared as a way to represent “digital ownership over digital or physical assets” (see EIP-721 homepage). Back in the early days of the Ethereum blockchain, before the EIP-721 ever existed, some teams started to think about what could be done on-chain apart from standard cryptocurrencies. As stated by the CrypoPunks founders:

Normally code is run on a server somewhere, and you basically need to trust the person running the server. Ethereum lets everyone execute the code, show each other what result they got, and agree that the code was executed properly and fairly.

We have written code that lives on the blockchain that anyone can use to buy and sell Punks with anyone else in the world.

This seminal work, together with some other projects like the CryptoKitties, paves the way to standardizing on-chain proof-of-ownership, eventually producing the well-known ERC721 standard.

<aside> 📌 The CryptoPunk contract does not follow the ERC721 standard as the project was released beforehand. We also believe that standardization should follow usage and consequently do not propose an EIP yet, but rather only Protocol for people to start digging around this innovation.

</aside>

A general extension used together with the mandatory NFT standard is the NFT Metadata one: it allows the contract to name its collection of assets (all the assets described in the given smart contract), to give it a symbol and, more interesting here, to return metadata for a given asset.

This metadata has to follow the ERC721 Metadata JSON Schema. It imposes three properties:

"name": {
    "type": "string",
    "description": "Identifies the asset to which this NFT represents"
},
"description": {
    "type": "string",
    "description": "Describes the asset to which this NFT represents"
},
"image": {
    "type": "string",
    "description": "A URI pointing to a resource with mime type image/* representing the asset to which this NFT represents. Consider making any images at a width between 320 and 1080 pixels and aspect ratio between 1.91:1 and 4:5 inclusive."
}

Both from its name (Non-fungible token) and from its mandatory fields, we can see that this standard is clearly strongly influenced by the first existing usages of non-fungible tokens like CryptoPunks, which are indeed a collection of images.

The idea of standardizing the ownership of something that is not a usual token (coin) as known at that time but still bears value drove this standard. As a matter of fact, the “NFT word choice” section of the standard stands:

“NFT” was satisfactory to nearly everyone surveyed and is widely applicable to a broad universe of distinguishable digital assets. We recognize that “deed” is very descriptive for certain applications of this standard (notably, physical property).

Alternatives considered: distinguishable asset, title, token, asset, equity, ticket

and in this context, the Simple Summary of the standard speaks for itself: