In my opinion a Layer-2 and/or sidechain implementation will bring EVM/WASM compatibility for NoM and will greatly expand the ecosystem. The NoM Multichain Technology can become a de-facto hub for interoperability within the ecosystem.
This way, the base layer remains minimal & efficient as Mr Kaine emphasizes and all the heavy work/bloat is kept in a separate execution domain.
Pillars produce inflation as ZNN and they will also run the orchestrator nodes. It makes sense for them to also act as validators for a L2/sidechain where fees are paid in ZNN. The L2/sidechain should not produce additional/separate inflation. Pillars can bridge part of their ZNN inflation into the L2/sidechain ecosystem and they will be incentivized to bridge more if usage is high.
ZNN is not a gas token because the L2/sidechain will use a wrapped representation of it. It can be called eZNN or xZNN (execution ZNN).
We can use the decentralized bridge @sumamu built and tweak it to support this type of wrapping. It would be a little bit different from wrapping ZNN to wZNN and unwrapping it later because xZNN will actually be consumed/burnt in the extension chain, so it won’t be a 1:1 backing.
xZNN can be associated with the gas concept for the extension chain.
Since there won’t be any inflation, the extension chain will only have a fee distribution mechanism:
What sort of validator requirements do you think we will have?
Just want to make sure I understand how the ZNN > xZNN would work. Alice deposits 100 ZNN into the “portal” and gets 100 xZNN on the L2. Alice does some “stuff” on the L2 and pays 3 xZNN in fees. The fees are paid to the deployer (1) , validator (1) , and burned (1). We have 100 ZNN locked up and 99 xZNN accounted for.
When the 1 xZNN is burned, I assume that also burns the ZNN also? There was another Cosmos chain that had a model like this that mooned a few months ago. Need to find it. We should look at how the fee mechanism worked.
It would be a little bit different from wrapping ZNN to wZNN and unwrapping it later because xZNN will actually be consumed/burnt in the extension chain, so it won’t be a 1:1 backing.
Canto… The shitposting on Twitter was so insane I actually had to block the word $canto. Maybe we should look at the tokenomics.
How Does Canto Work?
Canto advocates for DeFi primitives like decentralized exchanges, lending protocols, and units of account to be public utilities. That is why they are provided free-to-use on Canto. In other words, a Canto DEX, a Canto Lending Market, and a fully collateralized stablecoin are all built natively into Canto.
Canto aims to pioneer the concept of rent extraction resistance. As part of its policy to provide free public infrastructure, Canto designed its smart contracts in a revenue-sharing manner. More precisely, smart contract creators receive a 20% share of all transaction fees generated from users interacting with a project. The aim is to provide a new ground for economic experiments in web3, where DeFi builders and NFT creators can collectively benefit from a flourishing blockchain ecosystem.
If I understand this correctly, users will not own xZNN. When a contract is called on the sidechain, (and per the 33%, 33%, 34% distribution above), the builder received 0.33 ZNN, the validators receive 0.33 ZNN, and 0.34 ZNN is burned. this 1 ZNN will get represented as 1 xZNN on the sidechain and it will be consumed entirely to do the work. Is this correct?
Users will bridge/swap/convert ZNN for xZNN through an embedded contract (eg ext-chain-embedded) in order to be able to use their favorite dApps that will be live on the extension chain (for example Unizwap, games, meme tokens, NFT collections, etc.).
Users will be required to pay gas fees to interact with the EVM smart contracts. Therefore, they will consume xZNN and it will be redistributed according to the specified percentages directly by the system contract to the contract deployer, burn address and ext-chain validators.
More users => more activity => higher gas fees => more xZNN gets consumed => higher payouts for builders and validators and less ZNN in circulation. It’s a win-win-win situation for everybody.
The embedded that will convert ZNN to xZNN needs to be carefully designed, because there won’t be a 1:1 backing (we need to take into account xZNN burning).
One the ext chain is live on testnet it could be great, marketing wise, to run a stresstest on it. Just seeing those sweet sweet millions tps rolling in
This is still an open question. One possibility is to create a restaking embedded where Pillars or Sentinels can register to be part of the validation set of the ext-chain.
