3. Oracle Integration

Introduction

Scrypto components execute deterministically on the 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 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, 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 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 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 on Radix

RedStone is an example of a pull oracle that has integrated with Radix. Its price feeds are delivered as signed payloads that Scrypto components verify on-chain, treating the data as a first-class resource within the asset-oriented model.

External Links

• Scrypto Oracles Challenge — Radix Blog
• RedStone on Radix — RedStone Blog
• Will Radix Offer Decentralized Data Storage? — Radix Blog