[DCP-5] Cross-Chain Staking Development Options for DappRadar

Proposal Discussions
#1

The Snapshot vote has been confimed and it is decided that we will continue with LayerZero’s solution.

Summary

This year, DappRadar implemented an industry-first cross-chain staking functionality based on our technology partner, LayerZero (LZ). Our aim was to remove barriers for cost-conscious users to participate in staking by eliminating high fees, thus democratizing financial inclusion.

We were able to successfully allow our users to access RADAR staking from multiple chains, however, when working with any pioneering technology – development issues are commonplace. We were proactive with any issues, and early on upgraded our smart contracts from V1 to V2 when hardware wallets were not able to sign messages. However, another issue soon arose when, on September 8th, LayerZero (LZ) upgraded their smart contracts. DappRadar was not informed about any potential issues with the upgrade and therefore, the issue was only discovered afterward which resulted in an instant pause on cross-chain RADAR staking.

On September 9th, LZ eventually informed us that they would take 2-4 weeks to develop a workable solution which we communicated to the community. However, after missing this deadline, and providing a lack of updates to the DappRadar team, we were not able to give our community the certainty they needed.

On October 8th, LZ finally informed us that:

  • they would need a further 2-4 weeks to develop the solution or
  • our team could develop a solution and LayerZero would cover the development expenses

In the DCP, we’re proposing some options to DappRadar DAO in order to gather feedback on how to continue with the successful development of our cross-chain staking protocol.

Motivation

The lack of functionality with RADAR cross-chain staking has affected the DappRadar DAO members, holders of RADAR, and might also require development costs that will affect the DappRadar DAO Treasury.

In the spirit of increased transparency, as we progressively embrace the decentralization of DappRadar, it is necessary to give our community a full understanding of the events regarding our cross-chain staking platform, so we can collect guidance on how to proceed with a solution.

Abstract

DappRadar’s cross-chain staking platform provided accessibility to staking for a wide number of users on a number of different chains, helping to grow our community. This was an industry-leading innovation that received multiple press coverage across media outlets. We worked closely, with our technology partner, LayerZero, who provided the underlying cross-chain protocol and technical support necessary for the development of our staking platform. When LZ upgraded their contracts on September 8th, it caused the DappRadar staking to stop functioning, as we communicated through our social channels and on the cross-chain staking platform itself:

Technical details

The change was done in chain IDs introduced by LayerZero. It is a very simple yet critical issue. Previously, the Fantom chain ID on LayerZero was 12, now it is 112. We have 12 as a constant in our smart contracts and that is the reason why staking is not working after the LZ upgrade. We simply ask for 12 and LZ expects 112. Due to the immutable nature of the blockchain technology we don’t have an option to change 12 to 112 in the smart contract as it is now, so for the past month, we have been looking for a solution together with LZ.

Communication with LayerZero

Prior to the upgrade, LZ reached out to us requesting to review our smart contracts’ source code. Although we gladly shared the source code with them, there were no shared suggestions on the code amendments required before making the deployment of their new cross-chain protocol. In this situation, we are aware and empathize that there are large volumes of capital supported by their cross-chain protocol, and therefore, it may have been necessary to make the upgrade rather quickly to avoid the security risks involved in cross-chain protocol communication. That being said, it is still important to provide each partner with the necessary information to effectively deal with these developments.

Unfortunately, this upgrade meant a loss of access to the cross-staking platform for our community, a negative impact that could have been minimized if LZ had:

  1. informed the DappRadar team of the date of deployment for the upgrade
  2. and most importantly, work with our developers to ensure that DappRadar’s users would have continued access to the staking functionalities and their rewards.

This would have given us the ability to, at a minimum, provide our community with a reasonable time estimate on the resummation of the cross-chain staking platform, or even better, begin working together on a technical solution.

Since then they have been silent in our chats. Neither prior to nor after the upgrade had we had any other attempts of communication from the LZ side. We only understood their upgrade breaks our staking after it was actually done.

Once we had identified the issue on September 8, we immediately scheduled a call with LZ’s CEO and CTO where we agreed to go with a solution where LZ would build and deploy a temporary solution that would work for the next 7 months and complete the rest of the current staking campaign next 7 months.

By mid-September we synced and came up with an official message from DappRadar’s side, saying the fix is in progress and should be done soon. This was posted here.

However, on October 8, a month after staking stopped working, LZ told us the planned fix will take longer and suggested we look for another solution. Their proposals included:

  • Proceed with the current solution they’re building which they estimate will take another 2-4 weeks and would be at their expense
  • Look at other options

Of course, after waiting for a month with little communication on solutions and a refusal to communicate publicly from their own channels, this was difficult to comprehend. We were already struggling to communicate to our community how to move forward and this was another step backward that made it difficult to trust the proposed timelines.

This setback would impact the DappRadar DAO members, holders of RADAR, and will also require development costs that will affect the DappRadar DAO Treasury. Therefore, we crafted three solutions to present to our community to gather their feedback.

**Due to the time pressure regarding the development of the cross-chain staking platform, we propose an expediated version of the governance process where the Forum Proposal will maintain its standard Quorum but last 3 days rather than the standard 7 days – before moving to the standard SnapShot process.

Possible scenarios to have staking running again

  1. Proceed with LZ’s current solution

We would continue LZ’s solution of creating an additional deployment that would communicate with the current V2 smart contracts and enable the rewards to be unlocked and allocated to the appropriate RADAR stakers. This is the initial solution that we aimed for since September 8.

Benefits

  • If this solution works, V2 staking would just resume as if nothing happened
  • Besides communicating it when it’s done, it requires no action from the DappRadar team

Costs

  • Taking into consideration the initial expected timeline was 2 weeks, but in fact ended up being 4 weeks, with an estimate of another 2-4 weeks to wait, this would be two months without staking
  • There are unforeseen risks that may need to be considered i.e. unsuccessful audits of LZ’s smart contracts

  1. Launch V3 staking with state of V2

This would require DappRadar to:

  • Update our smart contracts to have the ability to transfer state from V2 to V3
  • Stop V2 and lock 92M RADAR tokens staked in V2 forever
  • Get 92M tokens from one of our treasuries and send to V3 staking (so all the existing stakers still have access to their tokens)

Benefits

  • As replicating the state of V2 into the new V3 contracts will simply copy who has staked what, and how many rewards they already have accumulated, users would be able to just continue with depositing/claiming/withdrawing as it was before – which is by far the most seamless option for the user.
  • Technically, this solution would lock the 92M RADAR tokens in the V2 smart contract, making them inaccessible forever, whilst at the same time, requiring us to unlock 92M RADAR from our treasury for the new V3 smart contract rewards. In effect, this would equate to burning the 92M tokens, which long-term would benefit the community by creating positive supply-side pressure for the price of RADAR.
  • Provides the DappRadar team with more control over deployment and the timeline
  • DappRadar team will be refunded for their development efforts

Costs

  • This solution is difficult to communicate to the entire community
  • It also requires high levels of trust, engineering, and of course, expenses

  1. Launch a fresh V3 staking

This would require DappRadar to:

  • Trigger the emergency function in the current contract that allows everyone to withdraw their stake (but not the rewards)
  • Refund gas fees & rewards to ±900 addresses
  • Set up V2/V3 migration on our product
  • Communicate this lengthy to the community

Benefits

  • We already implemented a similar upgrade from V1 to V2, when we noticed an issue with the hardware wallets being unable to sign messages with the initial V1 staking platform.
  • Provides the DappRadar team with more control over deployment and the timeline
  • DappRadar team will be refunded for their development efforts

Costs

  • This solution is difficult to communicate to the entire community, especially as not all the stakers will regularly be up-to-date with our social media channels
  • It requires high levels of trust, engineering, and of course, expenses.
  • Refunding gas fees & rewards to ±900 addresses could easily sum up to at least a five-figure cost in gas fees for DappRadar DAO
  • It is the most difficult to execute perfectly as some stakers may forget to withdraw their tokens. This should be reserved as a worst-case scenario solution.

Vote

    • Proceed with LZ’s current solution
    • Launch V3 staking with state of V2
    • Launch a fresh V3 staking platform

0 voters

2 Likes
#2

It appears that this damage suffered by the DappRadar community could have been minimized, or even completely avoided, if LZ simply communicated with DappRadar team about their upgrade schedule. This kind of oversight is understandable since such changes put a lot of pressure on teams.

However, a reasonable team, when its lack of communication to its partner ends up causing such a serious problem, would try to be especially more communicative and helpful from that point on. It does not appear that LZ has such a team. Even after the issue surfaced, it appears that LZ chose not to be more engaged with DappRadar team, not to provide more frequent updates, and not to stick to the time estimates it gave.

Most outrageous of it all is that LZ refused to communicate publicly about the issue, and refused to provide any updates to the DappRadar community who were the victims of LZ’s failure. It does not appear that they are any more communicative now than they were before with the DappRadar team either.

Anyone who tracked LZ’s social media activity throughout the past two months would have noticed that LZ has been primarily focused on touting its new upgrade, without acknowledging that any issues arose. DappRadar‘s staking issue is clearly not high up on LZ’s priority list. And I do not see this changing anytime soon.

So the first option, which would end up maintaining the status quo, would just leave the DappRadar community in the same frustrating position it is now. LZ will likely refuse to provide any information publicly, likely will not provide frequent updates to the Dappradar team itself, and very likely will not be able to fix this issue within 4 weeks. In a month from now, we will likely be having this same discussion here again.

So while options 2 and 3 have their pros and cons, which should be debated further, option 1 is clearly not a logical path to take at this point and should be avoided at all costs.

#3

why cuz we have to wait 2/3 more months for it to be fixed.?
looks like vote 2 is going though anyways unless a legion of grandads turns up.

I dont see how getting rid of 93,000,000 radar helps. options 2 and 3 are the worse out of the lot in my eyes cuz they cost the most.

DappRadar DAO Monthly Newsletter - October Edition
#4

Not very much of this response is factually accurate.

The update process we followed for the migration is one established by the leading security voices in the industry. We worked extremely closely with these industry security leaders throughout and have described the entire process here (ULNv1 Deprecation. Recently, an anonymous group of… | by Ryan Zarick | LayerZero Official | Sep, 2022 | Medium). Per the best security practices of the tech industry at large, it is necessary to not to expose potential vulnerabilities or griefing instances with any party ahead of time — including to application partners— until they have been patched. This is well establish from leading web3 companies all the way legacy web2 companies like apple and google.

I want to also mention that there are roughly 1300 smart contracts on top of LayerZero mainnet and an additional ~8000 on testnet. Of all of these nearly 10k smart contracts, there is only one single application we are aware of who has had this problem; this break stemmed from information being hard coded into DappRadar’s implementation of their contracts and was against well established best practices and all public documentation and available examples. This is very clearly described in our documentation here: (Messaging Properties - LayerZero Docs) and can be found in the LayerZero open source code directly here (LayerZero/Endpoint.sol at 3fb8f6962c1346eefa7e12f2cd8c299f0cfba944 · LayerZero-Labs/LayerZero · GitHub)

nonce
nonce1280×130 27.8 KB

Despite this unique instance, our team has been willing to work with the DappRadar team on solutions for them to migrate including solutions which involve creating an entire new custom ULN library specifically for the DappRadar team that LayerZero would both support fully but also get other parties to support for messaging.

Our process for shipping any code values security above all else. What this means is that for this collaborative solution we are committed to the following:

  • write custom validation library specifically for DappRadar
  • run through internally auditing process (1-3 internal audits)
  • run through external auditing process (2-4 external audits)
  • get relayers and oracles externally to support this library
  • set the library live

These developments are weeks of total engineering time, $50-100k in auditing costs, and time during which contracts are under audit. Developer experience, regardless of their team’s implementation practices, is paramount to our team. LayerZero will be developing this solution at our team’s own expense to assist DappRadar and the community. We had an original v1 candidate that had already been submitted to external audit but came back revealing an additional issue in how DappRadar handled both nonce and Chain ID. Since the return of this audit, our engineering team has been working on a final library candidate that will undergo internal audit process shortly. The efforts towards working with DappRadar to resolve this issue has been constant and ongoing; our team has been heads down.

The one thing we will never compromise on is security; thousands of contracts, millions of messages, and billions in transaction volume and TVL later, we still believe this now more than ever. This has been. and is still, in process on our end and we are unwilling to push unaudited contracts and put the entire DappRadar community at risk. Abiding by these commitments to DappRadar and the broader community, we will continue to follow the security practices that have gotten us here and will have a working implementation in formal audit soon.

3 Likes
#6

First of all, hats of for showing support to DR here in the forum, and of course defending LZ. It’s very much appreciated to see other companies paying attention and feeling involved in what we’re building here wiuth the DappRadar community.

Quick question thought, why didn’t LZ raise alarm bells when you noticed DR had hardcoded the chain info instead of your described solution? It took quite some time for LZ to get back to DR, which was time that could’ve been used to solve the issue or at the very least work on it.

I understand you guys want to do a full sweep, assess everything, before getting back. But in terms of communication, I feel there could’ve been done something more direct / on point.

Overall, personally I am on the fence between two proposed solutions. Need to give it some more thought. I can only add that I think that LayerZero’s omni-chain tool solutions are very strong, and potentially a crucial part of the future. Loved using it with RADAR staking, and will definitely check out other dapps using it.

1 Like
#7

Appreciate the kind words! for clarity, we had communication with the DR team basically throughout.

ULNv2 went live on September 7th. At this point we had no idea there was an issue with DR’s contacts. We had communication with the DR team on:

September 7th, 8th, 11th, 12th, 13th, 15th, 18th, 20th, 28th + October 7th, 8th, 12th.

This was a mix of messages, calls, etc., so active communication definitely wasn’t the issue but a final solution took time. We didn’t know the DappRadar contracts perfectly (obviously we didn’t write them) and had to go through and architect a few possible solutions, one of which ultimately seems to work and that we’re moving forward with now.

1 Like
#8

nice to know least stuff is being sorted out now.

1 Like
#9

Appreciate LZ’s @lz.Primo jumping in here, communicating with RADAR holders and committing to get this sorted out in the best way possible.

Having this in mind + the fact that amending staking contracts with state-upload functionality would require an audit as well, I’m in favor of proceeding with LZ’s proposed solution. I believe we should use the opportunity of NOT taking 92M tokens from the treasury. While the treasury looks pretty deep right now, we’re here for the long term and our DAO will certainly need these tokens at some point in time.

3 Likes
#10

100% agree with this statement. They need to hurry up with it tho after this vote cuz community’s gonna throw a stezz other wise. (Crying about Why was there even a vote?) Because if layer Zero didn’t respond the way they did and also the fact we would need to wait for another audit anyway it does not make sense to do another contract another audit would take they same amount of time if not longer. Layer Zero need to have this done by end of year tho fingers crossed. i don’t wanna see everyone Fudding i feel like there gonna tho. (end of October/November would be nice please ASAP @iz.Primo).
If you do go over the votes head break it down to them why.

#11

Mmm, I agree that time is of the essence. However, as @lz.Primo mentioned earlier, security is the most important issue here. Our community, and the crypto industry as a whole, are starting to understand that more and more.

That’s why ultimately I believe that involving LZ in the solution brainstorming process with the community is a win-win for all involved:

  • Everyone involved (RADAR holders, the DappRadar team and LZ) gets a deeper and more balanced understanding of the events that transpired
  • The community is able to see that DappRadar and LZ are sharing technical expertise and working together toward a solution and
  • The community gets the opportunity to weigh in on the next steps forward

The results might take a little longer, but that’s a small price to ensure community-led decisions and the highest level of security possible.

#13

Ummm someone please explain to me why the radar team is overruling community?

The Radar community has 17 Million votes for Option 2, and 10 Million votes for Option 1. So Option 2 is winning. But then radar team casts 12 Million vested votes for Option 1 and woops! Option 1 wins and nothing changes. I still cant withdraw my funds.

For a month and a half I have been told that the Radar team was doing everything they were capable of to find a fix so that we could withdraw our funds. Its out of their hands, they said. Its Lz’s issue, they said. I gave them the benefit of the doubt.

But now, there is finally an option to do that. You proposed it. And the discussion survey heavily favored it. And the DAO vote is heavily favoring it. Yet why, again, are you choosing to not allow us to withdraw? If you were going to overrule the community’s voice, then why did you propose it?

And please don’t tell me “option 2 will take just as long.” That is not what the proposal said, and we all know it took you only a week to switch the first staking contract. At least give us the option to withdraw the funds without staking. It’s not even clear how long LZ’s solution will take. Another 2 weeks? 4 weeks? Two months? And you are forcing this on us?

This whole thing is just crazy, and radar staking has become my biggest regret in this space. You don’t have the right to cause this much stress to people who trusted you. Shame.

#14

First of all, DappRadar team is not a single entity controlling all the tokens. Team consists of individuals who can vote with their vesting tokens purely on their own free will. Team members are a part of the community. If you look closer, the votes of team members were not fully aligned and we had votes for both, option 1 and option 2. There’s no incentive at all for anyone to keep staking paused, just different options how to get it resumed.

DappRadar is built with longterm vision in mind. We were always communicating this clearly. Having this in mind, it makes sense that not everybody is in favor of locking almost 1% of total supply forever. This is the ultimate drawback of option 2. If there’s an option that takes similar amount of time but allows the DAO to keep that many tokens instead of losing them forever, it’s not very surprising it wins the vote.

The point of the proposal was to come to the community in a very transparent way, present the options we have and let the community decide. The community has spoken, decision was taken, we all move forward.

1 Like
#15

Whoa that was quiet a response …
Minority rules these tokens are worth something lets not be haste to squander them away…i personally am so glad this happened this way i know its sad that we locked up and all but we still getting rewards.
As a guess id say between 3 weeks and end of November some time then hoping its sooner but is what it is man.
(130% apr while we suffer) Also I’m talking about compo all time to sooth them grieving hearts.
Some people might sell and never come back if that should be up to them. shouldn’t have nothing to do with re-staking -Specially with what’s gone off-
As for trusting the team you still have the money there just no access to it at the moment and your tokens grow at the same time i trust the team to undo that at some point. 100% when this is fixed.

And please don’t tell me “option 2 will take just as long.” That is not what the proposal said, and we all know it took you only a week to switch the first staking contract. It will tho and 1% is a lot know it doesn’t seem like it but it adds up that can be used for other stuff in the future.

#16

This I’m sorry to hear about what do u mean by this space if you mean crypto you are so lucky if this is your biggest regret if you mean as a member of the dappradar community all the updates we had this year as well and compotation’s and give always and stuff id say we had a good year this lock up has sucked and taken longer than expected and im sorry to hear that this is your biggest regret in this space. Hopefully this wont happen again in the future but they cant promise that. They didn’t know this was gonna happen.
And you are forcing this on us? LUL (evil cat face) “Yes to sTweels all uR MunEYS” Of course not but its happening anyways lol its like a truck falling down a cliff and ur looking at the driver like why did you force this on me He turns back round looks at you why did you get in the Truck? then i pop up in backseat looking at driver like i want some compo for this… Do you seeeee.

#17

I, like every other participant of this vote, truly appreciate the fact that we had this process and, more importantly, this discussion.

The Dappradar team members, each individually, are indeed no different than the rest of the community members and their votes should also be treated so. However, it should nevertheless be noted that the non-team members of the community voted against proceeding with LZ’s solution, and that the Dappradar team members’ votes in favor of LZ’s solution made the difference.

This must be underscored so that LZ understands that:

  1. they received a no-confidence vote by the non-team community; and
  2. the Dappradar team members are taking on a risk by nevertheless putting their faith in LZ.

Despite of LZ’s participation in this discussion and explanations, the non-team community is, evidently, still skeptical of LZ’s commitment. The lack of any public communications from LZ about this issue has created the perception that Dappradar team and community are just not worth the attention. It appears the non-team community does not expect this attitude to change.

So LZ must understand that, by vouching for them once again now, the Dappradar team is taking on an additional burden. The Dappradar team should not be put in the position of having to explain to their community what is taking long, or what stage the process is at.

According to LZ, Dappradar’s contract is the only one having this issue. It is then not unreasonable to expect public and frequent updates directly from LZ from this point on. Informing just one community about the status of the process, which audit the new contract just passed, what audit it still needs to pass, or how long the next audit could take, surely cannot be a very burdensome task. I sincerely hope, if nothing else, this discussion and vote will have served that purpose.

1 Like
#18

Perhaps @lz.Primo can give us an update on the way things are going and what the progress has been since the vote? Any little bit can help to recreate trust.

1 Like
#19

updated team 28th, 29th and then yesterday:

“got confirmation final version is in active audit cycle now so hopefully not longer than 2 weeks, then we implement on our side and then good to go”

Will update as soon as I heard exact time we should get report back"

“Need to confirm with team, I don’t want to give unrealistic expectations but I think implementation 1-2 weeks. I’ll try to get more specifics for you asap, and there is a chance auditors are done a little early too”

"confirmed audit should be finalized and report-in-hand by end of next week at absolute latest

possibility for sooner"

6 Likes
#20

Great news! Thanks for the update here on the Forum, I’m sure the community likes to hear this :smiley:

2 Likes
#21

Hey fam, thanks for the update and the explanations as to the estimates. Like said before, its more meaningful coming directly from you to the community, so its really appreciated.

3 Likes
#22

thanks for the reply was about to start crying bout this cuz of todays pump. 2 week so that would be 11 days …Hope its fixed by then.