Backed by blockchain technology, NFT is poised to revolutionize the digitization of ownership. To better understand its digital transformation and make a fully informed choice, it may be wise to know the mechanisms, and understand what is happening behind it.

What is the technical part behind all these features? How did these new standards come to be and why?

I - Technical properties

• Indivisible: An NFT cannot be divided into chunks, unlike the bitcoin which can be divided until it reaches its lowest unit "satoshi".

An NFT is an entity which is uniquely defined, even if the ownership can be shared by consensus, the NFT behind will remain intact.

• Non-interoperable: Each NFT is bound to a specific smart contract which contains the properties bound to this token as well as actions which can be triggered on it. Thus a Aavegotchi character won't be allowed natively in CryptoKitties for example, despite the fact that they're both on the Ethereum blockchain.

Contracts and teams are developing a rich landscape and environment for further collaborations.

• Indestructible: As smart contracts stores the whole NFT structure, and makes these metadata public, its token cannot be destroyed.

Even if you can burn an NFT by sending it to an address that can't redeem it, the identity of the token will still be accessible.

• Verifiable: It is possible to trace any movement of a NFT since its origin, making it easy to verify the nature of the NFT you're buying instead of a scammy one. Any attempt of replication will raise flags to possible buyers, for example that this mythic NFT art piece is only 4 days old.

These are the main properties a NFT must possess.

The owner of a NFT is the only person able to move it, and he/she owns the rights on this art NFT for example despite the fact that it didn't create it, even the society that emitted might have no more rights on it.

II - First NFTs

Bitcoin and the emergence of new tokens

After the emergence of the Bitcoin network and its incredible strength, Bitcoin was no longer enough. It wasn't long before the urge to add other tokens came to the minds of bitcoiners. It was necessary to be able to describe other assets, other tokens representing quantities or even unique items.

The first attempt was called "colored coins".

By adding metadata to bitcoin transactions, usually of a small amount, it is possible to "color" this amount of BTC. Indeed, 100 satoshis sent with the code "OWNEST" representing shares of Ownest, would be interpreted in a blockchain wallet compatible with colored coins as 100 shares of the company Ownest. This allows the creation of new classes of tokens and by adapting a standardised protocol, allows the implementation of specific exchanges of assets, and not only of BTC.

The first implementation of the colored coins protocol by ChromaWay worked by adding data directly to the metadata of bitcoin transactions. Technically this was done by adding an nSequence attribute which is a 32-bit integer whose last 6 bits represent the colored coin's "tag" allowing it to be associated with its family.

The second, more standardized implementation by OpenAssets uses opcodes instead, instructions that allow bitcoin to have a non-Turing-complete script language. Indeed put end to end these instructions form a logical chain of functions to check various conditions, such as the ability to prevent the movement of bitcoins associated with this transaction by this instruction:<expiry time> OP_CHECKLOCKTIMEVERIFY OP_DROP OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG.

Using these mechanisms OpenAssets has in fact standardized an implementation based on the "OP_RETURN" opcode, which can either mark a transaction as invalid or be used to bring in metadata as of version 0.9 of the btc protocol.

But let us return to the NFTs, and observe as Bergson already described:

"No doubt one will count the sheep of a flock and say that there are fifty of them, although they are distinguished from each other and the shepherd recognizes them without difficulty." (Bergson)

Now that we can create families of tokens, we still lack the characteristics to obtain a token with the characteristics of an NFT.

Counterparty was the first implementation of NFT on a blockchain. It is a software layer that relies on the Bitcoin network data to represent certain aspects such as the ownership of NFTs and their characterization. Through extensive standardization and the use of metadata in transactions, they created the first NFTs.

But innovation is moving fast in the sector and Ethereum will bring a modernity and an additional flexibility to the management of these NFT.

III - Ethereum standards

Undoubtedly the standardization of these protocols is essential to achieve a uniform and interconnected environment, and also to be able to create browsers and other visualization interfaces that need standards to work.

Before going further on Ethereum token standards it is necessary to recall that every token on Ethereum other than the ether, its crypto-currency, is managed by a smart-contract.

A smart-contract can be seen as the combination of object classes and storage made available to the users of the blockchain. The storage contains the long term data that the smart-contract must keep accessible in order to function, this one is actually managed by the methods of the contract, which drive these modifications. Any public method of the contract can be called by any address of the network, the contract will then evaluate if the rights of the caller are well in agreement with its request, if the arguments provided with this call are well in accordance, etc, until it reaches the result.

A smart-contract can thus be seen as a decentralized class on which everyone can interact according to the rules of the contract, i.e. the exposed methods. Unlike Bitcoin, the Ethereum network has a complete Turing language.

These smart-contracts, which can be developed in Solidity for example, are then compiled into bytecode (binary code) that can be executed by the EVM, the Ethereum Virtual Machine. The EVM is in fact responsible for the interpretation of the calls to the methods of the smart contracts, and each node of the Ethereum network compiles in an identical way thanks to the EVM.

From the space of freedom that comes from these smart-contracts several standards have quickly emerged: the fungible tokens ERC20, non-fungible tokens ERC721 and recently a standard proposing semi-fungible tokens, ERC1155. Many others could be cited but the list is long (https://eips.ethereum.org/erc).

We will concentrate only on these two standards modeling NFTs: ERC721 and ERC1155.

• Principles and structure of the NFT ERC721 standard

The ERC standards are described in Ethereum as a set of methods, attributes or events that a smart-contract must have. The ERC721 standard is the minimal interface that a smart contract must implement to allow the management of unique tokens, their possession and their exchange. It does not constitute a standard for the management of metadata associated with tokens and does not prevent the addition of additional functions.

"ERC-721 defines a minimum interface a smart contract must implement to allow unique tokens to be managed, owned, and traded. It does not mandate a standard for token metadata or restrict adding supplemental functions." erc721.org

On this contract it is necessary to be able to access a data structure called mapping in Solidity which links a tokenId to the properties of the token registered on the contract, like its current owner.

To be ERC721 compliant here are also the minimal methods to have:

• balanceOf(address _owner)**` to get the balance of an address, i.e. the number of tokens it owns on this contract
• *ownerOf(uint256 _tokenId)* to get the address of the current owner of the token
• *safeTransferFrom** and *transferFrom** which allow to transfer a token of the contract identified by its tokenId from _from to _to.
• Approve** and *setApprovalForAll** allows you to authorize or revoke the right of an address to send tokens from the wallet to another address. The authorized addresses can be other users or an operator (like a smart-contract or a decentralized exchange).
• *getApproved* and *isApprovedForAll** allows to get if an address is authorized to transfer tokens from the wallet

Each of these methods generates events when a transfer or an authorization is made, traces that are visible to everyone and registered on the Ethereum decentralized registry. These traces make it easier to understand the nature of interactions with a contract, in the case of blockchain explorers.

In addition to these traces, other data such as the name of the ERC721 and its short name are also filled in on the smart-contract, for example by the declaration ERC721Full("Ownest", "OWN") which creates an ERC721 contract with the name Ownest and whose tokens will be qualified by "OWN".

Here is the visibility obtained on a blockchain explorer like Ethereum for a transaction with a contract managing ERC721. You can see in the 3rd section "Tokens transferred" that there were 2 transfers of this ERC721 token for this transaction:

In reality this transaction represents the purchase of an Ethereum domain name called ENS: Ethereum Name Service. This domain name is represented by a token ERC721 here called "ownest.eth" obtained by the ENS. As this name did not exist the first creation transaction comes from the address 0x000... to the address of ENS, then from ENS to my address. This makes it easy to find the Ownest address by searching ownest.eth in the ENS contract or an explorer. Here is a real transaction of this service if you want to inspect the blockchain further: https://etherscan.io/tx/0x5fe5ed7ad3888351d1b141c9c48a298f4ecd1e73436cabc4c8209beb5c65d022

A complete implementation of these standards is provided by OpenZeppelin if you want to try to implement them I advise you a tour on their github reporetory https://github.com/OpenZeppelin/openzeppelin-contracts

A multi-token standard: the ERC1155

But each ERC721 family requires its own contract, and it can quickly become complicated to add a contract for each class of tokens you own. At Ownest for example, we have hundreds of NFT types, from parcels to luxury goods, which are all stored in the same contract.

IMAGE

This multi-token standard is called ERC1155. It makes it possible to manage different types of NFT within the same contract. It is even possible to manage fungible tokens within this standard.

A big advantage quickly follows: instead of having to call 10 different smart-contracts to transfer your assets, these transfers can now be done in a single transaction. This has several beneficial effects:

• a better UX for the user who does not have to validate each transfer individually
• a reduction in transaction costs since they are grouped in one, and also a reduction in network usage
• storage space on the distributed ledger is also saved because there is only one contract rather than hundreds

Now that we have a network that has agreed on these different structures of tokens it is now possible to create all types. On Ethereum there are thousands of them, of all types, of various usefulness or legitimacy.

But how to motivate the use of these tokens? How to bring this digital transformation to the largest number of people and guarantee the life of the ambitious projects underlying these tokens?

IV - Tokenomics

The same is true for "tokenomics": these are a set of smart-contract rules that will allow to convince or at least to incite users or investors to engage with the token. Many processes can be used, from financial rewards to other rewards. It is sometimes necessary to convince players, creators, sellers or buyers and every parameter of the tokenization of a project is taken into account.

This uses game theory to guide the behavior of a player in a dynamic environment if he wants to maximize his success.

Let's quickly see how some projects have created these "incentives", these involvement mechanisms.

Aavegotchi

Aavegotchi allows you to collect a number of virtual ghosts, the gotchis. Each gotchi is an NFT, and it can be associated with clothes and accessories of all kinds. In order to further engage users in perfecting the style of each ghost, they have developed a "rarity farming" mechanism: the 100 rarest gotchis get rewards in $GHST, the currency of the Aavegotchi ecosystem. This way, each player is encouraged to go further in the construction of his universe and it becomes a common goal for the players to reach. In addition to guaranteeing the involvement of the players, this also encourages the diversity of these little creatures, the gotchis, in order to have a universe that is always evolving.

The $GHST currency can be used in several ways:

• be exchanged in-game for items, gotchis
• to be exchanged against other crypto-currencies on decentralized exchanges like Quickswap for example
• be used in votes for the evolution of the project.

Indeed, the governance of decentralized projects tends to be democratic: the owners of $GHST are thus invited to vote for or against the various proposals of the developers or the community.

To perfect the tokenomy of the project Aavegotchi also allows to include tokens from their other project, a kind of blockchain bank with interest included. Indeed if you deposit 10ETH on Aave, you will not get 10aETH and each aETH earns a certain percentage per year. These aETH can now be inserted in properties on a gotchi in order to reinforce its power and uniqueness, and even the profitability of these deposits.

Rarible

Rarible is a platform for selling digital art. Each creator can define the percentage he will receive from the subsequent sales of these works. This is an incentive for creators to choose this platform in order to have the choice on their financial strategy and allow them to earn a sustainable income.

A photo on the internet can be resold/produced without the author being aware of it, so it guarantees a minimum of long-term remuneration for each artist's work.

By guaranteeing the presence of artists it allows to offer more works to the different visitors of the site and therefore maximizes the probability that a buyer and a seller will do business.

Ownest

At Ownest we want to be able to prove at any time who is responsible for a product within the supply chains. To do this we have developed NFTs representing physical assets, which are held by the owner of the physical product.

For example, as long as a driver has 10 pallets and 40 packages in his NFT portfolio, he is responsible for the physical products. So he can't for example transfer these tokens to another address without his agreement, it would be too easy to get rid of them and we can't guarantee that the new owner will become responsible or even be informed about it.

To transfer NFTs it is necessary to have the agreement of the destination wallet. This avoids any transfer that would aim at getting rid of the responsibility.

Moreover, as each person is responsible for the contents of his or her portfolio, this will encourage users to remember to transfer them in parallel with the physical transfer. Also, the condition and quality of the received products can be validated by consensus between the two parties and each received good can be scrupulously inspected in order to correctly report its condition.

With these mechanisms we can match the NFTs of our customers in their logistic networks to a present reality, so that the token always describes the current state of the physical product and its owner.

The technology and standards behind NFTs are constantly evolving, and it is likely that their definition and capabilities will change again over the next few years. Use cases and their variations will continue to test these standards and others will continue to emerge. One example is the acknowledgement of receipt mechanism developed within Ownest, which has no standardized equivalent.