Push vs Pull – has anyone heard of this concept before? Possibly in relation to art and design? What about how content is delivered in the media? I’m not artistic, so the first example doesn’t resonate with me, but Push vs. Pull as a content delivery strategy does. A great example? Fuckin commercials. Yeah, that’s right - commercials. Right now, I’m watching the greatest Star Wars movie ever made (The Empire Strikes Back), and Disney just cut from the pivotal moment of “No, I am your father” to a damn commercial. I know ad revenue is necessary for these streaming giants, but how dare they ruin Vader’s efforts to rule the galaxy with his son!
As I recover from ads disrupting my Star Wars fandom on a Monday morning, I realize the commercial break illustrates a broader principle that extends well beyond media. Essentially, Push vs Pull represents two fundamental approaches for delivering information, and those same strategies can be applied to decentralized oracle infrastructure. Push systems broadcast market data according to predetermined criteria (i.e., heartbeats, % price deviations) while pull systems publish it only on-demand.1 Although the differences may seem trivial, I assure you they can severely impact price feed reliability, cost, scalability, and the applications that support them. And as DeFi transitions from lending/borrowing markets to derivatives and asset tokenization, the need for reliable price discovery is more important than ever.
Background1,2,3
“Oracles are not the data source itself but rather a layer that retrieves, verifies, and relays external data to smart contracts.”
Considering smart contracts operate in isolated environments and can’t access external data or APIs, decentralized oracle networks (DONs) are necessary for sourcing, validating, and securely delivering price data on-chain. Historically, the infrastructure developed to solve this “oracle problem” relied on Push architecture, with networks actively providing price updates on-chain. Recently, however, the approach to delivering data has shifted from this traditional model to the newer, on-demand Pull architecture. To understand the fundamental differences between the two, let’s take a closer look at how they source, validate, and handle the transaction costs of price data delivery.
Push (Broadcast) Architecture1,2,4,5
Use Cases
· Collateralized Lending Protocols
How it Works
As I alluded to earlier, Push architecture operates on an active broadcast system. In this system, a decentralized network of oracle nodes continuously monitors external sources for the price of a particular asset (market makers, global exchanges, trading firms, or even central exchange APIs and decentralized liquidity pools, etc). When the nodes reach a consensus on the price, the network initiates a transaction and pushes the update to a designated on-chain smart contract (forming a price feed). The mechanism triggering these updates is governed by two external parameters: heartbeat timers and % price deviation thresholds-
· Heartbeat timer: strict time-based interval. Regardless of market volatility, once the time limit expires, price updates occur to prevent overly stale feeds
· % price deviation threshold: % change in the asset’s price (ex: 0.5%) during times of volatility pushes price updates on-chain
In this architecture, because oracle operators initiate the price updates, they are responsible for paying the transaction costs (gas). Application smart contracts then query the oracle smart contract and retrieve the price feed updates.
Advantages/Limitations
The primary advantage of a Push model is its predictable cadence and simplicity for developers. Because price data is continuously pushed to the blockchain, it creates an on-chain record that smart contracts can read immediately.
Unfortunately, that is where the advantages of Push architecture end. Push models face significant challenges with their price data concerning reliability, cost, speed, and scalability. Because the oracle operator is responsible for continuously updating feeds regardless of user demand, maintaining thousands of diverse, low-volume assets is not economically viable. Furthermore, relying on fixed “heartbeats” or % price deviations for updates makes Push models unsuitable for high-frequency trading platforms requiring real-time price data. And if that’s not enough, Push models also face significant reliability risks during periods of network congestion - if gas fees suddenly spike and the oracle network fails to push a price update, on-chain data becomes stale, inadvertently exposing lending protocols to bad debt and unjustified liquidations.
Pull (On-Demand) Architecture1,2,4,5,6
Use Cases
· Perpetual futures and Derivative trading platforms
· High Frequency Trading and DEX Aggregators
· Prediction Markets
How it Works
Pull models, in contrast to Push architecture, take an “on-demand” approach for price feed updates. Nodes in Pull oracle systems continuously source and aggregate price data at extremely high frequencies, even as fast as 1-200ms. Instead of broadcasting it directly to the blockchain, they generate a constant stream of high-frequency reports off-chain until a user or smart contract initiates a transaction that requires the price data for execution. Remember, this is an important distinction between Push and Pull oracle systems - data is only brought on-chain when a user or smart contract specifically requests it**.**
Let’s now take a closer look at Pyth Network as an example of how Pull architecture works in real-time. First, data providers publish price data for a particular asset directly on Pythnet, an application-specific blockchain. Next, Pythnet aggregates that data, creating a price feed with a respective confidence interval. Wormhole attests it (via guardians) and sends the price feed as a verified action approval (VAA) to an off-chain service, Hermes. Instead of forcing the price feed onto blockchains and incurring high gas fees, Hermes stores it until a request is made to complete a transaction (e.g trade). In short, publishers provide the price data, Pyth aggregates it, Wormhole verifies/moves it, and Hermes stores it until a user brings it on-chain (exactly when they need it).
Advantages/Limitations
Pull oracle models, despite their integration complexity, outperform Push-based systems across all critical metrics - reliability, gas efficiency, update frequency, latency, and scalability. By ensuring price data is only brought on-chain when a user requests it, the network avoids paying for redundant updates, enabling far broader asset coverage, more extensive blockchain support, and real-time price data to the end user. Additionally, the Pull model eliminates the risk of trading on stale data during periods of network congestion.
Industry Shift1,2,4,5
The transition toward Pull oracle infrastructure corresponds with the maturation of DeFi. As markets continue to expand beyond collateralized lending protocols into latency-sensitive applications (perpetual futures and prediction markets), the structural limitations of Push oracles have become even more apparent.
Closing Remarks7
On this May the Fourth (Be With You), it is worth remembering the fundamental differences between Push vs Pull systems, especially their reliability, scalability, speed, and cost-effectiveness of delivering price data. Although the landscape in oracle architecture continues to change (for instance, Pyth just passed PIP-100, sunsetting Pythnet), I think it’s safe to say that Pull systems are the preferred oracle architecture for most on-chain applications. In the future, I’m hoping to extend this conversation further by providing a comparative analysis of Push/Pull models for Pyth Network, Chainlink, and Redstone. In the meantime, to commemorate this awesome Star Wars day, I’ll leave you with the best 60sec in Star Wars Cinema. Come to think of it, the amount of Force pushing and pulling in the scene is almost too perfect for this topic…Enjoy!
References