On-chain oracles

Tokens
#1

At Riften Labs, we’re testing out an on-chain oracle contract. It’s currently in use on Cauldron dangerzone (hoover a token) to fetch the USD price of BCH.

The contract we’ve deployed fetches the price from oracles.cash and embeds it into a NFT commitment (I hope you don’t mind General Protocols). This allows us to both:

  • Read the price off the blockchain using electrum to use in a user interface, like we do on Cauldron
  • Fetch the price in other contracts by taking it as input and using introspection

oracleinput

The code for this is in oracle.cash.

Price aggregation

Additionally, there is a contract (aggregated.cash) that takes 3 other oracle contracts as input and publishes the median price of the three. It can also be chained to get “median of median” of more entities:

aggregated

The goal is to have multiple independent oracles and be able to get a price within a contract that is resistant to one or more of the entities “going rouge”.

Hoping for some review and feedback. The code and more info at Riften Labs / Moria / oracle-contract · GitLab

8 Likes
#2

Hey, it’s really cool to see another oracles.cash user in the wild! We absolutely don’t mind you guys using it - in fact we encourage creative uses! Just gotta keep a few things in mind:

  1. Just like all things in life, the commitment to run the oracle isn’t eternal. It’ll very likely run out way before heat death of the universe or the next thermonuclear world war, whichever comes first.

  2. But we are committed to doing things responsibly as far as we physically can…

  3. … and you can help extend the commitment further into the future by contributing to its operations at some point.

Happy hunting!

4 Likes
#3

You guys are the best :pray:

This is addressed in the contract. Contract owner can change the oracle used.

You can optionally verify that the oracle used in the contract has not been changed by
checking the first 20 bytes of the commitment. These bytes should match the hash of the oracle public key (hash160).

So short running contracts may want to additionally verify the oracle hash. Long running contracts may want to only verify the oracle category. For long running contract, it’s suggested that the DeFi application owner deploy their own oracle contract (so that they are the owner).

3 Likes
#4

It’s crucial for the future of the DeFi ecosystem on Bitcoin Cash to have a robust oracle solution. So this is very important discussion to be had :100: we need to make sure we have a good foundation to build an ecosytem on-top of.

Current situation

Currently the only production oracles on BCH are the ones run by General Protocols on oracles.cash, used for AnyHedge contracts and BCH Guru contracts. The 24 oracles have a commitment end date as mentioned above

Commitment End
2024-09-30T23:59:59.000Z

There’s multiple disadvantages of such a simple oracle setup

  1. Single trusted party as price source
  2. No business model because non-exclusionary (encourages free loading by others)
  3. Nothing directly at stake by data provider (besides reputation)

Tokenization

Tokenizing the oracle messages has the potential to solve 2) because consumers of NFT price interface could be charged upon usage.

Charging a fee for oracle usage is also part of the v2 oracle draft spec for oracles.cash by @Jonathan_Silverblood of GP.

This approach leaves problem 1) and 3): reliance on a single trusted party with “only” reputation at stake.

Aggregation

The D3lphi oracle contract by Riften Labs attempts to solve the reliance on a single trusted party:

Price aggregation

Additionally, there is a contract ( aggregated.cash ) that takes 3 other oracle contracts as input and publishes the median price of the three.

The goal is to have multiple independent oracles and be able to get a price within a contract that is resistant to one or more of the entities “going rouge”.

The idea of the contract design is simple, just take the median of 3 to solve reliance on a single data provider.

Notable in the design is that the actual data providers/signers are not paid, just the aggregator in the contract.The question then becomes what the incentives for the signers would be to part-take in this, besides trying to collude and manipulate the outcome. Even if the signers are honest, what are their incentives for monitoring the pricedata, having consistent uptime and publishing all the onchain messages?

So while the aggregation contract solves 1) it actually doesn’t solve 2) for the signers, and makes 3) somewhat worse as it is harder to find 3 different parties with enough vested interest in having a spot-free reputation.

Conclusion

To me it seems like to get a good foundation for the future DeFi ecosystem on Bitcoin Cash, we need a robust oracle solution which incentivizes data providers and can slash stake on dishonest behavior.

We should look over the fence at popular oracle solutions in the wider crypto-industry. Chainlink is the defacto standard on EVM, so we should investigate what they do well and what they do badly.

1 Like
#5

Depending on the contract, it seems like changing oracles could go badly if it could be done without the consent of all parties … you might find yourself taking a bad deal, if the othe rparty has swictched oracles to low;ball.offers.cash.

#6

welcome, Nobody!

Great point, but I don’t know there is an alternative. The only alternative is competition. And to do that we need more users and more exchanges. Free markets are the best equalizer.

1 Like
#7

I didn’t want to post a full article on this, but I did not find it in the docs and ChatGPT could not give me an answer:

If there is a bit of data required from an oracle in a smart contract, how does the oracle get the request?

#8

Oh, I might have just figured it out … the oracle could just read all the contract on the chain and search for those that needed its services.