Introduction
I believe that, right now, the space of projects/ideas enabled by keep3r oracles haven’t been explored at all, which may make it seem like they are just another oracle alternative where they are actually much more than that.
Concretely, there’s one aspect of them that I believe has been vastly overlooked: their permissionlessness. Anyone can setup an oracle for any asset, and this enables a completely new design space that hasn’t been explored at all yet.
The easiest way to understand this is imagining what a developer that is building a protocol that requires oracles has to go through. For starters, they’ll notice that one of the biggest players is completely out of their reach: Maker requires per-project approval votes to use their oracles, making it impossible for small players to join.
The next logical step would be to look at other players such as chainlink, but these only support oracles for a small set of assets. If you request other price feeds and are a nobody they won’t even bother answering you.
This heavily limits what your protocol can do and what assets it can support. But, most importantly, it makes it impossible to develop a protocol where anyone can create pools for any asset, such as uniswap.
In other words, this not only limits what protocols can do but it makes them inherit the permissioned nature of these oracle solutions.
TWAPs and Keep3r solve that by making it completely permissionless to create new oracles, thus democratizing oracle and enabling the models mentioned before. Keep3r even goes one step ahead and tackles the cost problems associated with TWAPs by building shared resources that can be maintained by the multiple protocols that use them.
However, when we look at the current implementation, it seems to have led to the problem of tragedy of the commons, that is, protocols would rather avoid bearing the cost of maintaining the oracles and instead just use them as a public good.
I believe that the solution for this lies in changing the entity that carries the burden of maintaining the oracles. Instead of putting that on the protocols’ teams we could shift that into the protocols themselves and the organic activity happening on them, thus turning them into self-maintaining systems. That’s the basic idea behind my proposal.
Intermittent oracles
The fundamental idea behind this proposal is that we’ll drive oracle updates through organic activity, which can be achieved by simply making all user interactions also trigger oracle updates.
The most basic way to achieve that is by making the oracle contract embed oracle updates into the method used to read the current price, making it so anyone using it is already contributing to keep it up-to-date. But it’s also possible to embed these updates into any other interaction.
However, using organic activity has the problem that it’s completely unpredictable, so it won’t be possible to use the current keep3r model as that requires regular updates. Instead we’ll need a new model that works with irregular or intermittent updates. Because of this, I’ve been calling these new systems “Intermittent oracles”.
A good way to solve this is to use an exponential moving average that weights new updates based on the time elapsed since the last update. This also has the added benefit of giving more weight to the latest prices, therefore increasing data freshness.
In practice, this means that oracle prices will update following these formulas:
The denominator was chosen in order to keep the price close to the daily moving average, the same price range used by current Keep3r oracles.
Problems
Gas costs
Making the user bear the burden of updating the oracles will increase the gas cost of their operations, but this can be heavily reduced by limitting these updates to 1/hour and only making the first user perform the update. A similar mechanism is used on uniswap, where only the first trade of each block has to update certain variables.
Overflowed cumulative prices
A problem with this model is that uniswap’s cumulative prices are meant to overflow, which is fine as long as they don’t overflow twice between two read operations, as that would lead to an incorrect value. To prevent this problem we’ll set a maximum time difference for oracle updates.
Sudden price movements
TWAPs are based on averages so sudden price changes will take a while to be registered. This model improves slightly on this by using exponential moving averages, which increase the important of recent prices.
Request for comments
What are your thoughts on this system? Do you see any problems with it? Anything that could be improved? Let’s discuss!