Exploring RedStone Oracle, Part I : The modular design of RedStone

4 min readJan 17, 2024

Let kick off middle-week by the start of a miniseries, exploring three different keys concepts from RedStone Oracle. That’s right ! With its new recent integrations, featuring popular blockchains such as Manta and Blast with their Core Model (Classic method as well for Manta), RedStone pursues its path of answering and completing the features that others Oracles cannot.

Let’s study RedStone in three parts, with each one getting its own article :

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

Exploring these fundamentals will allow you to understand the importance of an Oracle for the blockchains, dAaps, and how RedStone is offering exceptional features by “completing” others Oracles features.

What’s Modular ?

A laptop separated in different pieces — explaining the concept of Modular design

Before diving in the modular design of RedStone, exploring the word “Modular” in itself is necessary, as the concept can be hard to grasp at first.

“Modular design, or modularity in design, is a design principle that subdivides a system into smaller parts called modules (such as modular process skids), which can be independently created, modified, replaced, or exchanged with other modules or between different systems.” https://en.wikipedia.org/wiki/Modular_design

In its core principle, if we vulgarize modular design, we could see it as a method of separating a whole system in different parts, that are tinier and can function on their own, but finally grouped themselves by benefiting from each other's and form a whole network.

Modularity can be applied to blockchains, dApps as well, or any digital infrastructure. These days, an application is rarely running by its own as it needs data from outside its core, and that’s the main problem that blockchains are facing : they’re almost cut off from the internet by themselves. On-chain data will mostly contain data about all the transactions that have been made on the blockchain, but price feeds, and off-chain data (we can almost call it the WHOLE internet!), is inaccessible.

That’s where Oracles comes to the rescue : they offer the off-chain data, blockchains desperately needs.

And RedStone Modular design goes in with one step further : offering multiples flexible ways to be integrated in the blockchain, while also maintaining data integrity.

The Modular design of RedStone, adapting to the needs of where it's integrated

**https://docs.redstone.finance/docs/smart-contract-devs/how-it-works**

Oracles can have a strong limitation about the way data is handled. The application has to respect criteria that are given to him, making the process less intuitive and slower than it should. Furthermore, an Oracle that would be compromised would be terrible as data integrity wouldn’t be assured, and worse, the link to the applications severed. One answer could be to integrate multiples Oracles to the blockchains, assuring that not a single one of them is in charge of everything.

Not only RedStone offers different ways of integrations (which we will explore in part II), the way data is handled is optimized and given at a high frequency. They achieve this prowess by putting the data on what we call an “Availability layer”. This way, a large source of data is accessible, and broadcast permanently on a low cost layer ( Aerwave ), thanks to the Streamr network we will explore in the last part of this article.

Not only that, RedStone is fetching data feed from multiples endpoints, having more than 50 sources integrated. That way, if one source goes down, RedStone will have access to all others sources that are still online.

Without this modular concept, RedStone wouldn’t be separated in so much different parts and layers. Data integrity could be in danger if the data would be false / not fetch correctly, and the speed it would be given would be greatly weakened. Answering the needs of security, speed, and cost storage, the modular concept was crucial in the conception of RedStone.

In order to resume, RedStone Oracle is modular because of these keys facts :

Rather than forcing the blockchain to answer specific criteria given by RedStone, the blockchain can decide by itself on when and how the price feed is fetched from the Oracle. Not only this make the process less painful, it answers to the needs of builders who want flexibility, while keeping data that’s clean
RedStone is broadcasting the data at a light speed, answering the need of dAaps that needs data to be fetched instantly as accurately as possible. Some dAaps required transactions to be fast
The decentralized Streamr network offers a thousand of nodes that can work by themselves. It’s impossible for all of them to go down at the same time as they are present in multiples part of the world
The data is accessible from all the dAaps, blockchains and applications that have RedStone integrated at the same time