Level K had the idea to do something related with oracles, so we stared brainstorming and concluded that there is no perfect oracle solution. Every oracle is a tradeoff between decentralization, speed, and cost. We decided to make oracles that optimize for different trade-offs and can be used in different situations.

What it does

Puracle is a set of smart contracts to deploy different oracles on an oracle registry:

  • Simple oracle: An owned oracle that will be governed and updated by a central authority.
  • Signed oracle: An oracle owned by a central authority that will require a signature in order to be updated. The update can be executed by anyone in the network and updaters are rewarded in wei.
  • Pluracle: An oracle of oracles. This oracle uses multiple sub-oracles and reports the median value. Any oracle fees can be distributed to the sub-oracles.
  • Composable Oracle: Also an oracle of oracles. The Composable Oracle allows oracles to be chained in hierarchy. Cheap and fast but centralized oracles can be used by default but then fallback on more decentralized oracles up the chain when the reported value is challenged. This oracle is optimized for cost and decentralization but is slow to update.

How we built it

First we designed the interfaces so that any oracle could be swapped out with another. Because there are many oracle solutions and trade-offs, we believe it is important to allow oracle consumers to adopt new solutions without changing how their code interacts with the oracle. We aimed to share as much code as possible and keeping the code as simple as we can. After that we built a Factory for each oracle type and a registry of of all oracles in the pluracle-network. One single contract to get the oracles' owner, description, type, and data provided.

Challenges we ran into

We were stuck for quite some time trying to make the tests run with offchain signatures, since truffle adds a prefix for signing messages. We also had difficulty designing the Composable Oracle to allow for an adequate challenge period after a value is reported. This ended up requiring sub-oracles to have to track their history of reported data.

Accomplishments that we're proud of

We integrated with MakerDao on the Kovan testnet. You can check it out at (with MetaMask pointed at Kovan). We built multiple oracle types from simple interfaces and registered them all on an "official" registry which you can see at We have a simple tests with zos-lib that will allow contributors to work more easily with upgradeable proxies.

It is going to take a long time to finalize an oracle standard but we are happy with the design of our registry and factories supporting different types of oracles and we think it is one of the first implementations of generic swappable oracles.

What we learned

We learned how difficult it is to build with offchain data. We picked this idea thinking that it would be something simple that we could knock out of the park but we found ourselves in a much more complicated domain than anticipated. It was ultimately an awesome challenge and we are very proud of what were able to accomplish.

What's next for PLURACLE

Use ZeppelinOS and maybe AragonOS to govern Pluracles and the rules to calculate the data provided on it. Provide good quality of data curating different multiple sources for the same data, e.g BTC price can be queried from multiple exchanges and a pluracle can be built for it, where another exchanges can plug in easily. We'd also like to add new types of oracles such Shelling point oracles. And lastly, audit and review the code and try to add more functionality without taking away from the simplicity.

Built With

Share this project: