RedStone Oracles: 3 integration options to suit your needs

5 min readMay 26, 2024

Oracles supply data to multiple sources simultaneously and can be either centralized or decentralized. Centralized oracles fetch data from a single source, which is unreliable due to potential downtime. Decentralized oracles, like RedStone, fetch data from multiple sources, ensuring reliability even if one source fails.

RedStone offers 3 different methods of integration through its oracle. In practice we can even say 4 methods. You can find detailed instructions on how to integrate these different modes into your blockchain here: RedStone Documentation.

Here’s these methods:

1 - Core (Instant Data Request)

Lowest gas costs, a few seconds of latency, dApp users deliver signed data packages on demand to the destination chain. This the basic operating model. The data is automatically appended to user transaction.

Data is dynamically injected to user transactions achieving maximum gas efficiency and maintaining a great user experience as the whole process fits into a single transaction

This model is in production, protecting >$100M TVL of DeFi Protocols across multiple mainnets and the price feeds have been injected to more than ~50K transactions.

It is one of the simplest methods, requiring the integration of RedStone’s API into your code using a library created by RedStone. This allows you to receive real-time data for the desired token. You need to do 2 things, (1) adjust your smart contracts to include the libraries responsible for data extraction and verification and (2) adjust Javascript code of your dApp to inject the additional payload with data feeds.

2 - Classic (Push Model)

Compatible with traditional Oracles, dApp gets full control over data source and update conditions.

Data is pushed into on-chain storage via relayer. Dedicated to protocols designed for the traditional Oracles model, that want to have full control of the data source and update conditions.

Sticking to a traditional design when data is pushed on-chain can be useful, and this setup is reasonable if you are in at least one of these situations:

Well-audited codebase and not preferable to make tiny changes
Protocol is deployed on a private network or on a chain with very low gas costs
Prices don’t need to be updated frequently

The Classic approach is built on top of the Core model introduced above. This maintains the security level provided by RedStone.

Two main parts composes this model. The first one is the off-chain relayer. The second one is the on-chain contracts.

a - Off-Chain Relayer

The off-chain relayer is responsible for pushing data on-chain in a customized way. A defined set of conditions is defined, and when these conditions are satisfied, the prices are pushed. Multiple conditions cand be passed. Currently, two conditions are implemented:

a time condition described by UPDATE_PRICE_INTERVAL variable in milliseconds, which states how often prices should be updated (aka heartbeat), code
a value-deviation condition described by MIN_DEVIATION_PERCENTAGE variable which indicates how much value should change in order to trigger the price update, code.

The list a environment variables is available here. Finally, relayers are permissionless and anyone could run the service. The relayers are designed to work in parallel and the Redstone’s team recommend having multiple and ideally independent instances to mitigate the risks of failure and censorship.

b - On-Chain Contracts

The on-chain contracts enable storing prices and getting them through a familiar interface (e.g. the Chainlink Aggregator ). Thanks to that, RedStone Classic can be used on EVM-compatible L1s & L2s, Starknet and Fuel Network.

The PriceFeedsAdapter contract is central (and everything is available on Github ;) ). It is responsible for:

storing all price feeds’ symbols (mappings to RedStone dataFeedId),
storing price feeds values,
updating price feeds values in batch,
storing information regarding the round number and timestamp of the last update,
getting prices for multiple feeds’ values in a single call.

https://docs.redstone.finance/docs/smart-contract-devs/get-started/redstone-classic

3- RedStone X (No Front-Running)

Front-running proof, tailored for sophisticated protocols like Perps and Options, based on GMX design.

The model relies on a Deferred execution pattern . The transactions are processed in two steps:

A user initiates the transaction by recording on-chain an intention to interact with the protocol (ie. open a perpetual position) without knowing the exact context (ie. price) in which the transaction will be executed. This mitigates any attempts to arbitrage the protocols by front-running price delivery from Oracles.
The price is pushed on-chain only in the second step, which usually happens at the very next block. Anyone (including the user himself) could push the price, as its integrity is validated on-chain based on the protocol constraints. Such a price will be used to finally settle the transaction.

You need to do 2 things if you want to use this model:

Adjust your contracts to execute price-sensitive transactions in 2-phases (request -> execution), more details are given below
Deploy a keeper service that automatically fetches the price and triggers the execution.

About the 2-phases (request -> execution): the request corresponds, in the context of a price sensitive information, to collect some collateral, record request parameters, and ask keepers to provide price data. In the execution phase, the request from the user is executed with data received from the keeper network. The model will (1) validate if the parameters provided by keepers match the ones notarized by the user, then (2) check the timestamp for which the price is sourced matches the time when the request was recorded, and finally if (1) and (2) are fine, (3) send the appropriate value to the user.

https://docs.redstone.finance/docs/smart-contract-devs/get-started/redstone-x

4 - ERC7412

A word about the RedStone ERC7412 which is a combination of Classic and Core models. You’re gonna need to deploy price feed and modify your client code to use erc7412. This model is used by Synthetix. An example is given here.

Conclusion

The different ways to implement RedStone models is well-documented. Public GitHub repository provide detailed instructions, and very useful examples. Each method addresses specific needs, ensuring flexibility and efficiency for various web3 applications.