POA Forum

[ERC20-to-ERC20] - bridge redeployment issue

We’re using ERC20-to-ERC20 bridge and it works fine, at least while we are in development stage. We’re going to move our product (reward for surveys completing) to Production, and starting to think about any troubleshoots we might face in the future.

The main question is: What if we will need to redeploy the bridge from scratch?
(by any reason: issues, upgrade to new version of contacts, changing validator address, etc)

The problem here is that on every new redeployment it creates new token in Home net. Let’s imagine that users put their funds from Foreign network to our Private network and, actually, we want to keep the same ERC677 token as it was, to save users balances.
Is there any technically possiblity to redeploy all bridge contracts with existing token on Home side?

For example, transfer ownership of token from home bridge contract back to HOME_BRIDGE_OWNER, and then use this token again instead of newly deployed in deploy script. Will it work this way?

I predict that it would “forget” about total tokens amount transferred to Home net. Do they determine by balance of Foreign Bridge contact?
Is so, would it be possible to just put funds to new foreign bridge to make home–>foreign transfers possible with newly redeployed bridge?

And another recovery issue.
Let’s assume we lost private network that was totally funded from Foreign net. Would it be possible to unlock or return back all the tokens locked on Foreign Bridge contract?
You know there could be a lot of money, so we better have an access to them. Just in case, especially when they are not burned but just sit in bridge.

Any opinions are appreciated.

P.S. I know that validators / daily and tx limits are configurable, so it’s not required to redeploy the bridge to change them. However, I could not find scripts to do that.
Anyway, question is about emergency / recovery cases.

Hi! thanks for the questions.

Yes, it is possible. The bridge contracts are upgradable (we are using OpenZeppelin upgradable contract template) so:

  1. You could upgrade the bridge implementation contracts to be on a new version without necessity to deploy new bridge.
  2. You could upgrade the bridge contracts to introduce a method to change the token owner, deploy new bridge and transfer ownership by using this method to the new bridge contracts.

BTW, we have an issue for this improvement. So, you could contribute to the token bridge.

As well the upgradability property allows to address other cases you listed:

  • put funds to new foreign bridge to make home–>foreign transfers possible with newly redeployed bridge
  • unlock or return back all the tokens locked on Foreign Bridge contract

Steps to upgrade the implementation of the bridge contracts and to configure bridge parameters can be done is a similar way to described here. For you information, the bridge validators set can also be changed without necessity to re-deploy the contracts by using similar approach with methods addValidator/removeValidator from the bridge validators contract.

2 Likes