[DCP-15] Token Allocation and Bridging Service for Resuming ETH <> BNB Chain Operations

[vandynathan]

Co-Authored by : DappRadar (@michael-dappradar, @Osman and @vandynathan )

Summary

DappRadar used Multichain Bridge to enable bridging between Ethereum and BNB Chain. Recent events have shown that the DAO and user tokens locked on Ethereum and minted on BNB Chain may be compromised and on some steps that we have taken to resume bridging operations (for more information click here).

This proposal addresses the challenge of the likely inaccessible 96.55M RADAR tokens used in RADAR’s multichain expansion to BNB Chain via the Multichain bridge and the lack of bridging service. It aims to allocate tokens from the DAO treasury, establish a contingency plan, and integrate with Connext’s xERC20 standard in order to successfully resume bridging operations.

Motivation

The main motivations behind this proposal are to:

1. address the challenges posed by the currently inaccessible 96.55M tokens in the Multichain bridge
2. and ensure the continuity of bridging operations.

In the event of the tokens being returned, a contingency plan is necessary to guide the DAO’s actions and manage the allocation of the tokens effectively. This ensures preparedness and accountability in either scenario, maintaining the trust of the community and continuation of cross-chain services.

Abstract

Current status of bridged RADAR tokens

Recent events of a likely compromise in Multichain mean that the DAO and users have a total of 96.55M RADAR locked on Ethereum and inaccessible. DappRadar has no direct control over them leaving RADAR holders on BNB Chain without an effective bridging solution.

We have updated our community and advised them to no longer utilize the Multichain services until further notice. From the BNB Chain side, RADAR token minting rights are under our control and we have revoked Multichain’s rights to mint more tokens.

• In the worst-case scenario, the tokens could be under the control of a rogue employee or a foreign government meaning that they could eventually be sold on the market or permanently locked out of circulation
• In the best-case scenario is that Multichain operations will be resumed and/or the locked tokens will be returned to DappRadar

Next steps

We must be flexible on potential outcomes and take proactive steps to manage the risk while resuming ETH <> BNB Chain operations:

1. Allocation of RADAR tokens from our Treasury to resume ETH <> BNB Chain operations

Given the likely irrecoverability of the 98M tokens in the Multichain bridge, this proposal seeks to allocate tokens from the DAO treasury to resume bridging operations using an alternative bridge provider.

Simultaneously, it is vital to have a contingency plan in place if the tokens are eventually returned. This plan outlines the steps to be taken if the tokens are recovered, ensuring transparency and responsible management.

2. A contingency Plan in the event that access to RADAR tokens is returned

If access to the 96.55M RADAR tokens is returned from the Multichain bridge, both a (i) communications and (ii) treasury management strategy will be implemented:

(i) Communications

• For transparency and openness, promptly notify the community about the successful return of the tokens, including potential implications for the DAO treasury or token circulation.

• Develop a comprehensive governance proposal that outlines the proposed actions and allocations of the returned tokens and seek community input and participation

(ii) Treasury Management

• Implement measures to ensure transparency and accountability in the management of the returned tokens.
• Implement auditing or reporting processes to ensure that the tokens are used following the decisions made by the community.

3. Deployment of Connext as a new bridge for users to continue bridging tokens from ETH to BNB Chain

We propose to integrate with Connext and deploy the xERC20 standard on Ethereum and BNB Chain to support this new bridging standard so we have a bridge again after the Multichain bridge stopped working. The current RADAR smart contracts will remain as they are (ERC20 RADAR on Ethereum and on RADAR on BNB Chain).

(i) On Ethereum

Step 1: We will deploy xERC20.sol

On the xERC20 contract, we will approve the Connext bridging smart contract (ConnextDiamond) to mint & burn xERC20 so it can mint & burn the same amount of tokens on the source & the destination chain to complete the bridging operation.

Within the xERC20 contract itself, we will be able to limit the approval on how many xERC20 tokens the Connext smart contact can mint and burn per day.

Step 2: We will deploy Lockbox.sol

The Lockbox locks up ERC20 $RADAR and mints xERC20 $RADAR.

(ii) On BNB Chain

We will not deploy any new smart contracts on BNB Chain because our existing ERC20 $RADAR contract can already allow mint & burn for Connext bridging smart contracts. It can do so because it was needed for the old (Multichain) bridge as well.

Step 3: Approve the Connext bridging smart contract (ConnextDiamond)

This is used to mint & burn $RADAR from our existing ERC20 $RADAR contact. Currently, we can not limit how many ERC20 tokens the Connext smart contract can mint & burn per day, but in the future, we may. Otherwise, a new smart contract would be needed which in addition to audits and costs would extend the timeline.

Step 4: Opt-in to Routers for faster bridging services

On the default bridging settings, Connext executes bridging operations every 1-2 hours. However, this is too long for our RADAR holders, so we will utilize a feature “Routers”, which we provide with $RADAR liquidity, which allows for bridging operations to finish in under 60 seconds.

Our calculations show that we need to provide 1M $RADAR in total to the Routers so they have enough liquidity to allow for fast bridging operations (500k on the Ethereum Router and 500k on the BNB Chain Router). This liquidity can be withdrawn by the DAO at any time.

The Router will always get replenished and the user will be responsible for both the transaction and router fees. In the event that the Routers don’t have enough liquidity, bridging operations will resume to the default still 1-2h completion time.

Step 5: Utilize the Connext user interface to execute the bridging transactions

NB. It is important to mention that the proposal’s execution will be subject to a successful third-party audit of the xERC20 and Lockbox smart contracts – a process currently being managed by Connext.

Summary

Together we will need a total of 98M RADAR (96.55M for the locked tokens, 1M for the liquidity for Router, 0.45M for gas) for the resuming of ETH <> BNB Chain bridging services and to provide the necessary liquidity for allocating tokens from the Treasury for the bridging process and Connext/xERC20 integration. In combination with developing a contingency plan, the continued access to RADAR on BNB Chain and preparedness will help maintain stability and trust within the community – regardless of the outcome regarding the tokens’ recovery.

Benefits

• Continuation of Bridging Operations: By allocating tokens from the DAO treasury, the proposal ensures the continuation of bridging operations and the maintenance of liquidity
• Indemnification: Holders on BNB with locked RADAR will be provided with an equal number of xRADAR once the bridge is live
• Preparation for resumed access to RADAR tokens: Having a contingency plan in place ensures the DAO is ready to handle various outcomes
• Connext and xERC20 reduce future technology burdens: xERC20 allows us to connect multiple bridges to one token. In the future, this will also allow us to deploy RADAR on many more chains with reduced burden on tech and bridging side

Drawbacks

• Treasury Management Risks: Allocating tokens from the DAO treasury may deplete resources that could be used for other initiatives or investments. This could potentially impact the availability of tokens for future projects or unforeseen opportunities.
• Bridge Provider Selection: Connext is an established and experienced bridging company but as this bridge’s standard and contracts are new technologies which may still need improvements to reduce the smart contract risk.

Vote

• FOR: Allocate tokens from the DAO treasury to resume bridging operations utilizing the Connext bridge, with a contingency plan in place in case the 98M tokens are returned from the Multichain bridge.
• AGAINST: Do not allocate tokens from the DAO treasury for resuming bridging operations

[madeafterdeath]

@vandynathan

In the worst-case scenario, the tokens could be under the control of a rogue employee or a foreign government meaning that they could eventually be sold on the market or permanently locked out of circulation

If we can lock them out we should do if we can do just to keep the liquidity users safe from a rug. If there is ever a increase in token supply in the future take them into account that we had to lock out and put them back into play. If multi chaining keeps effecting the contract on the ETH and keeps putting them at risk i suggest we build new contracts on the chains we want to move onto and do a burn up to a certain amount on the eth side to match it (this is more work) but this is if multi-chaining continues to be a problem and puts liquidity at risk Then use some other token as a medium somehow between them say like BTT (on Tron network that’s got a good bridge selection to choose from)…just a thought or possible solution. Doesn’t sound good but no trust is lost from me. I don’t think it was done on purpose on ur side of things. and your being open about it now. need to finish reading this.

I voted no but that’s if we are using the same bridging provider. (they messed up way to many times now cant be trusted) They on that list. There CEO sucks.(personally i think they should have to pay towards any damage done to radar not are fault its there’s)

[SkirmantasJ]

A couple of key points to address your concerns @madeafterdeath:

1. We are not going to use Multichain services anymore. We are switching to Connext
2. 96M tokens that are currently in Multichain’s custody - there is nothing we can do about them at this moment. It is unknown whether they really have access to these funds, whether they would touch them or these tokens remain untouched forever. As long as tokens are not moved, there is a tiny chance we could get the tokens back if Multichain resumes operations at some point.

Since Multichain went down we initiated discussions with multiple bridge providers. Connext seems to be a best fit for us. Their team is top notch and the latest xERC20 is a public good initiative that allows us to not just use Connext for bridging RADAR cross-chain but to also utilize other bridges in parallel in the future.

[madeafterdeath]

you know if they was to sell the tokens right now this adds roughly up to over 400k obv price impact would effect how much they got but that’s a ton of money that can suddenly go missing or taken out of are market at some point. (which if radar ever does a good pump they will sell I’ve no doubt in my head about it which companies responsible for the tokens being unable to be moved? is there no legal actions we can take?) can they make it so the contract with the tokens locked onto it cant be accessed or moved ever? or are they on full on ignore mode?

[madeafterdeath]

can be detained in china for After an official arrest, you may be detained for up to 13.5 months before formal charges are laid and the case is transferred to the court.

This sucks should find out what’s happing hopefully in next couple of years…need to be greeting him if china don’t put him in prison. try and get are tokens back asap.

[madeafterdeath]

in the mean time we should be building up some cover for the price impact and the covering of a sell if there is any like i mentioned in discord incase they do get sold.

[nederob]

I don’t have a preference for Connext and have too little knowledge to do an advise on companies to work with. However, purely seen from a technology point of view, and as described, wrapping with xERC20 seems like a splendid way to keep tokens alive.

If the same thing would happen again - as it did with Multichain - we would still be able to move xERC20 around and move it back to the normal RADAR. So, using an open system like xERC20 is super beneficial and a strong Web3 product: open, composable and resistant.

Moreover, to me it makes sense to see RADAR move to Polygon, Polygon zkEVM, Base, Optimism, Arbitrum, and by the looks of it the xERC20 solution makes things VERY easy to deploy.

I’ve added my blessing purely based on the concept xERC20, and not necessarily on Connext.

[madeafterdeath]

sounds good. least it keeps the token safer this way. changed my vote for.

[Fav_truffe]

@vandynathan

It is important to mention that the proposal’s execution will be subject to a successful third-party audit of the xERC20 and Lockbox smart contracts

Hey @vandynathan! How is it going?

I just shared an audit competition proposal for xERC20 and Lockbox Smart Contracts and looking forward to hearing your feedback

[DCP-16] Audit Competition Proposal for xERC20 and Lockbox Smart Contracts by Hats Finance

Summary This is a proposal for DappRadar to conduct an audit competition for its xERC20 and Lockbox smart contracts on Hats Protocol. Abstract Hats audit competitions are revolutionizing the world of Web3 security, offering a dynamic, cost-effective, and time-efficient solution for smart contract auditing. By transforming the traditional auditing approach, they ensure enhanced security through a community-driven process. With audit competitions, you retain full control over your budget, attra…

[vandynathan]

Thanks for the update @Fav_truffe

I provided my reply in your Proposal!

[vandynathan]

Please find a high-level update on the successful Proposal and the next execution steps: