Real World Oracle Use Cases
Real World Oracle Use Cases
How Solving the Oracle Problem Yields Non-Crypto Utility
One of the promises of blockchain is immutable security. And this, for the most part, has held true. Although the news is plagued with crypto hacks, exploits, and collapses, this has almost exclusively derived from external factors.
Web3 is very good at being secure within the blockchain. But when it needs to rely on data from another chain, web2, or the real world, this becomes the Achilles heel for which to aim. And a technology that is only secure onto itself has no utility to the real world.
Source: BuiltIn
These points of failure are called oracles, transmitters of external data to settle on the blockchain. They’re needed because information like asset prices, cross-chain transactions, and IRL event outcomes of course do not exist natively on the secure blockchain.
Therefore, someone must be trusted to deliver this information for it to be used on-chain. But when you have trust, you have the possibility for this trust to be exploited: and thus web3 has not gone more than 14 days without a multi-million dollar exploit in nearly two years.
This is the oracle problem. How can we settle off-chain items and information, leveraging the security of the blockchain? And what good is a system that cannot do this? For web3 to be an actual web, it must replace middlemen with a decentralized system everywhere, otherwise it is no better than what we already have.
User-Validated, Off-Chain Consensus
Rather than explain how Ontropy solves the oracle problem with user-validated agreement, it’s more interesting to demonstrate with concrete examples. I’ll also skip how Ontropy creates verifiably fair price feeds, as we’ve covered this best here.
Instead, I’d like to focus on how off-chain consensus can be used to solve “non-crypto” problems and provide real utility to people. There are three types of transactions that can be replaced with blockchain if the oracle problem is solved: human-backed contracts, external data delivery, and digital asset exchange.
I will use the example of a house, plane ticket, and Twitter handle respectively. Web3 has not been adopted by the masses because there is little you can do with blockchain that you cannot do already with web2. This is about to change with the elimination of the oracle problem.
Human-Backed Contracts on Blockchain
The most achievable disruption by blockchain is societal-enforced contracts. Let’s say Alice has a house she wants to sell to Bob for $100,000. Currently, she’ll need to hire a lawyer and realtor to rubber stamp some documents and place the deposit in escrow.
Instead, what if she used Ontropy and a blockchain to make the transfer? All she would need to do is commit the existing deed to a holding contract and sign it over to Bob. Bob would then send his $100,000 to the contract. The magic of this system is that the swap of the deed and payment happens simultaneously, and only once the conditions of each of them are met. So, Alice and Bob can save thousands of dollars and days of waiting by trustlessly transacting on the blockchain.
This has the added benefit of transparency as well. In the eventual future where city governments accept crypto taxes, this record will be embedded within the contract, so the new owner will be aware of the rate and any liens on the property. I bought my first house when I was 19 using crypto profits. It had unpaid taxes by the previous owner, so web3 transparency would have saved me $3,000!
But this can already be done on the smart contract level, without Ontropy. In fact, it is one of the primary use cases of smart contracts. But, you may have noticed that consensus here occurs on chain. You may have also noticed that uploading an entire deed will be prohibitively expensive and reveal her house information and selling price to the world. It will also require Alice, someone who wants to sell her house quickly and without expensive specialists, to code a smart contract herself or hire and trust someone else. Bob will need to trust Alice’s contract as well.
Ontropy is the generalized solution that allows Alice and Bob to trustlessly and privately input data and agree on price.
Alice signs her deed and commits this to the holding contract, sending the original deed to Bob. Bob verifies the public signature against the deed and sends his payment. The transaction goes through after both parties sign the multisig.
Both parties agree on the price and the only on-chain data is the 257 bit signature and payment: cheap and private. Finality is achieved off-chain, but the result is publicly visible for external reference. The same Ontropy contract can be used for hotel stays, Uber rides, package deliveries, and other non-digital goods.
Source: Realtor.com
Exchanging Information
While real world assets, like houses, cannot be entirely secured by a blockchain, as society and government are the ultimate enforcers of paper and digital contracts alike, this is not so with information.
Imagine Bob wants to buy an airline ticket. First, he’ll go to a website and purchase it. While some sketchy websites won’t deliver the ticket, this is not where the bulk of the problems are (although it’s a problem blockchain solves as well). I’m going to use two ~ regrettably ~ personal anecdotes to explain where else centralized parties can exploit you.
The first is through customer cancellations. In flights arriving or departing from the United States, the customer, by law, has the right to cancel their ticket within 24 hours and receive 100% of their money back. On numerous occasions, this has not been honored, and I have had to file disputes.
But ignore my saltiness, blockchain offers a solution! After payment, the ticket information is sent to the customer while their money is held in a holding contract. The customer is now able to unilaterally withdraw their money within 24 hours of purchase, without agreement from the airline! However, the customer cannot do this and then still use the ticket. This is because the gate agent will discover the withdrawal using the contract ID, which is referenced on the now useless ticket.
So, both the airline and customer are protected by predefined rules, without the need for an arbiter. Also, Ontropy can guarantee privacy here using a combination of off-chain consensus and zero-knowledge proofs, if needed.
A second and more common example of airline exploitation is during delays and cancellations. You guessed it, I am still in a fight with an airline (JetBlue *>_<*) over this. Without going into detail, a delay or cancellation—which an airline will have to record to update their schedule and internal documents—can be used for automatic reimbursements and rescheduled tickets. No waiting in line or arguing on the phone!
Obviously, the possibilities for trustless data do not end here. Concert tickets, digital services like Spotify, articles, random numbers, and other payloads can be exchanged using this method.
If you’re curious why I classified an airline ticket or digital service as data and not an asset, it’s because it can be revoked. The item itself is not important, but what it grants access to, and this can be revoked or proven on chain easily. As we’ll explore next, exchanging rivalrous and excludable digital private goods is more difficult and more interesting.
Digital Assets
NFTs, of course, can be transacted trustlessly for payment. But on the horizon, domains, apps, games, stock photos, securities (and their validated prices), and Twitter handles can be traded too.
We “own” the handle @ontropyio, but say we’d like to purchase @ontropy. The best option in web2 is to send half of the payment up front and half afterward, hopefully getting our new account name in between. And while Twitter could solve this problem by creating a marketplace, this would still require their trust and permission.
Web3 creates an interoperable system that does not demand trust or that every platform build a marketplace—this friction is real as even the giant Twitter has not gotten around to building a marketplace yet. Ontropy and blockchain solve digital asset trading similarly to data exchanges, but both the money and assets are stored in the contract and released together with universal agreement.
What’s different compared to contracts and data exchanges is that the digital asset must exist on chain. This, of course, creates a chicken and egg problem as the entirety of Twitter would need to convert to the blockchain before handles can be trustlessly exchanged.
Ontropy is exploring this question. Perhaps a future product is the ability to overcome the chicken and egg problem by trustlessly tokenizing web2 digital assets. Another possibility for Ontropy is as an enterprise solution for onboarding these assets to chain. Our priority remains eliminating oracles in randomness and price feeds, but non-crypto assets with “real world” utility is definitely an interesting future in which we’ll take part.
Source: Kapwing
Collateral and Aggregation
For those interested, I included a brief description of existing oracle network security, and its constraints.
The first attempt to solve the oracle problem was collateral. Make oracles stake their assets to act as insurance, so their data is secured up to the value of this collateral.
Except, what exactly is the value of information? It has none, except the trades and bets that use it. Therefore, assigning collateral value is arbitrary. A higher value means there are fewer scenarios when delivering incorrect information is profitable, but tends towards centralization with fewer able to participate. A lower value is no better, as the security of each oracle plummets.
Furthermore, any collateral value is ineffective anyway as the vast majority of capital lost due to oracle exploits is from $50,000,000+ hacks. Because of the powers of leverage and derivative use, no collateral amount will ever be sufficient.
First party oracles engage “social capital,” relying on a company or person’s reputation to ensure truth. To me, this feels no better than the data delivery mechanism we already have, like something the paradigm shift of web3 is supposed to render unnecessary.
Another tool used by existing oracle networks is aggregation. We don’t need to look past Chainlink’s $11 million LUNA suspension, Coinbase’s $100 million DAI exploit, or Switchboard’s $117 million Mango hack to see why aggregation doesn’t work. This is primarily because while aggregation increases collateral, it does so only linearly. An exploit will always be profitable if the hack value is more than just half of the staked collateral.
More, aggregation requires liveness, which adds latency. There is also no privacy guarantee, so oracles are mostly unusable for delivering sensitive real-world asset information or random numbers for gambling.
These security issues, along with the fact that personal user agreement is needed for most real world validation, prevents oracles from scaling or capturing non-crypto value.
As always, thank you for reading! To stay updated, follow me and Ontropy on Twitter and check out our website.
Sources