WHAT ARE EXTENSION CHAINS?
I see extension chains as sidechains (think of a layer-2 solution similar to Liquid Network) that complements and enhances NoM (with smart contracts) and has the following properties:
Allows users of the
ZTStokens between the two networks with a
ZNNused in the extension chain is referred to as
xZNN, and each
xZNNhas a verifiably equivalent amount of
ZNNsecured by the Extension Consensus Group: ECG.
The ECG is operated & governed by a (sub)set of
Pillars. With no single entity in control and a geographically diverse membership, there is no single point of failure - similar to how
Pillarshave strong incentives to grow the ecosystem and will be additionally rewarded in
xZNNto run & manage the extension chain infrastructure (via a fee sharing mechanism). We can re-use some implementation details from @sumamu’s multi-chain technology.
WHY EXTENSION CHAINS?
In my opinion this type of sidechain implementation that can bring
WASM compatibility for NoM will greatly expand the ecosystem. As Mr Kaine already emphasized, extension chains are the fastest way to bring smart contracts to NoM. And we really need
EVM compatible smart contracts to grow the ecosystem. Moreover, the base layer remains minimal & efficient as Mr Kaine strongly suggested and all the heavy work/bloat is kept in a separate execution domain.
Pillars are the largest producer of
ZNN inflation in the network. They also run
orchestrator nodes for the bridge. It makes sense for them to also act as validators for the
ext-chain where fees are paid in
xZNN. It is important to note that the
ext-chain cannot produce additional/separate inflation.
Users, Pillars and every other network participant can
peg-in funds into the
ext-chain to benefit from smart contracts for example. We can also incentivize/penalize
ext-chain users via
peg-out fee similar to @sumamu’s affiliate fee. It is up to the
ext-chain deployer make this decision.
ZNN is not a gas token because the
ext-chain will use a wrapped representation of it. It can be called
xZNN (execution ZNN).
As I already mentioned earlier, we can re-use parts of @sumamu’s bridge and tweak them to support this type of wrapping. If we go with the burning fees, it would be a little bit different from wrapping
wZNN and unwrapping it later because
xZNN will actually be consumed/burnt in the
ext-chain (it won’t be a 1:1 backing).
xZNN can be associated with the gas concept for the
BUILT-IN POSITIVE FEEDBACK LOOPS
Since there won’t be any inflation within the
ext-chain, we must rely on a fee distribution mechanism.
That’s why I propose the following fee distribution mechanism:
- 33% distributed to builders (contract deployers)
- 33% distributed to ECG (
- 34% burned (similar to ETH)
This single piece of ingenuity attracts builders which in turn attracts users.
I’ve already investigated Canto and why it mooned: they’ve implemented the “golden” fee mechanism (
Users will bridge/swap/convert
xZNN through an embedded contract (eg
ext-chain-embedded) in order to be able to use their favorite dApps that will be run on the
ext-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 pay/consume
xZNN and it will be redistributed according to the specified percentages directly by the system contract to the contract deployer, burn address and ECG (
Positive feedback loop:
More users => more activity => higher gas fees => more `xZNN` gets consumed => higher payouts for builders & validators => less ZNN in circulation
A win-win-win situation for the whole ecosystem.
The embedded that will convert
xZNN needs to be carefully designed, because there won’t be a 1:1 backing (we need to take into account
WEN EXTENSION CHAINS?
I’m already working on a testnet that will go live during sometime during Q3 2023. I plan to release a fully functional mainnet release by the end of Q4 2023 or sooner.