Oracles bring off-chain data (such as cryptocurrency prices, weather, etc.) onto the chain. This may seem simple, but in reality, there are two completely different approaches: one is active data pushing, and the other is contract on-demand pulling.
**Push-Oracles — Broadcast Mode**
This is the most popular method today, similar to Chainlink's Data Feeds system. Oracle nodes operate automatically based on preset conditions, such as pushing data every 5 minutes or immediately updating on-chain when the price fluctuates by more than 0.5%.
Sounds good? It indeed has two advantages — DApp developers don't need to bother with request logic and can directly read the ready-made on-chain data; users also get data quickly because it’s already waiting there.
But there’s no free lunch. The issue lies in costs: as long as conditions are met, each update consumes Gas, regardless of whether anyone actually uses that data. Imagine supporting 1000 types of RWA assets, pushing updates every few minutes — the Gas costs would be astronomical. For trading pairs with low volume, this mode is especially wasteful.
**Pull-Oracles — On-Demand Mode**
Projects like Tellor(TRB) are exploring another path: contracts only pull data when there is a demand. The benefit is clear — if no one uses it, no money is spent; it’s a pay-as-you-go model, offering much better scalability.
Each mode has its trade-offs; the key depends on what the application scenario requires.
This page may contain third-party content, which is provided for information purposes only (not representations/warranties) and should not be considered as an endorsement of its views by Gate, nor as financial or professional advice. See Disclaimer for details.
21 Likes
Reward
21
5
Repost
Share
Comment
0/400
GasWhisperer
· 01-20 00:44
yo, so chainlink's literally just burning gwei on ghost updates nobody's even reading... kinda tragic ngl
Reply0
DaoDeveloper
· 01-19 15:55
The tradeoff between push and pull modes is indeed worth exploring deeply; gas costs are a real pain point. Chainlink's broadcast mode seems convenient, but once scaled up, costs explode. The game-theoretic implications here should not be underestimated.
View OriginalReply0
LightningHarvester
· 01-17 05:53
That Chainlink push model has long been a burden, with gas fees skyrocketing. Pull-based is the future.
View OriginalReply0
TrustlessMaximalist
· 01-17 05:53
Push mode is like throwing knives at trading pairs with low volume, with Gas fees eating up all the profits... Still, on-demand ones like Tellor are more reliable.
View OriginalReply0
BloodInStreets
· 01-17 05:30
The push oracle system is just riding the coattails of small trading pairs, with Gas fees pouring in like a bloodbath.
Oracles bring off-chain data (such as cryptocurrency prices, weather, etc.) onto the chain. This may seem simple, but in reality, there are two completely different approaches: one is active data pushing, and the other is contract on-demand pulling.
**Push-Oracles — Broadcast Mode**
This is the most popular method today, similar to Chainlink's Data Feeds system. Oracle nodes operate automatically based on preset conditions, such as pushing data every 5 minutes or immediately updating on-chain when the price fluctuates by more than 0.5%.
Sounds good? It indeed has two advantages — DApp developers don't need to bother with request logic and can directly read the ready-made on-chain data; users also get data quickly because it’s already waiting there.
But there’s no free lunch. The issue lies in costs: as long as conditions are met, each update consumes Gas, regardless of whether anyone actually uses that data. Imagine supporting 1000 types of RWA assets, pushing updates every few minutes — the Gas costs would be astronomical. For trading pairs with low volume, this mode is especially wasteful.
**Pull-Oracles — On-Demand Mode**
Projects like Tellor(TRB) are exploring another path: contracts only pull data when there is a demand. The benefit is clear — if no one uses it, no money is spent; it’s a pay-as-you-go model, offering much better scalability.
Each mode has its trade-offs; the key depends on what the application scenario requires.