[Portals] Powering the Multi-blockchain multiverse

Powering the Multi-blockchain multiverse

Recap :

Aave V3 allows the Aave governance to whitelist entities (such as Bridging protocols defined here as “Ports”) to mint “temporary unbacked” aTokens by interacting with an Aave Gateway contract. One of the main applications of this is Asset “teleportation” by collecting aTokens on one network to mint an equivalent amount on another chain. Settlement of multiple users teleports is done async by Ports using “official” cross-chain bridges to settle credit lines.

Portals are not a user-oriented feature, it’s a toolbox that Ports can integrate into their own architecture to act for example as a liquidity failsafe in case their router lack liquidity, and increase their reach and liquidity efficiency.

A “Port” is thus an Aave V3 Portals integration by a third-party app allowing cross-chain asset “teleportation” on 2 or more networks.

in this illustrative chart a first user has liquidity on Arbitrum, he teleport its liquidity via Connext Port, Connext mint onBehalf of the user liquidity on GnosisChain (xDAI) by interacting with the xDai Aave gateway and deliver liquidity to the user there. Connext will later Settle users positions in the gnosis chain to keep their Credit Line with the Aave Gateway. Second example is the same flow with an user using cBridge Port on Harmony to teleport liquidity on CELO

Aave V3 deployment strategy:

Aave V2 pioneered the “multiverse” with the “new frontiers” strategy and V2 deployments on the Polygon and Avalanche networks.

Low user overlap between networks, significant user growth, incentivized LM programs and boosted protocol revenue were among the many benefits of these deployments.

The protocol also learned about the challenges and limitations of liquidity fragmentation, non-optimal bridging experience, and liquidity limitations of L2<>L2 bridges adding friction to adoption and arbitrage action helping the rates equilibrium.

Aave is a neutral middleware liquidity protocol of DeFi. The potential synergies offered by portals will allow the current ecosystem bridges to reduce friction and help users find a seamless experience between networks.

Because Aave is neutral, it’s not efficient to “pick favorites” and mid-term Aave V3 can potentially be deployed on most EVM compatible networks and even long term out of the “EVM-comfort zone”

That being said, Aave community bandwidth and resources are not infinite, some prioritization might be needed in terms of the V3 deployment schedule.


The Aave protocol was born and raised in the Ethereum ecosystem, Ethereum is the center of gravity of the blockchain ecosystem innovation but is also a victim of its own success because ETH L1 is so valuable, users are overtime increasingly willing to pay to use it, we now reach a situation in which users worth less than 5 figures are de facto “priced-out” of ETH L1.

This challenge was expected and high transaction fees are a feature of a healthy L1. The Ethereum community and development foundation started working long ago on a “rollup-centric” approach considering L1 as the settlement and high-value network and L2s as application layers.

There are functional L2s on ETH available today, and several are still in development. Aave V3 and portals might contribute significantly to both the growth and the user experience of these networks.

Portals are ready-made “fast exit” solutions of L2s and mitigate the weekly or costly burden of leaving these L2s. With Aave V3, Users will experience seamless hop-in and out of these networks.

The current Rollups that traction and community interest are:

Which could be considered good candidates for a V3 deployment

EVM Alt-L1 networks

The first “new frontiers” experienced by the Aave protocol, AVAX, and Polygon are in this category with every metric showing great success.

With low witnessed user overlap between Aave deployment, these EVM Alt-L1 networks have fully-fledged communities and assets that make them different and valuable outside of the Ethereum sphere while conserving the Ethereum technology via EVM making deployment there almost seamless for the Aave protocol.

User activity and TVL growth make these network hard to ignore.

Aave V3 and portals will add value to these networks and allow Aave to meet new communities and potential users.

The current EVM Alt L1 that reached traction and/or maturity are :

Special Case Strategic CeFi EVM L1

Some alt EVM L1s are heavily linked to CeFi exchanges and are prime candidates for portals as they can act as “gateways” to in/offramp with CeFi.

For a set of reasons, CeFi is currently slow to support the multiverse, and heavily biased towards networks they have a natural synergy with only. They currently offer sporadic or no support at all for alternative networks adding real friction to onboarding new users into the multiverse as it can be costly and difficult to reach alternatives.

Having V3 portals on these networks mitigate these frictions and makes the Alt L1 EVMs more attractive and easier to access. Aave has both liquidity potential on these networks and volume opportunity for the Portals feature.

That being said the industry least kept secret is that these networks are often heavily centralized and will often favor short-term user comfort to long-term infrastructure sustainability.

It’s up to the governance to decide on the risk/reward of these strategic deployments and if the TVL, user growth, fee collection and volume potential are worth the infrastructure risks.

The main networks that reached maturity and are candidates are:

Alternatives option:

  • HECO (Huobi)
  • OKT (OKEX)
  • KCC (Kucoin)

EVM L2 on top of non-EVM networks: “bridgeheads”

In the multiverse blockchain ecosystem, over the last few years, Ethereum technology became the main standard but not the only one. Non-EVM networks are growing in every metric and are very likely to stay.

Adapting a protocol codebase that is potentially destined to hold Billions of $ of value is not a trivial process. Adapting the Aave protocol codebase outside of the EVM-comfort zone is extremely costly in 3 resources: bandwidth, money, and the most valuable of all three, Time.

An alternative or a complementary approach would be a “bridgehead” strategy, to “meet in the middle” the non-EVM community of Alt-L1 in the context of an EVM-compatible layer on top of the L1. This strategy allows the community to have access to the Aave protocol while staying in their ecosystem and benefiting from their own local assets.

The current EVM layers on top of non-EVM networks that are on the radar are:

  • NEON (Solana)
  • Acala (Polkadot own defi dapps) and Moonbeam (general purpose)
  • Aurora (NEAR)
  • Moonriver (Kusama)
  • Evmos (Cosmos)

Having Aave V3 on these networks will allow having many Ports at the benefit of the overall ecosystem user experience, helping arbitrage and rates equilibrium, and contributing to the Aave Protocol growth by every metric.

Please be aware that this list is for illustration only and does not reflect a precise and set-in-stone roadmap.

Any network willing to host Aave V3 should query the Aave governance sentiment by doing a Snapshot vote.

Pricing and fee model

Aave V3 and the portals feature will upgrade the multiverse users’ journey. This service has value and should bring value to the Aave ecosystem. The Aave governance should define whitelisted entities, a case-by-case basis fee model can exist via the AIP process.

  • Minting fee model

A straightforward way to implement fees is having the protocol to charge whitelisted entities minting fees.

If Port X collects 100 aUSDC from a user on Network A, they’ll be able to mint 100 aUSDC on network B but their credit line will be used for slightly more than 100 aUSDC.

When eventually Port X Settle() the positions taken on behalf of their users between network A et B, they will settle more than what has been minted by the Aave protocol.

Several pricing models can be defined on this minting fee model: volume-based, fixed fee, asset-based, and most likely a mix of these models.

One important note on this model is to recognize the current ecosystem context, most existing bridges are currently implementing fixed fees in a 5 to 10 bps range, any fixed-fee model shall be considered to be compatible with the current ecosystem to stay as an attractive tool for the protocols potentially integrating Portals.

  • Fee-based on interests model

The fixed fee model has some limitations, for very short mint and settle events, the “APR” of used liquidity can be high, Aave V1 had a “mint” fee on borrows and the community feedback helped introduce the reserveFactor model to replace it.

In this model, minted aTokens would be considered debt from a protocol perspective, the amount that a Minting entity will need to settle to replenish their credit line will grow over time.

This model has the advantage of favoriting the short-term usage of minted assets, the quick settlement of credit lines, and by applying only a reserve factor model for the fee collector might allow contributing to liquidity providers overall yield.

Aave is a decentralized protocol, this post is not intended to be an official roadmap but a starting resource for community discussion, the Aave governance will decide on this topic, and feel free to express your opinions on this topic in this thread.

Summary of the actions points of this thread :

  • Gather community discussion about the Portals feature and mechanisms
  • Gather community discussion on V3 deployment network candidates
  • Gather community discussion about the Portals fee model.

@MarcZeller thanks for summarizing this here. It’s great to see the development, visualization, and inspiration behind some of the new features of V3.

Correct me if I am wrong, but Portals seems to be a bridge aggregator - a “gateway” to multiple networks.

How will the efficacy (or profitability) of this feature be affected if users are hopping to / using one network much more than others?

“Bridgeheads” seems incredibly interesting. I am glad to see the inclusion of Aurora, Mooriver, and Evmos in particular - these are great ways to capture and plan for future growth.

For the minting fee model - are you able to combine certain pricing sub-models? Say a fixed fee up to an X% or $X - then transition to a volume-based fee for transactions greater than that?


Blockquote Correct me if I am wrong, but Portals seems to be a bridge aggregator - a “gateway” to multiple networks.

Portals at it’s core is a toolbox that Bridges protocols (in our context called “Ports”) can use to mint aTokens on networks they have a credit line on. Portals is not user-facing and do not compete with bridges, quite the opposite as bridges leverage from this feature to increase their potential reach.

How will the efficacy (or profitability) of this feature be affected if users are hopping to / using one network much more than others?

not much as feature especially before CCIP is live is heavily limited in scope to whitelisted entities having credit lines. if credit line runs out it’s the responsibility of the Port to settle their position if they wish to keep using portals, severe directional flux of transfers means settlement positions needs to happen more regularly and/or larger credit lines might be asked. even in this scenario, Ports actors benefits from economies of scale of batching their user volume and end users benefits from more liquidity that in current router bridge system directional flows means liquidity is quite scarce for these routes.

last point, very directional flow, means less and less token liquidity on the network people leave, that might end up in more attractive supply rates helping markets to find back some form of equilibrum.

For the minting fee model - are you able to combine certain pricing sub-models? Say a fixed fee up to an X% or $X - then transition to a volume-based fee for transactions greater than that?

V3 and Aave gateways allows full granularity on fee model.
Each port can ask for a unique to them fee model, and even a fee model different for each network and asset. up to Port to come forward to the governance with business model that’s is a win-win for actors involved.


To clarify, this will basically allow users to seamlessly move collateral and debt across different chains?
For instance, if a user has debt position on mainnet, then they can move debt position to Polygon using portals?

1 Like

For portals v0 as it’ll will exist in the early days of V3, only collateral can be moved seamlessly across networks (at the condition this teleport doesn’t cause a liquidation on the network the user exits)

Debt can’t be moved across networks yet.
Mid-term with the release of tech such as CCIP, an upgraded version of portals or third-party applications leveraging on both portals and credit delegation might provide debt teleport and with it full positions teleportation.


Im a bit concerned with all those bridge hacks going on. We have to choose very careful which bridge should be allowed to use this feature.


Maybe I am not understanding correctly, but the bridge hacks are a product of multi-sigs holding massive amounts of tokens on one chain, and wrapping those tokens for users on the new chain… Thus if the multi-sig is exploited, the funds backing the wrapped tokens are no longer available…(Please fact check me, as I am not very technical).

So, Wouldn’t the mint/burn functionality of portals ease the concern of an attack?


Can you explain how Aave portals works step by step?

Hi. This might not be defined as of yet, but any idea of what would be the “speed” of Aave Portals ? In the CCIP implementation, could we reasonably expect being able to “teleport mint” on Chain B funds in less than a minute (if the collateral was on Chain A for a while already and ready for it) ?
Or are we talking about delays similar to other bridges (multiple minutes).

Portals is a tool for bridges/entities not directly designed to be used by users.

so from the user perspective bridge time = portal time.

that said portals is “almost” instant so it might help bridge to speed up txs mid term.

Whats the status with Portals? Has anyone used it yet? I remember Connext and deBridge wanted to be whitelisted and then?

1 Like