[ARC] - Whitelist deBridge for Portals V3

Governance
1

Proposal

Hello Aave Community! deBridge (https://debridge.finance/) is a generic messaging and cross-chain interoperability protocol that enables decentralized transfers of arbitrary data and assets between blockchains. The protocol is an infrastructure platform and framework for:

  • Cross-chain composability of smart contracts
  • Cross-chain swaps (deSwap is one of the applications built on top of deBridge that enables capital-efficient cross-chain swaps)
  • Bridging of any arbitrary asset and data
  • Interoperability and bridging of NFTs

In deBridge, we strongly believe in the concept of composable finance where a combination of different DeFi primitives or protocols enables solutions with the highest level of capital efficiency that can’t be achieved by standalone protocols or applications. deBridge was designed to be fully compatible with the existing DeFi ecosystem, and deSwap (https://app.debridge.finance/deswap) is a good example of this. It leverages deBridge’s generic messaging framework in order to provide users and protocols with the ability to perform a capital-efficient cross-chain conversion between arbitrary liquid assets, all in one transaction.

More information about deSwap can be found here.

Instead of reinventing the wheel and developing a dedicated AMM or DEX, we integrated with Curve to utilize its capital-efficient stableswap AMM and partnered up and integrated with the liquidity aggregator 1inch. This design allows deSwap to source liquidity and routing from existing protocols. This is much more effective than running meaningless liquidity mining campaigns to have a ton of idle liquidity sitting as TVL with near-zero utilization. We believe it’s more reasonable to source liquidity from a protocol like AAVE when it’s needed and to do revenue sharing between the protocols.

Portals enable a great synergy between deBridge and AAVE by bringing additional utilization for locked liquidity in AAVE as well as providing a new type of routing for cross-chain swaps through deSwap, where no intermediary pools or wrapped tokens are needed. In addition, the integration will facilitate atomic transfers of positions between Aave instances on different chains which ease cross-chain interactions with no need to switch wallets/networks.

Technical Specifications

deBridge is an infrastructure for developers and projects to integrate with or use to build any type of cross-chain applications and primitives. The design of the deBridge protocol consists of two layers:

  • Protocol layer – on-chain smart contracts deployed on every blockchain supported by deBridge.
  • Infrastructure layer – off-chain validation nodes operated by validators that are elected by and work for deBridge governance. The list of active validators can be found here

More details about the technical implementation and design of the deBridge protocol can be found in our documentation portal: ​​https://docs.debridge.finance/

The protocol has been live since February and has processed over $43M in volume, 75k+ cross-chain transactions, 44k+ unique users, and generated over $120,000 in fees for the protocol and validators securing the network.

The major activity in the protocol has been generated by deSwap, a cross-chain swap solution built on top of the deBridge generic messaging protocol. deSwap enables decentralized cross-chain conversion of arbitrary liquid assets. Here is some useful information:

  • Is the entity a Bridge?
    • deBridge is a generic messaging and cross-chain interoperability protocol that enables decentralized transfers of arbitrary data and assets between blockchains
  • If applicable the number of routers, total liquidity of routers
    • Cross-chain swaps are currently routed through the deUSDC/deETH liquidity pools at Curve protocol which have ~$9M of liquidity provided by deBridge users and partners. A complete list of liquidity pools can be found here: Cross-Chain Swaps Liquidity - deBridge
  • Can anyone provide liquidity to the protocol?
    • Yes, anyone can provide liquidity to the protocol
  • Is liquidity incentivized?
    • At this moment liquidity is not incentivized. Liquidity providers receive 2 BPs in the form of trading fees from Curve.
    • Once control over the protocol is passed to governance, there is a plan to submit a governance proposal to the deBridge DAO to retroactively reward participants proportionally to how they have helped out the protocol in the early stages
  • Is there a fee model for participants?
    • The protocol takes a 10bps fee from every transaction (5bps go to validators and their delegators that help to secure the protocol, and another 5 bps go to deBridge treasury)
  • does the entity is or is planning to provide available liquidity into Aave protocol?
    • TBD
  • Link to analytics dashboard of protocol
  • If applicable, link to the user-focused dapp of the entity.
  • Link to technical documentation

At this stage, cross-chain swaps are routed through the intermediary deUSDC pool at Curve which sets the maximal amount of swaps being limited by liquidity in the pool (Cross-Chain Swaps Liquidity - deBridge). The credit line provided by Portals will solve this problem by enabling new routings and more capital-efficient cross-chain swaps with larger transactions, limited only by the amount of the credit line.

One of the unique features of deBridge is the cross-chain “transactions bundling” where an arbitrary set of actions can be packed into one cross-chain interaction, e.g. users can do a cross-chain swap and supply the resulting liquidity to AAVE.

The liquidity from Portals will be used in various scenarios:

  1. Facilitate liquidity inflow into AAVE v3 on different chains so users can supply liquidity using any arbitrary asset on any chain supported by deBridge.

  2. Let anyone automatically transfer positions across instances of AAVE v3 on different chains.

  3. Utilized for routing of cross-chain swaps performed by users/protocols through deSwap.

  4. Any applications and projects that integrate the deSwap API (debridge.finance/api) which will use Portals’ liquidity bringing additional monetization to the AAVE protocol.

We have prepared for the Aave community an application POC for swap + deposit into AAVE in a single transaction: https://stake-aave.debridge.finance/stake-aave

Once the deSwap widget is integrated into the AAVE application, all users of the AAVE UI will utilize the liquidity of Portals to perform the above-mentioned interactions with the protocol.

This is an example of ETH liquidity routing on Ethereum which is converted into AVAX and supplied to AAVE on Avalanche:

Once integrated with Portals, its credit line will be used instead of deUSDC.

Technical implementation

Integration with Portals is to be performed through a dedicated deAaveAdapter smart contract that will be developed by the deBridge team and audited by our security partner Halborn. This smart contract utilizes the deBridge generic messaging protocol and interacts with Portals (AAVE Pools).

It receives liquidity from the user, then redeems the loan on one chain and takes the same amount of credit to another chain. Whenever users or protocols perform a cross-chain swap, the following set of actions is performed by the smart contract:

  1. Accept liquidity from the sender on chain A (e.g. Arbitrum) and check if there is any unbacked amount to be repaid
  2. Pay the outstanding amount and lock the remaining liquidity in the deAaveAdapter
  3. Send a message to the deAaveAdapter on chain B (e.g. Polygon) through deBridge. The message contains a command to take a loan, redeem aToken and transfer liquidity to the receiver.

Once the transaction initiated on Chain A is final and irreversible, the deBridge infrastructure will execute the transaction on the destination Chain B in the following sequence:

  1. Execution of the passed message in the external call to deAaveAdapter
  2. deAaveAdapter will mint the needed amount of aTokens by calling mintUnbacked function of Portals
  3. deAaveAdapter will redeem received aTokens and transfer the resulting tokens to the receiver by calling withdraw method of AAVE protocol

This design of deAaveAdapter guarantees that the liquidity lent from Portals on one chain is always backed by the same amount of asset locked in deAaveAdapter on another chain. By this design, liquidity that was lent to deSwap always remains in AAVE’s possession as any user/protocol can bridge assets from the chain with an outstanding loan to unlock the corresponding amount of the same asset locked in the deAaveAdapter on another chain.

This diagram shows the general flow of a cross-chain interaction when deSwap will be integrated with Portals:

Proposed list Credit Line request

The credit lines to be allocated to deBridge are requested for each blockchain where AAVE v3 is deployed. deBridge is currently deployed on 6 blockchains and one of the reasons we haven’t deployed on others has been the lack of liquidity for deSwap. Portal is solving this problem and deBridge will prioritize integration to have the list of supported blockchains matching those where Portals are deployed.

Network Asset Current Liquidity Requested Credit Line (per chain) Fee Model* Fee Requested*
All USDC $9M $4M Fixed bps 2 bps
All USDT — $4M Fixed bps 2 bps
All ETH $0.7M 2000 ETH Fixed bps 2 bps

The maximal amount of the cross-chain swap that can be performed by users and protocols in one transaction is capped by the amount of approved credit line. deBridge will pay a 2bps fee on all the liquidity taken from Portals.

Incentives

An incentive program may be approved by the deBridge DAO after the deBridge token goes live.

Audits & Security

List of relevant security audits of the network
Security has always been our main priority. deBridge has passed four independent security audits by reputable companies such as

  • Halborn
  • Zokyo
  • Ackee Blockchain
  • Neodyme

All security audit reports can be found on our Github: https://github.com/debridge-finance/debridge-security

deBridge has a long-term partnership with Halborn that audits not only smart contracts but all the modules created for the protocol.

We also have an ongoing bug bounty program on Immunefi:
https://immunefi.com/bounty/debridge/

We have done extensive research and seen that many bridges are missing various security measures like basic balance sheet validation and nonce sequence validation. These crucial components among others have been implemented in deBridge. More details about our cross-chain security strategies can be found here: 10 Strategies for Cross-Chain Security

Has the Entity experienced outages, downtime, or exploits/hacks? on which Networks?

Never

10 Likes
2

Expressing my support for this proposal, Happy to see debridge join the candidates for Portals feature whitelist.

2 Likes
3

I agree with this proposal

4

Unfortunately,

The snapshot vote associated with this proposal lacked 30k YAE vote to reach quorum.

Given the lack of NAE votes, the proposal vote that was open during a weekend and the relatively low activity period in governance.

I’m opening a consultative community poll to check community sentiment on a re-run of this snapshot vote as I haver the feeling that quorum might had been reached if this vote had more spotlights ons.

  • YAE (I support a rerun of this vote)
  • NAE (I don’t support a rerun of this vote)
  • ABSTAIN

0 voters

1 Like
5

Yeah, we definitely need to rerun it
Definitely in favor of this proposal

1 Like
6

ser, the Snapshot had 120k YAE votes. I believe you mean 150k for the threshold (from portals gov framework)?

7

Yes,

The threshold is 150k votes so 30K YAE votes short from quorum ser.

2 Likes
8

Aha! I misread your first post, thanks for clarifying

9

I think it may be good to give people a hint that on weekends there isnt much going on in the governance and snapshot forums. I wasnt able to vote too, even though i would have voted yes.

2 Likes
10

Thanks for this rigorous proposal @alex_deBridge! Excited for crosschain Aave rebalances :slight_smile:

From what I understand, deBridge relies on permissionless contracts as well as the native bridges. Could you please detail the journey of the bridged liquidity from the Aave Market Chain 1 → portal → DeBridge → ?? → Aave Market Chain 2

There has been so many bridge vulnerabilities exposed these last few months, I’d love to hear if DeBridge is exposed and what mitigating measures you have in place. For example is DeBridge vulnerable to a server hack and stealing of keys? of social attacks? of a smart contract upgrade? I think it would be very helpful for the community to recap the latest hacks and explain how deBridge would have coped.

In terms of exposures, the proposed credit lines represent an overall appropriate risk level to bootstrap the portal feature. That being said, this can’t cause systemic risk or liquidity issues in Aave markets. If liquidity is scarce the limits must be adjusted based on the underlying liquidity to avoid concentration risk and affecting user experience. As a start, I would fix the credit line per portal user to a max 5% of the market liquidity per asset and 20% of the available liquidity.

Avalanche Polygon Optimism Arbitrum
Market Size 2,270,000,000 5% 112,450,000 5% 1,800,000,000 5% 39,390,000 5%
USDC 1,270,000,000 55.95% 63,500,000 38,560,000 34% 1,928,000 839,440,000 46.64% 41,972,000 15,540,000 39% 777,000
USDT 384,010,000 16.92% 19,200,500 4,030,000 4% 201,500 138,280,000 7.68% 6,914,000 1,260,000 3% 63,000
ETH 67,920 3,396 11,970 0% 599 106,450 5,323 8,550 428
Available Liquidity 20% 20% 20% 20%
USDC 523,620,000 26,181,000 28,500,000 1,425,000 183,880,000 9,194,000 10,990,000 549,500
USDT 36,330,000 1,816,500 813,470 40,674 24,840,000 1,242,000 435,110 21,756
ETH 64,033 3,202 10,201 510 85,042 4,252 7,586 379

The min of 5% of market size and 20% of available gives us the following maximum credit lines

Max Credit Line Avalanche Polygon Optimism Arbitrum
USDC 26,181,000 1,425,000 9,194,000 549,500
USDT 1,816,500 40,674 1,242,000 21,756
ETH 3,202 510 4,252 380

This requires some adjustment for the credit lines of:

  • USDC on Polygon with a cap of $1.4M, Arbitrum $550k
  • USDT on Avalanche with a cap of $1.8M, Polygon $40k, Optimism $1.25M, Arbitrum $22k
  • ETH on Polygon with a cap of 510ETH, Arbitrum 380ETH

Are credit lines worthwhile even if small, or is there a threshold required to start becoming relevant?

My understanding is bridging is a quantity business, with small fees that materialise with volume. I’d be curious to see some cashflow projections to understand how this liquidity will be used and the financial outcomes for the Aave DAO.

3 Likes
11

Hi Alex, thank you for the detailed comment:

From what I understand, deBridge relies on permissionless contracts as well as native bridges.

deBridge is a technology that consists of two layers:

  • Protocol layer — permissionless open-source smart contracts deployed on every blockchain deBridge supports.
  • Infrastructure layer — off-chain validation nodes operated by validators who are elected by and working for deBridge governance

The smart contracts act as cross-chain message routers providing an interface for users (EOA addresses) and protocols to interact with deBridge.

By design, deBridge doesn’t rely on native bridges, but since the protocol is fully compatible with the existing DeFi ecosystem, builders can opt to combine deBridge with canonical bridges when needed.

Could you please detail the journey of the bridged liquidity from the Aave Market Chain 1 → portal → DeBridge → ?? → Aave Market Chain 2

Yes. If we zoom out, a cross-chain value transfer is an order that can be settled in different ways. All existing bridges settle these orders from their own liquidity pools where liquidity is continuously locked. With this design, bridge projects are built as liquidity protocols which are forced into running unsustainable liquidity mining campaigns without the ability to monetize liquidity efficiently and securely. Moreover, this approach places bridges in competition with purpose-built and established liquidity protocols like Aave.

At deBridge, we are advocates of composability and synergy between protocols. That’s why instead of building a liquidity protocol, we believe that it’s better to source liquidity from an existing purpose-built liquidity protocol (Aave) bringing an additional monetization channel for its liquidity.

Let’s see how it works in practice using an example of value transfer:
Aave Market Chain 1 → Aave Market Chain 2

Sender interacts with the deAaveAdapter smart contract (to be developed by the deBridge team) where the Portal integration logic is implemented. Smart contract performs the following steps:

  1. Accept liquidity from the sender on Chain 1 and check if there is any unbacked amount to be repaid to Portal on this chain
  2. Pay the outstanding amount and lock the remaining liquidity in the deAaveAdapter
  3. Send a message to the deAaveAdapter on Chain 2 through deBridge. The message contains a command to borrow the corresponding amount of liquidity from Portal, redeem aToken and transfer liquidity to the receiver address.

Once the transaction on Chain 1 is final and irreversible, the deBridge infrastructure will execute the transaction on the destination Chain 2 in the following sequence:

  1. Execution of the message passed to deAaveAdapter. The deAaveAdapter smart contract validates message sender address and chainId
  2. deAaveAdapter mints the requested amount of aTokens by calling mintUnbacked function of Portals
  3. deAaveAdapter redeems received aTokens and transfers the resulting tokens to the receiver by calling withdraw method of AAVE protocol

This design guarantees that any amount outstanding to Portals on Chain 2 is backed by the same amount of collateral locked in the deAaveAdapter smart contract on Chain 1. More information about cross-chain generic messaging can be found in our documentation

At deBridge, security has been our main priority from day one — it was our first consideration before even starting to design the protocol. This is why we have a comprehensive set of security measures laid into the protocol design itself.
Some of these measures are described in our article published here.

There have been numerous hacks of bridging protocols, we can categorize them into two types of exploits:

  1. Vulnerabilities in smart contracts
  2. Social attacks where bridging infrastructure was compromised

The first group is related to attacks on projects like Wormhole and Nomad, where vulnerabilities of smart contracts led to exploits of the infrastructure. There is no way to guarantee that smart contracts don’t contain vulnerabilities, and the goal of all teams building in DeFi is to minimize the probability of their existence.
One analogy to conceptualize the security of bridging protocols is the “Swiss cheese model”, where the only way to execute an attack is if a number of “holes” momentarily line up. In order to make the level of risk negligible, the size of the hole on each layer should be aimed to be as minimal as possible, and the number of layers should be maximized.

These layers/security measures are divided into a few groups:

  • Measures built into protocol design:
    • State consistency validation (simply speaking - validation of balance sheets)
    • Nonce sequence validation (to prevent and instantly detect 51% attacks, reorgs, problems with consensus)
    • Strict transaction finality rules
    • Isolated security model for every chain (potential vulnerability in one chain shouldn’t influence liquidity locked in others)
    • Off-chain validation (validators don’t need to communicate with each other and expose their IP addresses and overall infrastructure)
  • Off-chain measures:
    • Monitoring scripts and backstop mechanism (to Pause the protocol if critical monitorings triggered)
    • Security audits
    • Code reviews and work-out flows of how code is delivered into production
    • Bug bounty campaigns
    • Decentralized protocol-authority key management

These are some points that we’ve implemented in deBridge. As example, State consistency validation could have minimized the damage done to Wormhole, since it wouldn’t allow an attacker to withdraw minted wETH tokens from Solana to Ethereum.

For example is DeBridge vulnerable to a server hack and stealing of keys? of social attacks? of a smart contract upgrade? I think it would be very helpful for the community to recap the latest hacks and explain how deBridge would have coped.

deBridge’s infrastructure is fully decentralized and in order to attack it with malicious intent, the attacker would need to compromise at least 8/12 validators by stealing their private keys or making them sign malicious transactions. Thanks to off-chain validation, validators don’t need to broadcast any transactions and don’t communicate with each other. That’s why validators never expose their IP addresses and the only way to perform the attack would be via social engineering. At deBridge, we work only with professional infrastructure providers, who strictly follow all the best security practices. A complete list of validators is available here.

Once control over the deBridge protocol is passed to governance, the number of validators will be gradually increased by governance. We are happy with the current state of decentralization, but will iteratively improve to make the protocol more decentralized.

Addressing your other question, the deBridge protocol smart contracts are upgradeable. Protocol authority is controlled through Gnosis Safe multisig, and we will gradually increase the list of signers by adding more reputable stakeholders from the industry, and eventually control should be passed to governance. This is a list of signers we will have prior to the integration with Portals.

We are always willing to add more signers and invite some prominent figure from the Aave community to become signers.

Your suggestion to adjust the size of credit lines makes a lot of sense, as we all want to be sure that Aave depositors can withdraw their liquidity from the protocol without being dependent on liquidity utilization within portals.

Are credit lines worthwhile even if small, or is there a threshold required to start becoming relevant?

Theoretically, all value transfers can be routed through one asset (e.g. USDC), but in this case users will have to pay swap fees in both chains. That’s why it’s better to route USDT->USDT and ETH->ETH transfers through these assets themselves.

USDT on Avalanche with a cap of $1.8M, Polygon $40k, Optimism $1.25M, Arbitrum $22k

I suggest removing Polygon ($40k) and Arbitrum ($22k) USDT lines, and route these value transfers through USDC to avoid complexities around rebalancing amounts within small credit lines.
Thanks for your consideration, we are looking forward to your feedback, and of course, let us know if you have any questions here or on another topic.

2 Likes
12

I think these are very important questions that need to be clarified before the community proceeds with adding deBridge to portals. I would also say it makes sense to set up some rules for Portals integrations with regards to:

  1. minimum time in operation
  2. audit & security practices
  3. maximum exposure thresholds

E.g. we could propose to have Portals partners scale up from $1M in the first 3mo to $2M in the first 6mo to $5M-10M thereafter. This would allow partners to integrate but scale safely with Aave.

1 Like
13

Hi, thank you for the comment

I think that risk control always makes sense, especially for cross-chain space, so this suggestion is reasonable. Do you think the proposed $1M initial limit should be per credit line/per chain/ or per all chains?