# Integration of deBridge Adapter into Multi-Bridge Implementation

In deBridge, we'd like to express our support for a multi-bridge Implementation developed by Celer team. We made a pull request (PR) where developed an adapter that adds support for deBridge infrastructure into the proposed multi-bridge framework.

To test out integration, we performed a mainnet deployment of all smart contracts in BNB and Polygon Chains and made a test `updateQuorumThreshold()` operation initiated in the `MultiBridgeSender` contract in BNB Chain and successfully settled in the `MultiBridgeReceiver` Polygon.

Transaction details can be found in [deBridge explorer.](https://app.debridge.finance/transaction?tx=0x33ecebfe8592d3879a1e48cb734dd61ceee450e5556180cf9c851643741c01de&chainId=56)

The source code and additional details are available here:
https://github.com/celer-network/sgn-v2-contracts/pull/232

**We would like to encourage all bridge teams that support multi-bridge Implementation to make similar pull requests, adding their bridge adapter to the framework**

# Advantages of multi-bridge implementation

Beyond what was previously mentioned by @modong, there are a few more benefits to the multi-bridge approach:
1. In order to add an adapter, every bridge team will have to perform a code review of the developed implementation. More eyes on the code improve security.
2. Each bridge team should allocate resources to perform the integration and develop the adapter. The source code of the adapter can be additionally used by the assessment team to better understand how the bridge is functioning and how the integration will work in practice.
3. The multi-bridge solution is universal and allows to have increased security even for blockchain ecosystems that have the canonical bridge, which can be one of the bridges participating in the framework. In case of any problem or vulnerability in the canonical bridge, no malicious messages/proposal can be passed as confirmation from non-canonical bridges will still be required

# Community feedback

I also wanted to comment on the following points which @Kydo raised above:

[quote="Kydo, post:2, topic:20148"]
1) its potentially long engineering time, 2) new attack surface/bugs due to increased code complexity, and 3) the difficulty to standardize messaging formats across bridge providers
[/quote]

1. The developed solution turned out to be not too complex and doesn't seem very different from vendor-lock integration, as all complexities are abstracted away into adapters that should be developed by the team of each bridge who want to join the framework
2. Same as with 1 bridge integration, the code should be thoroughly tested by the community, and security audits should be performed.
3. The advantage of the proposed solution is that standardization is performed through adapters that are developed by each bridge team

We'd love to hear feedback from @kydo and other community members on potential risks and problems of proposed implementation as well as ideas of what can be improved.