Single bridge vs multiple bridges

In the context of a "collateralized" bridge, the system must ensure at all times the eth collateral deposited by operators covers the locked doges. The main problem with that is the eth/doge price varies.

We carefully evaluated several solutions for that problem a couple of months ago before starting the implementation.

The multiple bridge solution seemed tempting at first, but then we found issues that are showstoppers:

• No fungibility between Doge Tokens:
  • 1 doge token on brige A would be backed by 0.01 eth, while 1 doge token on brige B would be backed by 0.1 eth.
  • That means the first doge token is worth less than the second.
• Exchanges would need to list 5 or 10 different doge tokens (one per bridge).
  • Users would have to recognize 5 different doge token icons, and 5 different token symbols (DOG1, DOG2, etc)
• Users would not be able to use Metamask, myethewallet/mycrypto, trezor, or Mist to store Doge tokens.
  • Existing wallets wouldn't be useful for storing doge tokens.
  • Only a yet-not-implemented server-side hot wallet that is connected 24x7 would work for users. The wallet has to be always online to unlock tokens from bridge A and lock them back to bridge B if price varies.
• It would be impractical to use Doge tokens in smart contracts.
  • The multi bridge solution requires users to be able to quickly unlock doge tokens if price changes. On many smart contracts, tokens can't be withdrawn quickly by design.
• A 5x or 10x overcollateralization is required most of the time
  • That discourages rational operators from participating in the system.
  • If Bridge A has collateral that covers up to an eth/doge price of 10, and bridge B has collateral that covers up to an eth/doge price of 100, when the price is 10.00000001, a 100 eth/doge collateral is required.
• Doge Token holders would not be able to directly send doge tokens from one bridge to another.
  • To send doge tokens from one bridge to the other users should unlock tokens from one bridge, get real doges and then lock them back to the other bridge: that takes a lot of time and cost fees.
• Truebit and bulletproofs are not implemented as of July 2018.

We decided to implement a "single bridge" solution:

• There is just 1 bridge.
• There is an oracle for eth/doge price.
  • Makerdao/dai (The most important live project in the ecosystem that uses a collateralized solution) uses an oracle system to solve the price variation problem too.
• If the eth/doge price moves, the collateral/locked doge ratio is stabilized in any of the following ways:
  • If variation is small, nothing needs to happen, the system is overcollateralized to deal with small movements of the price.
  • If the variation is big, some users would probably decide to be safe and voluntarily request an unlock of their doges.
  • Operators might mark themselves as "I want to reduce my collateral". Then, they would be given priority for unlock requests.
  • Operators might buy Doge Tokens on the market and ask the system to unlock them using themselves as operator.
  • Operators might add more eth deposit.
  • New operators might come in and add eth deposit.
  • As a last resource, the eth collateral is confiscated from operators that did not react when they should and given to doge token holders.
  • In no case a "sufficiently high DOGE price spike could ruin any (honest) Operator". Worst case scenario, they still have the locked doges.

As you can see this approach has some cons too: Using an oracle is adding a potential attack vector to the system. Forcing operators to react to price changes is a drawback. But those are minor issues compared to the problems of the "multiple bridge solution".