This list is constantly updated as new facets are added to the API.
Types of Features
We have defined 6 top level categories that smart contract features fit into. The categories described below cover a broad range of "facets" that may exist within a smart contract. Facets range from interesting smart contract features that users should be aware of, to warnings regarding risk and safety for a given contract. This list will be updated without notice as we continually identify new categories and uncover new threat patterns within the crypto space.
Rugpull
Rugpulls are generally classified as projects that are abandoned by project founders resulting in little to no recourse for the community to recover lost funds or where the value of funds have plummeted to zero. There is also a growing trend of smart contracts written by bad actors to support the likelihood of a future Rugpull. Below are two examples of popular mechanisms that can be hidden within a smart contract.
Drain - Interacting with this type of contract may result in assets being stolen from hot wallets. Drainage is an outcome of a contract reentrancy problem that is increasingly being found in rugpull contracts.
Honeypot - These contracts pretend to leak digital assets to a victim provided the victim sends funds to the contract. Once sufficient funds have been sent by a victim, the contract deployer will often execute a rugpull leaving the victim with no recourse on recovering funds.
| Facet | Why this is important |
|---|---|
| Reentrancy Variant (1, 3, 4) | This contract calls back to the calling contract before its first invocation is complete, potentially causing unexpected or malicious behavior. |
| Unchecked Low-level Calls | This contract may produce a fake transactions which claims to have been successful, though internally it has failed. This can result in a purchased asset not properly being accounted for, and funds being lost. |
| Looped Calls | This contract contains and implementation of a function that is not safe and can lead to exploits such as DOS. |
Asset Value Attack
Asset Value Attacks are a danger to existing asset holders that have interacted with a corresponding smart contract. Assets for existing holders may see a sudden price change resulting from various manipulation technics that are at times enabled through code present within a smart contract. Even though some of these contracts may have their source code published and verified, it is often the case that these smart contracts are effectively rubber stamped, and at various stages of an assets cycle, users often do take the time to take a closer look at the contract they about to interact with. Below are two examples of mechanisms used to invoke an Asset Value Attack.
Supply manipulation - Contact deployers have the ability to mint virtually an unlimited supply of assets, as present with a hidden mint fuction, or a contract does not support multi-sig allowing for virtually no enforcement of perceived asset/contract governance.
Price manipulation - Flash loan attacks are one such example of price manipulation. Contracts that have this feature a acquire debt, use that debt to manipulate the price of another asset, make trades on positions made on the target asset, and then repay the debt all within a single block.
| Facet | Why this is important |
|---|---|
| Reentrancy Variant 2 | This contract calls back to the calling contract before its first invocation is complete, potentially compromising ethereum transfers to the contract. |
| Unchecked Calls | This contract may produce a fake transactions which claims to have been successful, though internally it has failed. This can result in a purchased asset not properly being accounted for, and funds being lost. |
| Unchecked Ether Send | This contract may claimed to have sent ether, when internally the ether send has failed. This can result in lost funds and ether not being properly accounted for. |
| Unchecked Token Transfer | This contract may claimed to have sent tokens, when internally the token send has failed. This can result in lost funds and tokens not being properly accounted for. |
| Transaction Origin | The contract is susceptible to several attacks including phishing attacks, and access control vulnerabilities. |
| Faulty Calculations | This contract contains improper calculations that can lead to a loss of funds. |
| Uninitialized Variables | This contract may behave unexpectedly, which can end up being malicious and therefore in a loss of funds. |
| Hidden Mint | The contract may perform additional minting / supply of the token, and can be altered in a malicious way. |
3rd Party Dependency
More advanced smart contracts may have the need to acquire information or data for a transaction that is not readily available within a given network. If a data set that is not managed and operated in a decentralized fashion is used, there is potential risk that a user may face. When a contract is fed off-chain on-line data that cannot be independently verified, such as pricing feeds or other “oracled” information, users may be tricked to sell or buy under artificial conditions. Using Webacy's DD API, users are now afforded the ability practice more informed diligence when with these types of contracts are being interacted with
Code Mutability
Modern, more sophisticated smart contracts have the ability to be upgraded over time, or upgraded to include new features and functionality. The resulting changes may improve smart contract behavior, but in some cases, behavior may deteriorate. Using the Webacy DD API, users are made aware of this capability, and along with our advanced feature detection, but made aware if changes introduce alter behavior one way or the other.
| Facet | Why this is important |
|---|---|
| Low Level Call | The contract could bypass certain checks and balances, and behave in a way that is unexpected or malicious. |
| Shadowed Implementations | This contract may behave unexpectedly, which can end up being malicious and therefore in a loss of funds. |
Backdoor
Many smart contracts contain administrative functionality as defined by several ERC specifications that allows contract deployers or project owners to implement defensive functionality. For example, being able to pause/unpause or lock a smart contract is a mechanism used to protect asset holders or the project community at large, and is routinely used in ERC20 and ERC721 contracts. However, these defense mechanisms can also be used to allow certain users to bypass security provisions if not implemented correctly or by design. Webacy DD APIs can be used to bring awareness of these features and alert users so they can make more informed decisions.