What Makes Morpher Oracle Different from Traditional Oracles?

Blockchains are closed systems. Smart contracts are programs that run inside this sandbox. As long as they only interact with each other, everything works fine. However, for many suggested real-world use cases, these programs need data from outside the blockchain.

Let’s pick an example: settling a bet is a famous one.

With the 2024 U.S. election just behind us, let’s look at one smart contract that was wildly successful during the presidential race: Polymarket.

Discover Morpher Oracle

How Blockchain Betting Markets Work

With betting markets, you can bet on the probability of real-world events. Leading up to the 2024 election results, it was a race between Kamala Harris and Donald Trump. The smart contract works by letting people bet money on either side’s win or loss.

Vastly simplified: if 10 people each bet $1 on Harris winning and 5 people each bet $1 on Harris losing, we would have around 66% (or $10/$15) on Harris winning and 33% on Harris losing. You could buy into the bet that Harris loses for $0.33, and so on. It’s a bit more complicated than that, but here’s where oracles like Morpher oracle come in: How do you determine, on the blockchain, who won?

The Oracle Problem: Who Provides Trustworthy Data?

So the question is: who, if anyone, has the authority to announce on the blockchain that Trump won or Harris won? And why should we trust that person or entity?

In the real world, this is simple: just watch the news and wait for the votes to be counted.

But getting that result onto the blockchain is quite complex.

Among other things, there are a few popular options:

• You trust a single person to announce the correct result.
• You trust a group of people and aggregate their results.
• You allow someone to propose a result and let others dispute that proposal.

The first option is problematic. In this case, the fate of many people rests in the hands of a single person. This would only work if that person has significant skin in the game and can ensure the result is correct, perhaps by placing a bond. However, once that happens, it gradually shifts toward option three, where the result is merely a proposal that can be disputed.

That’s essentially how Polymarket works: when a bet ends and requires resolution, someone can propose a result and stake a bond. If the result is disputed by the community, the bond can be claimed. If no dispute occurs within a certain period, the result is accepted as “the truth”, and the bets are settled.

The Challenge of Trust in Small or No Communities

With Polymarket, this system works well. First, the current price of betting on a win/loss is determined by the total amount spent on each side. This means no external data is needed to price the bet until settlement. Additionally, the large community ensures that maliciously proposing a resolution and avoiding disputes through majority control is not a significant issue.

But what if there is only a small community? Or no community at all, and something needs to be settled between just two parties? Who do you trust?

How Real-World Data Reaches the Blockchain

Let’s say you are an insurance company looking to settle claims. You insure a supply chain for fresh meat transported from Asia to the U.S. Instead of relying on a department to process insurance claims, you implement a novel “claims smart contract” that automatically pays out as soon as certain criteria are met.

In a simple example, that criterion could be the failure of the ship’s cooling facilities while transporting the meat. But how do these smart contracts know the facilities failed? They need sensor data.

The idea is straightforward: when the temperature sensors in the storage room detect a certain threshold, the goods are considered spoiled, and the insurance payout is triggered. Of course, in a real world scenario, there would be multiple sensors monitoring various conditions inside and outside the product. But to keep things simple, this example focuses on how the system works.

How do these sensor data readings get onto the blockchain? After all, in this case, there are only two actors, so who ensures the data is reliable? Ideally, neither party should have sole control, which is where a third party (or even better, multiple third parties) comes in.

What if the data didn’t come from a single sensor but from an entire sensor network? What if multiple companies were involved, each with their own sensors and independent readings? The more sources contributing data, the lower the risk of manipulation, making the readings more reliable.

Imagine thousands of companies embedding their own sensor technology inside shipping containers, produce, or packaging, each independently supplying data points. Would an aggregate of these readings be more trustworthy? It certainly would, far more than relying on a single person taking a single reading inside a container ship and submitting one transaction.

This kind of aggregated sensor data already exists today, but it hasn’t yet been integrated into the blockchain.

That introduces another problem: who do we trust to aggregate these sensor readings? And can we also trust that person to send the transaction updating the blockchain?

Thinking a few steps ahead, all actors involved should be “sufficiently decentralized” to create a trusted environment. The more independent participants we have delivering data, the more reliable the system becomes.

Threshold-Based Data Submission: How Push Oracles Work

Up until the invention of the Morpher Oracle, there were two main ways to get data onto the blockchain.

Let’s go back to our example with sensor readings. Imagine the ship departs from Asia, and an initial reading is taken, it records -15°C, marking the start of the journey. This first reading is successfully entered onto the blockchain.

However, we know that updating values on the blockchain isn’t free (at least not usually). Plus, blockchains have a limited transaction capacity per second. Now, consider how many ships are operating globally and how frequently they might record sensor readings, perhaps dozens of times per minute, or even per second. If every single reading required a blockchain transaction, the system would quickly become overwhelmed.

A potential solution? Only send a transaction when a certain threshold is met.

This is exactly how push oracles, like Chainlink, operate.

In this particular case, we are only interested in a sensor reading if the value changes by 1–2 degrees Celsius. Additionally, a heartbeat transaction could be sent every 1–2 hours if the temperature remains within the threshold.

For our smart contract, it would retrieve sensor readings from another smart contract. That contract would continue to display -15°C until the temperature changes by 1 or 2 degrees, updating to -13°C, and so on. Our smart contract would then allow a claim to be made if the temperature readings reach +5°C or higher. This process could be fully automated, and as long as the oracle (the middleman carrying the data) is sufficiently decentralized, the system remains trustworthy.

However, this is where things get tricky. Push oracles can have slow update intervals. While this might work well for insurance claims, where a sensor reading triggers a (semi-)automatic payout, it’s not as effective for other use cases.

One of those cases? Live price information on the blockchain.

Pull Oracles: A New Approach to Real-Time Data

To achieve even better live data, another type of oracle emerged: the pull oracle. In this case, data is served outside the blockchain, but in a way that allows its authenticity to be verified, even if it’s sent by an untrusted party.

This may sound unusual at first, but imagine you write down an important piece of information in a letter. You place the letter in an envelope, seal it, and apply a wax seal on top. Then, you send it through the post. When the recipient receives the envelope, they can immediately tell if someone has tampered with the contents just by looking at the wax seal.

A real world example of this concept is used by some companies: they vacuum-seal a small parcel with beans or colorful marbles inside transparent packaging. Before sending it, they take a picture and email it to the recipient. Upon delivery, you can compare the package to the picture, if the beans or marbles are exactly as shown, the package is untouched. But if someone has tampered with it, it would be nearly impossible to put everything back in the exact same arrangement.

This is very similar to how pull oracles work. You query a data point outside the blockchain. It gets cryptographically signed (the wax seal), and then you send that data yourself to the receiving smart contract. The smart contract can then verify the cryptographic signature, ensuring the data is authentic and hasn’t been altered.

This approach is ideal for near real-time data and is widely used today by companies like Pyth.

However, this introduces another problem: you see the data before sending it, meaning you can choose whether to send it or not. This is especially problematic for platforms that allow some sort of leverage or placing big bets based on gradually changing data.

You, as the bearer of the news, can decide whether to actually deliver the news. That is, you query tamper-proof data, but you can still choose to send it or not. The data is visible and clearly readable before submission.

That brings two big problems:

• First, while the data itself, if sent, can be trusted, there’s no guarantee that the data will be sent if the outcome is unfavorable to a potential counterparty.
• Second, it introduces potential data licensing issues, as the data must be visible before it gets settled on the blockchain.

This is where the Morpher Oracle introduces a new approach to oracle architecture. It’s an intent-based oracle, representing a leap forward from the pull-based model.

Morpher Oracle: A New Solution for Blockchain Data Feeds

With the Morpher Oracle, the user is not responsible for sending a transaction but instead sends an intent to send a transaction. This reverses the pull oracle mechanism:

• The user places their transaction in an envelope, seals it with a wax seal, and hands it over to the oracle.
• The oracle cannot tamper with the contents of the envelope.
• The oracle has no incentive to withhold the transaction, as it gets paid for sending it.
• The oracle sees that the user needs up-to-date information and can piggyback a trusted data point on top of the user’s letter.

It is essentially putting the user’s letter into its own envelope and submitting everything to the blockchain.

With this, the user is guaranteed that their transaction is sent. The smart contract has guarantees that the information is up-to-date and cryptographically signed, similar to pull oracles. But the counterparty also has guarantees that the transaction is submitted, even if the oracle’s data point is unfavorable to the user, it’s a fair game.

Furthermore, data cannot be siphoned off in bulk, preventing the licensing issues that traditional pull oracles face.

Join Morpher Oracle Telegram group for more.

Morpher Oracle ensures real-time, tamper-proof data feeds without manipulation or delays—guaranteeing fair, trustless transactions on-chain. Test it now on BNB and Radix.

Disclaimer: All investments involve risk, and the past performance of a security, industry, sector, market, financial product, trading strategy, or individual’s trading does not guarantee future results or returns. Investors are fully responsible for any investment decisions they make. Such decisions should be based solely on an evaluation of their financial circumstances, investment objectives, risk tolerance, and liquidity needs. This post does not constitute investment advice.