Comment on page
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.
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":
{
"image":"ipfs://QmRRPWG96cmgTn2qSzjwr2qvfNEuhunv6FNeMFGa9bx6mQ",
"attributes":
[
{"trait_type":"Earring", "value":"Silver Hoop"},
{"trait_type":"Background","value":"Orange"},
{"trait_type":"Fur","value":"Robot"},
{"trait_type":"Clothes","value":"Striped Tee"},
{"trait_type":"Mouth","value":"Discomfort"},
{"trait_type":"Eyes","value":"X Eyes"}
]
}
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.
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 have an internal string array inside the smart contract which can store multiple metadata IPFS URIs as opposed to having a single string variable that can store a base IPFS URI. Using the IPFS URI array, the minting function can be modified to have a “tokenURI” parameter to add a new tokenURI to the end of the array for each of the new CBNFTs that are minted. 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, as payment won’t be necessary due to the fact that only authorized addresses held by company members should be able to mint, and only one token should be able to be minted at a time.
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 string array that can store the IPFS URIs of legally binding contracts’ digital signatures will be necessary as well; we’ll call this array “legalContractSignatureArray”. 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 “legalContractSignatureArray,” as the change in ownership necessitates a new legal contract to be bound to the CBNFT.
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 modified 9mo ago