Can oracle implementations like Oraclize and Reality Keys work with two different blockchains? More precisely, if I have a custom data source and my own oracle running on top of it, can that oracle determine the source of the API call and send data accordingly? Can I design a permission layer in this oracle to allow/deny API calls from a specific address?

2 Answers 2


As for Oraclize, you can potentially use it with any blockchain.

What Oraclize provides is a native integration with public blockchains (i.e.: Ethereum mainnet, Ethereum morden testnet, Bitcoin mainnet) and an HTTP API you can use to connect the Oraclize engine to any other blockchain (for example by using the Ethereum-bridge tool you can connect the engine to your private Ethereum testnet/Eris/etc).

Being this approach so flexible, it enables different blockchain to speak to each other by using Oraclize as a connector.

A datasource is the data provider: if you want to use your own web service as a datasource, you can implement there whatever logic you want - Oraclize is just abstracting the connection to the datasource so that it can be blockchain agnostic.

That said, this is all about transparency and auditability, so there is not effective way to restrict the visibility of data to some blockchains only (unless you are willing to lose the oracle abstraction layer part).

If what you want to achieve is having your own web service being able to answer just to queries coming from "authorized contracts" (let's say for example you want to allow using it on ETH but not on ETC), you can do that via Oraclize encrypted queries thanks to one of its features: a given encrypted string is binded to one contract only - which is the first one using it.

So let's say you want a given query Q, when you encrypt it you will have ENC1(Q), ENC2(Q), ENC3(Q) and so on.. every time you encrypt it, the encrypted string will be different.

If you deploy a contract using ENC1(Q) via oraclize_query, it will just work and the decrypted query will be visible to Oraclize - which will send your contract back the answer.

If another contract (on the same chain.. or on a different one!) then tries to use ENC1(Q), Oraclize will prevent the query to the datasource to succeed as the only contract allowed to use ENC1(Q) is just the first one who used it. Q is known to you and Oraclize only, enabling your datasource logic to work under some given circumstances only.

This feature was designed to use private api credentials as queries on public blockchains, but of course it enables many other useful applications to come to life: for example your chain-specific whitelisting feature or other interesting scenarios (a bit OT here).

Thomas Bertani - Oraclize

  • Thank you. Also, Can I achieve access control using an oracle? i.e, from an authorized smart contract, can I allow query Q1 but deny another query Q2. Is there any mechanism to take decisions whether to allow a specific query?
    – galahad
    Aug 12, 2016 at 16:38
  • With encrypted queries you could encrypt a secret key (like some api credentials) as part of the query and use it to access private apis. Is this what you want to achive? Aug 12, 2016 at 17:32
  • Not really. I want to know whether it's possible (through an oracle) to restrict access to some parts of data in my web service (data source).
    – galahad
    Aug 12, 2016 at 17:53
  • How would that be impossible by using api credentials? If those are encrypted, just the allowed contracts would use them. If you want to have the datasource choosing instead (based on each specific query), you would need to have the query_id to be passed along with the request. Anyway this sounds a lot like an overcomplication.. Aug 12, 2016 at 20:58

Edmund Edgar from Reality Keys here.

The way we work is by signing data and publishing it publicly off-chain. You then send it in a transaction to your blockchain yourself. This means that we don't need to interact with your blockchain, or even know that it exists. The same data will be usable on any blockchain that knows how to check the signature.

If you want to send different data to the different blockchains, you would put whatever is different in the definition of that event, and treat them as two different events.

If these are public blockchains and you're hoping to keep the data secret from users of the other chain, you're probably out of luck: Once you send data to a public blockchain, anyone can see what it is.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.