A lighthouse does not chase ships. It stands still and keeps shining. A messenger does the opposite. They move quickly and only speak when someone asks. In blockchain systems, data delivery often faces the same choice. Do you keep a public signal always available, like a lighthouse? Or do you fetch the truth only at the moment it is needed, like a messenger?
APRO describes two core oracle delivery models that reflect this choice: Data Push and Data Pull. Both aim to bring off-chain information on-chain in a usable form. “Off-chain” simply means the information lives outside the blockchain, such as exchange prices, liquidity metrics, or other market signals. A “smart contract” is a program that runs on the blockchain and executes rules exactly as written. The problem is that a smart contract cannot directly read the outside world. It can only act on what is provided to it in a form it can verify. An oracle exists to carry selected external facts into the contract’s world.
APRO’s larger idea is a familiar one in oracle design: do most of the heavy work off-chain, then deliver results on-chain with a verification method. Off-chain systems can collect, aggregate, and compute more efficiently. On-chain systems can enforce verification and record results in a way other contracts can reuse. Push and pull are two different ways to time that delivery.
In the push model, the oracle network publishes updates to the blockchain proactively. APRO describes this as node operators aggregating data and pushing new values when certain conditions are met. Those conditions are usually based on time and change. Time-based updates are often described with a “heartbeat,” which is simply an interval that ensures the on-chain value does not go stale for too long. Change-based updates are often tied to a threshold, meaning the oracle only updates when the price moves enough to matter. The result is a feed that lives on-chain and is refreshed on a schedule or when the market shifts.
The push model is easiest to understand from the perspective of shared infrastructure. Once a value is published on-chain, many applications can read it. They do not have to coordinate their own data requests. They do not need to be online at the same moment. They can rely on a public reference point that is already present in the chain’s state. This is why push feeds often become a kind of common language in an ecosystem. They make composability simpler. Composability is the ability for different protocols to build on each other, using the same on-chain building blocks.
But push feeds have a cost that is not philosophical at all. Every update is an on-chain transaction. On many networks, that means fees. It also means that “more freshness” can translate into “more cost.” If you publish too often, you spend more. If you publish too rarely, you risk staleness. So a push model is always a balancing act between timeliness and overhead.
In the pull model, APRO describes the opposite approach: data is retrieved when it is needed. Instead of writing frequent updates to the chain, the oracle provides a signed report that an application can submit for verification at the moment it wants to act. The report can include a price and a timestamp, along with cryptographic signatures from participating nodes. A digital signature is a cryptographic stamp that proves a message was approved by a specific key. Verification contracts can check those signatures and accept the report if it meets the expected rules. Once verified, the data can be used immediately, and it can also be stored for later reference depending on the design.
Pull changes the meaning of “freshness.” In a push model, freshness depends on how recently the feed was updated. In a pull model, freshness depends on how recently the report was produced and whether the application fetches it at the moment of execution. This can be especially useful for actions that are sensitive to the exact moment, like trade execution or liquidation checks. It can also be useful when a protocol does not need constant updates and would rather pay only when it actually uses the data.
Pull also changes the cost profile. Instead of paying continuously to keep a public feed updated, the system pays on demand. That can reduce wasted updates in periods of low usage. It can also help developers align costs with value: the protocol spends fees when it is about to perform an action that benefits from the verified input.
So which model fits which use case? The answer is not “push is better” or “pull is better.” It is closer to a question of posture.
Push tends to fit best when an ecosystem benefits from a shared, continuously available reference value. Lending and borrowing protocols often fall into this category, because many users and many positions depend on a common price reference. A public on-chain feed can also simplify integrations for smaller applications that do not want to run additional infrastructure to fetch reports. Push can be a better fit when many contracts need the same data and you want the chain itself to carry it as a public primitive.
Pull tends to fit best when the value you need is tied to a specific action at a specific time. Trading systems, settlement logic, and strategies that only need the “latest at execution” can benefit from pull, because it avoids relying on a feed that might be a few minutes old during fast moves. Pull can also be attractive when transaction costs make frequent push updates expensive, or when the protocol’s usage pattern is bursty rather than constant.
There is also a second dimension that matters: how much you want to rely on a feed being present versus how much you can tolerate doing extra work at execution. Push makes reading easy. The value is already on-chain. Pull makes execution more deliberate. You fetch, submit, and verify, then act. That adds steps, but it can also add precision, because you can couple “update” and “use” in the same flow. In many designs, that coupling is the point. It reduces the chance that a contract acts on an older value simply because the market moved between the last update and the moment of execution.
Multi-chain reality makes these choices sharper. Different chains have different fee environments and different throughput. A push model that is economical on one chain can be expensive on another. A pull model that is smooth on one chain can be harder on another if developer tooling is less mature. The existence of both models is one way APRO describes adapting to different ecosystems without forcing every application into the same timing philosophy.
No matter which model a developer chooses, the deeper issue remains: oracles operate at the border between certainty and uncertainty. Markets can be manipulated. Liquidity can thin out. Sources can disagree. And even perfect data can be used badly if the application logic is fragile. That is why oracle integration is not only “plug in a feed.” It is also about risk design. Developers commonly add safeguards such as sanity checks, maximum deviation limits, fallback logic, and circuit breakers. A circuit breaker is simply a rule that pauses or limits actions when something abnormal happens, like a sudden outlier move.
Seen this way, APRO’s push and pull models are not competing products. They are two ways of respecting the same truth: blockchains need external facts, but they also need control over how those facts enter the system. Push is the steady public signal. Pull is the just-in-time verified message. The right fit depends on whether your application lives like a lighthouse, serving many readers continuously, or like a messenger, speaking precisely when a decision must be made.
