“Identity on the blockchain” – chapter 2

Three months have already passed since the publishing of our first blog post around identity. We didn’t just stop there: what seemed to us like the most elegant way to address the “identity on the blockchain” problem has evolved quite a bit since then and this blog post wants to be a quick update to tell you all what’s exactly going on on our side and to collect some precious feedback from the community we love.



As a short recap, what we had published already was a first draft of “proof-of-identity”, an onchain identity framework where digital ID cards (namely just the Estonian e-residency card, at the time of writing) could be used to provide signatures verifiable by an Ethereum smartcontract. As part of the project, the ID card’s certificate validity check (against its revocation list) was there as well – a key feature, whose implementation is based on Oraclize as a connector to the Certificate Validity Confirmation webservice, to ensure provided signatures are authorized and not coming from stolen IDs or other undesirable situations.

If at this point you are a bit lost, reading again this introductory blog post will probably help.



On the 13th July we had the pleasure to partecipate to the first “Blockchain CTO roundtable” – a great initiative organized by Aron van Ammers to get different CTOs together to share ideas around a given topic. Being this first one specifically around “blockchains and identity” we had the chance to receive some high quality feedback from other players working in our same industry and facing our same challenges – which helped a lot. Listening to the other innovators out there was really exciting, we all acknowledge there are many ways forward and most of them are exploring new grounds (making all this interesting in a very special way!).






On the same day, our project proposal around the matter was accepted by the WanXiang Blockchain Labs BlockGrantX #4 with 30k USD being offered to specifically work on the improval of our “proof-of-identity” framework – these funds will help a lot to dedicate additional efforts and resources to the project. As a result, in the coming months we will work hard to extend its features and to bring this solution to an high quality standard ready to be used by production (mainnet) projects!



Last but not least, we love to have fun at hackathons and to just go there to explore new ideas over the weekend – this is what we did again last week, partecipating at the London Fintech Week “hack/make the bank” hackathon. The idea we wanted to test out was what to us will be the “bank 2.0” architecture – with banks being not custodians but just facilitators. The Blockchain enables, for the first time in history, to have a third party offering financial services while keeping the users fully in control of their funds.

In fact, the funds are hold and managed by an onchain “wallet manager” smartcontract (based on the “proof-of-identity” framework!) where the digital ID card acts as an hardware wallet. This means that any e-resident (~12k across the world, at the time of writing) has automatically access to an Ethereum wallet without even knowing! Funds move around based on a public identity reference (namely the ID card serial number) and can be claimed at any time by providing a signature with the ID card device. Our project included not only the wallet manager contract, but also the web interface to easily interact with the contract: all the complexity is hidden – there is no need to signup, signin as plugging in the ID card to the USB port is enough to potentially access a whole set of onchain financial services.



“Be (your own bank)” is the name we had chosen for the weekend project. While competing against ~100 of talented developers, we had the pleasure to win the first place!







As part of the hackathon prize, we had the opportunity, just few days after the event, to present the project again at the London Fintech Week – yet many other useful feedbacks!


In the coming months we will keep you posted with our progress, in the meanwhile please get in touch with us and provide your precious feedback – we really want you to share with us any thoughts around the matter!


Stay tuned,

Thomas Bertani

On the upcoming Ethereum hard-fork

Given the recent events around the Ethereum hard-fork, we felt there was a need to reassure our clients and the whole community around the actions that Oraclize will take in the coming days.

There is no need to recap what the whole communty have been discussing for the last few months around the rise and fall of theDAO. Many things have been said and many actions taken – while the first anniversary of the offical Ethereum launch is just around the corner, the community has now a strong need to face one of its biggest challenges, namely theDAO HF (hard-fork).

Regardless of our personal opinions around such a controversial matter, Oraclize wants to be platform agnostic as a service. We have a strong commitment to support and live in each context where our service might be useful. However we think this complex situation needs to be faced in a responsible way – we don’t believe having a split in the Ethereum community would be beneficial in any way due to its scarse resources (developers, users, funding, ..).

Some technical problems prevent a healty survival of both the HF and non-HF chains and we think the best choice the community could take is just to be united.

Many figures are showing how strong the community support on the HF chain already is. At this point it is very likely that after block 1920000, the HF will just happen and the majority of the network will be on that new chain.

Oraclize will continue to work as usual on the new HF chain, “Ethereum”. The service on the old one, which is likely to come to an end soon, will not be available. This is to encourage a healty upgrade process to the network the majority has chosen and to reduce market uncertainty to a minimum.

That said, there is no 100% guarantee the old network will die and once the above situation will be settled, there might be a (new?) community effort supporting the old chain. This is not something we want to stand with or against – the market will choose.

In order to stay consisent with that, we choose to update our on-chain query id calculation. The new formula takes into account an HF flag making the HF and non-HF chains to generate a different set of query ids.

The new Oraclize connector contract was already deployed on the Ethereum mainchain and will ensure a forward-compatible format (potentially enabling both chains to be safely supported) other than the impossibility to run effective replay attacks on the Oraclize callback transactions.


Friendly reminder – regardless of which chain you will choose to support, the last clients enable HF voting capabilities and can be find here: Geth 1.4.10, Mist 0.8.1.



Stay strong, stay consistent.

Thomas Bertani

StackExchange Bounty ÐApp

In the last few months there have been many call to arms to engage and grow the Ethereum StackExchange community and we have been working on a way to support it. We are presenting in this blog post a proof-of-concept ÐApp which wants to foster community engagement by providing an economic incentive for user participation, under the form of Ether bounties for StackExchange questions.  

What is the StackExchange Bounty ÐApp?

StackExchangeBounty ÐApp

StackExchange is a network of questions and answers, where users and experts of different fields can interact freely. Everyone can join in and ask questions about a topic over which they need some help from field experts.  Fields are divided in subsites: among the biggest there are, for example, Programming (Stack Overflow),  Linux, Maths,  Physics,  Cryptography and so on. New subsites can be proposed and created and, after a beta period, they will graduate to fully fledged ones. Right now, Ethereum Stack Exchange is a healthy beta but it needs a little extra push to finally graduate.

The StackExchange Bounty ÐApp wants to provide an easy way to create bounties for StackExchange questions, and therefore to incentivize users to be active on the Ethereum StackExchange board, but it works also on every other StackExchange subsites.

What is a ÐApp?

ÐApp stands for decentralized application. ÐApp are often made of a CSS/HTML5/JS front-end and a back-end made entirely by smart contracts running on Ethereum or other (statefull) blockchains.  The frontend can be stored on IPFS or SWARM, which are distribuited p2p file systems still in development, or simply by an old fashion web server as we are doing right now.

Our ÐApp is backed by the following smart contract code, running on the Ethereum blockchain. The smart contract provides a way to create a bounty without relying on a third-party escrow, but it cannot be called trustless: there is still some trust involved in the StackExchange APIs and in Oraclize, which fetches data from those APIs. When on-chain verification of Oracle honesty will be available, then our honesty could be proven inside the contract, reducing the trust relationships involved, at the expense of increasing the gas costs.

The ÐApp is in an early PoC stage and its smart contract has only been deployed on testnet. There are still some limitations in its current form:

  • Data Model: We are holding questions in an array. We know that is not a proper solution, as if the number of questions increases, it could reach a limit where the gas cost of going through the array is higher than the gas block limit. We will improve this aspect in the next iterations of the smart contract.
  • Expensive: the contract uses a lot of gas since there are many queries to Oraclize, which can drain users bounties quickly. This is why we are updating the data in the contract through Oraclize only once a day.

We would like to have community feedback on this PoC, both on the core concept and on its limitations or simply if you want to propose some features. Pull requests are welcome!

How Does it Work?

The smart contract can be initiated by adding a question and its bounty. Then, Oraclize will fetch the question data from StackExchange APIs and the smart contract will verify with sequential queries to Oraclize:

  1.  If the question does exist, the StackExchangeBounty smart contract will create a StackExchangeBountyAddress smart contract for that question:
    questions[i].contractAddress = new    StackExchangeBountyAddress(questionID, site, i);

    When the creation is completed, the UI will show you an address. You can now increase the bounty, or other users can partecipate adding their bounties, simply by sending ETH to the address of the newly created contract using any wallet. If you are not using Mist, then you must specify a transaction custom gas of at least 70000 gas unit. You can also see the address of a question smart contract by clicking on the “Sponsor This Question” button, as show in the picture:


  2. The ID of the accepted answer, called acceptedAnswerID in the code. The accepted answer is selected by the user which posted the question in first place.
  3. The user ID which posted the accepted answer, called winnerID in the code
  4. The Ethereum address matching the winnerID, called winnerAddress. The bounty can be sent only if the “winner” has an Ethereum address in the location field on his StackExchange subsite profile, as seen here.

If, at each step of the outlined, Oraclize returns empty data, then the contract will repeat that step, i.e requesting once again to Oraclize to provide that data, with a time delay. The time between updates is hard-coded to one day. The smart contract will continue to repeat the step until the data is either available or the question’s expiration date is reached. After that date, if there is neither an accepted answer nor a destination address, the bounty or bounties of the question will be returned to their respective owners.

If you want to see detailed information about bounties and question status, you can click on a question in the Question List UI and you will access the Question UI:

Schermata del 2016-05-17 11-40-51

To add questions to the StackExchange Bounty ÐApp you need to open your terminal and launch geth or your preferred ethereum node with the following parameters:

geth --testnet --rpc --rpccorsdomain http://dapps.oraclize.it --unlock "0"

You can replace geth with parity or another ethereum node ( warning: the command line interface syntax may be different) and “0” with the number ID of the account you want to unlock. Your CLI will then asks the password to unlock your local wallet file.

In the Web UI, you can connect to your localhost (http://localhost:8545) by clicking on the Advance Setting button. If everything works correctly, you will now be able to deposit a bounty on top of any StackExchange question.


Marco Giglio

Encrypted Queries: Private Data on a Public Blockchain


One of the biggest unsolved limitation of current  public and permission-less blockchain technologies, as Ethereum and Bitcoin, is the lack of  financial privacy that their inherent transparent nature produces. While in Bitcoin, this lack (given enough time and energy) enables a potential attacker with the ability to reconstruct the entire transaction history of a subject,  in Ethereum the problem is even more severe. As every smart contract holds its data in a public and easily accessible storage,  an attacker can easily reconstruct the meanings and logic behind it, potentially accessing the entire financial and non-financial history of an account across many smart contracts. For some types of trust-less financial application, the transparency is paramount. For example, by using a block explorer as Ether.camp, we can easily peek into TheDAO smart-contract storage and see that the crowdsourcing period will be over on the 28-May-2016 at 9 am GMT.  Since there is no function which can modify the closingTime variable in the verified smart contract code, we know that the crowdsourcing will close on that day in a completely trustless way. On the other hand, we can also see how many DAO Tokens each account owns. Considering that many of these token holders have transferred ether or bought directly tokens from centralized exchanges, which have to comply with KYC rules,  we can see how relevant is the privacy problem.

Ethereum, Bitcoin developers are well aware of these issues. Moreover, blockchain technologies have recently attracted a lot of interest among academic cryptographers and computer scientists. This is why both academia and crypto-currency developers are studying solutions to the problem, and we will see exciting developments in these research areas in the next few years.

Unfortunately, it will take some time before these technologies can be production ready. Until then, what can we do to enhance the privacy of current users? Before presenting a solution, let’s take a step back and see in brief what Oraclize does, and how does it fit in this discussion.

Oraclize: on-demand, provably honest data fetching for smart contracts

Oraclize provides data to smart contracts in a provably honest way.  To access to Oraclize service, smart contract developers have simply to insert a function call with the appropriate parameters in their contract:

oraclize_query('time','datasource', 'query_info','gas_limit');


  • time is the number of seconds which will pass before Oraclize will callback the contract, starting from the call execution. By default,  it’s zero.
  • datasource can be one of the parameters: URL,  WolframAlpha, Blockchain
  • query_info can be an URL with  or without parsing helpers, a question for WolframAlpha or some type of blockchain information. For more information and in-depth explanations, check out our developer documentation.
  • gas_limit is the maximum amount of gas that will be spent by Oraclize in the callback. By default, it’s 200k.

On Ethereum, calls between contracts are simply transactions between addresses with the calling parameters as data payload. As we said in the introduction, and as you will see in a later example, transactions and their data payload are public and it is easy to see their content. This currently prevents developers to fetch data from private or authenticated APIs.

Our Solution: Encrypted Queries

Starting from today, the parameters datasource and query_info can be encrypted locally using the same technology that makes public blockchain secure: namely public key cryptography. Using the opensource tool that we provide, developers can use our public key to encrypt their queries locally before using them in a smart contract. The only one who can then decrypt the call parameters is Oraclize, who will use the paired private key. Secret API keys, or simply any kind of information smart contract developer don’t want or can’t reveal to everybody while querying Oraclize, are now safe from prying eyes. In the later sections, you will see some example of the use cases of this feature. Developers should use it only when they feel that the additional privacy, enabled by encryption, is a requirement for their projects, and they are willing to bear its costs. In fact, since we are using public key cryptography to avoid any kind of authenticated, registration based approach, encrypted queries can be significantly longer that their cleartext counterparts. For example,  if we try to encrypt the following quote:

Privacy is necessary for an open society in the electronic age. Privacy is not secrecy. A private matter is something one doesn't want the whole world to know, but a secret matter is something one doesn't want anybody to know. Privacy is the power to selectively reveal oneself to the world.

We can see that the encrypted text is almost double as long as the cleartext:


On Ethereum,  on-chain data storage comes with a high cost:

  • It costs 20k gas for each additional 32 bytes of storage taken, which at current gas price rate is around 1/3 of US dollar cent.
  • Each instruction of a smart contract carries a gas cost. The sum of all the gas costs cannot be more than the current block gas limit, currently at 4.7 Mgas. Having many (long) encrypted queries in a smart contract will eat up the available gas during contract deployment, reducing the number of instructions the contract can execute for other useful things.

We are therefore actively working on reducing the footprint of encryption. In the close future we will introduce support to more compressed encoding schemes (Base85, z85) and  elliptic curve compact point representation.

Real World Examples

In this section, we will show three examples of why encrypted queries matter and how they will be used.

As we have said before, a contract sends its query parameters to Oraclize as the data payload (hex encoded) of an Ethereum transaction.  For example, here is what you can find analyzing the payload of some of the transactions:


Which decodes to:


If we keep looking into the payload, we can also recover the JSON HTTP POST request, here presented in decoded form:

  “params”: {
t              “apiKey”:”(hidden)”,

As you can see, we have got hold of a potentially secret API key, which we could now use in our own Ethereum smart contract:

oraclize_query( “URL”, “json(https://api.random.org/json-rpc/1/invoke).result.random.data.”, “{“jsonrpc”:”2.0",”method”:”generateIntegers”,”params”:{“apiKey”:”(hidden)”,”n”:1,”min”:1,”max”:10000},”id”:1}”);

or simply from the command line:

curl -H “Content-Type: application/json” -X POST -d ‘{“jsonrpc”:”2.0",”method”:”generateIntegers”,”params”:{“apiKey”:”(hidden)”,”n”:1,”min”:1,”max”:10000},”id”:1}’ https://api.random.org/json-rpc/1/invoke

This API key is used by random.org to limit calls to its JSON-RPC APIs. Their recommendation is to keep them as secret as possible.  Other private APIs providers, instead,  prohibit to publish API keys in a publically accessible format and therefore developers couldn’t use them in a smart contract. Well, until now. This is the same query as shown before, but with an encrypted POST request:

oraclize_query( “URL”, “json(https://api.random.org/json-rpc/1/invoke).result.random.data.”, “BAHlSM7HM0mQZJcxFQiNjGH6XNrubLY26W3ixCDoRm7RI5KDQ0x98oDkQJwyvTVOFI+xdm0HRMeXF2HSGh5yJhQJ2RB6Cn24ejD+UePzry4L5QWjAXmOFqLptA+BVIO/nBFnbLnlxhgiIeziPkQI39ICuB3mPUEcdJE+Tp0+8c0RIFuUzUsbb+lYweNR6Q5VuUftvvuNSH49ao7eOk/NlwpaCB/GB1yeIvlHEGNRhyMy1EQbcqEhj7HeJXrdw1W86ls7eiA1T7y2gBmkMJLp4TNfcaw4daM/ITbK2vhOaYfvd+qze71DuQ==”);

Note: this is not a working example, since I encrypted a JSON with a dummy API key.

Developers can arbitrarily encrypt any of the three string fields, with the third being optional, included in an oraclize_query. For example, it is possible to create a smart contract that awards some type of prize to the first person who is able to guess who said a precise quote. In this case, it would make sense to encrypt the query URL:


Because from the clear text version is quite obvious to who we are referring to:

oraclize_query(“URL”, “html(http://shitelonsays.com/).xpath("//p[@id="quote_34"]/a/text()"));

As you can see in the example, if it’s deemed necessary, also the datasource field can be encrypted. As the number of supported datasources grows, it may become attractive to do so for particular use cases. For example, let’s suppose to have datasources “Vitalik” and “Satoshi“, and a smart contract similar to the previous one:

oraclize_query(“BF5owprO/8PSlI9vfOlxGNAgkKX7gKxQ9SHSDsjCNkSWz45xPROBLdPzCjcHK/Z3S5eCrxOFoQcTobL7wd9lHMReTIdeWw50IMU7C1BhXwLg68gzpDNXhg==”, “What do you think about Litecoin?");

Using encrypted queries, we have successfully hidden our datasource.


In this blog post we have given a small introduction on how to use encrypted queries and why they are important for smart contracts. We invite anyone interested in the technical details to check out our documentation or to contact us on our gitter channel. Soon we will also release a more technical document.



Marco Giglio

Proof of Identity on Ethereum (or the “KYC problem”)

It doesn’t come as a surprise that the “KYC problem” is such a hot topic today when talking about interesting blockchain apps. Everybody keeps talking about it as the killer use case and for a good reason.

The “KYC” term, Know-Your-Customer, has an inherent reference to a centralized approach where a company needs to verify the identity of its customers. If we want to get rid of this company-oriented scenario and move to a decentralized approach, we need to take into account some considerations other than extra complexity. All the parties who will end up using such information would need to agree on the accountability of the identity verification criteria, the only way this can be sorted out is for them to avoid opening unnecessary trustlines. But wait, how can we prove the identity of someone in a trustless way? Unfortunately there is no way (yet) to accomplish that. Still, instead of opening new trustlines we could just rely on the parties we are already putting our trust in. Hey, most of the documents involved in the KYC verification processes are issued by governments already, aren’t they?

So what are we proposing here? Do we want the governments to verify our Ethereum address along with our ID issuance and to send those informations onchain to be reused by all the interested parties? Yes and No.

You may have heard already of the e-residency program run by the Estonian government, the way it does fit with smart contracts is well explained here. I strongly encourage you to read it carefully in order to get a better understanding of what follows.



As Estonian digi-ID devices can already provide RSA signatures verifiable by a smart contract, those signatures can be used to link your real identity with an Ethereum address. This would enable the birth of tons of useful applications, which could leverage this feature to solve the “KYC problem” in a very elegant and secure way.

RSA signatures verification is not “onchain” doable yet on an Ethereum smart contract, however the integration of that feature is being discussed already and, given its importance, we can expect to get something in place pretty soon. A possible temporary replacement could be delegating the RSA signature verification (mostly a bigint modexp) to an oracle like us or to the Ethereum computation market.

So what else is missing? Not much:

  • a smart contract putting all those pieces together to link Ethereum addresses to digi-ID identities
  • a way to check the certificate against the CRL (Certificate Revocation List) to ensure it wasn’t revocated.

What we haven’t already told you is that we got both those pieces ready!



The smart contract implementingthe actual linking is available here along with the web-ui. That code was mostly written a couple of weeks ago during the London Blockathon – thanks to all thidentifyhe team for pushing forward the brainstorming phase so hard (Daniel, Wen, Carlos: it was a real pleasure to work with you all)! The contract is deployed on the Ethereum Morden testnet (check the contract storage here) and it is designed to support the RSA signature checking (note that the web-ui is already integrated with the actual device signing, making the whole process very easy to deal with), but this piece is commented out as we are waiting for RSA_verify/bigint modpow (or some temporary replacement) to be ready.

You can easily check it out from the dapp website.


As you might have noticed, the Estonian digi-ID CRL bridging contract is already available in our github repository as well. There you can find both the base smart contract and a nice web-ui to easily test it. This is deployed on the Morden testnet and is very (VERY!) expensive in terms of gas, making it unfeasible for a production use.. for now. We are in the process of implementing a variation of the same contract based on an Oraclize OCSP datasource – this will make the whole process much cheaper and definitely affordable for this specific use.




Interoperability is one of the key features the blockchain does enable. Think about DAO participants, users of any service, secure wallets, tons of apps.. they can all leverage the same “proof of identity” information that a single smart contract like the one above can hold in itself.

Was the Estonian digi-ID designed for that specific use? It wasn’t. And this is why having open standards is so important.



Thomas Bertani



Understanding oracles

This post is to discuss about what we think oracles really are and to cover some common misconceptions around the matter.

To us an oracle is a third party you have to talk with when you need some data you don’t want to (or you cannot!) fetch by yourself. The reasons for this can be many.

On one side, you might not trust a single entity while signing your Bitcoin multi-signature transaction. Let’s say for example that you want some funds to be moved just under certain conditions. Instead of doing this on your own (which doesn’t give any guarantee to external parties) or delegating this to a third party (which you don’t want to put the trust in, as he could behave badly), the Bitcoin-way to enforce your logic is to split the transaction approval process to different signing parties (oracles?) via multi-signature transactions.

The way to leverage N-of-M multi-signature transactions is to ensure each oracle owns just one private key so that he can put one signature whenever he thinks its the right time to do so, but the transaction will be valid just once N-of-M oracles will have a consensus on which transaction to sign. This is much stronger than trusting a single external party since the chosen oracles might be competing ones and with a low change of being all fraudolent.

The idea of having a distributed oracles network has been there since years, however finding a consensus on an inter-oracle communication protocol (Orisi attempt?) is hard. Finding parties willing to join that network is even harder since a good incentive process needs to be in place and a proper design on how to interact with this oracle network is something there is still not a consensus on. Other than this, a major limitation can be the data-source you want to use to get your data – some of these might not be available without permission to external parties (we’ll talk more in deep about this later).

While talking about smart contracts (Ethereum) the idea is much different, your transaction approving logic is enforced by the network via your own smart contract code. This means the oracle is not putting a signature once some conditions are verified, but instead he is providing to you the data you asked for – the conditions can be verified on your side directly and trigger any transaction or status change.  Still you cannot rely on a distibuted network to get external data: applications/services executed on-chain live in their own walled garden, so you need oracles to throw external data in.

The growing need of data is just the result of a growing industry looking for more and more complex real-world use cases. However, most of the misconception around oracles is caused by a weak definition of what kind of data you might want an oracle to get for you.

For example prediction markets like Augur or Gnosis are meant to give a good and reliable indicator of the evolving sentiment (or knowledge!) of the crowd around future facts. Prediction markets are often referred to as oracles but in a broader and much different sense than the one discussed above.

Another point worth discussing is the following, do we want to call oracle what is just a price feed? That is just a data-source and most of the times it won’t have any connection with blockchains. Financial institutions often refer to “Bloomberg” or “Reuters” as oracles, but what they really mean is using them as data-source. Being the oracle brings with itself all the complexity of interfacing to blockchains, which is something data-sources have no interest in doing directly (extra complexity and costs). Still, an oracle could give access to Bloomberg data once the appropriate data-source and formula are chosen. Referring to those provides as “oracles” instead of “data-sources” is mostly yet another misuse of the term.

To make this more general, we can define 3 entities:

  • data-source
  • query
  • the oracle/oracle network


As for the data-source, this is the source of the information you are looking for, this can be anything depending on your actual query, some examples can be “Augur” (while looking at future events/facts), “Bloomberg” (while looking for financial data), “Bitcoin blockchain” (while looking for an address balance, a given transaction OP_RETURN content or any other blockchain data), “WolframAlpha” (while looking for the response to a given Wolfram Alpha query) or.. “Web”? Getting web data-feeds or APIs data is both the most simple and common place were you want to get some data from.

The query is a formula the data-soure you have chosen can understand in order to give you back the data you want.

The oracle/oracle network is the party in charge of connecting you to the data-source.


The two points worth discuss here are the following.

  1. Why would I trust a data-source? Most of the times you shouldn’t. Finding a consensus on different data-sources is a good way to go and gives you extra reliability while still using somehow “centralized” (useful) data.
  2. What if the oracle/oracle network gives me back a wrong result? This is the main point around preferring to use an oracle network consensus instead of a single oracle. But wait, isn’t there any other way to prevent the oracle to tamper data? We’ll discuss about this in a bit.



The Oraclize approach in being an oracle is different.

You can look at this like something in between the single oracle and an enhanced oracle network. Oraclize could potentially avoid giving back to you a response (for law-enforcement reasons or for downtimes), but cannot alter the data coming from the data-source you have chosen.

This is why we refer to our service as “provably-honest”. The way this is possible is thanks to TLSNotary/pagesigner. It’s a modification of TLS which is used by our oracle service to provide cryptographic proofs showing that the data we provided to you was really the one a given server gave back to us at a specific time. Other than providing this proof, Oraclize is distributing the proof across the permanent web. Being also part of the IPFS persistence consortium our proofs have a good chance to be available even once our system is unreachable (for any reason).

We do provide tools to verify our honesty indipendently. This is for example our network monitor for Ethereum, which is connecting on your client side (this is why it’s so heavy, sorry about that!) to public Ethereum nodes and IPFS gateways (or to your own if you want to) to look for Oraclize transactions, fetch their TLSNotary honesty proofs and verify them.

You can easily monitor the network by yourself to ensure Oraclize is behaving honestly and we really want to encourage you to do that!



What does this mean in practice? If we do alter your data, anybody can verify this at any time, automatically and in a jiffy, our reputation would be broken. If having a one time bad reply still sounds to you as too risky, you probably want to wait for us to release the opensource on-chain proof verification code for Ethereum that we are working on. This means that your smart contract code can verify the TLSNotary proof on its own while receiving the data from Oraclize so that this data is discarted if the proof turns out to be invalid!

In our opinion Oraclize is a good compromise to solve “the oracles problem” in a way which works today and does fit with decentralized blockchains and smart contracts. Having an oracles network would help addressing the “censorship/downtime” issue, but the risks involved in relying on a single oracle only are drastically reduced by the new approach Oraclize is implementing.


Thomas Bertani

Oraclize Dapps – Youtube views count based escrow

As we have previously stated in that post at Oraclize we really think providing some real world use cases is a very concrete way not only to get developers to understand what our service does, but also to get new people involved in the Ethereum decentralized movement.

When talking about real world dapps we don’t mean just releasing their source code (which is still a key point), but even to provide some easy way to interact with them for common people. Not only people but also developers are finding it difficult and non-trivial to learn all the fundamentals Ethereum is built on.

Even if we think understanding all the technical details is very important to better interact, leverage and appreciate this technology, providing a simple ready to use website means putting some fun back into this learning game other than helping learners not to feel left behind.

Our focus is in providing a reliable service to connect smart contracts to Internet data-feeds/APIs, however as a result of our growing team, we have chosen to dedicate some efforts to build dapps.oraclize.it as a platform to show different tangible Oraclize-based applications.


Well, that’s enough chat for today, let’s move on with our first dapp published on dapps.oraclize.it !



Our first dapp is coming from a very concrete need expressed by the community itself few weeks ago. As the webpage title says this is a Youtube video views-count based escrow.

What does it mean in practice?

  1.  you publish/choose a youtube video, a threshold (like 2222 views) and an expiry date (+1 week for example). Then you create a new instance of the smart contract with these given properties (this process is not trivial at this point, but we’ll make it easier as well soon). The published contract is here on identified by its address.
  2. the sponsors (or anybody) can go to the web frontend (readonly!), which shows the status of the contract and all the details in a convenient way (with no need to install anything or to be technical, should be really easy). The only thing you have to specify is the contract address of point 1 (which can be embedded into the url so that it can be easily linked).
  3. the smart contract checks automagically at the given time (+1 week for example) the views-count of the chosen video and if views>threshold it sends 100% of the funds to the contract owner, otherwise it sends to each sponsor 25% of their funds back (as partial refund) and all the rest to the contract owner.

So by using this dapp a youtuber can easily provide to his sponsors a transparent and automated escrow to give them back a partial refund once the sponsored video was not as succesful as they expected.

Well, this is probably easier to see in action, by clicking here.

The source code is available along with other examples in this github repository. Feel free to join our gitter channel and to follow us on Twitter if you want to discuss about this smart contract, we are eager to get your feedback!



Thomas Bertani

The API bridge to the Ethereum testnet is now there

Playing around on Ethereum comes at a cost – while designing your brand new smart contract your time is not the only resource you are spending, but gas costs come in as well.

Other than this, bloating the mainchain with your temporary tests is not something anyone would encourage you to do. This is why developers are mostly testing their Ethereum code on their private chains or on public testnets.

Morden is exactly that. Getting on track with it is as easy as typing “geth –testnet” and you can get some free testnet coins from faucets.

Being Oraclize a bridge between smart contracts and the Internet, one piece of our engine is sitting on the connected chain itself as a smart contract. This means that if you want to test your Oraclize integration, this has had to be done on the Ethereum mainchain – which could be sort of annoying (other than expensive!).

Oraclize can be easily plug in, on our side, with any chain, both public and private.

What we are announcing today is the integration with both Morden (public testnet with networkID 2) and  the test.ether.camp/ConsenSys one (public testnet with networkID 161).

This means that you can test Oraclize on testnets for free (well, paying testnet coins). The way it works is exactly the same as before, the only thing you need to change in your smart contract code is a one-time call to the function oraclize_setNetwork, which is as easy as typing in your constructor code (or wherever you find more appropriate) “oraclize_setNetwork(networkID_testNet)“.

Our Solidity API on github has been updated accordingly – feel free to join our gitter channel if you need any support while poking around with our toolset!


Happy new year and happy coding to all you brave developers :)



Thomas Bertani

Some good open source material to get started

The Ethereum community is producing an impressive amount of projects and ideas which are shaping the way this whole new industry is coming to life. Here at Oraclize we really want to be part of it. This means to us not only to keep providing a useful and reliable service but even to release open source code as a way to say something new and possibly inspiring.

This effort will have as consequence the releasing of different libraries and tools in the next few months, which will be available on our brand new github organization page.



Our first step to make the onboarding process for new developers simpler starts now: we just pushed our Ethereum API to a public repository, which you can always refer to while looking for the most updated Solidity helpers. Our documentation, our Cosmo editor fork and the client-side network monitor source code (for the honesty verification)  will come next.

Other than this we have already created an Ethereum examples repository showing with different Solidity code snippets how easy the integration with the Oraclize API is. We plan to keep this updated with any new code we think it’s worth showing. Having a lot of different examples there, ranging from the traditional HelloWorld to much more complex codes, this repository code base can be a good starting point for learning Solidity hands-on.

We understand that getting around many new concepts is not easy, at all. This is why we got a gitter channel ready, feel free to join if anything is not clear enough to you, if you are looking for support, if you want to tell us how badly designed our system looks to you or if you just want to say hi!



Thomas Bertani

Use case-driven approach

Understanding the rationale behind Oraclize is quite hard and we might be too early to market, we totally get that.

Anyway we think we have something to say and this is the reason why we are constantly trying to spread our vision by building different projects based on our technology. Feel free to call them use cases since this is exactly what they are.

Whether or not what we are doing is like trying to create a new market, this is up to you to say.

What this approach means to us is an effective way to show the potential of our technology in a new still very practical way: does the “use case-driven approach” naming fits better?


So, again, what is Oraclize about? A provably honest oracle (in the.. “blockchain” sense?) service. A platform-agnostic bridge between the blockchain and the Internet. A secure data-feed provider for smart contracts. Web API adapter for blockchain apps. The Bloomberg for decentralised networks. Financial feeds provider for the web3 era. And what about this.. the London temperature-based color changer for your brand new Etheria island.

I’m sure most of you have now an even more confused idea about what Oraclize does.

Let’s try with a different approach now.


Imagine a simple DAO-based flight delays insurance. Sometimes insurance companies have to make decisions based on a variety of information, which takes time to collate and integrate into decisions, and then contact customers to execute the claim transactions. All this takes time and administration cost. For this reason, providing smart insurance with trustless data feeds for contract execution is innovative and cheaper. On the customer side this is appealing because you don’t need to waste time filling up insurance forms. In fact the claiming process can be fully authomated by the smart contract, which is sending the compensation back to you as soon as the flight landed with a delay. On the other side, for the one providing funds to the DAO, this is a totally transparent investment with a probabilistic secure profit coming from premiums based on historical data.

The point where Oraclize comes in is the providing of flights data-feeds straight to the contract, which can then execute its logics based on these data.

This was the idea behind the InsurETH project we made three months ago at the London Fintech Week Hackathon, which ended up as winner.


Again, try to imagine having your web reputation linked to a set of Ethereum addresses. This could be useful in many ways.

For example if you have a smart contract acting as an automated escrow for a ETH/BTC trade, you can have it release the Ethers as soon as the Bitcoin deposit has at least N confirmation, where N could be depending on the reputation of the BTC sending party. This means, in practice, that if the other party has a good reputation the trade will be completed in a timely manner; while if he doesn’t the process will take more time, proportionally.

The contract providing the reputation index is called iudex and recently happened to be
the winner of the Ether-Camp Hackathon.

The cryptographically secure linking of Twitter accounts to Ethereum identities is obtained by iudex smart contracts thanks to the use of Oraclize as bridging to web data.


How are you feeling now?

If you are still confused or if you have any doubts, feel free to get in touch with us by email or on Twitter!

Thomas Bertani