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

Summary

DappRadar used Multichain Bridge to enable bridging between Ethereum and BNB Chain. Recent events 6 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:

• address the challenges posed by the currently inaccessible 96.55M tokens in the Multichain bridge
• 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 2 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 1 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 1 (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
• Compensating our user base: Users with locked RADAR tokens will be covered by the loss caused by the Multichain
• 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.