Exploring RedStone Oracle, Part II : The three methods of integration

9 min readJan 18, 2024

The RedStone miniseries, “Exploring RedStone Oracle”, pursue !

Part I : The modular design of RedStone
Part II : The three methods of integration ( We are here ! )
Part III : Data aggregation

Today, we will unveil what are the current methods of integration RedStone currently offers. Integrating an Oracle can be a painful process if done incorrectly, which is why understanding the process is important !

This article was updated recently in order to reflect the 4th new method of integration from RedStone.

The process of integration of an Oracle

Just like we’ve seen in the previous part, Oracle provides the data to multiples sources, at once (preferably.)

Oracle are, as well, centralized or decentralized. The key difference remains in that in a centralized setting, the Oracle will fetch the data from a single source. This is unreliable as the data feed would need to have a 100% uptime, which can’t be assured at all time because of outside events. A decentralized Oracle, just like RedStone, would fetch its data from multiples entry points, at all time. That way, if one goes down, the rest is still able to transmit the data.

However, an integration process is as well needed in order to connect the Oracle to the application. Often, there’s one specific methods where you need to respect the criteria given by the Oracle. Seen as previously in the modular design of RedStone, corresponding and scattering to the needs of different and vast application is one of the main key point RedStone wanted to achieve.

By its modular design, why wouldn’t RedStone offer not one, but multiples ways to be integrated ? Even better : offering a documentation explaining each method.

A well detailed documentation from RedStone, keeps trouble away

Most applications in web3 has a documentation implemented in their official website, RedStone included. The key difference remain in the way of how the documentation is presented. A badly documented documentation would be a difficult process to process for builders, and most of them would probably go elsewhere if they don’t understand how to integrate it.

Offering a documentation that’s explanatory to builders and developers is a necessity, providing a smooth integration at its core by making the process faster, less time-consuming. RedStone did that while also providing schemas, and an explanation to each of its methods. Furthermore, there’s a public GitHub accessible.

Each way that RedStone can be integrated is corresponding to a specific need, a necessity in web3 has many applications does have functionalities that can differ from one another.

With its four different methods of integration, RedStone answer the need most web3 applications needs :

“RedStone Core, 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
RedStone Classic, 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.
RedStone X, targeting the needs of the most advanced protocols such as perpetuals, options and derivatives by eliminating the front-running risk providing price feeds at the very next block after users’ interactions”
https://docs.redstone.finance/docs/smart-contract-devs/how-it-works#3-ways-to-integrate

Update 15/06/2024: The latest integration, called RedStone ERC7412, as been added alongside the three others methods. RedStone ERC7412 will replace the old Core model, while the old Core model will be accessible as a feature inside the ERC integration.

As of now, all the current nodes (responsible for fetching and distributing data), are operated by RedStone team. However, keep in mind this doesn’t remove the decentralized aspect as most of the data comes from multiples sources : it’s simply that, later on, nodes will be accessible by people outside the RedStone core team.

Now, let’s dive in each method further down 👇

RedStone core (old method — currently rebranded as RedStone ERC7412 below)

Made on Canvas, by me ! Optimization on transaction = less time, more $ saved up.

NOTE : this method has been moved to the ERC method as a new feature available.

RedStone core remains the most accessible integration yet, with an easy method. It’s the one many prefers as it’s a simple concept with a mature concept, which means it’s the oldest one yet.

Fitting in a single transaction, injecting the data and appending it to the initial user transaction provide a way to avoid the unnecessary concepts of creating a multitude of transactions that would need to wait to each other to process before the next one ! This can become quickly annoying if one transaction last for a few hours because it hasn’t processed a hundred one before, and cost a hundred of $ because it has been processed again and again on multiples layers.

The core model has a few key numbers that’re interesting to learn :

Protecting >$100M TVL of DeFi Protocols
The price feeds have been injected to more than ~50K transactions

There’s also a working demo you’ll be available to get by yourself in this dedicate repository.

The list of all price feeds can also be found here.

RedStone classic (Push)

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

RedStone classic would benefit applications that are modular themselves, as it allows them to get the decisive voice on when, and how, the price is updated.

“RedStone Classic has a significant advantage over traditional push Oracles. Our modular design gives you a decisive voice on when and how the price is updated (with other Oracles you have to accept dictated parameters).”
https://docs.redstone.finance/docs/smart-contract-devs/get-started/redstone-classic

Compared to the previous core concept, we looked at previously, the data will still be stored on-chain directly. HOWEVER ! This doesn’t mean we are doomed to pay a large cash of dollars because the transaction went through multiples portals. Built on top of core model, RedStone classic distribute the data to a relayer that will push the data on-chain in a customized way, depending on the destination needs. Because of this, RedStone won’t simply handle the data in a superficial way, but optimized.

Moreover, you need to cover a few necessary keys beforehand :

“- There is an existing well-audited codebase and the team prefers not to make even tiny amendments
- The protocol is deployed on a private network or a chain where the gas costs are minimal
- The prices don’t need to be updated too frequently”
https://docs.redstone.finance/docs/smart-contract-devs/get-started/redstone-classic

That’s why this method wouldn’t work on a classic chain like ERC-20 where gas fees are high, or an application that price feed in real time. So, instead, let’s take a look at blockchains that would benefit from this integration.

If we take a look at one of the most recent integrations with Manta Network, (Yes, Manta !), having control over the data that is being fetched is a game changer since a modular blockchain is bound to change: with its modular design in mind, evolution is deemed necessary, such as RedStone that’s working hard on providing new concepts over time.

RedStone X — An extreme protection agaisnt front-running

Front running, also known as tailgating, is the practice of entering into an equity (stock) trade, option, futures contract, derivative, or security-based swap to capitalize on advance, nonpublic knowledge of a large (“block”) pending transaction that will influence the price of the underlying security. In essence, it means the practice of engaging in a personal or proprietary securities transaction in advance of a transaction in the same security for a client’s account. Front running is considered a form of market manipulation in many markets.
https://en.wikipedia.org/wiki/Front_running

Front-running is, at its best, a security breach that could largely impact an advanced protocol, such as DeFi. Multiples front-running has lead to millions of $ lost over the past years in numerous DeFi protocols.

RedStone X offers a deferred execution pattern, offering a way to verify the integrity of the data, which hasn’t been manipulated by a malicious actor. If all checks are passed correctly, the appropriate value will be given back to the user. Otherwise, the order will be locked, with preferably a notification in order to block further attempt by the malicious actor. Incorrect data could lead to the closure of an application !

That’s why, part III will be about “Data Aggregation”.

RedStone ERC7412 — Classic and Core models combined

RedStone ERC-7412 has taken a lot of inspiration from this model, allowing it to combine its “Classic and Core models” together.

RedStone was already invested in a similar subject by investing in the Arweave smart contract technology , reducing the cost of storing such data on its smart contract with Warp, before streaming it to its whole network.

As for the classic push methods from RedStone, the Oracle is already very well capable to push data when needed. It also has the edge to allow the protocol that has RedStone integrated to have the decisive voice on how and when the data is pushed. As the classic method is built on top of the core model, it would make sense that RedStone is capable of handling a multicall process. The data can be appended to the user transaction already, and be processed off-chain from the Oracles gateway (network stream by Streamr — which RedStone uses)

Requirements to integrate RedStone ERC7412

As of now, this method requires the protocol to do two steps before integrating it:

— Deploying the price feed on its application

— Then, modify its code to use ERC7412 (With the library https://npmjs.com/package/@redstone-finance/erc7412…)

A method called “getTTL” is where the magic starts: it will return the duration in seconds before the price feeds become “stale”, which means incorrect. It will then be reverted on “read”, and wait for the price to be updated before being accepted.

This means that it would throw an error when a multicall would be made and, thus, fails the simulation.

Furthermore, down in the code, you can read this comment that was made:

This function will simulate transaction if transaction fails because of erc7412.OracleDataRequired, // it will fetch oracle payload from redstone oracles gateway // and prepare multicall transaction consisting of two transaction {user_tx,update_redstone_price_feed_tx}

The function “generate7412CompatibleCall” will then proceed by updating the price feed from RedStone accordingly, in order to remove the “stale” status from the price. Finally, it will fetch the update price feed from the Oracle gateway (completing the idea of ERC-7412.)

An example has been provided from RedStone GitHub as well, containing the ERC7412 method from RedStone, that has the functions required :

https://github.com/redstone-finance/erc7412-example

This is the end !

Thank you for reading the part II of RedStone miniseries ! I hope the information given were understable for you, and don’t hesitate to leave a comment if you deem any information incorrect, or that could be improved.

We will explore part III at the end of the week. Stay tuned !