What Blockchain Oracles Incidents Teaches Us — And How Gora Is Different
The Incident
On the Morpho Protocol, a DeFi user recently lost ( early March 2025 ) 14 ETH (~$33,000) due to an oracle-related issue. The loan, secured by cbETH on the Base network, was liquidated when the cbETH/USD price feed failed to update for 8 minutes — while ETH/USD continued to shift. The price deviation hit around 7%, leading to an unintended, automatic liquidation.
This is not an isolated issue. Oracle failures can — and do — lead to millions in user losses. And they point to a deeper problem with current oracle infrastructure.
The Problem with One-Size-Fits-All Oracles
Most legacy oracle providers — including some of the biggest names — treat all use cases the same; unless you can afford the high price tag of a custom implementation. But not every dApp needs the same update frequency, tolerance, or data strategy.
A liquidation system requires real-time, continuous pricing.
A swap app might only need a snapshot at the moment of transaction.
When oracles apply the same logic across all use cases, the result is either stale data, high costs, or security risks. Sometimes, all three
Gora’s Approach: App-Specific Oracles ( ASO )
This is exactly the type of issue Gora was built to solve.
Gora is a decentralized, app-specific oracle network, which means every application can deploy a custom oracle tailored to its own logic, timing, and needs. Let’s break that down:
⚙️ App-Specific Configuration
Each dApp can define:
- Data sources (price feeds, APIs, sensors, AI inference, etc.)
- Frequency of updates (real-time, scheduled, event-based)
- Latency tolerance and aggregation logic
There’s no waiting for the oracle provider to update its configs.
You own your oracle — Gora just powers the backend infrastructure.
And all of this while benefiting from Gora’s shared decentralized security layer.
🌐 Multi-Source, High-Speed Aggregation
Gora supports multiple data inputs for a single item (e.g., asset prices from different sources), aggregates them through off-chain computation, and returns a single, verifiable answer to the smart contract.
This protects against source failures and minimizes price manipulation or delays — ideal for volatile assets and dynamic markets.
🔄 On-Demand Computation and High Load Capacity
Gora’s architecture supports:
- Off-chain computation via WASM for advanced use cases
- High throughput from a decentralized node network
- Asynchronous, parallel processing for scalability
Can Gora handle millions of requests per second?
Yes — by design. Gora’s compute layer doesn’t just fetch data; it executes logic, compresses payloads, and distributes workload across nodes.
🔒 Security Without Centralization
Unlike some competitors that rely on whitelisted or static validators, Gora uses:
- VRF-based sortition (Verifiable Random Function) to select node operators fairly and unpredictably.
- Stake-weighted voting for consensus integrity.
- A shared security layer for all app-specific oracles.
This ensures both performance and decentralization, without trade-offs.
So, Can Gora Truly Handle What Other Oracles Couldn’t?
Let’s walk through the most critical questions:
🔁 Can GoraNetwork provide real-time data updates?
Yes. Gora uses a VRF-based consensus model that allows for dynamic node selection and stake-weighted voting, making real-time data delivery not only possible but optimized per app.
- Update latency: As low as 1.2 seconds in controlled testing environments for price feeds.
- Custom triggers: Apps can define push-based or pull-based updates, set to refresh every block, minute, or event trigger.
📡 Where does Gora get its data?
Gora supports multi-source integrations, pulling from:
- APIs (REST, GraphQL)
- Traditional data vendors
- On-chain smart contracts
- External AI/ML inference engines
- Sensor-based IoT streams (for insurance/weather oracles)
All incoming values are processed via off-chain computation and then aggregated and validated by a decentralized node network.
📈 Can Gora process multiple data points about a single item?
Absolutely. Take a stock price or asset like ETH:
- Gora can fetch prices from 5–10 different sources.
- Compute a median or weighted average.
- Discard outliers or stale data in real-time using custom logic.
- Deliver a finalized answer in milliseconds.
This protects against the type of failure seen with Pyth, where one price feed going stale led to liquidation.
🚀 Can Gora handle millions of requests?
Yes, and here’s the math:
- Each Gora node can process up to 2,000–3,000 requests per minute.
- With just 150 nodes active (current network size), that’s a theoretical capacity of >300,000 oracle computations per minute.
- Load-balanced, asynchronous architecture allows horizontal scaling via node delegation and app-specific compute instances.
For context: That’s enough to serve 100,000+ DeFi users executing oracles simultaneously — without delays.
Chart: Gora’s Oracle Capacity at Scale
Chart: Latency Comparison
📊 What This Means for the Industry
Oracles must adapt to the specific needs of the applications/chains they serve
The recent Pyth incident highlights a hard truth: DeFi apps need oracles they can trust, configure, and scale. Gora offers that — and more.
That’s the future Gora is building — where every app has its own oracle, tuned to its exact requirements, deployed in days, and owned by the developers. Don’t rent the rails. Build your own.
The Gora Network Difference
- Customizability: Every app gets its own oracle config.
- Decentralized computing: Supports off-chain computation for AI models, analytics, etc.
- Scalability: Processes millions of requests per hour.
- Flexibility: Works on Algorand, EVM chains, and more.
- Speed: Tuned per app — not one size fits all.
Learn More
Interested in deploying your own oracle?
→ https://www.gora.io/aso
Build smart. Build with Gora.
Because trust in DeFi starts with the data
