Hi guys, I am Bryant and I know Zenon from your member MoonBaze who convinced me to join. I’ve been looking through the tech & Zenon seems to have an elegant design for addressing the limitations of most L1s. I’d be happy to implement NFT support on Zenon and be part of your decentralization mission. But bear with me as I am fresh to Zenon and feel free to question or challenge me.
I have read the NFT article and from my POV, the team vaguely guided us on how to build NFTs and although the steganography add-up is cool, I don’t find it to be critical until a spec is defined and implemented.
I started digging to understand how can we build NFT support on Zenon and after days of active research & design tinkering, I think I finally came up with a solution.
Firstly, I started by analyzing Ethereum Improvement Proposals such as ERC-20, ERC-721 & ERC-1155 to see how can we adapt the whole ZTS specification to add NFT support.
The current ZTS spec is very similar to the ERC-20 spec. We know that ERC-20 is a token standard for creating fungible tokens on the Ethereum blockchain. Similarly, the ZTS spec is almost the same thing, the only structural difference is that ETH users must deploy an ERC-20 smart contract, while Zenon has an embedded smart contract that handles the creation and management of the ZTS.
ERC-20 & ZTS have a similar smart contract design with the following interface functions: totalSupply (maxSupply for ZTS), transfer (protocol-level for ZTS), owner.
Now, let’s take a look at ERC-721 which defines non-fungible tokens. The interface functions of an ERC-721 smart contract are balanceOf, ownerOf, approve, transferFrom and tokenID. However, in terms of deployment, ERC-721 requires a separate smart contract for each token while again, Zenon has only one embedded smart contract that operates at the protocol level.
The last Ethereum I mentioned is the ERC-1155 which was launched in 2018 and opened a new chapter in Ethereum’s history which in my opinion was the true game-changer that filled a void in the market. Fungible and non-fungible coins could be created in the same smart contract: “[…] the key principle of ERC-1155 is that a given, smart contract can control an endless amount of coins.”
Combining the abilities of ZTS and NFT, we can create an all-inclusive asset standard that can be operated by both user and embedded smart contracts.
My solution is simple & quite elaborate at the same time: creating a new “umbrella” standard, the “Zenon Asset Standard” which will represent the foundation for ZTS (Zenon Token Standard), NFTs (Non-Fungible Tokens), Bonds, and many more.
ZAS (Zenon Asset Standard) would be a layer 1 feature that will allow users to represent any asset on the Zenon chain, benefiting from the same level of security and feeless property as the native ZNN & QSR.
Here are some concepts that need to be clarified:
- How to issue ZAS assets
- ZAS specification
- Interaction with embedded contracts (protocol level)
- Interaction with user smart contracts (e.g. EVM integration)
Zenon currently works with embedded smart contracts that are defined at the protocol level, but user smart contract support can be added by integrating for example the EVM support into the chain. This will enable users to deploy and run smart contracts and those contracts will need to interact with protocol-level assets.
Zenon Asset Standard specification
Update the ZTS spec and create the Non-fungible Token specification
- Deprecate/remove the following fields: “isUtility”, “tokenDomain”, “decimals”, “name”, “symbol”
- Add an extra optional field called “metadata” in JSON format
A ZAS resembling a ZTS will have the deprecated fields moved into the newly created metadata field. A ZAS resembling a NFT will have a totalSupply of 1, a maxSupply of 1, and no decimals spec in the metadata field. Any NFT-specific fields will be added to the metadata field.
After the integration of user smart contracts, the next logical step will be to enable ZAS to be used within them.
For example, one can wrap the ZAS into a ZSA (Zenon Smart Asset) to be used by user smart contracts. Therefore, the user smart contract can have functionalities that can freeze, blacklist, whitelist, or charge fees upon making transactions with this token. On the contrary, using a ZAS asset inherits the protocol-level properties such as censorship resistance (no one can block transactions) and the feeless property.
Embedded contracts will only use ZAS protocol level tokens, NFTs, etc.
When user smart contracts will be available, the ZAS will be wrapped as ZSA (Wrapped ZAS => ZSA, similar to BNB/WBNB on BNB Smart Chain) in order to be used in the user smart contract logic.
- Loyalty Points e.g. For using exclusively Uber, you’d receive loyalty points that can be traded in for merchandise or other benefits
- In-game points e.g. Buy badges, gems, or any in-game assets.
- System/store credits e.g. Provide credits to customers that can be redeemed in-store.
- Supply Chain e.g. Track food items through the supply chain to the consumer.
- Tickets Sales e.g. Issue tickets to a basketball game where each ticket may have a different value.
- Cryptocurrencies e.g. stable coins, fiat currency.
- Real Estate e.g. Issue the ownership of a building
- Certification e.g. KYC-certified account