Intent-Based Data Delivery: Why It Matters and How It Works

Oracles in the context of blockchains should bring data from outside the blockchain into the blockchain world. In our [previous article] we discussed the three different oracle types, the pull oracle, the push oracle and our new intent based oracle.

Let’s summarize quickly how they work, so it becomes obvious why we need a new type of oracle, the intent based one.

Push Oracles

The “push oracle” is probably the oldest idea. With a push oracle, data is readily available on chain and gets updated after some time or when a threshold is reached. For example, an off-chain component observes the average temperature in Paris. It’s 25°C at the beginning and it writes this data point on the chain. Now everyone on the chain can access this data. It can be a rule that data is updated on-chain when the temperature changes by 1°C or after 60 minutes, which is called a heartbeat, to know the oracle is working in general. Let’s assume now the temperature changes to 25.6, 25.7, 25.8°C, but nothing changes on the chain. Off chain the trend becomes very obvious. It finally reaches 26°C and a transaction is sent to the blockchain to update the temperature in the so-called oracle contract. 

The important part is to understand what happens there: The transaction is sent, but it is not immediately visible on-chain. It needs to be mined, or confirmed, first. In fact, since all information is public, it’s known what the new data point will be before the transaction is confirmed.

Let’s say there is a large derivatives market on-chain using this data where you can bet on the temperature. Might be as simple as: You bet the temperature will rise, but you can always exit your position. If you ever traded options, this might sound very familiar. Imagine you bet on falling temperatures and you see there is a new transaction coming with higher temperatures that might render your position invalid. You can just send off a transaction with higher gas to front run the oracle update, get it confirmed with the old 25°C right before the oracle updates to 26°C. 

So, data is not real-time, by any common metric how we define the term “real-time”. Data is stale mostly and data is public and visible before it’s confirmed. 

Even with smaller and smaller thresholds, and/or faster and faster heartbeats, this architecture does not scale well. Let’s go to the extreme and say we want to bring traditional US equity data on-chain. It’s not uncommon that a stock is traded several thousand or tens or thousands of times per second, changing the price ever so slightly in the cents up and down. On Ethereum a transaction (currently) is confirmed every ~14 seconds. On Polygon it’s much faster. It’s not the transaction throughput, it’s the confirmation time as well that matters. Tens of thousands of updates per second – and per market – is unfeasible with this architecture. Updating the on-chain information push-based simply does not work if data needs to be on-chain in real-time. Besides the network congestion, simply doing a napkin calculation on the cost of all the transactions, even if they are in the 0.001 cents per transaction, it won’t be able to handle all the price updates with a high enough sampling rate to satisfy businesses who rely on real-time data.

Pull Oracles

This is where pull oracles come in. A pull oracle turns the problem of data dependency on its head. Instead of making the data readily available on-chain, a pull oracle makes it readily available off-chain with signature mechanisms to be able to verify the data is valid.

You subscribe to a regular http/websocket data feed. You get real-time updates. And when you need a price, you use the data in your own transaction. The data is given to you in a way that you cannot temper with the data.

Let’s go back to the example with the temperature and the bet on the temperature. There is the Oracle (O) and the Participant or User (U) and the Market (M).

O has the data. U wants to trade on M. Instead of querying the data on-chain, the User U gets the temperature from O off-chain. But O does not simply send the current temperature, but sends it with a cryptographic signature so that M (or anybody else) can verify it has not been tempered with. Now the User sends the transaction on-chain containing the Data from the Oracle to the Market, which then can confirm the datapoint is really from the off-chain oracle and lets you trade whatever you want to trade. 

This scales well, but introduces two other, very big problems:

1. On the User/Market side, the User can see the data before it’s sent. The user queries the data and, while not being able to tamper (modify) the data, he can decide to send the transaction or not.
2. Data is publicly available, which is a problem for data licensing and data rights. A lot of data, especially financial data, is narrowly licensed for distribution, display and other rights. If the oracle itself needs data to be visible and is distributing it via a socket, it usually means that traditional data providers can not (and will not) provide data through that oracle.

The Morpher Oracle is different from both approaches. 

The intent based system builds upon account abstraction, also known as ERC4337. ERC4337 itself has nothing to do with oracles, but is the technology Morpher uses to build its oracle technology on top to solve the two remaining issues with pull oracles.

Account Abstraction: a short deep dive

Account Abstraction solves an unrelated problem to oracles, but a long standing problem to EVM (Ethereum Virtual Machine) based systems. 

With EVM based systems, a transaction that is sent, needs “gas” – someone who pays for the transaction. Transactions are not free and are a crucial economic part of how the blockchain operates and pays its validators or miners. 

In current EVM based systems, there are two types of accounts: EOA (externally owned accounts) and contract accounts. EOAs are the ones you usually see in your wallet, which are controlled by a private key. Contract accounts are smart contracts. 

On Ethereum only EOAs can pay for transactions. And this cannot be delegated. I cannot say: “I want to send this transaction, but I want [other account] to pay for it”. It has been tried to solve this problem for years by creating a construct called “account abstraction”. The term generally means that the line between EOAs and contracts gets blurry, where maybe contracts can pay for transactions themselves. 

In the first draft(s) of account abstraction (there were many drafts that never made it to production), a contract could pay for transactions. But it turns out that it’s a very complex problem to solve, with very deep changes to the architecture of the blockchain and the nodes itself, probably needing a number of hard-forks and breaking updates and generally community consent.

Then came another proposal along – proposal number 4337, or ERC4337. Here, no changes to the blockchain itself were necessary. It was fully backwards compatible and relatively easy to implement. 

The idea was to use a number of different signature mechanisms and off-chain and on-chain participants to delegate the sending of the transaction. 

Each one of the participants would have a distinct function and either cannot temper with the data, or, mostly by game theory, don’t want to withhold data.

Let’s do a concrete example.

In the ERC4337 world there are a number of participants. 

1. There is you, the user who wants to send a transaction. 
2. There is a bundler, which is a piece of software that takes in so-called user-operations, very similar to regular transactions, but yet unpaid for. 
3. There is a paymaster, which is someone who could pay for your transaction. This is the crucial part where you can delegate the payment for transactions to someone else. This person can then make sure he gets paid from you either off-chain or directly and transparently on-chain. 
4. There is an entrypoint, which is a smart contract mostly validating signatures and making sure everyone is paid correctly. 
5. There is an on-chain wallet, a so-called smart account, which is yet another smart contract. Smart Accounts existed already before ERC4337 and are developed in parallel or independent to account abstraction, they simply complement each other. They are smart contracts that behave like regular wallets, which are then simply controlled by an externally owned account (an account controlled by a private key). 
6. Then there is the final contract you want to interact with.

The crucial part with ERC4337 is that not you, with your externally owned account, are interacting with the final contract, but you instruct your on-chain wallet to interact with the final contract you want to interact with.

In general, the common recommendation is to use an on-chain wallets over EOAs, regardless of using account abstraction or not. For example https://safe.global/: it has plenty of benefits, such as multi-signature authorization, social recovery and many more. While this is beyond the scope of this article, generally, the movement is towards on-chain wallets.

For our example, let’s say you want to send 1 ETH from your smart wallet to someone else. But instead of directly interacting with your smart wallet, you want to send it in a “gasless” way. That means, your EOA might have 0 ETH to pay for the transaction, but you still want to instruct your on-chain wallet somehow to send the 1 ETH from itself to someone else in your name.

This works by crafting a UserOperation (userOp). A userOp looks very similar to a regular Transaction, structurally.

Let’s drill into this a bit for better understanding:

1. It has a sender, which is your smart account. 
2. It has a nonce, which is an ever increasing number. Very similar to a normal transaction, however, instead of getting this from the blockchain nodes itself, you get this from the entrypoint. 
3. It has an initCode, which creates a smart account (on-chain wallet) if you don’t have one yet. 
4. It has callData, which is similar to the data part in a regular transaction. This part instructs your smart wallet to do something in your name.
5. Then it has a number of gas variables to determine how much to pay to the bundler. 
6. Then there is a paymaster, which is another participant who could pay for the transaction.
7. The signature is a cryptographic mechanism to make the userOp temper proof. It’s a message signature scheme from the externally owned account, where it signs the whole userOp without sending it as a transaction.

Then we’re finished. That one is sent to the bundler.

A bundler is a piece of software that has basically only one purpose: It takes userOps (one or several of them, that’s important!), wraps them into a real transaction he pays for and sends them to the entrypoint. The bundler is not a charity, its not sending the userOps without getting paid. This is where the gas variables in the userOp come into play. The entrypoint uses these variables to determine how much to “pay back” the bundler. 

Because that is known beforehand, the bundler can also verify before sending the actual transaction, that he gets paid enough (equal or more than sending the actual transaction costs). Running a bundler should be an economically sound operation after all.

Then the entrypoint forwards the user’s intent with the callData to the sender (the user’s smart wallet) and the smart wallet executes whatever action the user wanted to do. Of course, everything is signed, double signed and triple signed, so nobody can temper with any data. Since everyone gets paid along the way a small but handsome profit, there is also no reason to believe that they would intentionally collude to withhold any transaction.

The bundlers themselves are connected via a pool where they share pending user operations, similar to an actual transaction pool on Ethereum.

The interesting part for the oracle is: A bundler can send one or many userOps in the same transaction. So, it’s one transaction that wraps several userOps.

The Morpher Oracle

This is what the Morpher Oracle uses to inject a price information or a data point into the system.

In a regular account abstraction scheme, the user interacts with a bundler by sending a POST request to a certain URL. The bundler would take that userOp and add it to its transaction pool.

In the Morpher Oracle, the user also interacts with a bundler, however, instead of sending a UserOp, the user sends a slightly different request, which is a DataOp.

The dataOp looks exactly like the userOp, but before sending the transaction to the endpoint just like that, the bundler will inject that data point as a userOp before the actual userOp of the user. This is determined by the contract the user interacts with, it can specify a new requirement for the interaction:

On the off-chain side, before sending the transaction, this is checked and then it’s determined that the contract needs additional data and then it’s injected as a userOp.

This is an atomic operation, there are not two transactions, but only one single transaction sent to the entry point with two (or more) userOps. The first userOp is updating the oracle, very similar to a push oracle, but intent based, where the data is indeed real-time from a user point of view. The second userOp is the User’s userOp which then interacts with his smart wallet, which interacts with the final contract, which reads the oracle data from the oracle contract.

The oracle itself can make sure it’s also paid through a similar, transparent, on-chain payment scheme, where the oracle interaction is then not free.

The data is not only temper proof from the point of view of the user and the final contract. It’s also not possible to withhold data, because it’s private. A user cannot see the data before it is sent to the final contract on-chain. Furthermore, most, if not, all of the licensing issues for data providers are solved, because data remains private. It does not need any display rights or distribution rights. Data remains scoped readable just for the receiving final contract who needs the datapoint and pays for it.

Curious to see how intent-based oracles work? Check it out live on Morpher Oracle.

Want to dive deeper into the discussion? Join our Telegram group.

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.