--- title: "8. Oracle Integration" url: "https://radix.wiki/developers/scrypto/08-oracle-integration" version: "2.2.1" updated: 2026-07-29 last_verified: 2026-07-27 license: CC-BY-4.0 license_url: "https://creativecommons.org/licenses/by/4.0/" --- # 8. Oracle Integration | | | | --- | --- | | Challenge | [Scrypto Oracles Challenge](https://radixdlt.medium.com/scrypto-oracles-challenge-is-live-the-radix-blog-radix-dlt-6b958c4d9948) | | Example Provider | [RedStone on Radix](https://blog.redstone.finance/2025/06/12/redstone-brings-secure-gas-efficient-oracle-solutions-to-radix-defi-ecosystem/) | ## Introduction [Scrypto](/developers/scrypto/01-fundamentals) components execute deterministically on the [Radix Engine](/contents/tech/core-protocols/radix-engine) and can only access data already present on the ledger – they cannot make HTTP calls or read external APIs. When a dApp needs external data (asset prices, exchange rates, weather data, random numbers), it requires an **oracle**: a service that bridges off-chain information to on-ledger state. Oracle design is one of the most challenging aspects of decentralised application development. This article covers the two main oracle patterns on Radix, their trade-offs, and how to integrate existing oracle providers. ## Push Oracles A push oracle is an off-chain service that periodically submits transactions to update on-ledger price data. A [Scrypto](/developers/scrypto/01-fundamentals) component stores the latest values and exposes a read method that other components call. ### Architecture 1. An off-chain relayer monitors data sources (exchange APIs, aggregator feeds). 2. The relayer signs and submits a transaction calling `update_price(asset, price, timestamp)` on the oracle component. 3. The oracle component, protected by an [admin badge](/developers/scrypto/03-authorization-and-badges), stores the update in an on-ledger vault or key-value store. 4. Consumer components call `get_price(asset)` to read the latest value. ### Trade-offs - **Pros**: Simple consumer integration, predictable data freshness, works with any data type. - **Cons**: Relayer must pay transaction fees for every update, data staleness between updates, single-point-of-failure if the relayer goes offline. ### Mitigations Include a `timestamp` field in each price update and check staleness in consumer logic: reject prices older than a threshold (e.g. 5 minutes). Use multiple independent relayers with a median/aggregation mechanism to reduce trust assumptions. ## Pull Oracles A pull oracle delivers data _within the consumer's transaction_ rather than pre-posting it on-ledger. The oracle provider signs the data off-chain, and the consumer's [transaction manifest](https://docs.radixdlt.com/docs/learning-to-create-and-use-transaction-manifests) includes both the signed data payload and a verification call to the oracle contract. ### Architecture 1. The consumer's frontend fetches a signed price attestation from the oracle provider's API. 2. The frontend constructs a [transaction manifest](/contents/tech/core-protocols/transaction-manifests) that first calls the oracle component's `verify_and_store(signed_data)` method, then calls the consumer component's business logic. 3. The oracle component verifies the provider's signature and exposes the data for the remainder of the transaction. ### Trade-offs - **Pros**: Data is always fresh (fetched at transaction time), no relayer infrastructure needed, consumer pays the gas. - **Cons**: More complex frontend integration, requires the oracle provider to run a signing API, consumer must handle the multi-step manifest. ### [RedStone](https://redstone.finance) on Radix [RedStone](https://blog.redstone.finance/2025/06/12/redstone-brings-secure-gas-efficient-oracle-solutions-to-radix-defi-ecosystem/) is an example of a pull oracle that has integrated with Radix. Its price feeds are delivered as signed payloads that [Scrypto](/developers/scrypto/01-fundamentals) components verify on-chain, treating the data as a first-class resource within the [asset-oriented](/contents/tech/core-concepts/asset-oriented-programming) model. ### [Supra](https://www.prnewswire.com/news-releases/supraoracles-integrates-with-radix-the-full-stack-layer-1-smart-contract-platform-302009059.html) on Radix [Supra](https://www.prnewswire.com/news-releases/supraoracles-integrates-with-radix-the-full-stack-layer-1-smart-contract-platform-302009059.html) is a second oracle provider on Radix, offering both **push** and **pull** price feeds for 100+ of the most-traded crypto asset pairs, plus decentralised randomness through a [verifiable random function](https://en.wikipedia.org/wiki/Verifiable_random_function) (VRF). The VRF is useful for on-ledger gaming, lotteries, and fair NFT distribution, where a manipulable random source would be exploitable. ## Next Steps - [Transaction Manifest Language](/developers/transactions/01-manifest-language) – drive your components from the outside, the way users actually will - [Permissioned and Regulated Assets](/developers/scrypto/09-permissioned-and-regulated-assets) – withdraw and deposit rules, freeze, recall, and the account-side deposit controls ## External Links - [Scrypto Oracles Challenge – Radix Blog](https://radixdlt.medium.com/scrypto-oracles-challenge-is-live-the-radix-blog-radix-dlt-6b958c4d9948) - [RedStone on Radix – RedStone Blog](https://blog.redstone.finance/2025/06/12/redstone-brings-secure-gas-efficient-oracle-solutions-to-radix-defi-ecosystem/) - [SupraOracles integrates with Radix – PRNewswire](https://www.prnewswire.com/news-releases/supraoracles-integrates-with-radix-the-full-stack-layer-1-smart-contract-platform-302009059.html) - [Will Radix Offer Decentralized Data Storage? – Radix Blog](https://www.radixdlt.com/blog/will-radix-offer-decentralized-data-storage)