Feb 8, 2024
Useful Links
Website: redstone.finance | Warp (Arweave SDK)
Documentation: RedStone Docs | API Docs | GitHub
Contracts: EVM Connector
Dashboards: Dune Dashboard
Introduction
RedStone is an Oracle provider that offers a multitude of data feeds that are available to DeFi protocols across over 30 chains. It currently supports over 1000 assets and aggregates a wide range of data sources, including CEXs, DEXs, and broad market aggregators. The alpha version of the product launched in January 2022 to improve inefficiencies in existing oracles, addressing affordable storage, on-demand fetching, and flexible data streams that give custom support for underserved areas of DeFi.
RedStone has emphasized supporting Liquid Staking Derivative (LSD) assets with price feed data, allowing them to gain adoption through DeFi integrations. Their LSTfi Report makes a note of the $22.4B market for LSDs, the largest DeFi category by TVL. In 2023, RedStone created price feeds for a number of early-stage LSD protocols, including Swell swETH, Stader ETHx, Stakewise osETH, and EtherFi eETH. This has led to integrations with DeFi protocols such as Sommelier and Gravita.
This review evaluates RedStone's architecture and performance as an Oracle provider. We aim to deliver a comprehensive and objective assessment of its suitability to secure user value for the critical application of liquidations processing in DeFi lending markets. Specifically, we aim to form a recommendation about if and how RedStone can be integrated with Prisma to onboard additional collateral types.
Section 1: Oracle System Design Overview
This section provides an overview of RedStone's design and the motivation for those design decisions. It highlights how this provider differs from other Oracle networks and provides an overview of the system components and the data flow process. Finally, it expands on the product offerings relevant to prospective DeFi integrators.
1.1 Design Goals
1.2 Infrastructure Components
1.3 Data Flow Process
1.4 Integration Options
1.1 Design Goals
RedStone aims to improve a range of inefficiencies and constraints of existing Oracle architectures. The main issues that RedStone attempts to address are:
Affordable Storage: Historical data is stored on the Arweave data storage chain, which is designed to store large amounts of data at low cost.
On-Demand Fetching: Instead of the Oracle nodes regularly pushing data on-chain, it is broadcasted to the Streamr network and/or open source gateways that sign the data, allowing any relayer to push data on-chain.
Flexible Data Streams: A modular design allows applications consuming data to customize data delivery to fit their needs.
In response to these challenges, RedStone built their oracle solution with modular design to allow greater autonomy and simple Integration. RedStone aims to improve user autonomy and data transmission efficiency, avoiding the need for data providers to continuous post data on-chain.
1.2 Infrastructure Components
The protocol can be dissected into multiple components. The Redstone Oracle system components include:
Data Sources
Redstone data sources include CEXs (e.g., Binance, Coinbase), DEXs (e.g., Uniswap, Curve), and broad market aggregators (e.g., Coingecko, Kaiko). Over 50 data sources are integrated with specific data sources curated to suit individual price feeds.
Redstone Oracle nodes
A set of Oracle nodes perform off-chain data source aggregation, data processing, and signing to a Distributed Data Layer (DDL). Aggregation methodology is configurable, e.g., by median of values, volume-weighted average price (VWAP), or liquidity-weighted average price (LWAP), although RedStone passes the median value by default. The Oracle nodes can theoretically be independent operators, although currently on mainnet, RedStone operates all 5 Oracle Nodes.
Data-Cache Layer
This data availability layer ensures that signed data is packed as meta-transactions without requiring regular price updates to be pushed on-chain. This is handled through an integration with Streamr Network and Gateways that are currently operated by the RedStone team but can theoretically be spun up permissionlessly via the open source cache-service.
Data Storage
Because the data cache layer stores data for a short time, a decentralized storage provider is needed to preserve archived data. Arweave is a blockchain specialized in data storage. Historical price feed data is archived to ensure data provider accountability.
Relayers
Relayers push data on-chain under predefined conditions, such as by a heartbeat or price deviation threshold. The relayer can be configurable per price feed, although on mainnet, RedStone operates whitelisted relayers.
The overall architecture is shown below:
Source: RedStone Docs
1.3 Data Flow Process
RedStone supports over 1000 price feeds from over 50 data providers (CEXs, DEXs, Oracles, and Market Data Aggregators).
A set of Oracle nodes query multiple API/RPCs and aggregate data using various methodologies like median, TWAP, LWAP, VWAP, etc., and perform security checks with outlier detection.
Processed data is then signed by node operators and delivered to the Data Distribution Layer (DDL). Signed data is passed to the decentralized Streamr network and Redstone light cache nodes packed in a message containing various metadata such as timestamp, number of signers, and value per signer.
At the time of broadcasting, data feeds represent live data, but with each new broadcast, previous data is archived on Arweave, a permanent storage network.
Live and historical data can be pushed on-chain from the DDL by a dedicated Relayer with a predefined set of conditions (e.g., update frequency, price deviation). This is currently managed by the RedStone team on mainnet, although it is configurable per price feed and can theoretically be managed by liquidation bots or end users.
When an application requires the updated value, the RedStone smart contract extracts the signed data with a timestamp, verifies it, and passes it to the target contract.
1.4 Integration Options
Per the diagram below, data cached in the DDL can be delivered on-chain using one of three models, depending on the user's needs. The three models are called Classic, Core, and X.
Source: Redstone Docs- Architecture
Core Oracle Model (Pull)
The Core Oracle Model also called the "on-demand fetching model," involves automatically injecting data into user transactions to improve gas efficiency and UX. This model is the most mature method to consume RedStone data that currently secures the most value, according to the RedStone docs.
Classic Oracle Model (Push)
The Redstone Classic model uses a more traditional Oracle design where data is regularly pushed on-chain based on predefined conditions. This may be suitable for protocols that: 1) Don't need to be updated frequently 2) Do not want to modify the codebase, which is required for Core model functionality 3) Run on a chain with low gas fees
RedStone Classic is built on top of the Redstone Core model and consists of two main parts: the off-chain relayer and on-chain smart contracts.
Relayer
The off-chain Relayer is responsible for pushing data on-chain in a customized way using environment variables. The Relayers can theoretically be operated permissionlessly because data is validated on-chain using conditions defined by the protocol stakeholders. In practice, the RedStone team currently manages whitelisted Relayer addresses on mainnet.
The layers are designed to work in parallel to avoid a single point of failure. There are two Relayer trigger conditions: a time condition (UPDATE_PRICE_INTERVAL) and a value-deviation condition (MIN_DEVIATION_PERCENTAGE). The Relayer update conditions can be found in the Redstone GitHub.
PriceFeedsAdapter Contract
The on-chain Relayer stores prices that go through a familiar interface like the Chainlink Aggregator). The on-chain relayer is based on RedstoneAdapterBase.sol contract, used to push RedStone data to blockchain storage repeatedly. Some of the contract's main features are:
Values for data feeds can be updated using the
updateDataFeedsValuesfunction.All data feeds must be updated within a single call; partial updates are not allowed (batch updating).
The minimum interval between updates is configurable.
If the protocol wants to be fully compatible with Chainlink Price Feed, additional PriceFeed contracts need to be deployed.
The scheme below shows the data flow for the implementation of the RedStone Classic (Push) Oracle system:
Source: Redstone Finance documentation - Classic Model
RedStone X
This model was popularised by perpetual protocols such as GMX to prevent front-running. The user initiates a transaction before knowing the price, mitigating attempts to arbitrage the Oracle. The cost can then be pushed as soon as the next block is undertaken by anyone acting as the Resolver. While the Resolver role is permissionless, RedStone's integration requires a Keeper service that receives requests when the NewOracleDataRequest event is triggered, which relays signed data from the Data Distribution Layer.
Source: RedStone Documentation - RedstoneX Oracle model
Section 2: Decentralization and Security
This section will dissect the components of the oracle provider's architecture to elucidate any trust assumptions and/or security considerations. The sub-sections start with the data source and progress through each component in the system. The section concludes with an overview of security audits.
2.1 Data Sources
2.2 Oracle Nodes
2.3 Data-Cache Layer
2.4. Permanent Storage
2.5 EVM Connectors
2.6 On-chain Relayer
2.7 Smart Contract Audits
2.1 Data Sources
RedStone collects information from both on-chain and off-chain sources via API and RPC queries. That includes DEXs (Curve pools, Uniswap pools, Balancer pools, etc.), CEXs (Binance, Bitget, Coinbase, OKX, Kraken, etc.), Oracle providers (Chainlink, Band protocol, DIA), Social Graph (Lens) and aggregators (CoinmarketCap, Coingecko, Kaiko. etc.). RedStone has integrated 162 data sources at the time of writing.
All available data sources are displayed on the RedStone dashboard with reliability metrics like "Incorrect Price," "Fetching Failed," "Success Rate," and "Stability Reports":
Source: Redstone App - sources
For example, a report about the Binance data source shows dates and call counts of failed and incorrect data:
Source: Redstone-app - Binance report
2.2 Oracle Nodes
The RedStone nodes play a crucial role in the protocol. RedStone nodes operate based on predefined configurations set by the RedStone team or as independent Oracle nodes with higher customization levels regarding data sources and types. Nodes perform the following tasks:
Data Fetching: Multiple Oracle nodes fetch data from various external APIs.
Data Processing and Aggregation: The data is aggregated (typically using a median aggregator) and attested with a cryptographic signature after fetching.
Transmission to DDL: The signed data is then sent to the Distributed Data Layer (DDL), making it available to end users.
Users should be aware that although the docs assist anyone in spinning up their own RedStone node from source code, the only nodes currently securing the network are operated by the RedStone team. RedStone is taking steps to onboard Data Providers in the coming months, reviewing a shortlist of ~15 node operators. Eventually, a crypto-economic security model will involve a native token with staking/slashing, although this upgrade has no clear timeline.
Data providers can be checked in the RedStone web app under "Data services." This shows what assets are supported (the total number of assets), accessible data sources for a specific asset, the number of nodes, and the time interval between updates.
Source: Redstone WebApp
Off-Chain Aggregation
Off-chain data aggregation is an initial aggregation performed by independent node providers. These nodes first collect data from data providers and then aggregate collected data using methodologies like median, Time-Weighted Average Price (TWAP), Last Weighted Average Price (LWAP), or any other custom calculation (i.e., using slippage instead of volume for wstETH price feed). After aggregation and processing, the node operators sign the data, underwriting its quality and integrity.
The methodology of the off-chain aggregation employed by the Data Provider is significant to the reliability of the data feed. While the methodology is configurable per data feed, RedStone has a preference to use the median of aggregated quotes, which it uses as the base for its LSD price feeds. The team considers this a conservative approach that favors manipulation resistance (by discarding outliers), over price accuracy, which while attainable from more sophisticated weighting strategies (e.g. VWAP), may become vulnerable to manipulation in some cases.
See below an example of RedStone Oracles collecting data from 6 sources and producing a medianized price at each timestamp.
Source: RedStone Blog - Data Aggregation
The median strategy requires monitoring to ensure the viability of each data source involved in the aggregation. It may become necessary to exclude or introduce data sources as volumes and liquidity shift, especially with emerging assets, which are a focus for RedStone. For this, RedStone conducts internal real-time monitoring of DEX data sources to check if slippage exceeds safe levels. If triggered, the affected data source will be automatically disconnected from the aggregation until liquidity increases. They are also able to medianize data across multiple blocks to increase the economic costs of price manipulation by extending the window where the price could be arbitraged.
The Redstone Oracle node's operational parameters are defined by a Manifest, which includes data sources, update intervals, and validation checks, ensuring accurate and timely data delivery to blockchain networks. The Manifest is a public JSON file defining the provider's obligation regarding the data they provide. In the official RedStone GitHub, it is possible to check various types of Manifests and providers. Data Service Manifests like main.json and primary.json (rapid.json) are essential for providing aggregated price data from multiple sources and crucial for oracle reliability and accuracy.
2.3 Data-Cache Layer
The Data-Cache Layer has two broadcasting channels: Streamr Network and custom Gateway network(s). Currently, only the RedStone team has implemented direct Gateways. However, the Gateway is open source, and over time, there are intended to be more diverse broadcasting channels operated by independent operators.
The Streamr Network is a decentralized platform designed explicitly for real-time data exchange. It operates as a peer-to-peer network, allowing direct data transmission from producers to consumers without central authority involvement.
Source: DeveloperDAO blog
RedStone nodes include a price requester module that fetches signed data from the Streamr Network. This data is then attached to meta-transactions before being submitted on-chain. When a transaction is executed on-chain, it can access the linked data. This process eliminates the need to regularly push data to the blockchain, making it more efficient and cost-effective.
Initially, Streamr Nodes were used by RedStone as an additional data broadcasting channel to ensure liveness of the data-cache layer. It does come with trade-offs, namely that a distributed network like Streamr takes longer to propogate than RedStone operated Gateways. Therefore, it is used as a backup, in case RedStone's own Gateways have failed for any reason.
The data-cache layer packs the transaction with signed data from various Oracle nodes. The package can be fetched through direct injection of a user transaction (Core model) or by a Relayer (Classic model) and unpacked on-chain. The data-cache layer packs the transaction with the following format:
Source: RedStone Docs
2.4 Permanent Storage
RedStone uses a permanent storage solution as part of its Data Distribution Layer to preserve all historical data and help ensure accountability of the Data Providers. While primarily used for storage, it can also be useful in certain applications that require historical data.
Arweave is a blockchain that offers scalable and performant solutions for immutable and permanent data storage. The core of this functionality is SmartWeave, an Arweave native smart contracts SDK. SmartWeave facilitates the creation of smart contracts on Arweave, allowing for the development of decentralized applications that require immutable data storage. It enables transactions to include an initial state and associated business logic, which defines the rules for updating the state. Subsequent transactions can then reference this initial transaction, proposing new state updates based on the current state and the predefined rules.
The approach of SmartWeave leverages lazy evaluation, where the execution of contract logic is deferred until the data is requested. This method shifts the computational load from the network to the clients or users of the smart contracts, enabling more efficient use of network resources. However, this approach often necessitates a centralized caching layer to ensure efficient access to the contract's current state while preserving the decentralized, immutable nature of the data stored on Arweave.
Warp Contracts is an implementation of the SmartWeave smart contracts protocol, designed to enhance the functionality and efficiency of smart contracts on Arweave. By optimizing the execution and state management of SmartWeave contracts, Warp Contracts aims to reduce the reliance on centralized caching mechanisms, thereby decentralizing the computational load and improving the scalability of applications built on Arweave.
2.5 EVM Connectors
The Redstone team's EVM-Connector module implements an alternative design for providing data to smart contracts. Instead of constantly pushing Oracle data on-chain (in EVM storage), information is brought on-chain only when needed—"on-demand fetching." Between "on-demand fetching" events, data is available in the protocol Data-Cache Layer (also called Flash Storage). Transferring data on-chain requires packing an extra payload off-chain to a user's transaction and processing the message on-chain. The process is described in the scheme below:
Source: Redstone Github
Data packing (off-chain data encoding) - all three steps are executed automatically and transparently by the ContractWrapper:
Streamr network and RedStone cache layer (as a backup source) fetch relevant data from Oracle nodes
Data is packed into a message according to the specified structure
The package is appended to the original transaction message, signed, and submitted to the network
Data unpacking (on-chain data verification) - all four steps below are executed on-chain by using a low-level assembly code (significant gas cost reduction):
The appended data package is extracted from the msg.data
The data signature is verified by checking if the signer is one of the approved providers
The timestamp is also verified, checking if the information is not obsolete
The value that matches a given symbol is extracted from the data package
On-chain aggregation and verification occur when this data is brought onto the blockchain, ensuring its validity and preparing it for use by smart contracts and end-users. This mechanism also requires signing a threshold signature from authorized data providers for a given data feed.
Source: RedstoneConsumerBase.sol - Github
2.6 On-chain Relayer
In the Classic Model, a crucial part of the data delivery is pushing the prices on-chain. According to the RedStone team, they have 4 cascading fallback layers to ensure the continuity of service:
Main Relayers (using multiple redundant RPCs and monitoring current gas level),
Fallback Relayers (similar nodes in a different geo-location),
Gelato automation (using Gelato infrastructure),
Manual Relayers (leveraging the fact that anyone can trustlessly bring signed data packages on chain).
In theory, the Relayers service can operate permissionlessly to validate the on-chain requirements set by the protocol stakeholders. In practice, the RedStone team whitelists trusted addresses to perform this function. Additionally, Relayers are designed to function in parallel, and it is advisable to run multiple independent instances to reduce the risks associated with single points of failure and censorship.
The Relayer service works in a customizable way based on environment variables from the table below:
Source: Redstone documentation - env variables
Relayer Operation
The Relayer is initially set up with installed dependencies, compiled and deployed contracts, and in place has an env variable configuration.
The Relayer fetches data packages from the Data Distribution Layer. Scripts like fetch-data-packages.ts manage this, ensuring data is up-to-date and relevant.
The Relayer performs an update condition and checks before updating on-chain prices. The Relayer checks two conditions: Time-Based Checks (time-condition.ts) and Value Deviation Checks (check-value-deviation-condition.ts and value-deviation-condition.ts)
The TxDeliveryManSingleton.ts script manages the delivery of transactions to the blockchain, ensuring efficient use of resources and gas optimization.
The Relayer operates continuously, as is evident from scripts like run-relayer.ts, which manages iterative operations to keep the on-chain data up-to-date.
The image below is an example of the Manifest for Ethereum ETHx/ETH Relayer, showing the updatetriggers conditions:
Source: Github - Relayer Manifests
2.7 Smart Contract Audits
ABDK Cons - 22nd, November 2022
Auditor found 3 major, ten moderate, and 28 minor issues
Auditor found 2 critical, one major, one moderate and 15 minor issues
Auditor found three medium, three low and seven quality assurance issues (no high issues)
ABDK Consulting - 16st, June 2023
Auditor found two major, six moderate and 18 minor issues
Section 3: Adoption
This section will review the level of DeFi adoption achieved by RedStone to date, with particular focus on its support for liquid staking derivatives. The section is divided into 3 sub-sections that review the unique LSD price feeds available, adoption of RedStone compared with other Oracle providers, and specific DeFi integrations.
3.1: LSD Price Feed Support
3.2 Oracles Comparison
3.3 DeFi Integrations
3.1: LSD Price Feed Support
Below is an overview of the ETH Liquid Staking Derivatives with a RedStone Oracle price feed. For a complete list of the RedStone data feeds, see the Price Feed docs.
Swell swETH
Manifest: swell.json
The swETH feed ingests data from the following sources:
Balancer: SwETH/Boosted Aave V3 WETH (0x02d928e68d8f10c0358566152677db51e1e2dc8c)
Uniswap V3: UniV3 ETH/swETH pool (0x30ea22c879628514f1494d4bbfef79d21a6b49a2)
Maverick: Maverick ETH-swETH pool (0x0ce176e1b11a8f88a4ba2535de80e81f88592bad)
RedStone implemented a liquidity monitoring service to rearrange pools in case of liquidity migration.
StakeWise osETH
Manifest: ethereumStakewiseOsetheth.json
The osETH feed ingests data from the following sources:
Balancer: osETH-WETH
Uniswap V3: osETH-USDC
Curve: osETH-rETH
RedStone implemented a liquidity monitoring service to rearrange pools in case of liquidity migration.
Stader ETHx
Manifest: ethereumEthxeth.json
The osETH feed ingests data from the following sources:
Balancer
Curve Finance
PancakeSwap
Wombat Exchange
Etherfi weETH
Manifest: ethereumEtherfiWeeth.json and ethereumEtherfiWeetheth.json
The osETH feed ingests data from the following sources:
Balancer
Curve Finance
Maverick
3.2 Oracles Comparison
According to data from DefiLlama in late January, RedStone is a minor player in the price feed oracle market, ranking 13 in terms of Total Value Secured (TVS). The TVS calculation includes the value of tokens borrowed in lending applications.
While DeFiLlama conveniently displays data about oracle provider usage in DeFi, it should be noted that it does not present a complete picture of all RedStone integrations, as DeFiLlama requires an oracle provider to secure 50% of the protocol TVL to be listed as an integration. In reality, the majority of the protocols have their TVL accumulated in one or two markets i.e. ETH or stETH. For example, in Gravita, RedStone feeds are used for weETH, swETH, osETH, ETHx (~36% of the market) and Chainlink feeds for WETH, wstETH, and rETH, although the full TVL is assigned only to Chainlink.
Source: DefiLlama Oracles | Date: 1/26/2024
Compared with the most prominent Oracle providers, RedStone appears to have been a historically minor market participant with a shorter history of securing value. The industry leader, Chainlink, has a history of securing value in DeFi since May 2019, while RedStone began securing value in January 2023.
Source: DefiLlama Oracles | Date: 1/26/2024
3.3 DeFi Integrations
This section will first review the DeFi integrations shown on DeFiLlama, which require RedStone to secure >50% of the protocol TVL to be listed. Afterwards we will cover additional protocol integrations where RedStone secures some assets making up a minority of protocol TVL. Finally, we will make mention of upcoming integrations.
DeFiLlama Oracle Dashboard
Upon review of DefiLlama data, which shares the integrations in which RedStone dominates, RedStone provides price feed data to 14 protocols. The Total Value Secured (TVS) by RedStone services is ~$102.5 million as of mid-January 2024.
When looking at a breakdown of the protocols using RedStone, we observe that a number of the protocols are deprecated for a variety of reasons or otherwise have negligible TVL. Four of the 14 protocols are active with a TVL that is reasonably substantial (>$10m).
Source: DefiLlama Oracles
CIAN
Integration Announcement - July 12, 2023
CIAN is an automation platform that can be used to create delta-neutral strategies, with particular emphasis on LSDs, liquid restaking tokens, and Real-World assets. Strategies involve leveraged exposure to yield-bearing assets with built-in liquidation protection. It has deployed on Ethereum, Avalanche, Polygon, Optimism, Arbitrum, and BSC.
CIAN integrated RedStone price feeds to monitor user collateral ratios and provide liquidation protection. RedStone's Core Model was chosen as a low-latency and efficient solution since gas fees are only charged when data is needed.
Angle
Integration Announcement - August 10, 2023
Angle is an over-collateralized stablecoin protocol with a unique strategy of rehypothecating stablecoin collateral into various third-party applications to improve capital efficiency. The protocol experienced a crisis in March 2023 when the Euler lending protocol, containing many Angle protocol funds, was hacked. A migration to Angle V2 occurred several months later, in August 2023.
Angle integrated a RedStone price feed for a short-term Euro treasury bond tokenized by Backed (bC3M) which allows users, through the transmuter module, to mint and burn its native stablecoin agEUR from bC3M at the oracle price. As of January 26, bC3M makes up €8m in collateral with €6.236m agEUR minted against it (26.8% of the 23.25m outstanding agEUR). There is a second oracle managed by Backed which is required to be within reasonable bounds of the Redstone price. Otherwise, transactions will revert.
Source: Angle Analytics
DeltaPrime
Integration Announcement 1 - November 29, 2022
Integration Announcement 2 - June 19, 2023
DeltaPrime is a lending protocol that allows up to 5x leverage by creating personal brokerage smart contract accounts. The protocol is native to Avalanche and has also been deployed on Arbitrum. It offers various collateral types, including crypto blue-chips, stablecoins, staking derivatives, and governance tokens.
DeltaPrime integrated RedStone price feeds as its exclusive oracle provider because it was the only provider allowing feeds for derivative tokens and offered a low-latency solution. It combined the Core Model to process liquidations, which only pushes data on-chain when needed. The Integration involves support for ~40 tokens with a 10s latency guarantee.
Yield Yak
Integration Announcement - May 12, 2023
Yield Yak is a yield aggregator that accepts a deposit token that it deploys to various yield-earning strategies. The protocol is native to Avalanche and has also been deployed on Arbitrum.
The Integration with Yield Yak is through DeltaPrime to allow leverage on autocompounding Yield Yak deposits. Users can gain access to leverage through the DeltaPrime leverage farms, including the AVAX strategy on AAVE, GLP strategy on GMX, AVAX-USDC on Pangolin, AVAX-ETH from Pangolin, AVAX-USDC from TraderJoe, or AVAX-ETH from TraderJoe. RedStone calculates the collateral ratio of the leveraged farm position and processes liquidation when necessary.
Conclusion
Most of the primary RedStone integrations involve leveraged yield and trading strategies, emphasizing Avalanche-based applications. In some cases, RedStone is employed as a liquidation protection mechanism (CIAN), and in others, it is used to process timely liquidation (DeltaPrime/Yield Yak). One protocol uses RedStone to mint and redeem a stablecoin (Angle) as one of several Oracle providers used within the protocol. Angle is also the most notable protocol that uses RedStone price data on the Ethereum mainnet.
Additional RedStone Integrations
The following list includes minor integrations that are not credited in DeFiLlama's curated oracle integrations list because RedStone does not secure >50% of the protocol TVL. Many of the integrations revolve around RedStone's support for emerging LSD assets, other assets that have limited price feeds available, and combined with other oracle providers for improved resiliency.
Sommelier utilizes RedStone’s weETH, ETHx, and swETH feeds for in its yield strategies.
Enzyme utilizes RedStone's swETH and ETHx feeds for its yield strategies.
Gravita utilizes RedStone's swETH, weETH, and osETH feeds to secure collateral for its GRAI stablecoin.
Mento uses RedStone as the main Oracle in the SortedOracles module.
Silo utilizes RedStone's weETH feed for the weETH, ETH, XAI Market to secure collateral and will soon use the agEUR feed on Arbitrum.
Term Finance utilizes RedStone's weETH feed to secure it as collateral on its lending platform.
Gearbox uses a multitude of RedStone pricefeeds in addition to other oracle providers to secure collateral assets.
Venus incorporates RedStone feeds in its "Resilient Price Oracle" design that uses Chainlink, RedStone, Pyth, TWAP, and Binance Oracle in a series of fallback mechanisms for securing collateral.
Abracadabra uses RedStone feeds in its Kava markets (MIM/USDT Curve LP and Tether USDT-LP cauldrons) to secure collateral.
A Morpho Blue vault launched by Re7 uses RedStone's LST feeds to secure the underlying collateral assets.
Upcoming RedStone Integrations
The RedStone team has shared information about upcoming integrations, planned as of February 1, 2024.
LayerBank- In the first week of February they plan to switch from their own Oracles to RedStone as the only Oracle provider.
ZeroLend- In the first week of February they plan to switch to RedStone as the only Oracle provider on Manta.
Shoebill- In the first week of February they plan to switch to RedStone as the only Oracle provider on Manta.
Radiant- They will use RedStone feeds for LSTs and other assets in their upcoming v3 launch.
Fluid (by Instadapp)- A new lending primitive by Instadapp similar to Morpho Blue. They’ll launch open access in February that plans to utilize RedStone feeds.
Pendle- They plan to launch the wstETH market on Mantle L2 with the RedStone feed and evaluate an expanded cooperation.
Spark- They’re working 10 add RedStone to their oracles interface in Q1.
Synthetix- They’re finanlizing addition of RedStone to their ERC-7412 Oracle module, which should be ready in February.
Seamless- They’ll use RedStone for the upcoming markets i.e. tBTC.
Curvance (pre-launch)- They’ll use RedStone in the Oracle module.
Conic V2- The team intends to use RedStone in their upcoming V2 release.
eBTC (pre-launch, by BadgerDAO)- They’ll use RedStone’s stETH feed in addition to Chainlink’s.
Liquity- They shortlisted RedStone together with Chainlink for their multi-oracle V2 setup.
Lybra- RedStone’s ETHx price feed passed Halborn’s audit, currently in discussion of integration.
Section 4: Regulatory Compliance and Transparency
This section reviews any relevant regulatory considerations regarding Oracle services generally and contractual obligations specifically offered by RedStone. Finally, it reviews plans for an arbitration process that aims to ensure data integrity and user assurances.
4.1 International Policy Recommendations
4.2 Contractual Obligations
4.3 On-chain Arbitration
4.1 International Policy Recommendations
Financial Stability Board
In their seminal research paper, "The Financial Stability Risks of Decentralised Finance," the Financial Stability Board (FSB) sheds light on the pivotal role of oracles in the DeFi ecosystem. According to the FSB, an oracle is "a service that enables smart contracts to access, in real-time, relevant external or off-chain data using queries typically through crypto-asset exchange application programming interfaces and which provides inputs to smart contracts". The oracles' fundamental role in DeFi is recognized by reference to their function, i.e., smart contracts to access external ("off-chain"), real-world data.
While oracles are indispensable, they also introduce a layer of risk, referred to in the paper as "oracle risk." This risk arises when an oracle fails to function as expected or is compromised. The implications of such failures can be far-reaching. For instance, erroneous data inputs from an oracle can trigger adverse actions in a DeFi protocol, like unwarranted liquidations, leading to cascading effects across interconnected protocols.
In the next place, oracles are seen as market manipulation targets. This vulnerability is particularly acute when a dominant protocol heavily relies on a single oracle or when multiple protocols depend on the same oracle source. An oracle's failure or manipulation could catalyze a systemic shock within the DeFi ecosystem in such scenarios.
Although the FSB's analysis acknowledges oracle risk, it stops short of proposing specific regulations for oracle activities.
International Organization of Securities Commissions
Another international standard-setting body, the International Organization of Securities Commissions (IOSCO), wields significant influence over policy recommendations in the DeFi sector. IOSCO has provided guidelines suggesting that national regulators thoroughly assess the operational and technological risks associated with DeFi products and services. One of the key recommendations is that regulators should require the Responsible Person(s) of DeFi products that rely on oracles to actively identify, manage, and mitigate the risks posed by such technologies. In some regions, regulators may opt for more stringent measures, including stricter oversight and compliance requirements for DeFi entities using oracles.
Interestingly, while IOSCO emphasizes the need to identify and address material risks, including those associated with oracles, it does not explicitly mandate introducing a regulatory regime specifically for oracles. This suggests a measured approach, focusing on understanding and managing the risks rather than imposing prescriptive regulatory frameworks.
MiCA
Recital 93 of MiCA offers a crucial distinction between Crypto-Asset Service Providers (CASPs) engaged in transfer services as a regulated activity and other entities like validators, nodes, or miners involved in confirming transactions and updating the state of the underlying distributed ledger.
Oracles are primarily recognized as suppliers of external data, such as asset prices, and do not participate in confirming transactions on the blockchain. Their role does not extend to updating the blockchain state; instead, they are commissioned to deliver specific external information. In essence, oracles act as third-party services enabling smart contracts to access necessary data, whether on-chain or off-chain, which then becomes an input for the smart contract's functionality ("Systemic Implications and Policy Options by ESRB Task Force").
MiCA exempts parties with core technical functions, such as nodes and validators, from its regulatory scope. The exemption provides a basis to assert that oracles, given their clearly defined role as external data suppliers, do not fall within the ambit of MiCA regulation. This interpretation aligns with MiCA's focus on regulating activities more directly involved in asset transfer and management rather than entities that provide ancillary services to the DeFi ecosystem.
4.2 Contractual Obligations
A) Client Relations
By entering into a Services Agreement with clients, RedStone commits to integrating various Oracle systems and establishing a contractual framework defining the scope and quality of the services provided.
RedStone is contractually obligated to perform its services with great diligence and professionalism. The Agreement grants RedStone the right to engage third parties or contractors to assist in providing services. A pivotal aspect of RedStone's contractual obligations is the assurance of a specified Service Level Agreement. SLA defines the expected performance performance and reliability levels of the Oracle feeds or services provided.
B) Business Relations
When onboarding Data Providers, RedStone considers only those entities with whom they have maintained a relationship for at least six months. Providers with narrow specialization in data delivery, aligning with their commitment to quality and reliability, are prioritized. These Data Providers must deliver price feeds per the terms of the contract concluded between the RedStone Association (domiciled in Switzerland) and their respective entity(ies). In return for their services, Data Providers receive RedStone tokens, which are accounted for and distributed monthly, contingent upon adherence to the contract's stipulations.
The primary responsibility of Data Providers is to deploy and consistently maintain Data Provision nodes. They retain the right to terminate the service provision. However, this decision must be communicated with at least a two-month notice period, providing sufficient time for RedStone to make necessary adjustments. If Data Providers fail to deliver the agreed-upon service, they are obligated to reimburse the affected party. The compensation is calculated based on the extent of the damage incurred due to the service lapse.
It is important to note that the summary of the rights and obligations of Data Providers is based on specific details provided by RedStone. Due to confidentiality reasons, the actual contract has not been reviewed in this context.
4.3 On-chain Arbitration
RedStone's roadmap involves plans to address the need to resolve disputes related to data accuracy through a novel approach: on-chain arbitration on ARgue. This decentralized dispute resolution protocol will allow users to claim refunds in the event of the submission of faulty data, with disputes being adjudicated by decentralized juries.
The dispute process within ARgue is multi-staged, involving several vital actors and a systematic approach.
Source: ARgue Architecture
Pre-Dispute Phase: Data providers post collateral as RedStone tokens to signal their commitment to data quality. The collateral amount affects the dispute opening fee and the potential reward for challengers.
Opening a Dispute: Any party can initiate a dispute by depositing a stake proportional to the provider's collateral, with a minimum value to deter spam.
Voting Process: Jurors stake tokens to vote for or against the dispute within a limited period, influenced by their voting capacity.
Verdict and Appeal: A verdict is reached when a quorum is met. Parties dissatisfied with the verdict can appeal by doubling the challenge fee, leading to a new voting round with a higher quorum requirement.
Settlement: The final verdict triggers the distribution of rewards, funded by the losing side's stake. Jurors voting with the majority gain a portion of the opposing side's stake and enhance their voting capacity.
RedStone plans to implement a random-based selection process for jurors to ensure fairness and prevent front-running in high-stake disputes.
No on-chain arbitration has been conducted, primarily because the RedStone token is not yet live. The final version of the arbitration protocol will undergo thorough consultation and auditing before deployment. Therefore, the implementation details may be subject to change.
Recommendation
After reviewing the RedStone protocol design, implementation, development roadmap, historical adoption, and user assurances, we propose a solution involving a compromise that limits the risk to the mkUSD peg while enabling growth potential by onboarding newly emerging LSD protocols. We recommend exercising caution in onboarding additional oracle providers directly to Prisma and to take a multi-step approach that begins by creating markets on third-party lending protocols that leverage RedStone price feeds. After a period of time monitoring Oracle performance, data can be used for evaluating RedStone and potentially onboard it as an Oracle provider directly to Prisma.
We have been in talks with Morpho Blue to create a lending market aggregator for Prisma that pairs long-tail ETH LSDs against mkUSD, based entirely on RedStone price feeds. These LSD assets likely do not qualify for onboarding to Prisma directly because of, for example, their short history and lower liquidity. They may, however, benefit from inclusion in a lending market that supports their adoption, which also provides a pathway for well-performing assets to eventually be onboarded directly to Prisma.
RedStone already has price feeds available for these emerging assets and has signaled a priority to emphasize support for the LSD market. Example pairings below:
Support for these assets involves greater risk and diligence to prevent market manipulation, given that they generally have considerably lower liquidity and limited trading venues than mainstream competitors. Third-party lending platforms such as Morpho may be better equipped to manage market demand for additional risk with a dynamic interest rate model.
This solution also allows Prisma to observe the performance of RedStone over time and revisit the possibility of onboarding RedStone directly to Prisma in the future. There are essential upgrades in development, including a crypto-economic arbitration model involving a native RedStone token and the onboarding of independent node operators. RedStone is designed modularly with a pathway to become a genuinely decentralized oracle provider, although developments should be monitored as RedStone secures Prisma's third-party lending markets. Building a substantial history connecting value for Prisma and observing TVLs grow over time will be essential in establishing trust that RedStone can be onboarded as an oracle provider directly for Prisma vaults.