[ARC] - Whitelist Hashflow/Wormhole for V3 Portals

Governance
1

Proposal

Wormhole is a leading cross-chain interoperability protocol, allowing generic messaging over 22 heterogenous blockchains and soon to be many more.

Since launch on mainnet in August 2021, 160 million messages have been transmitted with 2 million messages currently generated a day between asset transfers and messaging. The sheer load of messages that Wormhole processes in a 24 hour period is comparable to an L1 and signals its high reliability.

Wormhole has nineteen guardians comprised of the leading PoS validators who jointly attest to messages. Each guardian holds equal weight in governance and consensus. Wormhole requires over two-thirds of the 19 guardians to gain consensus and pass verification, thus we assume that at least one-third of our guardian set is trustworthy.

Hashflow is a decentralized exchange platform designed for interoperability, zero slippage, and MEV-protected trades. Hashflow works by connecting professional market makers directly to traders using a request-for-quote (RFQ) model.

Hashflow uses DeFi-native RFQs to fetch quotes from market makers who are responsible for managing liquidity in the pools. Market makers are required to cryptographically sign quotes that remain unchanged for the duration of the trade. This ensures that the price is guaranteed and cannot be front-run or sandwich attacked. It also protects traders against slippage if there is significant price movement between the time it takes to validate the transaction on the source chain and relay the payload on to the destination chain.

Hashflow leverages Wormhole’s generalized message-passing to communicate between source and destination chains.

We propose a custom protocol utilizing Wormhole’s generic messaging for cross-chain communication and Hashflow’s cross-chain DEX to facilitate collateral transfers when backing aTokens (detailed below). Generic messaging unlocks Wormhole as a neutral interoperability layer on which protocols can serve users across most chains today. Wormhole has been integrated with Hashflow, which leverages a request-for-quote (RFQ) model for efficient liquidity provision, depth, and order execution quality. Users request a quote to sell some amount of asset X on the source chain and buy some amount of asset Y on the target chain without incurring slippage on the quoted price. Institutional market makers compete on price and depth for order execution and provide a signed quote to the user, which the user includes as calldata when sending the trade transaction on the source chain. With over $11.75B in lifetime trading volume and aggregate average daily volume of $25M from traders directly using the platform and through the aggregators 1inch Network, Open Ocean, Odos, and Zerion, Hashflow has been battle-tested and is a logical starting choice for these cross-chain collateral transfers. Users pay no trading fees for this cross-chain swap but are responsible for the associated gas fees when bridging their aTokens and might incur an implicit fee in any price-differences between the collateral asset on the source and destination chain. Additionally, Wormhole currently does not charge any fees for token bridging.

Pending Aave V3 deployments on the specific L1s/L2s, the protocol can support Aave on Ethereum, Avalanche, Polygon, Arbitrum, Optimism, and BNB. To start, we suggest piloting Portals on Arbitrum as a burgeoning deployment and ecosystem.

Integration

A custom protocol (”Protocol”) utilizing Wormhole and Hashflow for a Portals integration could function as follows for a given source and target chain:

  1. User uses the Protocol front-end built on Wormhole to transfer aTokens to the Protocol contract.

    1. Protocol front-end will fetch a signed quote from Hashflow which will be used as a payload to perform the cross-chain swap
    2. Protocol front-end will allow the user to review the quote before confirming the transaction
    3. User’s aTokens are then escrowed in the Protocol on the source chain.

  2. Following the transfer of aTokens, the source chain Protocol contract calls the withdraw function in the Aave Pool contract on the source chain, which transfers the user’s previously escrowed aTokens from the Protocol contract to the Aave Pool contract and then transfers the user’s underlying collateral from the Aave Pool contract to the Protocol contract.

  3. The contract then submits the signed quote to Hashflow’s cross-chain router to swap the user’s source-chain native collateral to the target-chain native collateral, sending this collateral to the target chain Protocol contract.

  4. Next, the target chain Protocol contract calls mintUnbacked function in the target chain Aave Pool contract followed by the backUnbacked function to atomically mint aTokens to the user on the target chain and back these aTokens.

image
image1920Ă—1176 38.9 KB

To prevent the collateral risk to the Protocol on the source chain and to allow for seamless atomic liquidations on the target chain, we suggest that Aave prevent users from bridging aTokens used as collateral on the source chain and prevent the use of the unbacked aTokens as collateral on the target chain until they’ve been backed by the bridge.

Technical Specifications

Proposed Portals Asset Minting Caps

On all networks that Aave V3 is deployed on and Wormhole supports, we propose conservative Portals minting caps of $0.5M, $1M, and 50 ETH respectively for USDC, USDT, and ETH to begin with but aim to increase this over time subject to governance. The protocol will charge users a nominal 3bps fee to bridge over their aTokens, of which the Aave DAO will be entitled to 50%.

Screenshot 2023-02-22 at 3.27.46 PM
Screenshot 2023-02-22 at 3.27.46 PM1436Ă—168 6.53 KB

Benefits to AaveDAO

Aave is at an inflection point, with a sizable but closing head-start on its multi-chain deployment and usage. With the launch of V3 on Ethereum, it is timely to pilot Portals, enabling seamless flows of capital from the liquidity hub of Ethereum to the other V3 deployments. For AaveDao’s longterm success, it’s imperative that the DAO fosters these multi-chain deployments while still in the lead as the tight integration of aToken assets into DeFi creates a strong moat. Additionally, with tens to hundreds of millions of TVL and volume in Hashflow and Wormhole, we see Portals as an natural way to onboard Hashflow and Wormhole users into the Aave ecosystem.

Audits & Security

  • List of relevant security audits of the Wormhole network

  • List of relevant security audits of Hashflow

  • Security Properties

    • The Wormhole dependency in the implementation above is in the core messaging layer, relying on the standard trust assumption of the PoA consensus with 19 guardians where more than two-thirds are required to reach consensus and verify a message. These guardians are made up of some of the largest and most reputable staking providers in crypto. This level of operational security diversity is a useful property in preventing wholesale compromise of the Guardian Set due to operational failures of a single or small number of organizations. More information on Wormhole security practices can be found here.

    • Hashflow relies on Market Makers for providing quotes, and Wormhole for ensuring that the cross-chain messages are correctly passed. The former is a transparent process (the user can see these quotes ahead of execution), whereas the latter falls back on Wormhole’s security properties.

    • The logic of creating new unbacked aTokens on the target chain, withdrawing collateral on behalf of the user on the source chain, and backing users’ unbacked aTokens on the target chain lies in the Aave protocol, falling back on Aave’s security.

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

    • We recognize that Wormhole has earned some press for the hack in February of this year. Since then, Wormhole continues to add multiple security layers to help prevent/mitigate the effects of smart contract bugs like the one responsible for that hack:

      • The first of these, Governor, allows each Guardian to set limits on the notional value of any transfer originating on a supported chain within a specified time period. The Governor allows Wormhole Guardians to provide optional value movement protections to token bridges built on Wormhole. This protection allows Wormhole Guardians to govern (or effectively rate-limit) the notional flow of assets from any given token bridge chain. This safety feature allows Guardians to limit the impact of any security issue any given chain may have from affecting other connected chains. The Governor allows the setting of daily limits of notional flow and also has an ability to set a fixed finality delay for transactions over a specific size for each supported chain.

      • Further layers of security to prevent incorrect withdrawals of funds is the Cosmos-based Wormhole Chain, which enables Guardians to independently verify if the source chain has sufficient funds to do cross-chain transfers, and an emergency shutdown module, allowing a quorum of Guardians to temporarily pause value movement through Wormhole.

    • Additionally, Wormhole has a $2.5M bounty program on Immunefi.
8 Likes
2

Thanks @gandalfthebrown for the post!

With V3 finally live on Ethereum, it’s great to see the discussion around portals pick up again.

Given the Hashflow/Wormhole infrastructure combination has been live and working great for a considerable period of time, we are in support of this proposal!

The no-slippage benefit of utilizing an RFQ model over an AMM is a big plus for UX on Aave; the 3bp fee is fair and the 50% revenue split is a nice way to align incentives.

We just had one question regarding the minting caps, is there a reason why USDC < USDT? We would be in favour of bumping USDC up to $1M given it can be used as collateral on both Arbitrum and Ethereum. Adding to this, USDT on Ethereum V3 cannot be used as collateral and on Arbitrum it can only be used in isolation mode.

Thanks!

Disclaimer: Wintermute is an investor in Hashflow and facilitates RFQs on the platform.

4 Likes
3

hello @gandalfthebrown and thanks for this ARC proposal.

The proposal is a elegant and efficient implementation of portals, to our current understanding, it’s a Just in time (JIT) intra-block liquidity leveraging portals allowing both conservative Aave protocol risk exposure and because the credit line can be virtually re-mobilized frequently it can lead to high aggregated volume even with proposed strict credit line caps.

The Aave-Chan initiative have a few recommendations/remarks :

  1. The current proposal is a “pilot” program, we think there’s a clear usecase for L1 <> L2 JIT liquidity and would support a experiment between L1 & Arbitrum and/or Optimism first, then after a period that allow to collect data and experience expand to other networks.

  2. Considering the relatively small amount of credit line requested, I think the community would appreciate that a equivalent amount could be deposited in Aave Pools in the form of aTokens that could be potentially mobilized in case of shortfall, it is likely that the actors involved in the current proposal have the ability without too much friction to make it happen.

  3. We consider the fee model fair and efficient and while even with a large success it won’t represent the majority of DAO revenue, the current model is beneficial to all actors involved and for end-users.

  4. While the current position of the ACI is supportive, we would recommend a “Temp check” snapshot to gauge community support and have tech (@bgdlabs) & risk service provider provide valuable feedback for this proposal, in the case of not strong opposition from these actors, the ACI would be in a better position to form a educated opinion & happy to both support this proposal and to be considered an available ressource for the implementation of this proposal AIP.

6 Likes
4

Appreciate the post here and glad to see months of work come to the forums. From our side, the Wormhole/Hashflow infra combo and connections has been working well for a while now, and we’re confident they’re good partners for this endeavor as well. We’re glad to see the portals discussions come back to the forums and think its a great time to introduce them finally.

@WintermuteGovernance makes a good point regarding why USDC < USDT and would be in support of upping USDC to $1M as well.

We are also in support of @MarcZeller’s point on having a snapshot temperature check to see how the general community feels on this as well/feedback, before an on chain vote.

2 Likes
5

Thank you for your feedback @WintermuteGovernance @MarcZeller @PennBlockchain! We’ve incorporated your feedback and addressed them in the points below.

We just had one question regarding the minting caps, is there a reason why USDC < USDT? We would be in favour of bumping USDC up to $1M given it can be used as collateral on both Arbitrum and Ethereum.

Absolutely, we will bump up the USDC mint cap to $1M.

The current proposal is a “pilot” program, we think there’s a clear usecase for L1 <> L2 JIT liquidity and would support a experiment between L1 & Arbitrum and/or Optimism first, then after a period that allow to collect data and experience expand to other networks.

We agree that ETH <> Arbitrum and/or Optimism are the best chains to run the pilot and showcase the power of the proposed design. Expansion to new chains should be decided on following sufficient time for evaluation.

While the current position of the ACI is supportive, we would recommend a “Temp check” snapshot to gauge community support and have tech (@bgdlabs) & risk service provider provide valuable feedback for this proposal, in the case of not strong opposition from these actors, the ACI would be in a better position to form a educated opinion & happy to both support this proposal and to be considered an available ressource for the implementation of this proposal AIP.

We agree, @MarcZeller @PennBlockchain-- we support a snapshot temperature check to gauge community support and additional due diligence required before proceeding to an on-chain vote.

1 Like
6

Thanks for the proposal @gandalfthebrown ! Some questions about it:

  1. Could you clarify if the system will deal somehow with the collateral side of the protocol? From our understanding, the solution deals with aTokens whenever they are not used as collateral (meaning no borrowings on the user initiating the tx on L1, or HF allowing him to transfer), but you mention this too
  1. Is it possible to have a more explicit flow with example actors/amounts/assets and timeline, let’s say between Ethereum and Arbitrum?
  2. A key aspect of all cross-chain systems like this is finality. Could you elaborate on what regards block confirmation you wait on the source chain before execution of the mintUnbacked on the target chain?
  3. Are we right that initially, this is to be used for just bridging of the same assets, and not for any type of cross-chain asset swap? Meaning aUSDC (L2/non-Ethereum) → aUSDC (Ethereum), but not any combination like aUSDC → WETH → aUSDC?
  4. Assume it is a YES, but will it be fine to not include any function on the Protocol Contract on L1 enabling borrow() or giving credit delegation?
1 Like
7
  1. Could you clarify if the system will deal somehow with the collateral side of the protocol? From our understanding, the solution deals with aTokens whenever they are not used as collateral (meaning no borrowings on the user initiating the tx on L1, or HF allowing him to transfer), but you mention this too

a. The protocol will not interact with the collateral side of the protocol as in no aTokens actively used as collateral are eligible to bridge to mitigate any undercollaterlized borrowing risks that could occur. By collateral, we mean the underlying tokens that were initially deposited to mint the aTokens.

  1. Is it possible to have a more explicit flow with example actors/amounts/assets and timeline, let’s say between Ethereum and Arbitrum?

a. User decides that they want to earn yield on Arbitrum with their 10K USDC earning interest on Aave, for example, so they interact with the Protocol frontend to bridge their 10K aUSDC to Arbitrum. The frontend then fetches a signed quote from Hashflow via these apis and calls into the Protocol Contract’s
swap function. swap atomically transfers the User’s 10K aUSDC to the Protocol Contract and then calls withdrawal in the Aave Pool Contract, burning the 10K aUSDC and retrieving the 10K USDC. Next, tradeXChain is called with the source and destination chainIds, and the 10K USDC as the token amount.

b. Once the Ethereum side of the swap is executed and the confirmation time of two epochs have passed, the Hashflow relayer will first submit the emitted Wormhole message to the Hashflow Router on Arbitrum. This will effectuate the second leg of the trade and send the 10K Arbitrum USDC to the Protocol
Contract on Arbitrum. Then, completeTransfer is called in the Protocol Contract, which will collect the 3 bps fee and first call mintUnbacked with the 9,997 USDC as the amount and the address and the User’s address as onBehalfOf, and lastly call backUnbacked with the 9,997 USDC as the amount and address and 1.5 as the fee .

  1. A key aspect of all cross-chain systems like this is finality. Could you elaborate on what regards block confirmation you wait on the source chain before execution of the mintUnbacked on the target chain?

a. Hashflow relies on Wormhole’s predefined confirmation time of 15 minutes before the Wormhole signed message is emitted. mintUnbacked will thus be executed at least 15 minutes after swap is called in the Protocol Contract on Ethereum.

  1. Are we right that initially, this is to be used for just bridging of the same assets, and not for any type of cross-chain asset swap? Meaning aUSDC (L2/non-Ethereum) → aUSDC (Ethereum), but not any combination like aUSDC → WETH → aUSDC?

a. Initially we plan on piloting with asset to asset but can then easily expand to any-any asset swaps as Hashflow already supports this.

  1. Assume it is a YES, but will it be fine to not include any function on the Protocol Contract on L1 enabling borrow() or giving credit delegation?

a. Yes, we think that the Protocol Contract should be limited just to withdrawing the underlying tokens from the L1 contract and calling into the Hashflow contracts to minimize complexity and risk for this pilot deployment.

8

Hello, The proposal has matured enough to be escalated to the snapshot phase.

The Aave-Chan Initiative has published a Snapshot vote with vote starting tomorrow.

If the outcome of this temp check vote is YAE, the proposal will be escalated to ARFC stage, and the discussion will be more focused on technical integration & risk management. The risk & dev services providers will be invited for a deeper dive into the proposal and provide feedback on it.

We want to thank everyone involved in the discussions.

3 Likes
9

Hi all, just some feedback from our side and our rationale on this vote, we’ll publish this on our Delegate Platform as well:

We are in support of this proposal to facilitate collateral transfers when backing aTokens using Wormhole and Hashflow, with a couple of points of consideration for the Aave community. Firstly, this proposal extends Aave’s head-start on its multi-chain deployment and usage and provides a very relevant use case to pilot v3’s Portals function, which is necessary. Secondly, Wormhole currently does not charge any fees for token bridging. The fee model makes sense and is likely not to change in the short to medium term. Thirdly, users also pay no trading fees for this cross-chain swap and are only responsible for the gas fees. Fourthly, the minting caps initially are small and mitigate risk, and are for three of the most-used and liquid assets in DeFi. And finally, Wormhole has put in steps to mitigate risks after the hack, including the Governor function, Wormhole Chain on Cosmos, and an emergency shutdown module (which, however, poses some centralisation risk since it is controlled by the Guardians).

However, we have two points to consider. First, Wormhole is controlled by 19 guardians and its consensus mechanism is proof of authority, so it is centralised to an extent and more of a risk for security. We recognise that they are exploring zk-bridging and this is not necessarily a reason to reject the proposal at the moment. However, the centralisation aspect does need to improve and become more resilient over time especially given the hack last year. Second, as @MarcZeller has suggested, in the event of a shortfall, it would be good if an equivalent amount could be deposited in Aave Pools in the form of aTokens that could be potentially mobilised. Wormhole/Hashflow could similarly deposit a percentage of fees generated to an Insurance Fund which would protect Aave in case of a shortfall. This is as Wormhole/Hashflow are sharing in the upside of transaction fees on Aave, but in the (unfortunate) circumstance that a hack occurs, Aave would have to bear all of the cost and therefore some sort of protection against a shortfall would be better to align incentives.

Overall, we are in favour of this proposal and will vote YES, while encouraging the actors involved in the current proposal to consider including an Insurance Fund (or something in the same vein) to better align incentives between Aave and Wormhole/Hashflow.

2 Likes