Hello everyone, hi @MarcZeller,
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:
Conclusion
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.