# How accurate are Etherscan's internal tx's on Rinkeby for Oraclize calls?

I'm trying to optimize my smart contract and am breaking down where the gas is being spent.

Each execution for one function costs me about $5 in gas. I looked at Etherscan and in the internal tx's it shows a value of$5 sent to Oraclize address for my Oraclize call (just a URL call).

Am i really sending that much gas to Oraclize or is Etherscan's value calculator for internal tx's including storage costs in the function that places the Oraclize call? My oraclize call I put 800000 for gas in the custom parameter.

Thanks for any clarification.

### Disclosure: am an Oraclize employee.

There includes in the Oraclize API a helper function called oraclize_getPrice. It expects two parameters, the first is the data-source you are querying, for example "URL" or "computation", and the second is the gas limit you are providing to Oraclize to run your __callback. It returns the amount of Wei as a type 'uint' that your query will cost, and so take out of your contract when you call oraclize_query.

It's calculated by taking your gas limit supplied (in your case 800000) and multiplying it by the gas price you may or may not have specified. If you haven't set a custom limit via oraclize_setCustomGasPrice then it will default to 20gwei. It will then add to this the base price of the query type you are making, in this case "URL", plus any additional fee for a proof type (You can see the breakdown here). Fees are calculated in Wei using the current USD/ETH exchange rate.

800000 gasLimit * 20e8 gasPrice = 0.016 ETH


Which at the current ETH prices you can see is by far the larger part of the $5 (~ 90%) fee you're seeing leave you contract. And as such, it's imperative you make your __callback (and indeed any function in Solidity) as gas efficient as possible! W/r/t pivoting away from Oraclize, that is of course your prerogative. You still ought to fine-tune the gas prices of your contract functions, since those will need to be paid regardless by either yourself or users of your smart-contract. But what Oraclize offer as a service is a trustless model where, via the proof-types supplied, you don't have to trust Oraclize at all. Better still, you can put a value on that trustlessness. By choosing say the TLS_Notary proof, you're relying on an AWS instance, the cost of hacking/breaking/altering then is quantifiable. This means you know for how much your Oraclize-dependant contract is "safe", incentivally speaking. You can absolutely roll your own of course, but should you start requiring this level of quantifiable trustlessness and thus start implementing the structures required to achieve this, you may soon start to appreciate that$0.05c fee after all!

• I agree with most of what you say. I've been gas optimizing my contract and it is currently \$8 less now overall. That being said, it is because I've sacrificed some storage on-chain and stopped using Oraclize. The problem with Oraclize is it requires extra storage to track queries and who they belong too (I used non-constant delayed queries). Also this is a more specific use-case and not Oraclize's fault in any way but I need the data at a certain non-constant time. Using Oraclize I end up getting the data a few blocks later (or min. later). – savard Aug 25 '18 at 16:11
• Overall it adds computation and storage that ends up costing much more then 0.05c. The UX is also worse. This is the state the chain is at right now, I've realized I need to sacrifice some qualities for now and re-implement them when economically feasible when there are better dev. abilities. – savard Aug 25 '18 at 16:13

The answer is that it is accurate for how much value you're sending to Oraclize and not just how much value was used in the function.

I looked at Oraclize docs. and they use gasPrice of 20 Gwei and I'm setting a custom gasLimit of 800000. Oraclize can't refund unused gas so they take it all.

So 20 Gwei * 800000 wei = 0.016 ETH. Solution would be change the gasPrice from 20 Gwei or gasLimit to lower or don't use Oraclize.

• I don't understand this kind of "added value" services like Oraclize. If you can do it yourself, why pay for it... – Nulik Aug 24 '18 at 18:54
• I agree for production use. For me I used it initially when I just started because it was easier and convenient to get a prototype running (where cost doesn't really matter). They offer the 'provably-fair' which is nice, but you can also make your own method to make it provably-fair. I'm pivoting off them now. – savard Aug 24 '18 at 19:01