How to implement ZNN/QSR on (Hyperion)

One factor to launching a NoM architecture extension is that NoM has emissions - and an extension-chain can’t emit ZNN/QSR out of thin air. Numerous community members have voiced the desire to concentrate focus on ZNN and QSR, rather than creating new utility assets for extension chains, which could dilute the value and focus from ZNN/QSR. I agree with that sentiment.

My thought is that collateralized ZNN/QSR could be emitted from a contract controlled address, but this requires development. Therefore, an initial Betanet with Betanet tokens would serve to get the governance and emissions development accomplished before moving on to a more robust (Hyperion) brand.

Please discuss.

what sort of contract? Embedded on the L1? How do we get it from the L1 to the L2?

I’m imagining that ultimately, AZ would be enabled pay out to a third party address.

The receiving address could be somehow connected to an emissions contract on the L2.

Not exactly sure what this means. Are you proposing that the L1 emit tokens using a different token standard? Do tokens get on the L2 through an AZ emitted from the L1?

These are good questions. I think it’s wisest to let them stand, and allow others to engage because while I would like to see collateralized ZNN/QSR utilized as the native tokens on L2, we have to figure out how.

Therefore, if utilizing ZNN/QSR is an absolute must, we need someone to design a workable solution.

Through that process, we will either achieve the preferred outcome, or we will have to adapt to another idea.

1 Like

The problem you are describing is not exclusive to us, in general terms. The final implementation no doubt will be custom made for us, given our unique dual-coin architecture, but the ways in which many other chains approach the issue could help us determine a candidate path forward.

We should research them.

bZNN and bQSR could imply they are collateralized

1 Like