RedStone

• Name: RedStone
• URL: https://www.redstone.finance/
• Category: oracle / signed-payload delivery middleware / pull-feed packaging stack
• Tags: ethereum-ecosystem
• Summary: RedStone is a packaging-first oracle stack. The useful cut is not another feed network; it is that signed payloads ride with transactions or RedStone-shaped delivery infrastructure, so the real product is packaging format, signer policy, and cache / relay defaults rather than a canonical feed contract.
• What it does:
  • Provides cross-chain oracle/data-feed infrastructure for dApps, smart contracts, and blockchain networks
  • Uses a pull-model integration pattern in which signed data packages are appended to user transactions and verified onchain, aiming to reduce storage and gas overhead
  • Supports specialized feeds beyond standard crypto spot prices, including categories like LRT, BTCFi, and RWA-related assets
  • Ships developer tooling and infrastructure components through a public monorepo, including oracle nodes, cache services, EVM connectors, protocol packages, SDKs, and related contracts
  • Publishes public security-audit references covering multiple components, including oracle contracts, connectors, token/vesting components, and newer connectors/aggregators
• Key claims:
  • Official docs describe RedStone as a leading blockchain data provider trusted by 100+ dApps and securing billions of dollars of value; those are vendor claims, not neutral facts.
  • The pull-model docs are the real reason to keep the note: RedStone pushes signed payloads into user transactions or nearby delivery middleware instead of treating onchain storage as the default oracle surface.
  • That design makes freshness timing and delivery policy more application-shaped than in always-pushed feed systems. The practical question shifts from who updates the contract? to who packages the payload, where does the app fetch it, and what happens when cache or relay paths wobble?
  • The GitHub monorepo is useful because it shows the stack is broader than a verifier contract: nodes, cache services, connectors, SDKs, and related contracts all matter to the real control surface.
  • The audits page is a positive diligence signal, but it does not change the main analytical point: RedStone is a delivery-and-packaging stack first.
• Whitepaper: No classic whitepaper or litepaper was found during this pass. The strongest primary materials were RedStone’s official docs, GitHub monorepo README, and public audit index; see ../whitepapers/redstone-primary-sources-2026-04-23.md.
• Sources:
  • https://www.redstone.finance/
  • https://docs.redstone.finance/docs/introduction
  • https://docs.redstone.finance/docs/dapps/redstone-pull/
  • https://docs.redstone.finance/docs/security/audits/
  • https://github.com/redstone-finance/redstone-oracles-monorepo

Internal linkages

• Best upward reads: chainlink-data-streams and pyth-pro. Those keep the note on the strongest low-latency signed-payload and pull-delivery contrasts.

Control surface

• RedStone is mainly a packaging and delivery architecture: signer policy, payload format, cache and relay behavior, and application-side retrieval timing matter more than any grand oracle network framing.
• The practical split is simple: contracts verify bundled payloads, while signer operation, payload packaging, caching, and delivery defaults stay with RedStone-run or RedStone-shaped offchain infrastructure.
• Keep the note on that split. The product menu is not the point.

Governance / control risk

• The key questions are who controls signer sets and asset coverage, how cache / delivery infrastructure fails over, how much downstream protocols rely on RedStone-managed offchain services during stressed markets, and whether pull-style integration makes freshness policy easier to ignore until a crisis.

• Useful because those choke points are plain. Still an oracle-delivery note, not a category-defining network anchor.

• Last reviewed: 2026-06-04 UTC