Cover photo

Redstone's oracle model for your need.

RedStone's price feeds originate from a diverse array of over 50 providers, including both off-chain and on-chain sources, aggregators, and are meticulously processed and signed by independent nodes operated by data providers, ensuring data quality and reliability. These feeds are broadcasted on the Streamr network and open-source gateways, with flexibility for on-chain integration through dedicated relayers, bots, or end users. The data is cryptographically verified within the protocol to confirm its origin and timestamps, guaranteeing accuracy and integrity in the DeFi ecosystem. To make it more cost efficient and reliable, redstone has introduced 3 different oracle model specially crafted for your need. These are,

  1. Core Model (On-Demand Feed)

  2. Classic Model (Pushing Feed)

  3. Redstone X (No Front Running Feed)

CORE MODEL

The Core model operates on an on-demand fetching mechanism, where data is retrieved only when needed. This model is preferred for its efficiency and scalability. It's designed to accommodate protocols that are open to adopting a more dynamic and resource-efficient approach. RedStone's fundamental operational model involves the automatic appending of data to user transactions, representing its core and well-established approach that has undergone rigorous testing in production environments. This battle-tested model safeguards over $100 million in Total Value Locked (TVL) for various DeFi protocols across multiple mainnets. The reliability and effectiveness of this model are evidenced by the injection of price feeds into more than 50,000 transactions, showcasing its integral role in securing and enhancing the functionality of decentralized finance applications.

To integrate Redstone’s core model please head over to Redstone Core.

CLASSIC MODEL

While RedStone Core is particularly advantageous for scenarios where the codebase can be adapted to integrate the fetching model seamlessly, RedStone Classic, on the other hand, caters to protocols that adhere to a traditional design, pushing data on-chain. This approach might be preferable under certain circumstances:

  1. Existing Codebase: The Classic model permits the continuation of a more conventional configuration in cases where a protocol already has a well audited codebase and the team is hesitant to make any changes.

  2. Private Network or Low Gas Costs: Pushing data on-chain could be a practical and economical option if the protocol runs on a blockchain with low gas costs or a private network under consideration.

  3. Infrequent Price Updates: In situations where prices don't need to be updated very frequently, the overhead of an on-demand fetching model might be unnecessary.

post image

RedStone Classic's modular design is one of its main advantages. RedStone Classic gives users complete control over when and how price changes happen, in contrast to other Oracle systems that frequently set parameters for data updates. For protocols with particular requirements or preferences, this modularity offers a degree of customization and control that can be essential, providing flexibility that would not be found in other Oracle solutions.

All things considered, RedStone Classic offers a modular and configurable approach to on-chain data updates, whereas RedStone Core shines in efficiency and scalability through on-demand fetching. The particular needs and conditions of the protocol in issue ultimately determine which option—Core or Classic—to choose.

To integrate Redstone’s core model please head over to Redstone Classic.

REDSTONE X

RedStone X introduces a robust solution for extreme protection against front-running, a common issue in decentralized finance (DeFi). The model implements a Deferred Execution Pattern, a two-step transaction processing approach to mitigate front-running attempts effectively. These are,

  1. Initiating the Transaction with Intention: In the first step, a user initializes a transaction by recording on-chain their intention to interact with the protocol. For example, this could involve opening a perpetual position. Crucially, at this stage, the user doesn't have precise information about the transaction's context, such as the exact price at which the transaction will be executed. This intentional ambiguity prevents potential arbitrage opportunities that could arise from front-running the price delivery from Oracles.

  2. Pushing Price On-Chain: The second step involves pushing the price on-chain, typically occurring in the next block. Importantly, this step is separate from the initial transaction initiation, and anyone, including the user who initiated the transaction, can push the price. The integrity of the price is validated on-chain based on the protocol's predefined constraints. This validated price is then used to settle the transaction, ensuring the accuracy and fairness of the final execution.

post image

This deferred execution architecture, made famous by perpetual protocols such as GMX, offers a novel way to address the front-running problem. RedStone X opens the door for a new generation of extremely efficient DeFi projects by separating the start of a transaction from the disclosure of the pricing. These initiatives, which make use of the Deferred Execution Pattern, have proven resilient and profitable even during downturns in the market, demonstrating the usefulness of this strategy in promoting secure and equitable decentralized financial transactions. RedStone X's architecture supports efficient transaction processing while resolving important security issues in line with the DeFi industry's changing needs.

To integrate Redstone’s core model please head over to Redstone X.

Website: https://redstone.finance
Twitter: https://twitter.com/redstone_defi
Discord: https://discord.gg/redstonedefi
Docs: https://docs.redstone.finance/