RedStone red

RedStone is a modular oracle and data-delivery ecosystem for decentralized applications and smart contracts. It supplies frequently updated data feeds, including crypto prices and specialized instruments such as liquid restaking tokens, Bitcoin DeFi derivatives, and real-world assets. The project is designed for both EVM and non-EVM environments and describes support for more than 70 blockchain networks.

Its central design choice is to separate data collection from data delivery. Rather than requiring a new oracle-node deployment for every destination chain, the same feed infrastructure can be delivered to multiple chains through chain-specific connectors. RedStone’s public monorepo contains the reference oracle node, cache service, EVM connector, protocol and SDK packages, plus Ethereum contracts.

For EVM use, RedStone attaches signed data to a user transaction and removes it after execution instead of persisting every value in expensive EVM storage. This is intended to reduce gas costs while retaining on-chain verification. Feed processing uses source checks, anomaly detection, market-depth and cross-source variance checks, customized aggregation, and agreement among multiple independent operators.

RedStone publishes external audit reports for core oracle and adapter components, connectors, token/vesting contracts, and aggregation infrastructure. Builders should still evaluate the exact feed, connector, deployment and freshness guarantees relevant to their application rather than treating an oracle integration as risk-free.

Smart contracts cannot natively access current off-chain prices, rates, indices or other external information, yet lending, derivatives, stablecoins, RWA products and many other dApps depend on that information. Oracle systems must therefore bridge external data into deterministic contract execution while addressing freshness, manipulation, outages, chain coverage and gas cost.

Traditional designs that write every update into each destination chain’s storage can be expensive and operationally difficult to scale. RedStone addresses this by separating data production from delivery and by using transaction-attached data for its EVM model, allowing a feed to be consumed without maintaining a permanent storage slot for every update. The remaining risks include source quality, signer/operator security, aggregation assumptions, connector correctness and stale-data handling by the consuming protocol.

Data providers and RedStone infrastructure collect values for configured feeds. The system applies feed-specific validation and aggregation, including anomaly checks, market-depth analysis and comparisons across sources; specialized assets can use customized parameters rather than a one-size-fits-all price rule. Multiple independent operators participate in consensus/validation before a value is treated as usable.

For EVM integrations, the selected signed payload is carried with the user’s transaction. RedStone connector logic verifies the payload, feed identifier, timestamp/freshness and signatures, then exposes the validated value to the consuming contract during execution. Because the payload is transaction data rather than a permanently stored value, the design avoids recurring EVM storage writes for each update.

The modular delivery layer lets the same collection and validation stack serve many destination networks through connectors. The monorepo provides reusable protocol, SDK and connector packages, while cache services and oracle nodes support data distribution. Integrators must configure supported feeds and chains and implement application-level checks for freshness, bounds and failure behavior.