How Coinbase reviews tokens on Ethereum for technical security risks

Reviewing digital assets so you don’t have to

At Coinbase, we review every ERC-20 and ERC-721 asset for security concerns before deciding whether to list the asset. In fact, we review every function within each token's smart contract(s) and provide recommendations to our Listings partners based on our findings. Our Ethereum token review framework provides security engineers with an inventory of risks/mitigations and a standardized security review process to determine confidence in custodiability.

Our proprietary security tools combined with a team of blockchain experts has enabled Coinbase to perform over 2,000 Ethereum-based token security reviews. Each of these reviews detects tokens with malicious code by informing us if a token is designed in a way that can put your tokens at risk. At Coinbase, we prioritize the safety and custody of our customers’ funds; if a token contains critical risks to custody, we won’t list it.

In this article, we breakdown our ERC-20 token review framework by detailing the review categories that we examine when performing security reviews of token projects. We explain why these risks matter and detail how similar risks can materialize within our traditional financial system. 

Understanding how smart contracts represent ERC-20/721 assets

Tokens fundamentally achieve two functions: 1) to assign ownership of tokens to users, and 2) to transfer tokens from one user to another. That said, every token may add on additional constraints or functionality modifying the token’s behavior. Because token balances can be impacted by any function within the smart contract code, Coinbase uses proprietary tooling in addition to manual review to facilitate detection, guarding that no risks impacting our customers slip through the cracks.

Coinbase’s Ethereum-based token review framework

Our EVM token review framework looks at risks across three categories:

1. Operational Risk — Authorization features that are exploited when token network governance is insufficient or flawed.

2. Implementation Risk — Intrinsic errors that result in unintended smart contract behavior.

3. Design Risk — Accepted system features that are exploited to alter intended smart contract behavior.

Operational Risks 

In smart contracts, operational risks typically manifest as superuser risks: when single actors have the sole authority to execute a dangerous function, we will not recommend the asset for listing. Instead, we will work with asset issuers to help them apply mitigations to decentralize decision-making across multiple stakeholders of the project. A contract with dangerous superuser roles is only as secure as the protections on those roles. 

When single actors hold the privilege to execute dangerous functions, there is nothing that can stop them from unilaterally executing that risky function and potentially impact millions of token holders; we do not believe this represents an open, blockchain-based financial system. 

To better understand how this risk could materialize, consider what a manifestation of operational risk looks like in traditional finance:

Timmy has $1000 dollars in his bank account. The CEO of the bank, Mr. Smith, decides he’s going to take 20% of his depositors funds to invest in an ‘exciting opportunity’.  Mr. Smith logs into his account and updates the depositor's account balances by moving 20% of user balances to his own personal account leaving Timmy with $800. 

Reframing this interaction within the smart contract paradigm, all of Mr. Smith’s actions would be limited to the functionality that is defined within the contract. If the contract does not have a feature it cannot be executed. Using this same example as above, imagine Timmy has 1000 tokens of Mr. Smith’s ERC-20 project held in his digital wallet and also that the smart contract code has the functionality to take 20% of tokens from holders. Would you want Mr. Smith to have the sole functionality to execute this function? Refer below for what that privilege would look like as a function within a Solidity smart contract:

As these financial service offerings move to the blockchain, operational risk will remain present. Crypto enables users to have easier access to capital, therefore projects should feel empowered to enable functionality for fundraising, investment pooling, lending, etc. However, they should strive to decentralize decision-making to call risky functions in order to create an open, blockchain-based financial system. 

Implementation Risks 

Implementation risks are exchange related risks that can arise when unique or non-standard logic results in unintended behavior. When reviewing an asset for listing, we examine the entirety of the contract code, function by function, and tag unique or non-standard functions that impact our ability to display balances or accurately make transfers. These risks are then communicated to our CryptoEng team who will codify mitigations to support unique or non-standard logic.

Let’s break down an example of unique token logic whereby a token takes a fee whenever a transfer is conducted. Transfer fees are considered critical risks because they impact the ability to track on-chain balances; however, the risk can be mitigated with specific integration measures, when possible.   

Alice wants to send Bob $10 through a new app, SlingCash. Alice inputs the details to send $10 to Bob and confirms the send. Bob only receives $9.75 because SlingCash takes a 2.5% fee in every transaction.  The hidden fee was not clear to Alice or Bob and the two never returned to the app.

Accounting errors exist outside of blockchains, however traditional financial companies have the ability to go back and change their books. In the smart contract world, blockchains are immutable, meaning you can’t just rewind the error (in most cases). Identifying implementation risks and ensuring they are accounted for upon integration will remain a critical risk category as we examine token projects for support. All assets with critical integration risks require evidence of mitigation before they are recommended for launch. 

Design Risks

Only operational and implementation risks have critical risks that can prevent an asset from listing, however, there are additional non-critical risks that can be driven by the assets design. We inventory risks that are non-critical because we want to establish a holistic understanding of the asset. The more insights we have into assets, the better we can support token communities and provide security insights and best practices. Design risks include but are not limited to external calls to other smart contracts, assembly code, off-chain signatures, etc. 

The equivalent of design risk within the traditional finance world could manifest as something such as bad reference data or any other commonly accepted practice with vulnerable risk vectors, for example: 

To produce a price on an exotic option offering, the firm, OptionsGoBurr, requires niche, infrequent trading data to perform the calculations within their in-house pricing team.  The wrong data was pushed to the pricing engine resulting in the exotic options being priced at a 50% discount until the bad data was remediated.

Whether the firm used in-house data or a direct feed from a data vendor, the possible risk of bad data is generally accepted, however it should not be ignored. As a user, imagine putting a stop loss order to sell the exotic option if the option declines 50% and the sale executes due to the pricing error.  No fun.

Contrasting this to smart contracts, external calls deliver data to the smart contract and are considered a commonly accepted practice. Once again, these design features are not immune to risk; in cases where essential balance-impacting functions contain external calls, we may elevate the external call risk to critical and audit the external call dependency that it relies upon to gain additional comfort. In summary, while risks in this category are not direct they still open smart contracts up to potential exploits that could impact custodiability. 

Why Smart Contract Security Matters

The EVM token review framework is designed to assess the quality of an asset’s custodiability based on the design of the smart contacts and the functions contained within. While smart contracts can be exposed to various security risks, our review frameworks focus specifically on the ability to custody an asset. This helps keep our customers' assets secure from common security pitfalls. This gives you the confidence that, when your funds are held by Coinbase, the only person who can move those funds is you. By looking at our risk categories through the lens of traditional finance risks, it can be easier to understand the approach we take to smart contract security when reviewing tokens on Ethereum. We are deeply focused on solving our customers’ problems with technology and enabling them to acquire, store and use crypto. We strive to be the most user friendly, trusted and secure exchange platform in Web3.