Welcome to the multiverse: bridging the Zenon ecosystem

This article has been in the writing for some time and we approached it by asking ourselves questions that we though a community member would have asked in the first place. Below you will find a list with those questions. There’s a lot of information, so you can skip to the ones that spark your interest if you want a quick read.

Who are you?

We are a team of rockstar engineers that tackle complex software projects and strive to deliver comprehensive solutions.

Are you part of the community?

If you want us to take you to our leader, then that’s sumamu.

How did you find out about Zenon?

While looking to fund our work on similar projects by reaching out to other cryptocurrency communities such as Thorchain, we found out about Zenon’s Accelerator-Z funding program and started learning more about it. We decided to participate into the Hyperspace program that has a specific call to action for interoperability solutions.

What did you like about Zenon?

It gives us the opportunity to build on a promising network, while being rewarded for our efforts.

Why are you building on Zenon?

We’ve been working with similar tech before and we believe Zenon has huge growth potential in the mid and long-run.

What are you building on Zenon?

Basically a full-stack cross-chain solution that will enable the flow of assets between Zenon and other blockchains.

What will the bridge do?

The bridge will be based on a lock-and-release mechanism that will allow users to transfer assets to and from Zenon (swap ZNN to wrapped ZNN on other chains and vice-versa).

How are you building it?

By coding it, of course. But before that, there’s a lot of research that we’ve done and a lot more still to be done.

We’ve delegated members of our team for the following tasks: researching existing bridging solutions, learning their faults, assessing their limitations, learning the go-zenon codebase, and also keeping in touch with the community (we know, that can be improved).

With what we’ve learned so far, we’re able to give you some of the details that we’re fairly certain of.

The bridge will have the following components:

1. Bridge Embedded Contract

A new embedded contract is needed in order to allow the secure storage of funds. Our first approach was creating a Zenon address based on a EdDSA pubkey, which we successfully accomplished (including all the necessary unit testing). This work was not in vain since it will later enable us to develop custom multisig tech compatible with Zenon. However upon further research, better ways to design the bridge architecture have been discovered: via the embedded contracts. Although it will be a challenge to get them included into go-zenon, we are confident that the community will support us in this endeavor.

2. EVM Contracts

EVM blockchains will store the funds in smart contracts. To swap assets to Zenon, users will simply need to send them to the smart contract specifying the Zenon address where the funds will be released to. Users will also be able to redeem funds by providing a valid TSS signature when calling the smart contract.

3. The TSS module

TSS is state-of-the-art cryptography that enables distributing access to an address between multiple parties. Just like multisig, TSS allows signing a message with a threshold of M out of N, but unlike multisig addresses, it looks and behaves much like a regular address. This also means that no information about the co-signers is published on-chain.

4. The bridge participants

The participating nodes will provide the infrastructure needed to run the bridge components. They will be running the bridge logic, the go-zenon node (znnd) and the corresponding nodes for each supported network (geth for ETH/BNB Smart Chain, bitcoind for BTC, etc). They will also store and secure the secret shares used to generate the TSS pubkeys.

What about security?

We are aware of the exploits happening right now in the cross-chain bridges space. That’s exactly why we will employ a multi-layered security approach and we’ll get into the details in a dedicated post. One security layer that we’re testing is an innovative delay mechanism, which will allow additional security measures to kick-in and halt operations if abnormal activity is detected.

Will the bridge be audited?

Internal audits will be the first ones to be performed. The community will also have the opportunity to audit the entire code and efforts will be made to engage external parties to perform extensive security audits after the code is open sourced.

What blockchains will the bridge support?

The architecture is designed with support for EVM chains such as Ethereum, BNB Smart Chain and at a later time it will be possible to offer support for Bitcoin.

What assets will be supported?

Any ERC-20/BEP-20 token can be integrated as long as a ZTS counterpart exists. Supporting wZNN and later on wQSR is the primary objective.

Who will be able to participate?

The first iteration will run on Pillars, since they already fulfill most of the requirements for running the entire stack and are most invested into the ecosystem. For the next iteration we are taking into consideration running the entire stack on Sentinels, since there’s already an incentivization mechanism present, and that mechanism can be used to incentivize bridge participants.

What about fees?

There will be fees as they are necessary for preventing spam and as a way to incentivize nodes participating in the bridge.

How will participants be incentivized?

During the first iteration, participants will be incentivized via fees. In the next iteration rewards will be distributed based on participation.

What is the current status of the project?

There wasn’t much public activity on this topic, but internally we’ve been very busy. At this point we’ve been able to fulfill all technical requirements for on-ramp and off-ramp.

How will users be able to interact with the bridge?

Users will be able to interact with the bridge using any means accessible to them. Most users will likely use Web3 apps, since these are already being developed. At a later time, more ways to interact with the bridge will become available. Ideally the bridge will also be directly integrated into the Syrius wallets.

Where can I test it?

All testing is currently being performed internally. As we make additional progress we’ll also be looking into ways to open public beta testing.

When will the bridge open?

We’re expecting to be able to deliver publicly accessible infrastructure by November.

How will you integrate the bridge with go-zenon?

We’ll leverage the already present spork system and create a pull request for the project.

When will it be ready?

By the end of the year, but even earlier if everything goes as expected.

How much will it cost?

It’s difficult to make an estimation at this point, but one thing is for sure: it will be outweighed by the amount of time and energy required by this kind of project (in terms of complexity) and the value that it will provide to the entire ecosystem both in the short and long term. We’ll be posting updates as we make progress and follow-up milestones with Accelerator projects to cover R&D costs. Starting with this post we’ll also be creating the first A-Z project and phase for covering the research we’ve done so far.

What do you intend to do with the funds?

We intend to become a major contributor to the ecosystem and use most of the funds to establish our presence into the network.

Will you develop other projects?

We’ll assess the needs of the ecosystem together with the community and do our best to deliver where our skills meet the demand.

We understand that taking the time to read this post means you are also part of the ecosystem and/or interested in growing it, so we invite you to follow the progress and support our efforts.

26 Likes

LETS FUCKING GO!!! This is really exciting to read. I’m happy to help with any and all testing.

3 Likes

This is awesome! I’m not so tech savy but my only concern is the fees system, I know it’s meant to prevent spamming and incentives nodes participants, but since the NoM is known for its feeless feature, it would be ideal to have this feature on our crosschain solution, is it possible to make the bridge feeless while preventing spam?

1 Like

Brillant! Can’t wait to test it

The fees are most useful for spam prevention when swapping from NoM (which is feeless by design) to other chains. So the other way around could be feeless.

However, when it comes to incentivizing the nodes that participate in the bridge, it’s too early to tell how much will be enough to cover the costs and also maintain interest.

Switching from Pillars to Sentinels could be the move that enables the bridge to be completely feeless.

4 Likes

Sounds great! Looking forward to learn more about it.

1 Like

Welcome to our community, grandiose entrance, way to go. Looking forward to eating Chankonabe with sumamu in space sometime :wink:

I’m particularly looking forward to the TSS implementation as a fundamental building block that allows other applications to be built on top of NoM with a higher degree of security and decentralization.

Just read a medium to inform myself in the fundamental differences between multisig and tss.

2 Likes

Welcome to the community

2 Likes

Worth noting the core team set the precedent for submitting multiple AZ proposals if the current max (5000znn) grant isn’t sufficient for the work being undertaken

2 Likes

Thank you all for the warm welcome!

2 Likes

Who creates and owns the wrapped token contract on the EVM side? With wZNN/BSC it is the Zenon team. But if the team is not involved in the new bridge(s) then who owns it?
Also, how do we manage the minting and burning of the wrapped tokens on the EVM chain side? Today this is done either centrally (eg in wZNN/BSC, and also on bridges such as chainport) or by a smartcontract (which often leads to these terrible hacks which we saw happening again and again).

4 Likes

Good questions, especially with regard to avoiding hacks.

1 Like

Sir, would you be willing to have a twitter spaces to discuss your AZ Proposal?

3 Likes

Great idea

1 Like

@sumamu can we have you join a twitter spaces for the community to ask some questions? Or a scheduled TG chat?

@sumamu any chance you can address the following thoughts shared by another member?

"So the only details we have from the bridge proposal are that it will use TSS and that pillars will run it first, then maybe sentinels.

How does a bridge work? Someone has to run a node for the other blockchain. And watch for transactions there. Are all pillars/sentinels going to run a node for every bridged network? If not all of them, then which ones? This determines how many people have to sign for the threshold signature.

The proposal kinda seems to want to blindly copy the Thorchain model. But Thorchain is a purpose built chain for swaps with the RUNE token providing cryptoeconomic security and incentives.

The proposal suggests that people are going to want to run the nodes for other networks without providing any information about what incentives will exist to run them."

1 Like

Wow, there’s lot of activity here. I’ve been watching this thread for a few days after the initial post, but there wasn’t anything new, so I stopped refreshing it so often. I guess the extra exposure and awareness generated by Accelerator-Z have drawn more people alienz here.

3 Likes

Well, there are 2 mechanisms that can be used:
A. lock and release
B. burn and mint

Mechanism A is used when the EVM side of the bridge doesn’t have minting privileges for the token.
Mechanism B is used when the EVM side of the bridge DOES have minting privileges for the token.

In case of a vulnerability, both mechanism are affected. The main difference is that in case of mechanism A, the damage is limited by the amount of tokens locked in the EVM bridge contracts.

In the case of bridging a ZTS to ERC, which applies to both ZNN and QSR, if the EVM bridge is unable to mint the ZTS’ counterpart on the EVM side, then bridge’s usability is limited by the token’s circulating supply on that specific EVM network, which can cause a complete halt of that ZTS’ ability to be bridged to a specific EVM network.

Therefore, mechanism B would be more appropriate for ZTS’, meaning that the EVM bridge should have minting privileges for the ERC okens that only existed as ZTS’ before being bridged.

Pretty much the same applies for ERC tokens that didn’t have a ZTS counterpart before being bridged.

In conclusion, in the case of any token (ZTS of ERC), that didn’t have a counterpart on the other side, unless there is a third party making sure the bridge has enough liquidity, then the bridge should have minting privileges (mechanism B).

The issues you are concerned with actually rise from the lack of other security measures (which are considered in the bridge’s design already), not from the the choice of using one mechanism or the other.

1 Like

This forum is a great place for discussions because it’s well organized and the content will remain easily accessible for anyone interested in the topic.

3 Likes

How does a bridge work? Someone has to run a node for the other blockchain. And watch for transactions there. Are all pillars/sentinels going to run a node for every bridged network? If not all of them, then which ones? This determines how many people have to sign for the threshold signature.

Like any other bridge, it lets users transfer assets across chains. Yes, node operators will need to provide a full node/light node/3rd party node for every other bridged network. It will be run by Pillars at first because they are the most invested in the network, they most likely have the technical skills necessary to participate in the bridge. They also likely understand the value this bridge can bring to the ecosystem and have the potential to benefit from it. Any active pillar that produces momentums will be able to become a bridge participant. A minimum number of pillars is to be set in order to ensure a higher degree of decentralization and security. The threshold will likely be 2/3 of the participants.


The proposal kinda seems to want to blindly copy the Thorchain model. But Thorchain is a purpose built chain for swaps with the RUNE token providing cryptoeconomic security and incentives.

The same TSS technology is used, however pretty much everything else is different. Just like you said, Thorchain is a purpose build chain for swaps, which provides cross-chain native swaps. That’s the main reason it needs liquidity to run and a very delicate system to secure that TVL. This bridge’s main objective is to allow the bridging of ZTS’ to ERCs and the other way around, which requires a fraction of Thorchain’s TVL.


The proposal suggests that people are going to want to run the nodes for other networks without providing any information about what incentives will exist to run them."

Participants will be incentivized using the fees at first. There is also the Orbital program which could provide a source of incentives. However, in the next phase we’ll be looking into how Sentinels could become bridge participants and how the current incentives model can be changed in order to reward those Sentinels who are active and hones bridge participants.

5 Likes