Is ZTS the best token model, or we can do better?

Zenon Asset Standard

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.

The research: ZTS vs ERC

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.”

The Solution: Zenon Asset Standard (ZAS)

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.

Future-Proofing: Zenon Smart Assets (ZSA)

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.

Example use-cases

  1. Loyalty Points e.g. For using exclusively Uber, you’d receive loyalty points that can be traded in for merchandise or other benefits
  2. In-game points e.g. Buy badges, gems, or any in-game assets.
  3. System/store credits e.g. Provide credits to customers that can be redeemed in-store.
  4. Supply Chain e.g. Track food items through the supply chain to the consumer.
  5. Tickets Sales e.g. Issue tickets to a basketball game where each ticket may have a different value.
  6. Cryptocurrencies e.g. stable coins, fiat currency.
  7. Real Estate e.g. Issue the ownership of a building
  8. Certification e.g. KYC-certified account

Mr B. Thank you very much for this post. Please allow me to ask a really stupid question.

Why is this token standard, as described above, possible on Zenon and not on other L1s? Why do you want to build this on Zenon and not Ethereum, for example. I understand that ZAS & ZSA will be feeless on NoM, but is there some technical advantage to our protocol? Don’t get me wrong. We could not be more excited about this post and your ideas. I’m just trying to understand what makes Zenon unique in it’s ability to deliver this token standard.

Thank you zir!

1 Like

Thanks for your contribution. With this implementation, can we imagine a NFT holding NFTs or tokens ? I’m thinking about gaming (such as the early Cronje game on ETH) where your character is a NFT holding its items as other NFTs (ERC 1155 are a good aproach here, yourr character can hold an unique sword as well as gold, for example).

Ethereum already has several well defined standards that work very well with user smart contracts. I might be wrong, but I assume that the feeless property only applies to protocol level tokens handled by embedded smart contracts. A future VM implementation should consume gas to prevent spam (infinite loops) and will work with user smart contracts. That’s why we’ll have ZAS (ZNN) for interaction with embedded sc and ZSA (WZNN) for interaction with user smart contracts.


Basically the plan is to preserve only minimal properties required by the protocol (for example isBurnable, isMintable) and put the ERC-1155 spec inside the metadata (as JSON).

From my understanding any implementation will leverage the fee structure of the NoM. Zenon Network isn’t feeless per se, users need plasma or / and have to compute pow in order to transact ; this anti spam mechanism should be the same, no matter the type of transaction or smart contract.


I’ve read this many times now.
You’re presenting a solution without describing the problem, I think. I’m assuming you have identified one, but I can’t get a hold on it.

I see the appeal of generalizing things and adding the ability to specialize them. That also has a cost though; standards with fixed properties are clearly specified, efficiently represented and handled. So before thinking about replacing a fixed representation with a schemaless model, I would like to understand why.
Are any applications not possible with the current standard, assuming the eventual existence of a vm and user level smart contracts?


Agree with chadass – my assessment is that everything would utilize the feeless structure because it’s already designed at the protocol level with spam-prevention (infinite loops)… specifically because it does PoW or uses plasma like mana is used in games

and as far as what dumeril is saying, I believe the ZTS standard is overly-restrictive for certain use cases but will let Bryant chime in… that said, per my understanding from Bryant’s post, he would remove certain aspects of ZTS and replace with a more generalized standard… is it possible to create a more generalized standard and keep ZTS in tact?

ZTS for token creation, another standard (ZAS/ZSA) for other things?

Dumeril and this ugly fatass of a Chadass being the bullies as usual. We’re sorry sir.


my take on it was that @mr_bryant is proposing a second NFT protocol (in addition to ZTS) that would be able to utilize both the embedded smart contract that ZTS uses as well as future smart contract mechanisms. It would in theory give us flexibility to attract existing NFT marketplaces/tokens to the NoM via familiar mechanisms. Am I off completely?

We can preserve the ZTS standard at the moment and implement ZAS separately and (optionally) deprecate the future creation of ZTS later after people will migrate their assets.

ZAS (Zenon Asset Standard) will be feeless at protocol level like ZNN, QSR, BTC (hopefully), similar to their ZTS counterparts & will interact with the embedded contracts.

ZSA (Zenon Smart Asset) will be the wrapped representation of a ZAS asset WZNN, WQSR, WBTC and will be used inside a VM that supports user smart contracts.

I already gave the example with BNB and WBNB. To use BNB in smart contracts or dApps like PancakeSwap you need to wrap BNB to WBNB and use it.

Hope this further helps to clarify the differences.

The main idea to replace the fixed properties with a schemaless model is to accomodate the future VM integration regardless of the actual implementation that will be used (EVM, WASM or maybe a custom VM).

I looked into the code and the fixed properties that I suggested to be removed are not used in the protocol/embedded smart contracts.


That sounds about right.

Thanks. So my immediate questions then would be

  1. (to the devs) why were these properties included in the first place? Surely there was some reasoning behind that.
  2. (to you) are these properties a problem that would prevent implementation of nf or other tokens, in any sort of smart contract engine? 2b. Would these changes give you the ability to implement any sort of logic needed for the kind of tokens you have in mind, that would normally require a functioning vm implementation?

My reasoning is, if you can indeed do things that would require a vm in other networks, just by adding a custom (it would necessarily have to be limited to certain bounds) metadata field, that would be a pretty big deal imo.
If, on the other hand, it would be a change only needed to better accommodate the latest crypto trend (let’s not take the upcoming nft revolution for granted) while also introducing an overhead and complexity into the data processing part of the network that’s not required for the core functionality, then I would say it’s probably not a good idea.

1 Like

I guess this boils down to

  • Would it break things we’re maybe not aware of
  • Is it necessary, or would it enable features / use cases not possible otherwise

Regarding the second point; I’m pro experimentation and new approaches and ideas, but when it comes to changes at the protocol level / core code, I think we should maintain a conservative stance as much as possible.

1 Like