Requesting Support for an ERC-20 with Anchorage

The rise of DeFi and DAOs on Ethereum has led to an explosion of ERC-20 tokens that serve as the unit of account for these applications. This exciting period of experimentation has been accompanied by a significant increase in the number of ERC-20 tokens our clients ask us to support, and in response to this demand, we have built out an industry-leading, risk management-first framework for evaluating new ERC-20’s.

This piece is a guide for both protocol teams and clients alike to know how to request custody support for ERC-20s. And in it, we’ll cover some of the specific criteria we’re obligated to consider, as the first and only operational federally chartered digital asset bank. We hope that in sharing our experience, we can continue to lead the industry as a whole towards greater regulatory clarity, stronger compliance, and better technical innovation for a safe digital asset ecosystem.

Who can request asset support?

As a digital bank that exclusively serves institutions, we are always listening to the requests of our clients and prospective clients. We also encourage token development teams to reach out to us early on for consideration.

When should an institution or protocol team request asset support?

Ideally, this should be done as early as possible in the asset’s life cycle. We are committed to partnering with innovators from day one — not just after they have been “proven” in the market, and our mission has always been to support institutional access. From our past launches of Compound, dYdX, and other ERC-20s at launch, we’ve seen that early support helps protocols and institutions alike.

Doing so provides a longer lead time to support the participation features a token team eventually envisions. While custody is our starting point, we also support vesting, voting, staking, and delegation operations for some eligible protocols. Starting the conversation early gives us space to arrange our roadmap accordingly. If we can handle heavy evaluation lifting before the token has been deployed, then it is largely a question of “turning it on” at launch time.

This does not disqualify tokens that have already been launched. In fact, publicly available data in the form of source code and transaction history streamlines our review process, which we’ll explain in the subsequent section.

What goes into Anchorage’s asset support review process?

Our review process takes a risk management-first approach that uses both compliance considerations and technical implementation details as inputs. Because code enforces the token behavior, the two are often inseparable. For example, we audit the smart contracts to ensure the governance model that a team claims to have is actually reflected in the code.

From a compliance perspective, two major risks we look for are i) the potential for the token to be considered an unregistered security and ii) reputational risk. In accordance with our bank charter, we use existing legal frameworks and tools for these analyses.

When we are evaluating if a token may be a security, we look for:

• Clear utility and functionality. Some examples of this are governance participation rights or payment features. Assets sometimes come with legal opinions on security status or are ranked by industry associations; we take these additional factors into account as well.
• Fair distribution of control over the network. If a single entity exerts disproportionate influence, through token ownership or governance rights, or some other mechanism, it increases the odds of being considered a security. Some ways to mitigate this are having a governance model that incentivizes widespread community participation, publishing token distribution schedules, and market presence/pricing historical data.

With reputational risk, we look for:

• Any non-standard features of the token, such as privacy enhancement. Precedent is important in compliance analysis, so when there is none it is especially important to build a strong understanding of the rationale behind non-standard features. Privacy enhancing tokens, for example, we have chosen not to support because we must have a strong view of the provenance of all our custodied assets.
• Team and investor history. As a regulated bank, we have to comply with strict Bank Secrecy Act and Anti Money Laundering (BSA/AML) laws. Builders should be doing due diligence on their team members, and investors should in turn be doing due diligence on their portfolio companies.

Assuming all compliance checks are passed, the technology review does two things: ensures the stated token functionality is consistent with its implementation, and audits the code structure and process.

The technical review is primarily designed to expose two types of technical risks: i) consistency with stated functionality and ii) vulnerability to exploits.

Consistency with stated functionality means we must be confident that the token will function as advertised in non-technical documents. We need to ensure a match between expected behavior and actual code paths. Checking for vulnerability to exploits involves taking an adversarial view of code quality and determining where there could be a risk to our ability to custody. For example, we look deeply into any privileged roles and associated functions, such as in pausable and proxy contracts. While the presence of these patterns themselves does not signal malicious intent, we have to consider how they are secured against bad actors. Thus, the team’s word that a privileged function is protected is not enough — a technical mitigant such as requiring a threshold of signatures to call the function must be present in the code.

We also check for structural setup, such as a token contract being separate from the rest of the protocol logic to limit complexity, or look to see if tokens use widely accepted open-source code libraries versus creating new, untested functionalities, which require deep review. Lastly, we require that source code must be publicly available on Etherscan.io for auditability purposes.

Because our process is incredibly thorough, the tokens we add for custody support come to our clients well-vetted for long-term custody support and access.

If you’d like to learn more about our asset support at Anchorage, please get in touch.

This post is intended for informational purposes only. It is not to be construed as and does not constitute an offer to sell or a solicitation of an offer to purchase any securities in Anchor Labs, Inc., or any of its subsidiaries, and should not be relied upon to make any investment decisions. Furthermore, nothing within this announcement is intended to provide tax, legal, or investment advice and its contents should not be construed as a recommendation to buy, sell, or hold any security or digital asset or to engage in any transaction therein.