thanks for the answer. Fully understand and respect the decision to stick with a valuable and proven partner.
If there is some “minor experimentation” that you guys would like to conduct, we’d love to get in touch to potentially explore some of that.
I would like to echo Ugur’s comment here about us being willing to work with BGD and AAVE on whatever proof of concept is needed to show the reliability of our dAPIs.
We understand why BGD are reluctant to use different oracle providers, but I (personally) feel that dismissing oracles without testing could be seen as a protocol risk in itself, assuming a fork with a potentially more optimal solution is able to drain TVL (or gain TVL before an AAVE protocol deployment).
Thank you Marc Zeller for initiating this ARFC and to the broader AAVE community for engaging in this important discussion.
We have read the different options presented here, and we would like to express our support for Aave exploring integration opportunities with both Pyth and API3 as primary oracles on the Polygon zkEVM.
Starting with Pyth, they have a strong record of providing reliable and timely prices on different EVM chains through their cross-chain design. Pyth’s on-demand model accomplishes scalable provision of prices without sacrificing user experience or overwhelming blockspace on different networks. In particular, Pyth already provides prices for 0vix, a borrow-lend protocol on Polygon and zkEVM (and in fact the first borrow-lend platform on the zkEVM). Also QuickSwap will be integrating Pyth prices for their upcoming perpetual protocol. While there has been an important discussion on the push vs pull model and the subsequent trade offs each model make. We take the perspective that more frequent and granular pricing is best for protocol health and solvency.
On the other hand, API3 ambitious roadmap for self funded APIs, managed APIs for price feeds as 1st party oracles and then Oracle extractable value is really interesting for apps. API3 does not require dApps to run and monitor a separate price pusher instance or deal with additional infrastructure concerns. API3 is also close partners with us and we encourage new and novel oracle designs to push decentralization of this essential infrastructure stack.
The Polygon community appreciates the fair and reasonable arguments debated in public by @KemarTiti and @ugurmersin from both sides.
In the face of this conundrum, this may be an opportunity to improve oracle decentralisation and mitigate reliance on either oracle. We suggest the following situation -
Use Pyth oracles as primary source for price feeds while exploring Api3 as a secondary backup source.
Rationale this preposition is that, Pyth has been live in production since months, whereas API3 recently released the price feeds.
Marcin from RedStone here - first of all, we’re glad to see that the discussion about Chainlink alternatives opens up as the market matures. Monopolies are never good for innovation and can lead to groupthink, which is detrimental to the security, especially in distributed Web3 space - we are strongly convinced that Aave needs more than just one oracle to be sustainable and safe in the long run (aligned with your approach @fig).
Why RedStone Oracles
RedStone is best positioned as a first-line oracle for Aave on chains that lack Chainlink implementation, such as Polygon zkEVM, let me explain why:
RedStone is “The” On-Demand Oracle - we have been promoting the on-demand model narrative and developing our solution for the past 2 years. We know it’s “trendy” to call yourself On-Demand Oracle but the implementation of such a model is far from trivial.
RedStone has been developed & tested since Dec 2020, on mainnet since March 2022, well audited and securing real funds. Along the way we had to solve countless tech challenges (i.e. Assembly-level optimisation of costs), so we are confident that our implementation is the most technologically advanced if it comes to the on-demand oracle model.
Our flow is designed to be maximally cost efficient - happy to provide benchmarks vs other oracles on that front.
Our team embraced various Oracles needs from a diverse suite of protocols. Therefore, we leverage the Modular architecture of RedStone to offer tailor-made models meeting dApss needs. Currently, we offer 3 bespoke data consumption models (details below) and are open to creating the next ones, as RedStone components have been designed to be adjustable.
DeFi ecosystem is built on a promise of decentralisation & permissionlessness. Looking at factors limiting the decentralisation of Oracles such as governance of “ultimate” multisig or full control over the off-chain component, we designed the RedStone ecosystem, so that it can operate under any circumstances.
While we give maximum possible freedom to dApps builders, we also acknowledge that the overhead of running Oracle relayers can be an overkill. Hence in our RedStone Classic model, our team can take care of running the Relayer or share the responsibility with a dApp. No need to run, maintain and secure your own service - we take care of that.
Battle-tested - on mainnet with 100% uptime since March 2022, and thousands of transactions secured, i.e. for DeltaPrime on Avalanche (dedicated Dune dashboard).
A protocol using RedStone Oracle has full clarity and transparency in terms of data sources and origins of consumed price feeds - as opposed to the black box offered by some of the popular incumbents. On top of that, we give dApps creators a spectrum of customisation options regarding off-chain and on-chain aggregation methods, as well as picking Data Providers they trust.
RedStone specialises in EVM L1s & L2s, our Founder knows all its quirks and features thanks to his Smart Contract auditing experience. At the same time, our team (80% devs) keeps up with the ZK-tech, therefore RedStone is available on zkSync Era, Polygon zkEVM, Scroll and Starknet. Our infrastructure is designed for Oracle use cases from day 1, as opposed to forking a legacy codebase or trying to adapt blockchains & bridges that haven’t been designed for that use case (true story).
On top of that, RedStone = working shoulder-to-shoulder with builders.
We collaborate hands-on with our Partners to come up with an optimal solution for their specific use case, customising many parameters such as:
data aggregation mechanisms,
data injection to the chain,
custom flows of liquidation/opening a position etc.
We are fully committed to building an entirely dedicated solution for Aave including risk mitigation mechanisms, i.e. lower liquidity in the early days of Polygon zkEVM.
Additionally, we plan to be in close contact and at disposal of Aave’s risk analysis partners.
Currently available RedStone models
Core model (On-Demand): data is dynamically injected into users’ transactions achieving maximum gas efficiency and maintaining great user experience as the whole process fits into a single transaction.
Classic model (Push): data is pushed into on-chain storage via decentralized and permissionless relayers. Dedicated to protocols designed for the traditional Oracles model + getting full control of the data source and update conditions (dApp contracts and relayer operators specify heartbeat & deviation threshold). No need to change the code logic vs Chainlink setup.
X model (No Front-running): targeting the needs of the most advanced DeFi protocols by eliminating the front-running risk through offsetting the delay between the user’s interaction and the Oracle price update
We believe the best solution for Aave would be RedStone Classic model, which offers full compatibility with Chainlink interface (hence ease of risk analysis @bgdlabs). If there’s interest, we’d be happy to facilitate the transition into the cost-optimal RedStone Core model in long term.
We are also keen to support Aave on other existing and upcoming L1s & L2s.To learn more about our models and positioning you can explore the below governance proposal on the Celo forum:
To sum up, we’re happy to work closely with @MarcZeller@bgdlabs or any entity contributing to Aave’s development on the oracle front and provide all the necessary data and input for them to make the most optimal decision. We’re open to joining governance calls where each Oracle can present and answer questions regarding implementation for Aave.
If we were to propose the next step in this discussion we would suggest that each oracle provider prepares a testnet POC for benchmarking purposes to gather data and see which oracle solution would be best suited for Aave’s specific needs.
End Note: Our sincere apologies for submitting this comment only now. A large part of the discussion took place over the Easter Holidays and there was no official timeframe or any submitting period defined, therefore we wanted to get involved once our team is back from family tables.
In my opinion none of the three points you gave are very strong, and instead show personal attachment to a solution based on legacy.
Aave hasn’t tried alternatives. yes chainlink has succeeded, but what makes it technically superior to alternatives? Saying chainlink has worked doesn’t mean anything without a comparison to alternatives.
I am not technical so I cant say for sure, but my thoughts here are that if BGD isnt willing to add this “extra piece” another group would be fine doing it. If adding an extra piece is a barrier to changing the aave protocol for the better then that is not good.
If there is an alternative, and it works well, and the DAO is ok with it it is weird not to except that alternative. It is backwards thinking to just go with chainlink cos it is a long term partner. the Dao should strive for greatness and there are so many obvious benefits to accepting chainlink alternatives
overall in my opinion there should be a temp check in the community to figure out if the dao is ok with chainlink alternatives. this comment section definitely implies many in the community are at least open to the idea
Chainlink are important infrastructure and key part of defi, but that doesnt mean aave cant have controlled experiments with other providers
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.
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.
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.
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.
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.
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.
Recognizing the importance of stablecoins to the DeFi ecosystem generally and Aave ecosystem in particular, Aave’s expansion onto Polygon zkEVM will be supported by immediate liquidity of $1M of stables
For sake of consistency, the ACI has collected the information in this thread into a format that matches the New Chain Deployment Template. Since the ARFC for this deployment has already passed snapshot, we will proceed to the AIP stage using the following proposal.
Title: [ARFC] Aave V3 Deployment on zkEVM L2
Author: Aave-Chan Initiative
Proposal for the deployment of Aave V3 on zkEVM L2, with key assets onboarding to establish a strategic Aave presence early in this new network while staying conservative in terms of risk.
This ARFC proposes the deployment of Aave V3 on the zkEVM L2 network, an EVM-equivalent zk-rollup developed by the Polygon team.
The deployment of Aave V3 on zkEVM L2 aims to establish a strategic presence on this new network early on, promoting L2 diversity and expanding Aave’s reach in the DeFi space.
Proof of Liquidity and Deposit Commitments:
Recognizing the importance of stablecoins to the DeFi ecosystem generally and Aave ecosystem in particular, Aave’s expansion onto Polygon zkEVM will be supported by immediate liquidity of $1M of stables provided by Polygon Foundation and partners.
The proposal outlines the deployment of Aave V3 on zkEVM L2. Risk parameters are provided for community discussion and feedback from risk service providers.
After feedback from risk managers, we propose the following initial parameters.
Gauntlet and ChaosLabs recommend delaying all asset listings until there’s increased liquidity in LSTs and the new bridged USDC in Polygon zkEVM.
We still provide recommendations for WETH, USDC, and WMATIC should the community choose to list these assets. Due to minimal wstETH liquidity, we do not recommend listing wstETH. Consequently, the eMode category for WETH is now set to N/A. The borrow caps and IR curves for WETH and WMATIC are set anticipating the eventual listing and eMode activation of LSTs for these tokens. This approach aims to maintain IR curve consistency across markets. However, without the relevant LSTs listed, these assets will likely have minimal borrowing demand.
For these reasons and the minimal liquidity in the new USDC, we suggest delaying asset listings until there’s increased liquidity in LSTs and new USDC.
Borrowable in Isolation
Loan To Value
Liquidation Protocol Fee
We recommend the ETH eMode pools start with the same parameters as Ethereum mainnet, Polygon PoS, Optimism, and Gnosis: 93% LT, 90% LTV, and 1% LB.