Introduction

The decentralized finance (DeFi) space has grown rapidly in recent years, with new protocols and products being launched all the time. From 2020 to today, the DeFi Total Value Locked (TVL) increased from $600 million to $177 billion. This growth has been driven by several factors, including the increasing number of new chains entering the market, and the growing level of innovation in use cases. 

Oracles are a fundamental building block of DeFi dApps, as they connect on-chain smart contracts with external data that lives off-chain. In other words, oracles give smart contracts, which are fundamentally restricted to accessing on-chain data, answers to questions about both the on-chain and off-chainworlds. They enable smart contracts to utilize real-world data and make decisions based on the latest external information when they are executed. In most cases, without an oracle supplying information, there would be no way for a smart contract to be able to know the things it needs to know in order to do its job. This data provided by oracles encompasses a wide range of information, from stock and asset prices to weather forecasts, provable randomness, cross-chain details, etc. 

Since an oracle determines what a smart contract sees (i.e. it controls the inputs to the smart contract) it also holds the power to control what the smart contract does in response to these inputs. This means that oracles possess an enormous amount of power when it comes to smart contracts. If the oracle is compromised, so is the entire dApp, as the smart contract might still work as expected but with a malicious or faulty input that was not expected. Therefore, there are many challenges and trade-offs to be considered in developing effective and trustworthy oracles such as scalability, incentivisation, and decentralization, which forms the so-called “Oracle Problem”.

Different oracle projects were built over the years to manage effectively the Oracle Problem; however, most of them still come with some disadvantages that are reflected on the end users, such as: limits to the ability to tailor data to specific needs, low data update frequency, limits to the scalability in terms of numbers and types of data covered, and limits in terms of making data available across different chains. 

RedStone aims to address these challenges with affordable storage, on-demand fetching, flexible data streams, and cross-chain interoperability. Thus, offering custom support for underserved areas of DeFi, as well as bringing an efficient and scalable approach to data management and accessibility. To achieve this goal, RedStone has developed an oracle solution with a completely new modular design that increases user autonomy and data transmission efficiency.

In this report we will start covering the background of RedStone, cementing the amount of trust it has gained by numerous investors, protocols, and users over the years. Then we will illustrate in more detail the Oracle Problem and the limits of current oracle solutions. Later, we will describe the reason why RedStone was founded, what challenges it addresses,  and what key use cases it enables. After that, we will focus on the components that make up its modular architecture and the different options end users have to consume data feeds. We will go through the fast rate of adoption of RedStone within the Oracle landscape, and finally introduce what the next steps are in order to improve the cryptoeconomic security and utility of the network.

Key Takeaways

• Background: RedStone Oracle was founded in 2021 and launched its first mainnet deployment in January 2023, introducing a modular design that allows for rapid network integration and adaptation to market needs.
• Addressing the limitations of current Oracle solutions: RedStone’s goal is to address major challenges faced by most Oracle solutions such as high maintenance costs, low update frequency, limitations in customizing data to specific needs, and restricted scalability in terms of the variety of data that can be handled. This is achieved with solutions like affordable storage, on-demand data fetching, flexible data streams, and cross-chain interoperability.
• Modular Architecture: The modular architecture of RedStone enables it to support over 1,000 assets with real-time updates every 10 seconds, providing DeFi protocols with advanced financial data integration and diverse data types beyond traditional financial information. For instance, RedStone specializes in yield-bearing collateral for lending markets, particularly emphasizing liquid staking tokens (LSTs) and liquid restaking tokens (LRTs), delivering unique price feeds not available elsewhere.
• Cross-Chain Agnostic: RedStone’s chain-agnostic approach ensures compatibility with multiple blockchain environments, enhancing gas efficiency and data integrity through cryptographic signing and flexible data delivery models.
• Future Developments for Security: RedStone is exploring the introduction of its own token and leveraging restaking via enshrining Actively Validated Service (AVS) on EigenLayer or another restaking platform to strengthen its cryptoeconomic security, ensuring reliable data provision and robust network reliability.

Background

RedStone was established in 2021 during the Arweave incubation program and launched its first mainnet deployments in January 2023. Unlike other blockchain oracles like Chainlink and Pyth Network, RedStone differentiates itself through its modular design. As stated by Wojciechowski, RedStone’s CEO, “Our modular architecture allows for quicker network launches and flow adjustments based on market needs. For example, with the liquid restaking tokens wave, we were the first oracle to support projects such as Ether.Fi, Renzo, Puffer, and Swell.”

Currently, RedStone provides frequently updated and diverse data feeds for decentralized applications (dApps) and smart contracts across multiple Layer 1 (L1) and Layer 2 (L2) blockchains. It supports over 1,000 assets and offers data feeds to DeFi protocols on more than 50 chains, aggregating data from centralized exchanges (CEXs), decentralized exchanges (DEXs), and broad market aggregators.

Thanks to its modular nature, RedStone delivers unique data feeds not available elsewhere, particularly specializing in yield-bearing collateral for lending markets, such as Liquid Staking Tokens (LSTs) and Liquid Restaking Tokens (LRTs). Being chain-agnostic, it can push data to EVMs, non-EVM ecosystems, rollups, and various appchains. This flexibility is demonstrated by its recent integration with The Open Network (TON), where it remains the only oracle provider.

According to DefiLlama, RedStone is now the fifth largest blockchain oracle by TVS, securing a total value of approximately $3.8 billion. This achievement reflects its rapid growth and successful integration across numerous chains.

The company was co-founded by Jakub Wojciechowski and Marcin Kazmierczak. Jakub, with a background in computer science, has valuable experience from DeltaPrime and OpenZeppelin. Marcin, an ex-Google Cloud Product Manager, has been active in the blockchain space since 2017, participating in numerous hackathons and conferences.

Since June 2021, RedStone has successfully conducted four seed and one early-stage funding rounds, raising approximately $22.9 million from 39 investors, including 31 institutions and 8 angel investors.

Figure 1: RedStone’s funding rounds to date

Source: tracxn, RedStone

The latest one was held on July 2, 2024 when RedStone announced a $15M series A funding round led by Arrington Capital, followed by other leading investment funds in the Web3.

Figure 2: Series A $15M funding round announced on July 2024

Source: RedStone Blog

RedStone’s Series A funding round precedes its anticipated token launch later this year. Rumors suggest that the project plans to use $RED as its token ticker, with a total supply of 1 billion tokens.

The Oracle Problem

A high-level definition of the Oracle Problem can be found in an article written by Jimmy Song: “There’s a need for the digital world to know about the physical world. This is known as the Oracle problem.”

Blockchains operate in isolated environments and cannot inherently communicate with the outside world or other blockchains. Oracles serve as a middleware solution that connects blockchains to external data sources. They provide the necessary data to build complex blockchain applications and enable real-world use cases. Oracles may initially appear contradictory to the decentralized nature of blockchains. For example, if a blockchain application depends on data from a centralized source, such as an oracle, it might seem to undermine its decentralization. However, the goal is to incorporate real-world data onto the blockchain in a decentralized manner, minimizing risks to the application or protocol. This balance allows oracles to increase blockchain functionality while maintaining the integrity of decentralized systems.

Since an oracle controls the inputs to a smart contract, it also dictates the contract’s actions in response to these inputs. This grants oracles significant power over smart contracts. If an oracle is compromised, the entire contract is at risk. This is why centralized oracle services are often not seen as a viable solution to “The Oracle Problem”. Relying on a single central oracle negates the decentralization benefits of the blockchain, effectively undermining the trustless and distributed nature of the system.

The Oracle Problem can be broken down into three main areas: scalability, incentivization, and decentralization.

• Scalability: This involves enabling oracles to process tens of thousands of transactions per minute without incurring immense gas costs, balancing the Data Latency vs. Data Cost dilemma. The more frequently data is fetched, the higher the cost. In standard oracle solutions, fetching data more frequently can lead to exponentially rising costs. Proper scalability also ensures the oracle continues operating under extreme market conditions.
• Incentivization: Designing the right incentivization model is crucial for cryptoeconomic security. If the potential rewards for bribing or colluding with nodes are higher than the costs, it could lead to system abuse. Even in a decentralized system, it’s vital to ensure trustlessness by making the cost of fraud higher than the potential profit. This ensures that nodes act economically rational, making the network fraud-resistant.
• Decentralization: Eliminating single points of failure is necessary to prevent malicious actors, including insiders, from effectively attacking the network. Decentralization ensures that even if someone gains access to the technology behind the oracle network, they cannot compromise its security.

Given these challenges, early oracle solutions employed a “two-phase approach” in which a smart contract sends a data request to an oracle, and the oracle then responds with the necessary data. This method, introduced by Chainlink and Provable, had two major drawbacks: delayed data access and non-atomic data fetching. The former means that the smart contract cannot instantly access the data, reducing usability due to the wait time for a response. This issue is compounded in blockchain environments, where transaction times are typically slower than traditional API requests. Non-atomic data fetching refers to the fact that data retrieval does not happen within a single transaction. As a result, the oracle must synchronize with multiple contracts, adding complexity, slowing down processes, and ultimately hindering interoperability.

To address the issues associated with the two-phase approach, blockchains have increasingly adopted the strategy of storing all data directly on-chain. This ensures that information is available within the context of a single transaction, thereby enhancing usability and interoperability. However, this method comes with significant downsides: high maintenance costs, lower update frequency, limitations in customizing data to specific needs, and restricted scalability in terms of the variety of data that can be handled.

Expensive Storage and Lower Update Frequency

Storing data on-chain is prohibitively expensive, especially during periods of high network activity. For instance, on days when the average gas price is 500 gwei, a single transaction can cost over $100. If data needs to be updated every 10 minutes across 30 sources, the daily cost can exceed $400,000 per token. In addition, these costs force Oracles to keep a lower update frequency of data feeds.

Lack of Data Customization 

The high costs necessitate pooling funds from multiple protocols, which results in the adoption of uniform configurations and limits the ability to tailor data to specific needs. 

Lack of Scalability

This model can only support a limited number of tokens, often excluding less popular ones from oracle services, thereby the current approach to the Oracle problem is inefficient in scaling both the number of assets covered and the variety of data types. Thus, failing to fulfill the needs coming from the evolving DeFi landscape for new types of data beyond token prices. 

While directly storing data on-chain was initially effective for scenarios with large update intervals and a small number of assets, the rapid growth of DeFi has significantly increased the demand for diverse data types, including LST/LRT, RWAs, NFTs, gaming, betting, and more. This increase in demand also necessitates lower latency and consistent data availability across multiple blockchains. The traditional approach fails to meet these evolving requirements efficiently.

Why RedStone?

RedStone aims to address these challenges by offering affordable storage, on-demand data fetching, flexible data streams, and cross-chain interoperability. This approach provides custom support for underserved areas of DeFi and offers an efficient, scalable solution for data management and accessibility.

To achieve this, RedStone has developed an oracle solution with a modular design that increases user autonomy and data transmission efficiency, eliminating the need for continuous on-chain data posting. In this design, data is first placed in a data availability layer and then fetched on-chain as needed. This allows RedStone to broadcast numerous assets at high frequency to a less expensive layer, only putting data on-chain when required by the protocol. Unlike traditional oracles, RedStone stores its data on the Arweave blockchain, providing it to DeFi projects through a decentralized public cache maintained by its node and partner network. RedStone’s EVM-Connector injects this data into the target chain only when needed, ensuring data integrity and security.

Furthermore, RedStone will eventually allow multiple data providers to enter the blockchain ecosystem, each capable of applying different aggregation rules to tailor their services to the specific needs of DeFi protocols. For example, a lending pool might require time-averaged data to avoid liquidating users due to a price flash-movement, while a synthetic DEX or a margin-trading protocol would need the most up-to-date information.

This architecture not only reduces costs but also ensures faster and more reliable access to essential data across multiple blockchain networks. The modular design allows RedStone to update or replace components independently, ensuring scalability and integration across different blockchains. For instance, RedStone was the first oracle to support projects like Ether.Fi, Renzo, Puffer, and Swell, and it completed an end-to-end integration with The Open Network (TON) in just four months, despite TON’s complex architecture.

Addressing Challenges and Enabling New Use Cases

RedStone’s modular design enables it to overcome numerous challenges within the Oracle landscape, unlocking a variety of applications and business models across the DeFi ecosystem. This approach allows it to scale more rapidly than its competitors (i.e. Chainlink, UMA Oracle, Band Protocol, Pyth, and API3), providing robust and versatile solutions for decentralized finance.

DeFi Protocols

DeFi protocols often struggle to provide price data for less popular tokens because it is not economically viable for most oracles; the costs of providing the data exceed the revenue generated. RedStone overcomes this challenge by offering data for over 1,000 different crypto assets. This extensive data provision enables DeFi protocols to integrate advanced financial data such as interest rates, volatility, and liquidity. Additionally, RedStone’s real-time price feeds facilitate accurate execution of trades, liquidations, and the use of derivatives on DeFi platforms, enhancing their functionality and reliability.

Real-Time and Historical Data Access

The second problem RedStone addresses is the data update interval. Most current data solutions update on-chain data every 10 minutes or longer. In contrast, RedStone provides dApps with refreshed data every 10 seconds for any asset supported by the oracle. Some assets already have a 2 seconds refresh interval and the team works further to improve oracle’s performance.

Additionally, historical data typically holds less economic value for DeFi protocols than real-time data, which is why most oracles do not support it. Unlike other oracles, RedStone supports the use of historical data on-chain, providing DeFi applications with a rich dataset for historical analysis. This capability enables DeFi platforms to introduce new features and key metrics.

Diverse Data Types

Another key problem RedStone solves is the diversity of data available on-chain. Unlike other oracles in the market, RedStone is not limited to financial data alone. It can handle a wide array of data types, including financial derivatives, voting data, political decisions, climate conditions, sports competition results, and more. This flexibility makes RedStone a versatile tool adaptable for numerous use cases beyond the financial sector. 

In fact, RedStone already supports data feeds for various applications, including LST & LRT protocols, financial derivative platforms, insurance dApps, prediction markets, dynamic NFTs, and gaming. This broad spectrum of data capabilities allows RedStone to fulfill a diverse range of needs within the DeFi ecosystem.

Figure 3: Diverse base of projects already supported by RedStone

Source: RedStone website

Cross-Chain Interoperability

Another challenge RedStone is addressing is cross-chain interoperability. Standard oracles typically deliver data feeds to a single Layer 1 blockchain. In contrast, RedStone’s chain-agnostic approach allows it to push data to multiple EVM and non-EVM ecosystems, rollups, and appchains. This makes RedStone an ideal partner for Rollup-as-a-Service providers and Eigenlayer AVSs, ensuring broad compatibility and seamless integration across diverse blockchain environments.

Figure 4: RedStone – Cross-chain interoperability

Source: RedStone website

RedStone’s data is cryptographically signed by providers and can be verified on any chain that supports basic cryptographic primitives. This abstraction of storage from usage means that, although RedStone persists data on the Arweave chain, it can be utilized with any blockchain.

This flexibility supports all types of DeFi dApps by offering both Classic (Push) and Core (Pull) data consumption models, ensuring new chains can be oracle-ready from day one. Moreover, RedStone excels in gas efficiency, which enhances long-term system efficiency for dApps and reduces unnecessary costs and dependencies, such as using a bridge in the data delivery process. By not pushing the same data to multiple chains, RedStone further avoids unnecessary gas expenditures.

Focus on key use cases: LST/LRT price feeds and the OEV solution

Among the use cases enabled by RedStone, two stand out: (1) the provision of specialized price feeds for LST (Liquid Staking Tokens) and LRT (Liquid Restaking Tokens), (2) RedStone’s recent exploration of Oracle Extractable Value (OEV) and solution.

LST & LRT price feeds: RedStone’s specialization

Looking at the Total Value Locked of the DeFi market, year to date it almost doubled reaching $172.8 billion. In particular, liquid staking and restaking add up to 66.2 billion (38%), liquid staking now being the first category. 

Figure 5: DeFi – Total Value Locked

Source: DefiLlama. As of July 28, 2024

This is one of the reasons why RedStone specializes in yield-bearing collateral for lending markets, particularly emphasizing liquid staking tokens (LSTs) and liquid restaking tokens (LRTs), delivering unique price feeds not available elsewhere. Hence, LSTs & LRT platforms represent a significant portion of RedStone’s user base. 

Figure 6: RedStone – LST/LRT data feeds

Source: RedStone website

Accurate real-time data is crucial for valuing staked assets and their tokenized forms. This data impacts trading prices, redemption values, risk management, market volatility, and liquidity monitoring. Additionally, it is essential for calculating and distributing staking rewards based on current asset performance and market conditions.

Oracle Extractable Value (OEV): RedStone’s Solution

Oracle Extractable Value (OEV) refers to the ability of oracles to capture value by controlling the timing and sequence of data updates, similar to Maximal Extractable Value (MEV) in blockchains. This occurs primarily during liquidation events in lending protocols where timely data feeds are crucial. Oracles can either directly extract OEV or sell the right to do so, which can be financially beneficial but may result in lost value for the DeFi protocols and their users.

In traditional oracle setups, value can leak when liquidation thresholds are met but not acted upon due to delays or inefficiencies in data updates. This leakage translates into potential profits that are not captured by the protocol but by external actors who capitalize on these inefficiencies. For instance, if a liquidation threshold is met, but the price feed update is delayed, the opportunity for a profitable liquidation might be missed, causing financial losses for the lending protocol (known as bad debt).

RedStone addresses the issue of OEV by creating a more efficient and fair system for handling price feed updates. Here’s how:

1. Data Fetching and Speed: RedStone fetches data directly from both centralized (CEXes) and decentralized exchanges (DEXes), allowing for quick and accurate price data without intermediaries.
2. Modular Design: RedStone’s Data Distribution Layer (DDL) ensures that signed price packages are publicly visible before they are sent on-chain. This transparency allows liquidators to analyze and act on price data swiftly.
3. Versatile Liquidation Logic: RedStone supports various models (Push, Pull, and Perps) to ensure adaptable and efficient liquidation processes. This flexibility helps maintain the integrity and efficiency of the DeFi protocols using RedStone.
4. Auction System for OEV: By implementing an auction system, RedStone increases competition among searchers (those looking to capitalize on OEV), which minimizes value loss and redirects benefits back to the protocol and its users. This approach ensures that the best offer gets to liquidate collateral, thus improving fairness and efficiency.

An example of RedStone’s integration is seen in the Morpho Blue project, where RedStone’s price feeds are used alongside UMA’s OVAL product. This setup involves running order flow auctions in Flashbots’ MEV-Share, where searchers bid for the right to use price data for liquidations. The proceeds from these auctions are then returned to the protocol, reducing the impact of value leakage and enhancing economic security. 

In conclusion, RedStone’s approach to managing OEV not only mitigates value leakage but also ensures that the reclaimed value is redistributed to the DeFi protocols and their users.

Components of RedStone’s Modular Architecture

The protocol can be dissected into multiple independent modules: (1) Data Sources, (2) RedStone Oracle Nodes, (3) Data Distribution Layer – DDL, and (4) Data consumers.

Figure 7: RedStone – Data Flow

Source: RedStone Docs

Data Sources

RedStone data sources include price feeds from multiple sources such as CEXs (Binance, Coinbase & Kraken, etc.), DEXs (Uniswap, Sushiswap, Balancer, etc.) and broad market aggregators (CoinmarketCap, Coingecko, Kaiko). 

The sources are publicly visible in the RedStone website with reliability metrics such as incorrect price, fetching failed, success rate, and stability report.

Figure 8: RedStone – Data Sources

Source: RedStone Website

Oracle Nodes

RedStone Oracle Nodes perform: (1) data fetching from various external APIs, (2) data processing and aggregation, and (3) transmission to the Distributed Data Layer. 

Data fetching in RedStone occurs through various external APIs. Once fetched, the data is processed and aggregated by node operators. The aggregation methodology is configurable and can be set to methods such as the median of values, volume-weighted average price (VWAP), or liquidity-weighted average price (LWAP). Although each data feed can have a custom aggregation method, RedStone generally prefers using the median of aggregated quotes. The median value is considered a conservative approach because it enhances resistance to manipulation by discarding outliers. While more sophisticated weighting strategies like VWAP can achieve greater price accuracy, they may also become susceptible to manipulation in certain cases. This balance ensures that RedStone’s data feeds remain reliable and secure against potential tampering.

Figure 9: Example of data aggregation for $SOL price from multiple sources

Source: RedStone website

The cleaned and processed data is then signed by node operators, ensuring its quality, and delivered to the Data Distribution Layer (DDL).

It’s worth noting that the operational parameters of RedStone Oracle nodes are defined by a public Manifest. This Manifest includes details such as data sources, update intervals, and validation checks, essentially outlining the provider’s obligations regarding the data provided. While RedStone currently operates all Oracle nodes on the mainnet, these nodes will eventually be managed by independent operators. Information about data sources and providers is publicly accessible on the RedStone website, including details about the number of nodes, the number of assets supported, and the update intervals.

Figure 10: RedStone – Data Services

Source: RedStone website

Data Distribution Layer

The Data Distribution Layer (DDL) consists of two main components: the data availability layer and data storage.

The data availability layer ensures that signed data (verified and approved for use) is packed as meta-transactions without the need for regular price updates to be pushed on-chain. Meta-transactions are special transactions that bundle multiple pieces of data together and allow users to interact with a blockchain network without paying transaction fees, as third-party actors can cover the user’s gas costs.

These transactions are managed through an integration with Streamr Network, a peer-to-peer network for real-time data publishing and subscribing, and open-source Direct Gateways operated by RedStone. These gateways can be spun up permissionlessly using the open-source cache-service.

At the time of broadcasting, data feeds represent live data. With each new broadcast, previous data is archived on the Arweave blockchain, designed to store large amounts of data at a fraction of the cost of chains like Ethereum. This archival process preserves all historical data and ensures the accountability of data providers. Currently, storing 1GB on Arweave costs $26.5, which is significantly cheaper than on Ethereum. These low operating costs enable RedStone to process more data with a higher update frequency.

Data Consumers

Finally, both live and historical data can be pushed on-chain by different data consumers. This can be done through a dedicated relayer operating under predefined conditions (such as heartbeat intervals or price deviations), by a bot performing actions like liquidations, or even by end users interacting with the protocol. 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.

Flexible Data Streams

One of RedStone’s key distinguishing features is the flexibility it offers to its end users, the data consumers. They can choose how to receive data based on their specific business needs, rather than being forced into a predefined and standard delivery method. Users can choose between four models: (1) RedStone Core, (2) RedStone Classic, (3) RedStone X, and (4) RedStone ERC7412.

Figure 11: RedStone – Data delivery models

Source: RedStone Documentation

RedStone Core 

The Core Model (Pull) involves automatically injecting data into user transactions to improve gas efficiency and UX. This model, already available in production across multiple mainnets, is the most mature, efficient, and scalable method to use RedStone. 

Instead of constantly pushing Oracle data on-chain (in EVM storage), information is brought on-chain only when needed (on-demand fetching) thanks to the RedStone’s EVM-Connector module. Between on-demand fetching events, data is available in the DDL. When data has to be transferred on-chain, it is transferred to EVM via a mechanism based on a meta-transaction pattern and the information integrity is verified on-chain through signature checking.  Hence, transferring data to an EVM environment requires packing an extra payload to a user’s transaction and processing the message on-chain. 

Figure 12: RedStone’s EVM-Connector

Source: RedStone Documentation

In other words, data such as a cryptocurrency’s price is embedded into the calldata of a user’s transaction on the blockchain – that is, read-only temporary data that is attached to a transaction. This is possible because blockchains transition from one state to another and can include additional information in these transitions for different purposes. RedStone leverages this capability by inserting its data into the calldata of a user’s transaction, effectively placing the data onto the blockchain.

In summary, this architecture saves on transaction fees that would otherwise be spent on constantly updating the destination blockchain. Data feeds are delivered only when needed, utilizing on-demand fetching to optimize cost-efficiency.

RedStone Classic 

The Classic Model (Push) is built on top of the Core Model and adopts a traditional Oracle approach where data is regularly pushed into on-chain storage via a relayer based on predefined conditions. This model is ideal for protocols that want full control over the data source and update conditions, do not require frequent updates, prefer not to modify their codebase as needed for the Core Model, and operate on chains with low gas fees.

Unlike traditional push Oracles, the Classic Model’s modular design offers data consumers the flexibility to choose when and how the price is updated. In many other Oracle solutions, users must accept predefined parameters. With RedStone’s Classic Model, customization is achieved through an off-chain relayer service that pushes data on-chain in a tailored manner using environment variables. The relayer periodically checks a set of predefined conditions and pushes prices when these conditions are met.

Currently, users can set two main conditions:

• Update Price Interval (Heartbeat): defines how often prices should be updated.
• Minimum Deviation Percentage: specifies the amount of value change required to trigger a price update.

When these conditions are satisfied, the relayer pushes the data to the on-chain contracts for storage. Data consumers can then access the data through familiar interfaces like the Chainlink Aggregator. This approach reduces transaction fees by minimizing unnecessary updates and provides protocols with greater control and flexibility.

Figure 13: RedStone Classic Model (Push)

Source: RedStone Documentation

RedStone X 

The RedStone X model is designed for protocols such as perpetuals, options, and derivatives, aiming to protect against front-running risks by providing price feeds in the very next block after user interactions. This model uses a deferred execution pattern where transactions are processed in two phases.

First, a user initiates the transaction by recording an on-chain intention to interact with the protocol (e.g., opening a perpetual position) without knowing the exact context (e.g., price) in which the transaction will be executed. This mitigates any attempts to exploit the protocol by front-running price delivery from oracles. Only after this initial step is the price pushed on-chain, typically in the very next block. Anyone, including the user, can push the price, as its integrity is validated on-chain based on the protocol constraints. This validated price is then used to finally settle the transaction.

Figure 14: RedStone X Model

Source: RedStone Documentation

While the Resolver role is permissionless, RedStone’s integration requires a Keeper service that automatically fetches the price and triggers the execution.

RedStone ERC7412

The last model, RedStone ERC7412 is a combination of the Classic and Core ones and it has been introduced in the form of ERC7412, a method to construct multicalls with prepended verifiable off-chain data and popularized by perpetual protocol Synthetix. 

Growth in RedStone Adoption

RedStone’s modular approach and the use cases it enables are proving highly beneficial. From January ’24 to July ’24, the Total Value Secured (TVS) by RedStone surged from $108 million to $3.7 billion, raising it from the 13th to the 5th largest oracle by TVS. TVS, similar to Total Value Locked (TVL), also includes assets temporarily outside the protocol (e.g., borrows and double counts) but potentially at risk if an oracle misprices delivered feeds.

It’s important to note, as highlighted by PrismaRisk, that while DeFiLlama provides data on oracle provider usage, it does not fully capture all RedStone integrations. This is because DeFiLlama requires an oracle provider to secure 50% of the protocol’s TVL to be listed as an integration, which can omit some of RedStone’s extensive applications and partnerships.

Figure 15: Total Value Secured by top 5 Oracles

Source: DefiLlama. As of July 28, 2024

Keeping that in mind, RedStone has experienced substantial growth in market share since its inception in 2022. As of July ’24, its market share increased fivefold, rising from approximately 1% to around 5%.

Figure 16: TVS market share

Source: DefiLlama. As of July 28, 2024

RedStone’s Path to Security

Historically, many oracles have needed to create and launch their own tokens to secure their networks and operations. This approach, while effective, comes with significant challenges and complexities, including token distribution, liquidity management, and market adoption. Bootstrapping a new PoS network is challenging as projects must issue a new token and persuade people to buy and stake it. Moreover, these native tokens are often volatile, hard to access due to their novelty and lack of exchange listings, and they pose high inventory risk for holders. Since the native token’s value is closely tied to the system’s overall security, PoS networks in their early days might face a potential death spiral. 

Figure 17: Proof of Stake: Early Death Spiral Risk

Source: EigenLayer Blog

However, the advent of restaking primitives has revolutionized the landscape for bootstrapping distributed systems that require some degree of economic security. Initiated by EigenLayer and followed by platforms such as Symbiotic and Karak, restaking allows networks that operate off-chain and require economic security to bootstrap their operations more efficiently and quickly. These networks can now leverage existing staking mechanisms instead of launching their own tokens, simplifying the process and reducing associated risks.

At the moment, RedStone still does not have its own token although it has been mentioned more than once that there is the intention to have one as a way to coordinate the network and align the incentives of the stakeholders within the RedStone ecosystem. In particular, allowing multiple data providers generates a need to curate them and select the most reliable ones, hence data providers eventually may need to stake RedStone tokens as collateral to ensure that they will keep operating and providing high quality data (or be slashed otherwise). 

With the advent of restaking protocols, now RedStone has an additional option to secure its network. Each staking protocol uses different names to refer to the same thing (Actively Validated Services in EigenLayer, Vaults in Symbiotic, or DSS in Karak). In general, these names are a way to identify applications, protocols or infrastructure providers that require a distributed set of node operators to provide trust-minimized services, such as coprocessors, data availability layers, new virtual machines, keeper networks, oracle networks, bridges, threshold cryptography schemes, trusted execution environments, and more. They are analogous to verifiable SaaS (Software as a Service), providing specialized services on top of the staking protocol.

A first step in this direction has been already confirmed by the restaking delegation partnership between RedStone and Ether.fi, a leading restaking protocol. This collaboration intends to enhance the RedStone Oracle’s security schema by partially extending the security of Ethereum’s validator set, thereby increasing the network’s value and diversity. As per the delegation agreement, a subset of over 20,000 node operators from Ether.fi will manage RedStone’s AVS and employ Ether.fi’s native liquid restaking token (eETH). The restaked Ether will serve as a safeguard against both liveness failures and crypto-economic attacks within the network of RedStone’s node providers. This will guarantee that RedStone is secured by the most secure crypto collateral and consistently verified by a highly diverse validation set, thereby establishing the first oracle network secured by restaking. RedStone as an innovative and quickly growing player in the Oracle sector suffers from the common problems of bootstrapping security at a pace that matches the growth of the Total Value Secured (TVS). Having access to an external pool of capital will help to stabilize the system cryptoeconomics and ensure that the node operators are properly incentivised to provide high-quality data service. Additionally, most Oracle systems rely only on internal token security guarantees and suffer from the vulnerability of coordinated attacks where a sophisticated adversary will strategically accumulate a large amount of Oracle tokens to simultaneously attack the Oracle network and short the Oracle token. RedStone by extending their security model to an external and uncorrelated LRT token will mitigate this attack vector and pioneer the new higher standards of dual-token Oracle safety mechanism.

Dual staking allows the protocol to take advantage of the cryptoeconomic security offered by staking while benefiting from the utility of its own token. In a pre-restaking world, many projects, which did not need their own token, were forced to issue one, slowly and laboriously building their own crypto-economic security. Thanks to restaking, projects can start out using $ETH as the shared security layer, which reduces the endogenous risk associated with having a native token. Progressively, as the AVS/Chain/DSS grows, projects can pivot to a dual-token model and eventually launch their own native token if they decide to do so. 

Figure 18: Dual Staking Model

Source: EigenLayer Blog

A decrease in the native token’s value could significantly weaken the network’s security, leading to a drop in Total Value Locked (TVL), further decreasing the token’s price and creating a downward spiral. A dual-token model aims to solve this problem by using two tokens to secure the same PoS network. If one of these tokens is an external network token with lower volatility, deeper liquidity, and more accessibility, such as ETH, it can address the challenges new PoS networks face. Thus, dual staking can mitigate the death spiral effect; if the native token’s price falls, the PoS network’s security is still affected, but to a limited extent. This is because the ETH staked in the PoS network provides a baseline of economic security.

In summary, using the words of Jakub Wojciechowski, CEO of RedStone: “We are firmly convinced that this novel agreement, which showcases a leading oracle solution utilizing the restaking primitive to enhance system security against malicious threats, is immensely advantageous for all parties involved. RedStone, equipped with the ability to arbitrarily boost the value of its security backing, can swiftly and efficiently scale its services.”

Conclusion

RedStone has demonstrated significant growth and innovation in the DeFi ecosystem, addressing long-standing issues within the oracle landscape. From its establishment in 2021 through the Arweave incubation program to its first mainnet deployment in January 2023, RedStone has differentiated itself through its modular design, enabling rapid integration and adaptability to market needs.

RedStone’s approach solves several key problems faced by traditional oracles. By offering affordable storage, on-demand data fetching, flexible data streams, and cross-chain interoperability, RedStone provides an efficient and scalable solution for data management. This has allowed RedStone to support over 1,000 assets across more than 50 chains, offering unique data feeds, particularly for yield-bearing collateral in lending markets, such as Liquid Staking Tokens (LSTs) and Liquid Restaking Tokens (LRTs).

The significant growth in RedStone’s Total Value Secured (TVS), which surged from $108 million to $3.7 billion between January and July 2024, highlights the market’s trust and the effectiveness of its solutions. RedStone’s innovative approach allows it to also address use cases such as the Oracle Extractable Value (OEV), by implementing an efficient system for handling price feed updates and mitigating value leakage.

Furthermore, RedStone’s integration with multiple blockchains and its modular architecture ensures it can update or replace components independently, ensuring continuous scalability and interoperability. The collaboration with restaking protocols like Ether.fi underscores its commitment to enhancing security and leveraging existing staking mechanisms to bootstrap its operations efficiently.

Looking ahead, RedStone is exploring the introduction of its own token and becoming an Actively Validated Service (AVS) to manage its cryptoeconomic security. This move aims to align incentives within the ecosystem, allowing multiple data providers to stake RedStone tokens as collateral, thereby ensuring high-quality data provision and network reliability.

References

CaméSennin, (2024) RedStone Oracles in 10 Questions. Published on Medium | Link

Delphi, (2017) The Oracle Problem. Published on Medium | Link

Eckvahl C., (2022) RedStone Oracles: Reliable On-Demand Data for Stacks Applications. Stacks Blog | Link

Khatri Y., (2024) Blockchain oracle RedStone raises $15 million Series A via token round. The Block | Link

Lithium Digital, (2023) An in-depth exploration of RedStone Oracles: the data oracle transforming DeFi access to external data | Link

PrismaRisk, (2024) Oracle Risk Assessment: RedStone. HackMD | Link

RedStone, (2022) RedStone Oracle technical doc. Github | Link

RedStone Blog, (2022) Introducing RedStone – The next generation of Oracles | Link

RedStone Blog, (2022) The Oracle Problem and its implications for blockchains. Published on Medium | Link

RedStone Blog, (2023) Leading Web3 Builders back RedStone Oracles in an Exclusive Angel Round | Link

RedStone Blog, (2024) RedStone Oracles Raises $15M in Series A | Link

RedStone Blog, (2024) RedStone Oracles seals $500M restaking commitment with Ether.fi | Link 

RedStone Blog, (2024) What is RedStone? Modular Oracles for DeFi | Link

RedStone Documentation | Link

RedStone Website | Link

Song J., (2018) The truth about smart contracts. Published on Medium | Link

Disclosures

Revelo Intel is engaged in a commercial relationship with RedStone as part of an educational initiative and this report was commissioned as part of that engagement.

Members of the Revelo Intel team, including those directly involved in the analysis above, may have positions in the tokens discussed.

This content is provided for educational purposes only and does not constitute financial or investment advice. You should do your own research and only invest what you can afford to lose. Revelo Intel is a research platform and not an investment or financial advisor.