[ARFC] Aave V3 Deployment on zkEVM L2

Great discussion so far and we support the deployment of Aave V3 on Polygon’s zkEVM with the mentioned assets.

Thanks to @API3dave @UgurMersin and @KemarTiti for providing in-depth explanations of the differences and benefits between API3 and Pyth. On this note, we would also like to signal our appetite to explore alternative oracle solutions for Aave. Chainlink has continuously proven to be an exceptional oracle partner, however, we believe that Aave can certainly benefit from exploring alternative oracle solutions that could help the protocol’s expansion on chains where Chainlink does not exist and in general, provide further optionality to Aave.

Furthermore, higher frequency pull-based solutions like Pyth could unlock areas of protocol utility and it would be interesting to get @ChaosLabs and @Pauljlei opinions on the effects of more-frequent granular price updates on setting capital efficient risk parameters (specifically e-mode).

We respect @bgdlabs peace of mind sticking to the status quo, but we are curious how you’d picture Aave exploring different oracle sets outside of a new Aave deployment?

We believe Pyth as the primary oracle and Chainlink/API3 as the secondary oracle could offer higher security against bad debt for Aave, due to Pyth’s frequent price updates.


Disclaimer: Wintermute is a data provider on Pyth.

1 Like

Maybe this post wasn’t clear enough. The discussions about Oracles are closed.

Oracles are the most important piece of infrastructure for a liquidity protocol. Price feed is the way the protocol knows if a position is sufficiently collateralized or needs to be liquidated.

Any Oracle failure would have devastating effects on the protocol, the users, and Aave Brand.

That is why Oracle recommendations are not a beauty contest. Everyone had a fair shot at presenting their solution. Now the Aave DAO service provider will publish recommendations.

As the ACI, we will follow @bgdlabs recommendations on their upcoming report.

We invite the community to respect the governance process and refrain from adding to the oracle debate until BGD Labs recommendations are out.


As we also agree that having a discussion about everything around Aave is healthy, some extra considerations regarding our position:

  • First of all, we exclusively defend what we think is more optimal for Aave, from the standpoint of an entity with a deep understanding of all Aave technical infrastructure and the implications of changes.
    Our engagement with the DAO is to advise and contribute technically based on the previous principle, and the reality is that swapping an Oracle provider without a major reason is definitely not something that helps the perceived stability of the protocol, which goes before everything else.

  • We have absolutely no problem with proposals regarding more controlled experimentation of other types of oracles different from Chainlink. But we don’t think adding an extra variable on a potential deployment on a network with pretty new technology by itself (ZK/validity rollup) is positive for Aave under any circumstance unless it is simply impossible to have the current provider (Chainlink) there.

  • It is important to highlight that we are not saying that alternative solutions are not good, just that changing the approach precisely on a new network is not so good idea.

  • From a technical standpoint, it is not a realistic possibility to change from a “push” to a “pull” model right now on Aave. The implications on protocol design and especially user experience are high.

  • It is not so appropriate for this thread to become a discussion between price providers, as the topic is more regarding an Aave v3 deployment on zkEVM. We recommend the different participants to better create independent threads with specific comments.

  • We welcome also representatives from Chainlink to comment on their stand/timeline regarding Polygon zkEVM.


Thank you, @bgdlabs.

Hey everyone, Michael from Chainlink Labs here. I appreciate the community’s drive and excitement to expand to new networks.

Chainlink Labs has been actively working on deploying Chainlink Data Feeds on the Polygon zkEVM network, with additional zk-rollups such as zkSync and Starknet also being high priorities as well.

Chainlink Data Feeds are currently planned for deployment on zkEVM in Q2 of this year, pending a rigorous security and validation process and clearance of any technical issues, which is standard for new network launches. This would align with Aave’s roadmap and timelines for launching on the network.

As with every chain integration, Chainlink Labs always takes a methodical and security-focused approach, demonstrated by the proven track record of Chainlink Data Feed deployments on other blockchains, including those used across all existing Aave market deployments. Each blockchain and L2 has its own nuances, including differences in the EVM implementation, gas markets, consensus, finalization, and more. It is also not uncommon for new chains to iterate and modify how the chain operates, which may impact how oracles operate on that network. We are simply not willing to compromise on security.

We believe Aave shares a similar security-focused mindset, given the many decisions that have been made to protect the protocol. These initiatives include a robust and continuously improving Safety Module, adding Chainlink Proof of Reserve circuit breakers to Avalanche V3 Markets, onboarding two risk managers (@Gauntlet and @ChaosLabs), running the V3 protocol through six separate audits, and more plans on the way like Aave Forest.

As noted by @bgdlabs, zkEVM is still a very new network, so extra caution must be taken when deploying any DeFi-related infrastructure on a new network. It often takes time for a blockchain to become battle-tested once in production and address any potential issues not discovered in testing. A security-first approach is essential to ensuring Aave market deployments are robust against exploitation across a variety of verticals.

We are excited to continue supporting Aave’s multi-chain strategy and look forward to deploying Chainlink Data Feeds on zkEVM in the coming months.


relaunching this thread as @bgdlabs have published an infrastructure report, editing the proposal :


Chaos Labs Launch Parameter Recommendations

Chaos Labs supports listing WETH, USDC, and WMATIC as the initial assets on the proposed deployment on Polygon zkEVM. Launching these assets on a new deployment will help ensure a smooth and successful debut while minimizing risk. Additionally, these assets are widely used in the DeFi space, making them a reliable choice for early adoption on the zkEVM L2 network.

Following the guidelines of our approach to start with the battle-tested parameters of V3, we begin with a baseline of LT, LTV, Liquidation Penalty, and IR Curves similar to the values set today for WETH and USDC on Ethereum V3 and WMATIC on Polygon V3.

For the initial supply and borrow caps, following the same principles as our recommendations for launching new assets and introducing Aave on other new deployments, we suggest setting the supply cap at 2x the liquidity level available under the Liquidation Penalty price impact for each asset, and the borrow cap as (supply cap* UOptimal). These caps will be optimized via Risk Steward after observing usage on the new deployment and considering market and liquidity conditions.

Recommended Initial Parameters

Isolation Mode NO NO NO
Enable Borrow YES YES YES
Borrowable in Isolation NO YES NO
Enable Collateral YES YES YES
Loan To Value 80% 77% 68%
Liquidation Threshold 82.5% 80% 73%
Liquidation Bonus 5% 5% 10%
Reserve Factor 15% 10% 20%
Liquidation Protocol Fee 10% 10% 10%
Borrow Cap 280 1.26M 375K
Supply Cap 350 1.4M 500K
Debt Ceiling N/A N/A N/A
Base 1% 0% 0%
Slope1 3.8% 4% 6.1%
Uoptimal 80% 90% 75%
Slope2 80% 60% 100%

ARFC escalated to the snapshot stage

voting starts tomorrow.



Gauntlet supports the proposed parameters, which offer room for growth while balancing out risks associated with newer deployments. There is strong liquidity on Quickswap and Balancer relative to the size of Polygon zkEVM.

We have a few additional recommendations.

  • We recommend listing WSTETH at launch as well, with the below parameters.
  • We recommend lowering WETH Base to 0% and Slope 1 to 3.3% to accomodate for WSTETH recursive borrowing strategies.

Recommended Initial Parameters

Isolation Mode NO NO NO NO
Enable Borrow YES YES YES YES
Borrowable in Isolation NO YES NO NO
Enable Collateral YES YES YES YES
Emode Category ETH N/A N/A ETH
Loan To Value 80% 77% 68% 71%
Liquidation Threshold 82.5% 80% 73% 76%
Liquidation Bonus 5% 5.00% 10.00% 6%
Reserve Factor 15% 10% 20% 15%
Liquidation Protocol Fee 10.00% 10.00% 10.00% 10%
Borrow Cap 280 1.26m 375k 25
Supply Cap 350 1.4m 500k 250
Debt Ceiling N/A N/A N/A N/A
uOptimal 80% 90% 75% 45%
Base 0% 0% 0% 0%
Slope1 3.3% 4% 6.1% 7%
Slope2 80% 60% 100% 300%
1 Like