Modular Design of RedStone
Today we will touch upon one of the most important and interesting topics in the work of RedStone, where our data comes from, how and to whom it is sent, that is, if we speak briefly, I will tell you the main goal and work of the Redstone project.
RedStone’s price feeds come from a variety of sources. These include both CEX and DEX and various aggregators such as CMC and others. RedStone has almost taken over the market as it already has more than 150 integrated sources. Data is aggregated by independent nodes managed by data providers using different methodologies. Some methods include median, TWAP and LWAP, which are all designed to obtain the most accurate price by taking into account factors such as the amount of available liquidity and the average price over a certain time frame. So we can understand that the team is doing its best to provide the best possible conditions for its users. In addition, data quality measures, such as unexpected value detection, are implemented to ensure the correctness of the data. The cleaned and processed data is then signed by the node operators guaranteeing its quality. Channels are broadcast both in Streamr, a decentralized data network, and directly to open source gateways that can be easily separated if needed. Data can be transmitted to the blockchain either by a dedicated relay operating under predefined conditions, such as a certain price change, or by a bot (i.e., performing liquidations), or even by end users interacting with the protocol.
The first thing we have to consider is how data is encoded before it is included in the blockchain
1) Relevant data must be fetched from the data distribution layer, powered by the Streamr network or the RedStone gateways.
2) Data is packed into a message based on the structure of the ‘Transaction Payload’ diagram below…
3) The package is appended to the original transaction message, signed, and submitted to the network.
I have made such frames to make it easier for you to understand how it works, because it was easier for me personally to understand it, on this picture you can see 3 ways of RedStone work at once.
1) So let’s start with the first step Data Sourcing Component
RedStone, a decentralized data provider, takes data aggregation to the next level by integrating it with a decentralized oracle network. RedStone oracles aggregate data from various sources such as exchanges, off-chain APIs, and other verified data providers. This aggregated data is then used for multiple blockchain applications, most notably in DeFi protocols.
RedStone’s data aggregation process includes several key steps:
Data Collection: Information is gathered from various off-chain sources, including price aggregators and individual data feeds.
Data Filtering: Collected data undergoes filtering to eliminate any outliers or anomalies. This can be done through statistical methods like taking the median value, which reduces the influence of skewed data.
Validation and Signature: Each data provider validates their data, attaches a digital signature, and then forwards it to RedStone nodes.
Timestamping and Packaging: The validated data is timestamped and securely packaged into blockchain-compatible formats before being injected into the blockchain.
In simple words for beginners: For example, we have 100 kg of apples, and different scales by type, mechanical with weights or electronic, and each scale shows different values we record each reading, and then summarized these readings, calculating the average value of the weight. So much for aggregation in simple words!
Why is this stage important ?
RedStone applies various data aggregation techniques such as median, TWAP and LWAP to address the unique needs of each asset. A dedicated data extraction and processing module allows you to flexibly customize approaches and change them as needed. This adaptability ensures channel reliability and protects against data source failures. This makes the information provided accurate and resilient to change.
2) In the second step we have the Data Stoting Component
The next core component in RedStone’s infrastructure is the Data Distribution Layer (DDL), which serves as an off-chain “memory” for data.
The upper level of DDL — short-term memory is highlighted in red in the figure:
This layer represents the mechanisms for temporary storage and distribution of data. It includes RedStone gateways and the decentralized Streamr network. Streamr nodes provide short-term data storage, which temporarily stores relevant information needed for operational processing. Streamr gateways are responsible for distributing this data on demand. If one node fails, the other nodes continue to function, keeping the system stable and running smoothly. The data stored in this layer is “instantaneous” — it is updated as new streams of information arrive, ensuring relevance and responsiveness.
The lower DDL layer — long-term memory is highlighted in blue in the figure:
This layer is based on the use of the Arweave network, which provides long-term data storage. Arweave can be compared to the memory function of the brain which stores memories for long term. Archived data is written to a decentralized network, ensuring that the information is permanently stored. This allows dApps to access historical records when required, for example, to analyze, verify, or perform complex calculations. This approach makes the system resilient and guarantees data persistence regardless of changes in the current stream.
Get Andrey_24’s stories in your inbox
Join Medium for free to get updates from this writer.
In simple words: I suggest you dive a bit into psychology and understanding your brain and memory and how it works with us humans. As they say, we have two types of memory: short-term and long-term memory. What is long-term memory, for example, is languages or simply the multiplication table, the alphabet, which we learned as children and will remember for the rest of our lives. And short-term memory is the memory that we use right now, for example, we need to remember that today we have to 17: 00 for a haircut, you will remember it exactly until you come to get a haircut, but we all know very well how we remember the same time, here I have for example often that I sign up for a certain time somewhere and after half an hour already forget what time I signed up for, I think this was with many people not only with me, I personally solve this problem as well as the Upper Level DDL, I just often repeat to myself the information that I want to remember and so I do not forget at what time I get a haircut.
3) The third step is the Data Distribution Component
RedStone’s modular architecture offers three different integration models, each tailored to specific data access scenarios. This flexibility allows you to choose the most appropriate way to process and retrieve data depending on the needs of the user or application.
The foundation for this approach is the DDL (Data Delivery Layer), a layered system that provides both temporary and long-term data storage. DDL acts as a universal intermediary, allowing data to be stored, processed and accessed on demand. Through its design, the system supports rapid retrieval of current data for fast operations, and provides access to archived records for analytics, validation, or other purposes.
This structure combines reliability, speed, and adaptability to make data integration flexible and convenient. Users can choose the model that best fits their workflows, from instant access to up-to-date data to retrieving archived information needed for long-term decisions.
Pull Model
The Pull Model is geared towards applications (dApps) that need to access data only at certain times, as needed. Unlike the Push Model, where data is automatically sent to the blockchain in real-time, the Pull Model allows data to be retrieved only when requested. This makes the model more cost-effective and practical, especially for protocols where there is no need for constant data updates. The basic working principle is that dApps send a request for data at the moment it is needed. Once the request is received, the data is provided from a trusted source, bypassing persistent storage on the blockchain. This helps to significantly reduce the costs associated with transactions and storage on the network. The Pull Model is particularly useful for applications that deal with events that occur at different intervals or for tasks that require random access to data. For example, protocols that check the status of an asset, update a balance, or perform ad hoc calculations can use this model to minimize costs. With this approach, developers can provide their dApp with access to the data they need without loading the blockchain with redundant information. At the same time, the model maintains high reliability and accuracy as the on-demand data is updated and verified before transmission. The Pull Model combines efficiency and control, providing access to data exactly when it is needed.
Push Model
This integration model is designed to continuously push data to the blockchain. Data is automatically sent to the network in real time or at predetermined intervals, making the model particularly suitable for protocols that require a constant stream of updates. The basic principle behind the Push Model is that data is “pushed” into the blockchain, where it becomes available for use by other applications or smart contracts. This provides highly relevant information, which is critical for protocols such as liquidation platforms, automated market makers (AMMs) or any other solutions that depend on continuous status monitoring. Unlike traditional oracles, which can limit developers in how they update data, Push Model offers greater flexibility. Developers determine how often and in what format to push data to the blockchain. This approach optimizes transaction costs by choosing the frequency of updates to match the needs of a particular application. In addition, this model provides complete transparency and reliability, as data immediately becomes part of an immutable blockchain. This ensures that users and protocols are always working with up-to-date and reliable information.
Model X
Model X is designed to provide high security and data protection against front-running attacks. This model adopts a deferred data processing approach to minimize the risks of manipulation and information leakage during transmission.
The key feature of the model is two-stage data processing:
- The first stage is data preparation: in this stage, information is collected and pre-processed, but its transmission is not performed immediately. This delayed approach prevents attackers from exploiting the data before it becomes publicly available.
- The second stage is secure delivery: data is sent to recipients at a predetermined time or after the necessary conditions are met. This ensures that transmission is secure and orderly, ensuring that data is not intercepted or used to gain an unfair advantage.
Model X is ideal for complex financial protocols, such as open-ended contracts or derivatives, where data accuracy and confidentiality are key. For example, when calculating a price index or updating margin requirements, it is important that data remains protected until it is actually applied.
4) The last and most important step
We’ve covered the three main components of RedStone’s Modular Design, and at the end all we have to do is figure out how to connect all three of these components to make this design or solution, whatever you want to call it, work.
In short, every modular system depends on connectors for smooth operation, and RedStone’s infrastructure is no exception. For example, the push, pull, and X models rely heavily on these connections for data flow.
One of the key elements of RedStone’s architecture is its EVM connector, which provides easy integration with any EVM (Ethereum Virtual Machine) compatible blockchain or dApp. This connection allows RedStone to easily interoperate with a wide range of decentralized applications and blockchain networks, making the system flexible and available for use in a variety of EVM-compatible ecosystems. In addition, RedStone supports other connectors, such as for the TON (The Open Network) ecosystem, which extends connectivity and integration into various blockchain frameworks. This allows RedStone to work not only with Ethereum and its derivatives, but also with other popular blockchains, further increasing its versatility. This approach makes RedStone an excellent choice for partnering with solutions such as Rollup-as-a-Service and Eigenlayer AVS. For Rollup-as-a-Service vendors, this means the ability to integrate with RedStone to improve scalability and data management in rollup solutions. For Eigenlayer AVS (Advanced Virtual Services) users, it gives flexibility to manage and validate data across different layers of the infrastructure.
Overall, support for different connectors and ecosystems makes RedStone a convenient and interoperable solution for multiple blockchain platforms, ensuring a high degree of integration and compatibility across different network structures.
Useful links
