Hey! Alex from deBridge here. Here’s an overview of deBridge related to the questions from the Uniswap Foundation:
deBridge is a secure cross-chain infrastructure enabling seamless interoperability between blockchains, powering transfers of any messages and liquidity with zero slippage and zero locked liquidity at risk.
1. List 3 succinct reasons why you believe your bridge/solution would best serve Uniswap governance.
-
Security: deBridge has taken a unique approach and implemented an off-chain validation mechanism where all messages are signed by a set of validators who are elected by and work for deBridge governance. Validators are obliged to sign a unique identifier of every message that is sent through deBridge smart contract with their private key and then make the signatures public so anyone can execute messages on the destination chain. deBridge smart contract checks the validity of all the signatures and in the case at least 2/3rd of signatures are valid, delivers the message to the recipient.
Validators don’t communicate with each other and they never expose their IP addresses making it very difficult to attack the infrastructure. -
Unlimited throughput and scalability: deBridge doesn’t have its own blockchain or intermediary consensus layer, that’s why there is no throughput bottleneck. deBridge also doesn’t need to bootstrap liquidity pools in order to scale up to new chains. In case Uniswap governance decides to deploy on new chains that are not yet supported by deBridge, we will be able to quickly add support for these chains.
-
Optimal gas-efficiency: At deBridge, validators never broadcast any transactions. Hence, they never bear gas costs, unlike other interoperability protocols where gas costs of the validation layer are born by the message sender.
2. How long has the system been running on mainnet?
deBridge has been live on mainnet since February 2022. The protocol has been running successfully since day one with 100% uptime, 100% message deliverability, and no security/reliability issues.
3. How much value has the system secured? (Current TVL, total transaction volume)
deBridge is a cross-chain infrastructure that enables generic message transfers. The protocol has processed more than 131,000 messages from over 67,000 unique users. All protocol stats can be found in our deBridge explorer.
deSwap is the first value-transfer protocol built on top of deBridge and has processed ~$94M of volume without any incentives and liquidity minings. In deSwap, we have never been chasing volume as the primary goal, but rather to build a capital-efficient solution with a sustainable economy that doesn’t require TVL and distribution of liquidity incentives.
We also believe that cross-chain value transfer protocols shouldn’t have continuously locked liquidity or large TVL. That’s why we’re launching DLN, an asynchronous value transfer protocol built on top of the deBridge infrastructure. It’s using a fundamentally new paradigm called “liquidity on demand” where any cross-chain trade can be settled natively with zero TVL, solving problems with security, scalability, and capital-efficiency of classical value-transfer bridges based on liquidity pools. More information can be found here.
4. Provide a background on your team.
deBridge was started in early 2021 after winning a Chainlink hackathon among 140+ projects. The project’s founding team and overall technology and product team have extensive experience in blockchain and crypto development including building custody solutions, distributed systems, and other applications for banks and other companies.
deBridge’s CEO and Co-Founder, Alex Smirnov, is a mathematician, researcher, and developer. He has led and developed various blockchain solutions and dApps, and came out of academia where he was working on his Ph.D. in mechanics and mathematics. Now, he’s leading deBridge where his focus spans areas including protocol design, product management, ecosystem, and operations.
The team’s CTO and Co-Founder, Yaro Artyukh, has eleven years of experience in software development, six of which were involved in the development of different fintech and blockchain solutions. Yaro leads the development of all components for the deBridge protocol and architecture, making sure we have the go-to secure cross-chain infrastructure for any projects and users.
In sum, the team has a security-first mindset and approach when building infrastructure to be reliable and stable.
5. Please link your developer documentation.
Developer portal: deBridge Finance
Developer documentation: https://docs.debridge.finance/
deBridge Explorer: https://explorer.debridge.finance/
Security: 10 Strategies for Cross-Chain Security
Cross-chain Dapp example:
We cover all aspects of deBridge in our docs including a general overview of the protocol, smart contract, and use case examples, how our generic messaging framework works, building with our development tooling, and more.
6. Does the bridge support arbitrary message passing?
Yes, deBridge is a generic messaging infrastructure that enables arbitrary message passing. This goes for all types of messages including governance voting, smart contract logic, and contract calls.
Learn more here: Getting started - deBridge
7. Has the current deployed bridge code been audited? By a third party? What attack vectors and vulnerabilities were identified, if any? Have the identified vulnerabilities been remedied?
Yes. Security will always be deBridge’s primary focus area since it’s difficult to build a secure and reliable cross-chain infrastructure, and we want to make sure builders and users have a secure interoperable framework that they can build and interact with.
We have had 17+ audits up until this point where we have worked with 4 different security auditors in total. We have made sure to devote significant resources towards auditing our smart contracts, and also other aspects of the protocol including the deBridge node, our UI, Cloudflare, and other areas – all potential attack vectors in different ways. There have not been identified vulnerabilities in the deBridge protocol.
All security audits can be found here: GitHub - debridge-finance/debridge-security: deBridge security audits
8. Is there a bug bounty program?
Yes, we have an ongoing bug bounty program with Immunefi. This was initiated even before we went live on mainnet to make sure white hats, researchers, and others in the blockchain space help us discover any potential vulnerabilities in the architecture and overall protocol.
Our bug bounty overview can be found here: deBridge Bug Bounties | Immunefi
9. List ANY portion of the functional bridge that is upgradeable and explain how the upgrade process works.
Every on-chain component of deBridge, including but not limited to:
- deBridgeGate (the core gate contract)
- SignatureVerifier (the contract responsible for verifying message signatures and ensuring they are from trusted validators)
- CallProxy (the contract responsible for performing calls to target contracts) –
is represented as an upgradable contract using the transparent proxy pattern.
All proxies are currently controlled by a Safe multisig account shared across the deBride executive team. During the next few weeks, we are going to add deBridge validators and several reputable and experienced people in the industry as signatories to this account.
Any upgrade of smart contracts will involve a multi-step process:
- The upgrade should be fully audited by our security providers.
- The logic implemented by the upgrade will be described on the deBridge forum so every participant of the multisig account can validate the upgrade in advance and make sure it doesn’t harm nor influence any integrations performed with deBridge infrastructure.
- Safe transaction to be formed by the core team.
- Signing transactions by all multisig participants.
- Execution of the signed transaction.
10. Do any contracts have an owner or owner-like entity? If so, what can the owner do?
deBridge core contracts expose several administrative methods accessible to the controlling Safe multisig. These methods permit managing various protocol settings such as: pausing/unpausing the protocol; enabling/disabling chains where messages can be sent to/from; adding/removing validators’ addresses responsible for messages confirmation; setting signature acceptance thresholds and protocol fees.
Important to note: After introducing the deBridge token, governance will take control over the protocol and all the administrative processes.
11. What is the security model of the bridge? Please describe the security model for the current implementation of the bridge. What trust assumptions are you making?
Any non-canonical bridge has inevitably a validation layer with consensus participants, and like all bridging solutions applying to this Assessment Process, deBridge bears the assumption that consensus participants will never collude to forge messages.
One of the goals here is to make consensus participants bear financial responsibility and maximize their stake that acts as financial insurance. That’s why deBridge has a delegated staking and slashing module as a part of the protocol design (the module is not live yet and will be launched later this year).
Read more about our slashing and delegated staking here:
https://docs.debridge.finance/the-core-protocol/slashing-and-delegated-staking
deBridge has selected 12 professional and experienced infrastructure providers based on their performance e.g. stability of infrastructure, uptime, number of missed transactions, and validation speed. This includes HashQuark, Bware, and Stakin among others. After the launch of the deBridge DAO, governance will have the ability to decide on how many validators the network should have and who should be the validators.
The full list of deBridge validators can be found here: Debridge - Cross-chain Bridge
With this in mind, we can go into the security features to ensure we have a secure and reliable protocol. These include:
- Slashing Mechanism (to be launched in 2023): Validators have an important role in the deBridge protocol design. deBridge uses a slashing mechanism to disincentivize validators from colluding and acting against the best interest of the protocol.
- Transaction finality specifications: Validators need to wait for a specific number of block confirmations and sign transactions only when they have achieved their finality. This prevents double-spending since transactions become irreversible after achieving finality.
- Validation of nonce sequence: A nonce is the unique sequence number assigned to every transaction passing through the deBridge protocol. Validators are always required to confirm transactions in an ascending order which helps to avoid double-spending and improves overall protocol security against reorgs and 51% attacks.
More details about our security measures can be found here.
12. How can an adversary pass a fraudulent message from Ethereum to the destination chain? Please give specific and concrete examples.
Assuming the security of deBridge node and smart contracts, there’s only one way a fraudulent message can go from Ethereum to another chain. This is in case 2/3 (8 out of 12) validators come together to collude and sign a fraudulent (non-existing) message. Here, someone would need to get access to the private keys of at least 8 validators to sign a fraudulent message in order to execute it through the deBridge smart contract on the destination chain.
Thanks to deBridge off-chain validation, validators never communicate with each other and never broadcast any transactions. They never expose their IP addresses making it very difficult to attack the infrastructure as no one knows where validators are running the infrastructure.
Moreover, the number of validators will grow over time to increase the decentralization of deBridge and to make it more difficult for adversaries to do something maliciously.
13. How can an adversary withhold a valid governance message from Ethereum to the destination chain? Please give specific and concrete examples.
In case there’s an adversary that wants to censor a message, this can be achieved by 5/12 of the validators coming together. Validators that censor messages will also be slashed by protocol governance
14. What are the ramifications of fraud to the malicious actor(s)? If it is legal ramification, please share the suite of legal action you can provide. If it is slashing, please point us to the codebase of the slashing behavior and describe in words how slashing works in your system.
There are some specific ramifications and security precautions that we have thought about when designing the deBridge architecture. The main one is slashing mechanics where validators are required to provide financial guarantees in a form of collateral (their own + collateral delegated to them by delegators/users) in a delegated staking smart contract. This is to disincentivize colluding among validators, and the collateral will act as a guarantee of validators’ acting as they should and in the best interest of deBridge, since they otherwise will be slashed.
The slashing works the way that if validators decide to act maliciously, their stake will be slashed by the deBridge governance to payout to the affected users of the infrastructure.
––
deBridge is in favor of the MMA design option as Uniswap’s go-to implementation. We believe this will benefit the Uniswap protocol the most while bringing the best secure and reliable option.