RedStone

RedStone and API3 are the two major non-Chainlink oracle providers worth knowing about. Each has a different architectural approach to the same problem (getting reliable off-chain data into smart contracts), and the different approaches produce different tradeoffs. Knowing both exist — and how they differ from Chainlink — is useful context for evaluating which oracle infrastructure a given protocol uses and why.

RedStone's distinctive design is on-demand oracle data. Traditional oracles like Chainlink continuously update on-chain prices based on time intervals and deviation thresholds. This consumes gas continuously, regardless of whether the price is actually being used. RedStone takes a different approach: the oracle data lives off-chain on a decentralized data network, and the data is delivered to the smart contract only at the moment of query, signed by the oracle network's nodes. The signature is verified by the smart contract before the data is used.

The tradeoff RedStone makes is gas cost vs. flexibility. The on-demand model is cheaper for protocols that don't need continuous price updates (most lending protocols, most synthetic asset platforms, most prediction markets fall into this category). The model requires the user-initiated transaction to include the signed oracle data as a transaction input, which adds some complexity to the user experience and requires off-chain infrastructure to fetch and attach the signed data.

RedStone is meaningfully used in some protocols (Morpho Blue uses it for some assets, several Avalanche and Arbitrum-native protocols use it as a primary or backup oracle), but is not as broadly adopted as Chainlink or growing as fast as Pyth.

API3's distinctive design is the first-party data feed model. Traditional oracles like Chainlink use third-party node operators who independently fetch data from external APIs. API3 instead has the data providers themselves (typically the centralized exchanges or data vendors that originally produce the data) run the oracle nodes. The argument is that this reduces the trust layer — instead of trusting a node operator to faithfully fetch from a data provider, you're trusting the data provider directly to publish accurate data.

The tradeoff API3 makes is reduced redundancy in exchange for cleaner provenance. With third-party oracles, the failure mode is node operator corruption or compromise. With first-party oracles, the failure mode is data provider corruption or compromise. The former is more diverse (many nodes); the latter is more authoritative (the original source). API3's argument is that for many use cases, the first-party model is the cleaner trust model. The argument is reasonable; whether it wins broader adoption depends on whether the market values it enough to switch.

API3 also operates a service called Airnode that allows traditional API providers to natively serve oracle requests without intermediation. The model is technically interesting but has had limited adoption beyond a relatively small set of integrations.

The broader oracle landscape includes:

Chainlink. Dominant by deployment, most-conservative architecture (decentralized third-party node networks), most-trusted by institutional protocols.

Pyth Network. Fastest-growing, particularly on Solana and Solana-adjacent chains. First-party publisher model (exchanges submit prices directly). Sub-second update frequency.

RedStone. On-demand data delivery model. Gas-efficient. Meaningful presence on Avalanche, Arbitrum, and several other chains.

API3. First-party data feed model. Modest adoption.

Several smaller players exist (Tellor, UMA's optimistic oracles, others) with niche use cases.

Skim the RedStone and API3 documentation if you want to understand the alternative architectures. Neither is as dominant as Chainlink or growing as fast as Pyth, but both are legitimate alternatives in specific contexts. Worth knowing they exist.