6. Specialized CBNFT ERC-721 Smart Contract
ERC-721 smart contracts are the standard for representing the ownership of non-fungible tokens, and they can be modified for different purposes, such as storing the digital signatures of legally binding contracts. Although the additional functions that allow for the instantaneous uploading of signatures every transfer will not be authorized until a trading protocol for this purpose is built, tested, and established, those that use the Phynite Protocol can still use the specialized ERC-721 smart contract as it is certainly possible for this upgrade to be supported, and it will be executed in the near future. This section of the white paper will discuss how standard NFT smart contracts work, the differences of the specialized CBNFT smart contract compared to that of standard NFT smart contracts, as well as its upgradability.
6.1 How Standard NFT Smart Contracts Work
The ERC-721 standard smart contract consists of many functions that can be used for its core functionality of representing ownership of non-fungible tokens. There is a common way such functions are used for the majority of NFT projects, and we must first establish the common methods to display our differences.
Standard NFT smart contracts, including those used for popular NFT projects such as Bored Ape Yacht Club (BAYC), store a base IPFS URI inside their smart contract that points to a folder file containing the IPFS URIs of all of their NFTs’ metadatas, that can be indexed by following the base IPFS URI with a “/[INDEX #]”. Metadata in the NFT space is essentially text in a JSON format containing an NFT’s information such as name, image IPFS URI, or unique traits. For example, the following is BAYC #0’s metadata with the IPFS URI of "ipfs://bafybeihpjhkeuiq3k6nqa3fkgeigeri7iebtrsuyuey5y6vy36n345xmbi/0":
The majority of NFT projects use this method, as they only need to store one IPFS URI which contains a folder of premade JSON files that contain the NFT’s information. When it is time for an NFT project to launch its collection, buyers can mint the NFTs using the “mint()” function of smart contracts which generally have the parameters of “payableAmount (ether)” and “numberOfTokens (uint256).” However, this only works for normal NFT collections that can be arranged ahead of time that have the same minting, and for the purposes of systems such as the Phynite Protocol, different mechanisms are necessary.
Furthermore, most NFTs are transferred using the “transferFrom()” function [6], which is an interface function that is required by the ERC-721 standard. It has the parameters of “from (address),” “to (address),” and “tokenId (uint256),” and by inputting correct arguments into the “transferFrom()” function, the rightful owners or approved addresses can transfer the ownership of standard NFTs.
6.2 Differences to Standard NFT Smart Contracts
As stated in the previous subsection, the specialized CBNFT smart contracts for the Phynite Protocol need a different method of minting as the standard NFT smart contracts’ minting methods only work for collections that can have their NFTs’ metadata premade. This is due to the fact that when someone wishes to create a new CBNFT, new metadata needs to be created and stored on the blockchain to correspond to an NFT.
A solution to this issue is to simply not use IPFS, as IPFS limits the ability to update metadata flexibly. The large benefit of using IPFS is the fact that creators don't have to maintain a server that stores the metadata, and owners of NFTs that have IPFS metadata don't need to worry about the metadata suddenly being unsupported by a server. However, as a company, we have the resources and legal obligation to support such a server, therefore we don't need to face the disadvantages that arise when using IPFS for metadata. This means we can have a designated base URI that would be a HTTPS URL, and whenever a new CBNFT is minted on the smart contract, we would simply upload the corresponding metadata onto the server so that it can be retrieved when the NFT's metadata is indexed through the smart contract's "tokenURI" function.
Furthermore, only authorized addresses should be allowed to mint, as new CBNFTs that are being added to the protocol’s smart contracts should be thoroughly verified. This verification of eligible minters can be done by creating a list of addresses that are authorized to mint that only the owner of the smart contract can modify, then using the “require()” function to check if a certain address that is attempting to mint exists in the authorized array of addresses. Lastly, the standard parameters of “payableAmount” or “numberOfTokens” will not be necessary for the minting function, however, the parameter of "tokenId" will be necessary to assign specific tokenIds to each NFT for reasons to be explained in the next subsection.
Another large difference compared to standard NFT smart contracts are the CBNFT smart contract’s additional specialized “transferFrom” functions that should be able to instantaneously upload the IPFS URIs of legal contract signatures when transferring the ownership rights of the NFTs. Furthermore, a "uint256 to string" map variable that can store the IPFS URIs of legally binding contracts’ digital signatures will be necessary as well; we’ll call this map “legalContractSignatureURIs”. As the “transferFrom()” functions are interface functions required by the ERC-721 standard and simply changing the parameters will result in a change in the function signature (meaning that this function cannot be overridden for our purposes), a new function with a different name such as “legalTransferFrom()” is necessary. The specialized transfer function will have the extra parameter of string type for the legal digital signature, besides the other necessary parameters as stated in subsection 6.1. The new function will replace the old digital signature IPFS URI in the “legalContractSignatureURIs,” as the change in ownership necessitates a new legal contract to be bound to the CBNFT.
6.3 Proof of Identity and TokenId
An extra utility that the CBNFT smart contract has is the ability to generate hashes based on the uniquely identifiable attributes of physical assets, and such hashes can be used as the tokenId or unique identifier for CBNFTs. Such hashes are called Proofs of Identity, as they can be used to verify the identities of physical assets that correspond to such tokenIds. The onchain function which creates these hashes is called "generateProofOfIdentity()," and it uses the popular hashing function, keccak256. The data to be hashed, which we will call "itemId" is a human readable string that describes the physical assets, and a salt (random number that increases cryptographic security) will be used when hashing as well. The hash, which is a 64 digit hexadecimal number preceded by "0x", can be translated to a base 10 number using an onchain function called "getTokenId()." Lastly, a Proof of Identity can be easily validated by using another onchain function called "validateProofOfIdentity()," which has the parameters of "proofOfIdentity," "itemId," and "salt". There are 3 main reasons as to why the Proof of Identity is necessary for the Phynite Protocol:
When users are creating CBNFTs with us by submitting physical assets and signing legally binding contracts that bind both the company and the users to such CBNFTs, we would need to know the tokenIds of the CBNFTs before they are minted. TokenIds are the unique identifiers used to identify the CBNFTs in legal documents which are crucial to legal ownership of assets corresponding to CBNFTs, therefore Proof of Identity can be used to generate such unique identifiers.
Phynite CBNFTs use an HTTPS URL for the baseURI of the CBNFTs' metadata as opposed to IPFS which does not allow data at a certain URI to be changed. The Proof of Identity can be used to prevent tampering of the metadata and cryptographically prove that a CBNFT of certain tokenId has a corresponding physical asset of certain attributes and unique identifiers.
The CBNFT contracts can be used for physically-backed NFT drops. When a user mints a CBNFT in the drop, the the CBNFT will have a tokenId generated from a Proof of Identity. This way, companies like Phynite will have no way of switching assets connected to specific CBNFTs, and minting will not require trust in such companies as they will be legally liable if they tamper with cryptographic evidence.
6.4 Upgradability
As previously stated in different parts of this white paper, the instantaneous uploading of the IPFS URIs of legal contract signatures during ownership transfers is a feature that will not yet be supported, but in the near future. This is due to the fact that the specialized “legalTransferFrom()” functions will need to be used during trades, and the popular trading protocols that allow for the selling and auctioning of NFTs use the ERC-721 standard’s “transferFrom()” function for transferring the ownership of NFTs.
The current most gas-efficient trading protocol is the Seaport Protocol by Opensea, and although the software for this protocol is open source, it is a fairly intricate protocol which necessitates modification to not only the smart contract but its numerous SDKs as well. The Seaport Protocol achieved its efficiency through low level programming using a Solidity “assembly” language called Yul, and a trading protocol of that level of complexity that may potentially manage millions of dollars needs thorough auditing from specialists.
Although the time period in which this development will finish is uncertain, one thing for certain is that this is an engineering problem that can 100% be solved by competent engineers. Therefore, the CBNFT smart contracts for the Phynite Protocol will have the upgradability to allow such features. This can be achieved simply by having a boolean variable that determines whether or not the “legalTransferFrom()” function is allowed, a function reserved for the owner of the smart contract that can modify that boolean value, and lastly a modifier of sorts that checks the boolean value before allowing the “legalTransferFrom()” function to be ran.
Last updated