[ARC] - Portals governance framework

[ARC] - Portals governance framework

Portals is a powerful Aave V3 feature allowing to supercharge cross-chain bridges liquidity.

Portals have been presented in this governance thread : https://governance.aave.com/t/portals-powering-the-multi-blockchain-multiverse/6889

this thread is a proposal of a framework for entities willing to be whitelisted by Aave V3 to be a standard compliant candidate.

Title [ARC] - Whitelist [Entity] for V3 Portals


Brief presentation of the entity and ecosystem 250 words max

[Technical Specifications]

Brief technical presentation of the entity including

  • Is the entity a Bridge?
  • If applicable the number of routers, total Liquidity of routers
  • Can anyone provide liquidity to the protocol?
  • Is liquidity incentivized?
  • Is there a fee model for participants?
  • does the entity is or is planning to provide available liquidity into Aave protocol?
  • Link to analytics dashboard of protocol (Liquidity, assets, networks, volume) https://connextscan.io is a good example.
  • If applicable, link to the user-focused dapp of the entity.
  • Link to technical documentation

[Proposed list Credit Line request]

a list of Networks & assets the entity plans to request a credit line for.

  • What’s the current liquidity of the entity on the network
  • What’s the current average 30d volume of the entity on these networks
  • What’s the requested credit line per Asset, per network?
  • What’s the fee model proposed per asset, per network? (Fixed or APR x % premium)
  • What’s the fee (in bps) requested per asset, per network?

For this section, a table with all requested information is suggested inspiration can be taken from this example:

Network Asset Current Liquidity Current 30D volume Requested credit Line Fee Model Fee requested
Network A Asset A 100M$ 400M$ 50M$ Fixed 3 bps
Network A Asset B 30M$ 20M$ 5M$ APR Network A APR x 5% premium
Network B Asset A 10M$ 80M$ 15M$ Fixed 3 Bps


Short brief if the network wants to do a Liquidity Mining program and include Aave V3 in it.

[Audits & Security]

  • List of relevant security audits of the network
  • Has the Entity experienced outages, downtime, or exploits/hacks? on which Networks?

If yes:

  • How many outages/downtime has your chain experienced in the last year? Please list the 5 last occurrences with dates and explanations
  • How long was the longest downtime?
  • What were the main issues & have they been resolved?
  • Does the Entity have a “safety module” or shortfall mechanism in case of liquidity exploit allowing it to cover all or part of requested credit lines?

This framework is intended to provide standardization of credit lines requests.

The proposed governance process for this credit line requests is to have each entity do a governance thread open for at least 5 days.

Then open a snapshot vote with a starting voting period 24h in the future with at least 3 day open vote period considered valid with a 150k AAVE vote yae.

The Aave governance will then quarterly create a cohort AIP with all snapshot validated requests to update Portals contracts and activate credit lines.

In the case of Networks not supporting cross-chain governance bridge, the success of an AIP will be enforced by community multisig according to governance votes.

The community should take note that Portals are a “v0” implementation relying on some trust assumption and lacking Credit lines elasticity.

This framework is intended for the early days of the Portals and V3, with upcoming new AAVE tokenomics + cross-chain messaging infrastructure, it is expected that Portals will see a significant rework to implement a more resillient, scalable and risk-minimization “V1”.

This is why, first Quarterly Credit Line attribution should be on the cautious side of things with moderate overall Credit lines attribution and treated as a “MVP” and an opportunity to collect market data before scaling the feature upon more tested grounds.


@MarcZeller big fan of this. I am a firm believer in productive governance, and these types of proposals will absolutely increase efficiency for proposals to come. Thank you!!

Thanks @MarcZeller for initiating the discussion.

In addition to that, I would add if the entity would be interested in having the Aave Safety Module covering the risk too, and which kind of compensation for AAVE stakers would be in return.

Snapshot proposal is live, made a huge typo in title but we can’t edit snapshots :sweat_smile: :



The framework snapshot officially passed with a YAE outcome and is now considered as a standard for credit line requests.

We should expect Credit Lines ARC threads in the governance forum to be posted shortly.

Even if portals is an exciting feature and part of the future of Aave, I would invite the community to consider Portals V0 conservatively in regard of the amounts of the credit lines attributed.

The first cohorts attributions might benefit to be considered as an opportunity to “test in prod” this feature and collect market data in preparation of the upcoming Portals V1 integrating a cross-chain messaging infrastructure.

1 Like

Unfortunately v1 is relying on CCIP, which will be released sometime this year. Could be end of year though. Chainlink needs time to release stuff.

1 Like

What is the motivation to using CCIP over LayerZero?

I think both are an option in general. Probably just longer relationship with Chainlink and already other products they are using which makes sense.

But dont know, maybe there is some restriction from Dev side i dont see.

When we approach the launch of Portals, I would be keen to kick off a conversation on the forum around the different cross-chain messaging protocols, if the tech allows it.

Chainlink has a strong relationship with the DAO and LayerZero & Axelar (among others) have been around for a while so would love to see them involved and publishing proposals :smiley:

Portals from Aave V3 protocol perspective are just a couple of SC methods allowing whitelisted entity to BRRR & burn unbacked aTokens.

Obviously this needs to be limited and “unbacked” means in fact “backed on another chain” but for that to become a reality we need the protocol to be aware of what is happening on other network to manage trustlessly credit lines for portals operators.

Aave has a deep and ancient relationship with Chainlink that makes CCIP a prime candidate but two things:

  1. portals can have as many implementations as potential operators candidate, it would be efficient to have a protocol-recommended framework, but there’s no reason not to allow operators to have their own architecture as long as the DAO considers it acceptable
  2. The DAO decides, Portals & cross-chain msg solutions are both immature at this point, once we reach maturity on both, the DAO will decide via AIPs on each proposal.

Makes sense. Glad to know there is no technical blockers to having multiple providers.