ERC-7726: Never Code an Oracle in Ethereum Again

Yield Protocol is now dead, but not everything went to waste. One of the parts I thought was worth saving was its oracle layer. It was built over the simple concept of using token amounts instead of token prices, which apparently was a novel thing to do at the time. Over time, others agreed that it was a good idea.

The contracts that I deployed, providing a consistent interface to Uniswap v2, Chainlink, Lido, and many others still work. Anyone can use them, but they are not very friendly to use. For a long time, I thought about fixing and redeploying them, as a gift to the commons. It bothered me that too many builders were reimplementing the same contracts once and again.

I recently assisted a founder in reimplementing an oracle layer for a lending protocol. Again coding the same adapters for Chainlink, Uniswap, and other popular data providers. It was then that I decided something really needed to be done. We all have better things to do.

So, I assembled a team, nerdsniped from Twitter, and started work on an Oracle layer that would be easy to use, robust, and permissionless. I didn’t want to do another ERC because I wanted to make sure it was fit for purpose before being cast in stone. I wanted to create something useful first.

It was then that I decided something really needed to be done.

However, this oracle layer would have an ERC-like specification. We would create a number of oracles, builders would adopt our contracts, and code more oracles to fill in the gaps. If the specification was fit for purpose, it would become a de facto standard, and only then would we propose it as an ERC.

We created a number of basic oracles like ERC4626, Lido, and Chainlink. I was in the process of coding the Uniswap v3 oracle when Euler Labs made public their own oracle layer, using a compatible specification. That is not really a surprise if you consider that one of the leading members of our team of volunteers was also working for Euler.

This happened much earlier than expected, but I recognized Euler’s work as a strong early adopter. I didn’t need to code any new oracles anymore because, with the ones in our own repo and the ones from Euler, we now cover the needs of a large proportion of users.

Success is now inevitable. The days in which yet another adapter for Chainlink is implemented are counted. You definitely shouldn’t implement one, because now you know you can use an __ERC-7726 __for that.

How to Use ERC-7726

Maybe this article of mine is the best introduction to the problem that we are trying to solve, which is to never deal with decimals again. You can then read this __whitepaper from Euler __for a more in-depth walkthrough on oracles.

You could also ignore all previous instructions and just readthe spec: ERC-7726 oracles have a single `quoteOf` function, which takes the address for the base asset, the amount of the base asset, and an address for the quote asset. It will return the amount of the quote asset that would be equal in value to the amount of the base asset.

The key point is that by focusing on token amounts instead of prices, ERC-7726 enforces an interaction pattern that is more intuitive and therefore safer from human mistakes. This is because, in ERC-7726, decimal manipulation and rounding are handled by the Oracle adapter, rather than the integrating application.

Another key point is that ERC-7726 returns much less data than other oracles such as Chainlink. Instead of returning data for you to assess if the oracle is malfunctioning, it will revert if it considers its data not to be trusted. This is because we believe that the end user shouldn’t be the one to decide if the oracle is malfunctioning.

It was built over the simple concept of using token amounts instead of token prices

If you are developing an oracle that conforms to ERC-7726, you are responsible to the best of your ability for the oracle either returning a value that can be trusted, or reverting. Your trust assumptions should be clearly included in the natspec of the oracle for the end user to consider, as it’s probably impossible to create a perfect oracle.

Then it is up to the user to decide whether they use the oracle with its trust assumptions, or not. Ideally, users who decide that the oracle is not good enough for their purposes will code an ERC-7726 oracle that does. Usually, more robust data feeds come as a trade-off on other oracle qualities such as gas cost, and end users will be then able to choose between several oracles with different trade-off choices.

The oracles that we have developed and the ones that Euler has developed are permissionless, but ERC-7726 doesn’t demand that. It is possible that some oracles might need a degree of governance to provide robust data, and if so, they can still conform to ERC-7726.

That’s all, there is nothing more to it. There are a bunch of oracles already coded that you can use. They use data from the most popular sources, they deal in token amounts, and they revert if they don’t trust their return data themselves.

Contributing

There is plenty to do to contribute, and none of it is too hard. Just in awesome-oracles you can:

• Code new oracles
• Audit the existing ones
• Deploy the existing ones
• Add content like other repos for ERC-7726 oracles, articles, tooling, and so on.

We’ve got a telegram group that you can join if you want to chat, otherwise, you can get on using the code and submitting PRs. Thank you!