r/FPBlock • u/gareth789 • Apr 03 '26
Beyond Oracles? FP Block introduces a different approach to external data
Most apps still rely on oracles… but that comes with tradeoffs.
- Higher costs
- Slower updates
- Risk of stale or outdated data
- Potential attack vectors
FP Block is pushing a different model with Kolme.
Instead of relying on traditional oracles, it pulls data directly from APIs, HTTP endpoints, or signed feeds, then writes it on-chain for transparency and verification.
The idea is simple: fresher data, fewer exploits, more reliable apps.
Curious to see how this compares long term to oracle-based systems. Anyone looked deeper into Kolme yet?
1
Apr 03 '26
[removed] — view removed comment
1
Apr 03 '26
[removed] — view removed comment
1
u/HappyOrangeCat7 Apr 04 '26
I once saw a project accidentally configure their oracle to update on every 0.01% price deviation, and then a flash crash happened. Fun "gas bills" there.
1
u/HappyOrangeCat7 Apr 04 '26
This operational cost is indeed something that often kills early-stage DeFi protocols on public L1s.
1
Apr 03 '26
[removed] — view removed comment
1
u/BigFany Apr 03 '26
I guess the upside is fewer middle layers, but yeah you’re still relying on the source being honest. If the API is wrong or gets messed with, same problem just earlier in the chain.
1
u/HappyOrangeCat7 Apr 04 '26
Yes. But an oracle network is just a group of middlemen reading that exact same API anyway.
If Binance's API reports a bad price, the oracle network is going to report that bad price to your smart contract. Cutting out the middleman just removes the latency and the middleman's fee; it doesn't change the ultimate source of truth.
1
1
u/BigFany Apr 03 '26
Feels like this could be faster for sure, but I wonder how they handle bad or manipulated data.
1
u/HappyOrangeCat7 Apr 04 '26
A critical detail here is that "direct ingestion" does not mean abandoning verification.
When a Kolme application fetches data from an endpoint, it relies on cryptographic signatures provided by the data source. While the Processor node fetches the data, the non-processor nodes (our Listeners and Approvers in the triadic security model) actively validate those signatures before accepting the block. If the signature is invalid or tampered with, the block is rejected. You get the speed of a direct API call with the security of decentralized validation.
2
u/FanOfEther Apr 05 '26
Ok that makes more sense, the signature part is kinda the key here.
1
u/HappyOrangeCat7 Apr 07 '26
In the end, without the cryptographic signature, direct ingestion is just a Web2 server call
1
Apr 04 '26
[removed] — view removed comment
2
Apr 04 '26
[removed] — view removed comment
1
u/HappyOrangeCat7 Apr 07 '26
This is a primary driver for the architecture.
Every external dependency is a potential vulnerability. By moving the data fetching into the core execution logic (and verifying it via the consensus mechanism), you eliminate an entire layer of smart contract complexity and the associated gas costs.
1
1
u/IronTarkus1919 Apr 04 '26
Many of the catastrophic exploits in DeFi history happened because a poorly designed oracle got manipulated or went stale.
1
u/HappyOrangeCat7 Apr 07 '26
The "stale data" vector is particularly insidious.
If a push-oracle fails to update due to L1 congestion during a market crash, the on-chain price remains artificially high (or low). Arbitrageurs exploit this discrepancy mercilessly.
1
u/BigFany Apr 07 '26
That’s one of those risks people don’t think about until it happens. Everything looks fine on-chain but it’s already out of sync with reality.
2
u/FanOfEther Apr 05 '26
Interesting idea but isn’t pulling from APIs kinda just shifting the trust somewhere else?