Hey @sumamu bumped into a slight problem while tryna play with the TestNet bridge. I managed to install version 0.1.2 of Dexter’s browser extension and create a wallet. Following this I texted /faucet alongide my addy to @znn_faucet_bot and received the following confirmation.
However, I still haven’t received any of the test znn & qsr. I also attempted to create a new wallet and texted the bot through another tg account to no avail.
I also got @0x3639 to send my test wallet some znn & qsr
but my wallet is still empty.
I attempted switching my browser from Brave to Chrome and also attempted installing Alpha version 0.1.1 but I can’t see any znn/qsr sent from 0x or from the faucet bot.
is your wallet using the correct testnet node? it should be on
wss://syrius-testnet.zenon.community:35998
wow, can’t believe it was because I was connected to the wrong node :C. Everything came through all at once after I connected to wss://syrius-testnet.zenon.community
Observations from using the test bridge:
25tznn → twznn (Wrapping)
Waiting time for receiving approval from extension= 1:23 mins
Waiting time for the transaction to complete “signing”= over 4 mins
Redeeming the znn to twznn within MM consisted of two stages with the first taking 2 mins and the second being more immediate.
50tznn → twznn
Receiving approval from extension= 1:44 mins
Signing= 0:59 mins
Redeeming= 2 mins then instant.
75tznn → twznn
Receiving approval from extension= 3:13 mins
Signing= 0:47 mins
Redeeming= 2 mins then instant.
75twznn → tznn (Unwrapping)
Receiving approval from extension= 0:45 mins
Signing= 2:25 mins
Redeeming= 2:56 mins
50twznn → tznn
Receiving approval from extension= 0:47 mins
Signing= 2:58 mins
Redeeming= 1:28 mins
Issues identified:
After 9 months of high-paced development, the NoM Multichain infrastructure is finally ready for release: ZIP:sumamu-0002 Final
We are also preparing in parallel the applications to Accelerator-Z and pull requests for the go-zenon codebase.
Finally we’ll have both a decentralized bridge and the Orbital Program. It’s safe to say it’s a very important milestone for NoM. Good work, guys!
The NoM Multi-chain Infrastructure documentation:
You might want to join the convo on the main telegram
The docs are now available in web format here:
https://hypercore-team.github.io/
A lot of effort was invested into this documentation. Constructive feedback is appreciated!
Raising some points that have been addressed in the Zenon TG here:
Re: Orchestrator Nodes
“This design decision is based on the consideration that the security of the whole network depends on NoM consensus running nodes.”
How/why does this translate into the security of the bridge?
“Pillar operators already have both the technical background and know-how to operate nodes and a sufficient stake in the network to responsibly manage this critical piece of infrastructure.”
How do you measure “Responsible Management”?
How does the fact that someone runs a pillar mean they can maintain nodes of other other networks?
What is the incentive for them to do so?
Why did you not go for sentinel implementation which, according to Kaine are the right network participant to act as protocol level oracles (instead of having Pillar operators do this).
Re: Guardians
“Guardians will be elected from prominent members of the community. Their main responsibility is to safeguard the infrastructure in case of an emergency. They will act as judges in case of a major failure of the infrastructure and they are responsible to appoint a new admin.”
Why would “prominence” qualify for participation in a trusted setup?
How is “prominence” measured and who will be the judge of who is eligible?
Can you please show which other possible solutions you’ve exhausted?
The orchestrator has built-in authentication using libp2p and each Pillar already has an “identity”, namely a producer key that has implications for the security of the consensus protocol.
They already have a huge responsibility to maintain the security of the whole network by running consensus nodes.
As I’ve already stated, they have the technical background to run full nodes. Pillars are basically znnd full nodes. Running connectors/relayers for connected networks is an easy task given that the orchestrator supports light nodes and 3rd parties (that are good enough).
An obvious answer: Pillars heavily invested into this ecosystem. It is in their best interest to expand the ecosystem and tap into bigger markets (worth billions of $ combined). Plus the legacy bridge is closing and the remaining markets are either illiquid or centralized.
We like to take everything step by step. We’ve shipped a ton already. And some of you are still questioning us.
If everything goes smooth from now on, we’ll move on to tackle the Sentinels as well. We have many plans for the future.
Because several OG members have a very good track record. You can literally trust them with your funds (for example OTC trades).
We can propose some members and decide together with the community.
I think that what we try to deliver is vital for any young ecosystem. It’s up to every community member to support us or not.
I also think that the code alone speaks for itself and we are literally exhausted at this point. Only the documentation took us 7 days to finish… over 25 pages in total… I think many of you grossly underestimate the tremendous amount of time and resources we’ve already committed to this project.
Thank you for the answers.
I don’t believe anyone doubts the amount of work you have put into this. Yet, this is an open source community and you chose to implement design choices without really entering an open dialogue about them in the first place (despite continuous attempts by community members to engage you in one for months).
It may well be that you preferred focusing on delivering code you felt confident to be the best possible solution for a pragmatic and a fast time to market, rather than engaging in lengthy discussions, that’s fair enough.
But in that case it shouldn’t come to a surprise to you that some people will question your design choices until they fully understand why you made them.
Given that a supermajority of Pillars will need to run your code for it to be useful, educating the community about why you built this the way you did could be critical.
In politics, your loudest critics sometimes turn out to be your most useful allies.
Good luck!
Kuddos to sumamu and his team for the work.
I can’t wait to use the bridge, I’m gonna make a step-by-step guide like the one I did for the BSC bridge, it’ll be the same noob-friendly style. I reckon I’ll LP a small amount as well to be part of the orbital program party.
Love to see your dedication to zenon as well as your dedication to excellence (Mr Kaine is still reviewing, but he mentioned in telegram that he was really impressed by your coding skills!!)
I’m keen to provide some liquidity to the bridge. Can’t wait.
Adding this here
Web
bridge.testnet.zenon.community
Faucets
$ZNN: Telegram: Contact @znn_faucet_bot
$ETH: sepolia-faucet.pk910.de
Feedback
Source:
The upcoming bridge to Ethereum is set to open new markets and opportunities, creating an exciting space for users and developers. To prepare for this change and address concerns from the community and Mr. Kaine, a well-structured plan called the Liquidity Bootstrap & Provisioning campaign has been developed.
The timeline for the campaign is as follows:
Mr.K: Is there a dedicated window of time for bootstrapping the liquidity pools? How will you avoid unfair participation at the start of the Orbital Program?
Before starting the Orbital program, we need to give some time for early participants to transfer their assets, add them to the pool, and then move the pool tokens back to NoM to stake them in the Orbital program. This ensures they have a fair chance to participate. Daily rewards are 561.6 ZNN and 1,250 QSR. During the “Liquidity Bootstrap and provisioning” campaign, up to 250k ZNN and up to 600k QSR extra rewards may be given out based on the campaign results.
Mr.K: Do you have a plan to limit the risk exposure for the liquidity pool?
We have taken many steps to ensure the safety of the bridge contracts and the Orbital contract. These steps include unit-tests, static analysis, internal audits, community audits, and manual testing. Additionally, we will limit the maximum amount of wZNN in the pool to 100k at first to lower risk exposure and provide better incentives for early participants, making it more attractive to add liquidity.
Mr.K: Are there any mechanisms to avoid a liquidity implosion? (LPs swapping the wrapped tokens for the other tokens in the pool in order to provide liquidity)? Opening new market will generate activity which could, in turn, attract front running bots. Is there a way to protect users against this or leverage it to their advantage?
The campaign’s goal is to set up and add funds to the liquidity pools. To lower the risk of liquidity implosion, we will restrict swapping wrapped assets for their counterparts in the pools during the “Liquidity Bootstrap & Provisioning” campaign. This also protects participants and users from front-running during the campaign because a bot would only be able to execute a partial swap.
Overall, the Liquidity Bootstrap & Provisioning campaign has been designed with the best interests of the community in mind. It aims to create a fair, stable, and secure environment for users as they navigate the new opportunities presented by the Ethereum bridge. By implementing these measures, we hope to foster a thriving ecosystem that benefits all parties involved.
How long will this period be?
At least 1 month and likely up to 3 months, but the final period will have to be adjusted based on results.
Not entirely correct. What it actually means is that there will be a certain amount of rewards that will be distributed daily (561.6 ZNN and 1,250 QSR) and in the orbital contract there is an extra amount of rewards (250k ZNN and 600k QSR) out of which an optional amount can be distributed daily until it reaches zero.
