Most chains need an oracle because they cannot natively read another chain or a web API. That is why networks like Chainlink publish price feeds on-chain and why Pyth pushes low-latency prices that contracts then consume. 

Pelagos is built around a different assumption: the execution layer already has visibility into the external chains you connect. If the data is already on a chain Pelagos ingests, you do not need a second network to repeat it as you read the source directly, inside the same deterministic block. That is the core design difference.

Chainlink: big, battle-tested network that aggregates off-chain and multi-exchange data and writes it to on-chain reference contracts. Most chains rely on this because they can’t fetch/aggregate themselves.

Pyth: low-latency, publisher-heavy model that pushes prices and broadcasts them to many chains. Good for fast DeFi dApps / use cases that need continuous updates. 

RedStone: modular oracle that can do push or pull, lives on numerous chains, and is very good at adding long-tail assets (LSTs, LRTs, RWAs) quickly. They explicitly state that they secure price feeds for any asset, on any chain and support on-demand delivery.

API3 / Airnode: the API provider itself can publish on-chain, removing middlemen

Chainlink CCIP: shows oracles also stepped into cross-chain messaging because chains are siloed.

Current oracles exist to make data available on chains that cannot see it, and distribute the same data to many chains.

Pelagos already ingests the state/events of the chains it connects to. If a price/feed/state variable is on Ethereum, on an L2, or on an oracle’s own chain that Pelagos tracks, an appchain can read it directly in-transaction, aggregate it with other sources, and settle atomically on Pelagos. That removes the mandatory oracle hop for on-chain data. The latency here is 400-500 ms for cross-reads, which is in the same window in which Pyth advertises its update cadence, so one is not losing timeliness.

**Direct cross-chain read (oracle-less path).** Appchain asks Pelagos for a value that already exists on another chain (for example, a Chainlink reference contract on Ethereum, or a pool balance on an L2). Pelagos has that state; the appchain uses it in the same block. No external oracle call is needed.

Read existing on-chain oracle feeds. Chainlink, Pyth, and API3 all end up writing on-chain. Pelagos can read those chains once and make the data available to every Pelagos appchain. This keeps the oracle’s infrastructure intact but removes the need for 10+ separate deployments. 

Plug the oracle’s own chain. Pyth maintains its own low-latency network and then broadcasts to other chains. Pelagos can treat that network as just another client chain: ingest it once, expose it everywhere. 

External request/response. For oracles that operate on a pull model, an appchain emits a request, the oracle responds, and Pelagos turns the response into a transaction. You keep compatibility without changing the core.

Oracle-as-Appchain on Pelagos. Following the API3 “first-party” idea, an oracle provider can run its own Pelagos appchain, have publishers post data there, and every other appchain simply cross-reads. Pelagos becomes the distribution plane and the oracle logic stays with the data owner.

Deterministic HTTP fetch. Pelagos can add a controlled external-fetch transaction: validators fetch a URL, apply a deterministic aggregation function, and commit the result. This is the proper way to bring in data that never touches a blockchain, but it needs security and compliance hardening first.

If you need a value that already lives on a chain you index, Pelagos reads the source; no separate oracle network is required. That includes reading Chainlink reference contracts, Pyth prices that are already bridged to an EVM, and on-chain pool/state data. 

For real-world, off-chain, private, or paywalled data you still need publishers/oracle operators.

For example, Pelagos can consume public CEX market data (order books, trades) from Binance, Coinbase, and Kraken, combine it with on-chain DEX pool, compute a VWAP/TWAP with outlier controls, and then execute trades or liquidations atomically in the same block without standing up a separate oracle deployment. Practically, you either run a small oracle-as-appchain that pulls those feeds and publishes signed ticks, or use Pelagos’ deterministic HTTP-fetch pattern so validators fetch the same endpoints in parallel and aggregate deterministically. Because Chainlink, Pyth, and RedStone already publish data on-chain or via their own networks, Pelagos can also cross-read those sources once and fan them out to every appchain, avoiding per-appchain redeployments.

For broader finance, Pelagos can ingest licensed FX/equity/macro APIs, publish signed values to an oracle-as-appchain, and let RWA or risk engines act with the same atomicity guarantees. On top, you can publish short-horizon on-chain price predictions by running a deterministic model that consumes these features plus live CEX/DEX signals and writes each block. For data that already lives on a chain or an oracle network, Pelagos replaces the mandatory oracle hop with direct cross-reads. For off-chain data, Pelagos standardizes ingestion and distribution via first-party publishers

Chainlink CCIP exists because most chains cannot safely move messages/tokens across domains; the oracle network becomes the trusted courier. Pelagos’ premise is that cross-chain execution and state access are native, so the oracle can go back to being just a data source.

If the price is on a chain, Pelagos reads the chain. It doesn’t trust a third party to repeat. Delivery happens via the same consensus/sequencing that runs the appchain and there is no “oracle went down so DeFi died.” For off-chain stuff, we force multiple validators to fetch and aggregate with the same idea as first-party oracles but baked into Pelagos.

Pelagos makes the need to deploy an oracle to every chain / app pattern mostly obsolete for onchain data. Chainlink, Pyth, RedStone, and API3 all end up putting data somewhere onchain or in a network that can be read; Pelagos’ whole design is already ingesting those chains/networks and can execute atomically, so for prices and state that already exist on Ethereum, L2s, or an oracle’s own chain, Pelagos can just cross-read and use it in the same block. That shrinks oracles back to where they actually add value: publishing data that does not exist on any chain (RWAs, FX from banks, private APIs), or running their own economics. For that leftover part, Pelagos can host the oracle as an appchain and fan it out to every other appchain, giving the oracle distribution without 20 redeployments. So oracles don’t disappear, but they stop being mandatory middleware and Pelagos turns them into optional, standardized data sources in a multichain execution layer.

If you're a developer interested in building on Pelagos or a potential validator, we'd love to hear from you.

Check our partnership deck or fill out our BD form

• Visit our Website

• Join our Discord

• Follow us on X

• Email: contact@pelagos.network

Most chains need an oracle because they cannot natively read another chain or a web API. That is why networks like Chainlink publish price feeds on-chain and why Pyth pushes low-latency prices that contracts then consume. 

Pelagos is built around a different assumption: the execution layer already has visibility into the external chains you connect. If the data is already on a chain Pelagos ingests, you do not need a second network to repeat it as you read the source directly, inside the same deterministic block. That is the core design difference.

Chainlink: big, battle-tested network that aggregates off-chain and multi-exchange data and writes it to on-chain reference contracts. Most chains rely on this because they can’t fetch/aggregate themselves.

Pyth: low-latency, publisher-heavy model that pushes prices and broadcasts them to many chains. Good for fast DeFi dApps / use cases that need continuous updates. 

RedStone: modular oracle that can do push or pull, lives on numerous chains, and is very good at adding long-tail assets (LSTs, LRTs, RWAs) quickly. They explicitly state that they secure price feeds for any asset, on any chain and support on-demand delivery.

API3 / Airnode: the API provider itself can publish on-chain, removing middlemen

Chainlink CCIP: shows oracles also stepped into cross-chain messaging because chains are siloed.

Current oracles exist to make data available on chains that cannot see it, and distribute the same data to many chains.

Pelagos already ingests the state/events of the chains it connects to. If a price/feed/state variable is on Ethereum, on an L2, or on an oracle’s own chain that Pelagos tracks, an appchain can read it directly in-transaction, aggregate it with other sources, and settle atomically on Pelagos. That removes the mandatory oracle hop for on-chain data. The latency here is 400-500 ms for cross-reads, which is in the same window in which Pyth advertises its update cadence, so one is not losing timeliness.

**Direct cross-chain read (oracle-less path).** Appchain asks Pelagos for a value that already exists on another chain (for example, a Chainlink reference contract on Ethereum, or a pool balance on an L2). Pelagos has that state; the appchain uses it in the same block. No external oracle call is needed.

Read existing on-chain oracle feeds. Chainlink, Pyth, and API3 all end up writing on-chain. Pelagos can read those chains once and make the data available to every Pelagos appchain. This keeps the oracle’s infrastructure intact but removes the need for 10+ separate deployments. 

Plug the oracle’s own chain. Pyth maintains its own low-latency network and then broadcasts to other chains. Pelagos can treat that network as just another client chain: ingest it once, expose it everywhere. 

External request/response. For oracles that operate on a pull model, an appchain emits a request, the oracle responds, and Pelagos turns the response into a transaction. You keep compatibility without changing the core.

Oracle-as-Appchain on Pelagos. Following the API3 “first-party” idea, an oracle provider can run its own Pelagos appchain, have publishers post data there, and every other appchain simply cross-reads. Pelagos becomes the distribution plane and the oracle logic stays with the data owner.

Deterministic HTTP fetch. Pelagos can add a controlled external-fetch transaction: validators fetch a URL, apply a deterministic aggregation function, and commit the result. This is the proper way to bring in data that never touches a blockchain, but it needs security and compliance hardening first.

If you need a value that already lives on a chain you index, Pelagos reads the source; no separate oracle network is required. That includes reading Chainlink reference contracts, Pyth prices that are already bridged to an EVM, and on-chain pool/state data. 

For real-world, off-chain, private, or paywalled data you still need publishers/oracle operators.

For example, Pelagos can consume public CEX market data (order books, trades) from Binance, Coinbase, and Kraken, combine it with on-chain DEX pool, compute a VWAP/TWAP with outlier controls, and then execute trades or liquidations atomically in the same block without standing up a separate oracle deployment. Practically, you either run a small oracle-as-appchain that pulls those feeds and publishes signed ticks, or use Pelagos’ deterministic HTTP-fetch pattern so validators fetch the same endpoints in parallel and aggregate deterministically. Because Chainlink, Pyth, and RedStone already publish data on-chain or via their own networks, Pelagos can also cross-read those sources once and fan them out to every appchain, avoiding per-appchain redeployments.

For broader finance, Pelagos can ingest licensed FX/equity/macro APIs, publish signed values to an oracle-as-appchain, and let RWA or risk engines act with the same atomicity guarantees. On top, you can publish short-horizon on-chain price predictions by running a deterministic model that consumes these features plus live CEX/DEX signals and writes each block. For data that already lives on a chain or an oracle network, Pelagos replaces the mandatory oracle hop with direct cross-reads. For off-chain data, Pelagos standardizes ingestion and distribution via first-party publishers

Chainlink CCIP exists because most chains cannot safely move messages/tokens across domains; the oracle network becomes the trusted courier. Pelagos’ premise is that cross-chain execution and state access are native, so the oracle can go back to being just a data source.

If the price is on a chain, Pelagos reads the chain. It doesn’t trust a third party to repeat. Delivery happens via the same consensus/sequencing that runs the appchain and there is no “oracle went down so DeFi died.” For off-chain stuff, we force multiple validators to fetch and aggregate with the same idea as first-party oracles but baked into Pelagos.

Pelagos makes the need to deploy an oracle to every chain / app pattern mostly obsolete for onchain data. Chainlink, Pyth, RedStone, and API3 all end up putting data somewhere onchain or in a network that can be read; Pelagos’ whole design is already ingesting those chains/networks and can execute atomically, so for prices and state that already exist on Ethereum, L2s, or an oracle’s own chain, Pelagos can just cross-read and use it in the same block. That shrinks oracles back to where they actually add value: publishing data that does not exist on any chain (RWAs, FX from banks, private APIs), or running their own economics. For that leftover part, Pelagos can host the oracle as an appchain and fan it out to every other appchain, giving the oracle distribution without 20 redeployments. So oracles don’t disappear, but they stop being mandatory middleware and Pelagos turns them into optional, standardized data sources in a multichain execution layer.

If you're a developer interested in building on Pelagos or a potential validator, we'd love to hear from you.

Check our partnership deck or fill out our BD form

• Visit our Website

• Join our Discord

• Follow us on X

• Email: contact@pelagos.network