[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
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?
- 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.