Extension chains

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:

  • 33% distributed to builders (contract deployers)
  • 33% distributed to extension chain validators
  • 34% burned (similar to ETH)

Wanted to discuss how to approach the extension chain development.

1 Like

Are there any other chains like this that I can read about?

Wanted to make sure you saw this. @georgezgeorgez shared it some time ago: How the Sovereign SDK works — Sovereign

Will this be a zkrollup L2?

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.

No. As MrK mentioned, this would be more like a sidechain.

@sumamu has the necessary resources to build a proper zero-knowledge based L2.

I’ve already investigated Canto and why it mooned. The golden fee was in place: contractDeploymentFee

This single piece of ingenuity attracts builders which in turn attract users.

That’s why I proposed the following fee distribution mechanism:

What I really want to debate is how the extension chain will interact with the mainchain.


got it. so will the contract deployer and chain validators receive $ZNN or $xZNN?

@georgezgeorgez do you have any thoughts on this question?

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


Any updates?

I’m finishing some work on Syrius and will get back to the ext-chain development.


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


The first EVM compatible extension chain is now live :alien: :flying_saucer:

How to connect an EVM compatible wallet to the ext-chain:

  1. Install Metamask
  2. Create a new wallet
  3. Go to SettingsNetworks
  1. Post your address below and request xZNN for testing. Maximum amount is 10000 xZNN per user.

Who will be running the nodes when the chain enter in mainnet stage?

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.



Sent. Please check.

1 Like

pls send me xZNN

getting this error, RPC URL isn’t working atm?

Yes. New updated will be pushed soon. The testnet will be up again in the following days.


I was having this issue in Firefox, but not Chrome. I can’t explain why.

1 Like