Q. What is the default sorting order of contracts? What are the ones I see when I first enter?
Contract-Library continuously decompiles and analyzes all installed contracts on the Ethereum mainnet and testnets. By default, the contracts are ordered by creation block number, so the first page typically shows very fresh contracts, with zero ether balance and no source code available. Contracts with a lot more attributes can be found in later pages or by searching.
Q. The contract I care about is not decompiled or is not decompiled well. Is there anything I can do?
You can contact us and let us know. Contracts are decompiled and analyzed using automatically chosen settings, designed for maximum throughput. These include, e.g., timeout limits and choice of faster/less precise algorithms if a contract's metrics suggest it is complex. Once we know there is interest in a specific contract, we can change the settings until it is successfully decompiled and analyzed.
Q. How quickly is contract-library updated?
A contract should appear on contract-library within seconds of its creation. Its source code and ETH balance may not be updated until much later, however. Contract-library provides links to most popular blockchain explorers and decompilers, so that you can explore the contract’s status and code at any time, using the best information anyone has at the moment.
Q. Do new vulnerability analyses get added? Do existing analyses get improved? Do results for old contracts get updated?
New vulnerability analyses are added continually (currently at a rate of one every couple of weeks). More importantly, existing vulnerability analyses (e.g., for reentrancy, vulnerable delegatecall instructions, etc.) get updated to be more precise and to apply to more cases. Standard vulnerabilities are unlikely to occur in new contracts, since they are well-recognized by now. This is why we keep enhancing the definitions of vulnerabilities, trying to make them more relevant to current development. Once an analysis has been added or updated, it will immediately apply to all newly installed contracts, and will be eventually applied to all past contracts.
Q. How reliable are the vulnerability warnings?
Vulnerability warnings do not mean that a vulnerability is guaranteed to exist. (In fact, for well-known vulnerabilities, such as reentrancy, it is more likely that the vulnerability is not there.) However, the relevant code is suspicious and should be inspected. The warnings are as reliable as current automatic analysis technology will allow. We continuously work on improving the reliability and coverage of our analyses.
Q. What do these vulnerability warnings even mean? What is Accessible Self-Destruct, Bad Randomness, DoS (induction variable overflow), and all others?
Below is a partial list of descriptions for current vulnerabilities:
  • Accessible selfdestruct: the contract has a call to selfdestruct that seems reachable from public entry points
  • Bad randomness: the contract seems to be using a blockhash (e.g., blockhash(block.number - 1)) as a source of randomness.
  • DoS (induction variable over flow): a variable that changes inside a loop seems easy to overflow (e.g., is a uint8), which can cause unbounded iteration.
  • DoS (unbounded operation): a loop seems to be operating over a data structure whose size can increase as a result of a public call. This can be a source of denial-of-service attacks: an attacker can add a few hundred elements to the data structure and cause the loop to always fail under the current gas limit for the block.
  • DoS (wallet griefing): the contract seems to be calling an external function and blindly propagating exceptions of the called function, even when the call is in the middle of a loop. This is a problem in cases when stalling on a single recipient will prevent others from being reached.
  • Reentrancy: the contract makes an external call, which can itself re-enter the contract before the first call updates storage.
  • Reentrancy (Constantinople): the contract makes an external call that seems safe against reentrancy under the standard, expensive gas model for SSTORE instructions, but possibly not under a model that makes SSTOREs on the same address cheaper.
  • Tainted delegatecall: the contract seems to be making a delegatecall to an address that can be altered via external calls.
  • Tainted ether value: the contract seems to be passing a quantity of Ether that can be altered via external calls.
  • Tainted owner variable: the contract seems to allow altering its owner(s) via external calls. The analysis guesses what storage locations are supposed to represent owners based on how they are used to guard other functionality.
  • Tainted selfdestruct: the contract contains a selfdestruct call that forwards a balance to a recipient that can be changed via external calls.
  • Tainted storage index: the contract contains SSTORE instructions that can write to locations that may be changed via external calls.
Q. How reliable is the contract decompilation shown?
The decompiled code is just presenting in human-readable form the internal representation of the analysis. Some elements may be skipped, if they don’t straightforwardly map to code we can display. Generally, our emphasis is not on producing a decompiler, but on producing analyses for vulnerabilities. The best code inspection is on contract source code, when available. Also, for each contract, contract-library offers links to other popular decompilers (Eveem, EtherVM) so you can get as much information as possible.
Q. Can one add custom analyses? Do you have more analyses than the ones I see?
We currently don’t offer an open API for adding analyses. We are likely to do so in the future, once the value and scope of the service are clearer. We do have private, not shown analyses that we use to assist our manual contract auditing. Most of these are harder to interpret and have little value outside the context of a real contract audit: instead of complete vulnerabilities, they catch partial patterns that an auditor should pay attention to, to ensure that they cannot be combined to become a vulnerability.
Q. Who are you?
We are Dedaub (https://dedaub.com). We build foundational technology for smart contract security and offer auditing services. Contact us at contact@dedaub.com
Q: How does contract-library work?
If you’re interested in the dark magic behind this, take a look at some of our scientific publications: https://www.dedaub.com/blog