Coinbase

by Coinbase Cloud team

Coinbase Cloud’s Solana Archival Nodes can examine historical address balances, run complex queries, and simulate the blockchain state at any given point in the chain’s history.

Coinbase Cloud previously launched secure, dedicated Solana infrastructure nodes via Query & Transact, allowing builders to access and verify data and transaction information from the Solana blockchain.

Today, Coinbase Cloud is expanding that offering with the launch of Solana Archival Nodes. Managing archival nodes in a scalable way is technically challenging due to Solana’s high throughput design (~2–3 blocks/sec) and large data footprint (~100TB for all historical data).

We’re excited about helping to empower developers to build better products and services that contribute to the growth of the Solana community!

Solana Archival Node Highlights:

• Built for builders: Solana builders can let Coinbase Cloud do the heavy lifting and access the archival data they need.
• Built with Solana expertise: Coinbase Cloud’s Solana archival node infrastructure is built with deep understanding of the Solana network. We operated one of the first validators on Solana on the Tour de Sol testnet, and have since been running validator and read/write node infrastructure.
• Cloud-based, reliable infrastructure: Coinbase Cloud’s multi-cloud, multi-region infrastructure is architected to minimize downtime risk, and let you access data without skipping a beat.
• Security-first: Coinbase Cloud’s infrastructure is built to meet or exceed the security needs of highly regulated institutions.
• Designated support: Our engineers and customer success team are ready to assist you in managing your infrastructure.

Solana: a high-performance blockchain

Solana is an open source, high-performance, permissionless blockchain that uses highly scalable technology to prioritize transaction throughput, the ability to process a large number of transactions in a short span of time. Solana is currently able to process more than 50,000 transactions per second.

Secure, reliable, and easy-to-use infrastructure is critical for the continued flourishing of the Solana ecosystem. Solana’s high throughput capacity is well-suited for many use cases including trading. The high throughput capacity also requires expertise in developer operations and hardware selection to run a performant node. Nodes require powerful hardware, extremely high bandwidth, and significant protocol expertise to manage participation.

Coinbase Cloud has collaborated closely with the Solana team to support the network as it is growing and scaling securely. We operated one of the first nodes in Tour de Sol, Solana’s incentivized testnet. Since mainnet beta launch, we have helped our clients manage the complexity of participation with secure, tested validator infrastructure run by seasoned protocol engineers and specialists.

Now, we are expanding our Solana offerings to include our Solana Archival Nodes to empower developers interested in building on the blockchain.

Solana Query & Transact: run reliable, secure read/write nodes to build applications and services

With Query & Transact, developers interested in building on Solana can easily run read/write nodes, access data from the blockchain, and build applications and services that connect to Solana.

Even for highly technical teams, running nodes can be an expensive, time-consuming process. It requires strong protocol expertise, staying up-to-date with the latest network changes, and scaling infrastructure to manage potential changes in throughput. These demands are particularly true for Solana read/write infrastructure, given the higher throughput capacity than other protocols.

Coinbase Cloud’s Solana Query & Transact alleviates this challenge and makes it easier to build on Solana. Developers and enterprises interested in building applications and services connected to the Solana network can easily manage their infrastructure from a single platform, and quickly scale their infrastructure based on changing throughput requirements.

Why run Solana Archival Nodes with Coinbase Cloud?

We are infrastructure experts with a deep understanding of the Solana network. With Solana Archival Nodes running on Query & Transact read/write infrastructure, you can focus on your product and customers instead of core node infrastructure.

• High uptime: Our Query & Transact read/write nodes are built on multi-region cloud infrastructure, with 99.9% uptime guarantee.*
• Easy-to-use platform: We make participation and building on blockchains simple, including more complex networks like Solana. You can manage your node infrastructure easily from a single dashboard.
• Dedicated support: Our engineers and customer success team are ready to assist you in managing your infrastructure.

Get in touch with us about our Solana products:

• Solana Participate (staking infrastructure): Secure validator infrastructure to participate in the Solana network.
• Solana Query & Transact (read/write infrastructure): Read/write infrastructure to access data from the Solana network, verify information and transactions, and build products and services that run on Solana.

*subject to the terms and conditions set forth in our SLA, some exceptions apply

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 Solana Archival Nodes to empower the Solana developer community was originally published in The Coinbase Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

Tl;dr: This blog post describes how we developed an efficient, reliable Python ecosystem using Pants, an open source build system, and solved the challenge of managing Python applications at a large scale at Coinbase.

By The Coinbase Compute Platform Team

Python is one of the most frequently used programming languages for data scientists, machine learning practitioners, and blockchain researchers at Coinbase. Over the past few years, we have witnessed a growth of Python applications that aim to solve many challenging problems in the cryptocurrency world like Airflow data pipelines, blockchain analytics tools, machine learning applications, and many others. Based on our internal data, the number of Python applications has almost doubled since Q3, 2022. According to our internal data, today there are approximately 1,500 data processing pipelines and services developed with Python. The total number of builds is around 500 per week at the time of writing. We foresee an even wider application as more Python centric frameworks (such as Ray, Modin, DASK, etc.) are adopted into our data ecosystem.

Choosing the right tool

Engineering success comes largely from choosing the right tools. Building a large-scale Python ecosystem to support our growing engineering requirements could raise some challenges, including using a reliable build system, flexible dependency management, fast software release, and consistent code quality check. However, these challenges can be combated by integrating Pants, a build system developed by Toolchain labs, into the Coinbase build infrastructure. We chose this as the Python build system for the following reasons:

1. Pants is ergonomic and user-friendly,
2. Pants understands many build-related commands, such as “test”, “lint”, “fmt”, “typecheck”, and “package”
3. Pants was designed with real-world Python use as a first-class use-case, including handling third party dependencies. In fact, parts of Pants itself is written in Python (with the rest written in Rust).
4. Pants requires less metadata and BUILD file boilerplate than other tools, thanks to the dependency inference, sensible defaults and auto-generation of BUILD files. Bazel requires a huge amount of handwritten BUILD boilerplate.
5. Pants is easy to extend, with a powerful plugin API that uses idiomatic Python 3 async code, so that users can have a natural control flow in their plugins.
6. Pants has true OSS governance, where any org can play an equal role.
7. Pants has a gentle learning curve. It has much less friction than other tools. The maintenance cost is moderate thanks to the one-click installation experience of the tool and simple configuration files.

Previous problems

Python is one of the most popular programming languages for machine learning and data science applications. However, prior to adopting the Python-first build system, Pants, our internal investment in the Python ecosystem was low in comparison to that of Golang and Ruby — the primary choice for writing services and web applications at Coinbase.

According to the usage statistics of Coinbase’s monorepo, Python today accounts for only 4% of the usage because of lack of build system support. Before 2021, most of the Python projects were in multiple repositories without a unified build infrastructure — leading to the following issues:

1. Challenges with code sharing: The process for an engineer to update a shared library was complex. Changes made to the code were published to an internal PyPI server before being proven to be more stable. A library that was upgraded to a new version, but had not undergone enough testing, could potentially break the dependee that consumed the library without a pinned version.
2. Lack of streamlined release process: Code change often required complicated cross-repository updates and releases. There was no automatic workflow to carry out the integration and staging tests for the relevant changes. The lack of coherent observability and reliability imposed a tremendous engineering overhead.
3. Inconsistent development experiences: Development experience varied a lot as each repository had its own way of virtual environment setup, code quality check, build and deployment etc.

Building PyNest for data organization

We decided to build PyNest — a new Python “monorepo” for the data organization at Coinbase. It is not our intention for PyNest to be use as a monorepo for the entire company, but rather that the repository is used for projects within the data organization.

1. Building a company-wide monorepo requires a team of elites. We do not have enough crew to reproduce the success stories of monorepos at Facebook, Twitter, and Google.
2. Python is primarily used within the data org in the company. It is important to set the right scope so that we can focus on data priorities without being distracted by ad hoc requirements. The PyNest build infrastructure can be reused by other teams to expedite their Python repositories.
3. It is desirable to consolidate mutually dependent projects (see the dependency graph for ML platform projects) into a single repository to prevent inadvertent cyclic dependencies.

Figure 1. Dependency graph for machine learning platform (MLP) projects.

1. Although monorepo promised a new world of productivity, it has been proven not to be a long term solution for Coinbase. The Golang monorepo is a lesson, where problems emerged after a year of usage such as sprawling codebase, failed IDE integrations, slow CI/CD, out-of-date dependencies, etc.
2. Open source projects should be kept in individual repositories.

The graph below shows the repository architecture at Coinbase, where the green blocks indicate the new Python ecosystem we have built. Inter-repository operability is achieved by serving layers including the code artifacts and schema registry.

Figure 2. Repository architecture at Coinbase

PyNest repository structure

# third-party dependencies

# third-party dependencies

├── 3rdparty

│   ├── dependency1

│   │   ├── BUILD

│   │   ├── requirements.txt

│   │   └── resolve1.lock # lockfile

│   │

│   └── dependency2

│   │   ├── BUILD

│   │   ├── requirements.txt

│   │   └── resolve2.lock

...

│

# shared libraries

├── lib

│

# top level project folders

├── project1 # project name

│    ├── src

│    │    └── python

│    │         ├── databricks

│    │         │    ├── BUILD

│    │         │    ├── OWNERS

│    │         │    ├── gateway.py

│    │         │    ...

│    │         └── notebook

│    │              ├── BUILD

│    │              ├── OWNERS

│    │              ├── etl_job.py

│    │              ...

│    └── test

│         └── python

│              ├── databricks

│              │    ├── BUILD

│              │    ├── gateway_test.py

│              │    ...

│              └── notebook

│                   ├── BUILD

│                   ├── etl_job_test.py

│                   ...

├── project2

...

│

# Docker files

├── dockerfiles

│

# tools for lint, formatting, etc.

├── tools

│

# Buildkite CI workflow

├── .buildkite

│    ├── pipeline.yml

│    └── hooks

│

# Pants library

├── pants

├── pants.toml

└── pants.ci.toml

Figure 3. Pynest repository structure

The following is a list of the major elements of the repository and their explanations.

1. 3rdparty

Third party dependencies are placed under this folder. Pants will parse the requirements.txt files and automatically generate the “python_requirement” target for each of the dependencies. Multiple versions of the same dependency are supported by the multiple lockfiles feature of Pants. This feature makes it possible for projects to have conflicts in either direct or transitive dependencies. Pants generates lockfiles to pin every dependency and ensure a reproducible build. More explanations of the pants multiple lock is in the dependency management section.

2. Lib

Shared libraries accessible to all the projects. Projects within PyNest can directly import the source code. For projects outside PyNest, the libraries can be accessed via pip installing the wheel files from an internal PyPI server.

3. Project folders

Individual projects live in this folder. The folder path is formatted as “{project_name}/{src or test}/python/{namespace}”. The source root is configured as “src/python” or “test/python”, and the underneath namespace is used to isolate the modules.

4. Code owner files

Code owner files (OWNERS) are added to the folders to define the individuals or teams that are responsible for the code in the folder tree. The CI workflow invokes a script to compile all the OWNERS files into a CODEOWNERS file under “.github/”. Code owner approval rule requires all pull requests to have at least one approval from the group of code owners before they can be merged.

5. Tools

Tools folder contains the configuration files for the code quality tools, e.g. flake8, black, isort, mypy, etc. These files are referenced by Pants to configure the linters.

6. Buildkite workflow

Coinbase uses Buildkite as the CI platform. The Buildkite workflow and the hook definitions are defined in this folder. The CI workflow defines the steps such as

• Check whether dependency lockfiles need updating.
• Execute lints and code quality tools.
• Build source code and docker images.
• Runs unit and integration tests.
• Generates reports of code coverages.

7. Dockerfiles

Dockerfiles are defined in this folder. The docker images are built by the CI workflow and deployed by Codeflow — an internal deployment platform at Coinbase.

8. Pants libraries

This folder contains the Pants script and the configuration files (pants.toml, pants.ci.toml).

This article describes how we build PyNest using the Pants build system. In our next blog post, we will explain dependency management and CI/CD.

Building a Python ecosystem for efficient and reliable development was originally published in The Coinbase Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

A guide to the projects and companies working to make web3 development as easy as web2

Around the Block, from Coinbase Ventures sheds light on key trends in crypto. Written by Jonathan King, Connor Dempsey, & Hoolie Tejwani

Special thanks to Mike Armstrong, Aaron Henshaw, Michael Atassi, Steven Willinger, and Shan Aggarwal for helping to inform this article.

Despite the rise of Bitcoin and Ethereum, along with the emergence of new categories like DeFi, NFTs, GameFi and DAOs, web3 developers represent less than 1% of the 31.1M software developers globally.*

So why are there so few developers in web3 today? For one, the tools and infrastructure available to web3 developers are much less robust than that of web2. This simply makes it more difficult to get started building, experimenting, and deploying in web3. That’s all quickly changing however, as the number of monthly active web3 developers hit all-time highs at the end of 2021. And to support this growing contingency, is a vibrant ecosystem of teams working to simplify the entire web3 developer journey, which will ultimately help unlock the next stage of web3 growth and innovation.

In this edition of Around The Block, we’ll explore the growing web3 developer stack.

The Web3 Developer Stack

Building in Web2 vs Web3

Software development is the process of building computer programs. There are three main components to a given program:

1. The front-end (what users interact with)
2. The back-end (what users don’t see)
3. Database (where critical data is stored)

The front-end that a typical user interacts with through a mobile or desktop browser is basically the same in web2 and web3. A web3 app like Uniswap looks similar to a typical web2 app because both front-ends are mostly created using React — a popular developer framework for web and mobile apps.

It’s under the hood where web2 and web3 differ. The backend frameworks and types of databases that make web3’s defining characteristic — user-defined ownership — possible are new and unique.

Where web2 applications largely rely on centralized databases, web3 applications are built on decentralized databases (blockchains). This requires entirely new backends and new primitives like wallets.

The tools that aid in the creation, deployment, and maintenance of web2 applications are incredibly developer-friendly, thanks to decades of cumulative development. Out of the box solutions, mature infrastructure, shared code libraries, and easy to use frameworks largely make building in web2 a breeze.

Web3 on the other hand still requires specialized expertise to interface with complex infrastructure and commonly involves many redundant processes given that the stack is less developed, leaving teams to have to reinvent the wheel. That said, the tooling that will help onboard the next 1M+ web3 developers is rapidly improving.

Let’s take a (non-exhaustive) look at the evolving Web3 developer stack layer by layer (* denotes Coinbase Ventures portfolio company).

Protocol layer

The first decision a web3 developer has to make is which blockchain protocol to build on. Building on Bitcoin is entirely different from building on Ethereum, and Solana differs from Ethereum, etc.

For faster and lower-cost applications, developers might want to build on a layer2 protocol — Optimism*, Arbitrum*, etc. For applications that need to port value from one chain to another, developers will want to leverage cross-chain bridges like Hop* or Synapse*.

Once these decisions are made, developers can start to incorporate building blocks that make user applications possible.

Infrastructure primitives

The next thing a developer needs to figure out is how their application will ultimately interact with the underlying blockchains. This is where infrastructure primitives come into play.

Node infrastructure — Nodes are where an app’s interaction with a blockchain “happens.” They’re computers that read the state of the blockchain and write updates to it once a user interacts with an application. Node infrastructure providers like Coinbase Cloud, Infura*, and Alchemy* let developers easily set-up, manage, or access blockchain nodes, saving developers considerable time and resources.

Wallet & Key Management — Blockchain wallets, like Coinbase Wallet, allow users to manage the private keys needed to perform transactions within web3 applications. Wallet and key management providers like Web3Auth* or Pine Street Labs*, enable developers to build secure connectivity between blockchain wallets and user-facing applications.

Identity — protocols like ENS* serve as a user’s identity across applications. Spruce* provides frameworks and toolkits that developers can use to verify user credentials to authenticate actions on Ethereum. For example, developers can use the Spruce ID toolkit to empower users to sign into dApps with their ENS accounts. Additionally, companies like Lit Protocol provide developer tooling for granting access to content, software, and other data utilizing their tokens or NFTs.

Decentralized compute — Compute resources provide processing power that applications rely on to carry out computational tasks. Currently, most of the web’s compute is provided by centrally owned providers like AWS. Decentralized compute is a shift towards community-owned networks, in which compute resources are distributed in a permissionless manner at low-cost. Companies like Akash Network and Aleph.im have emerged to provide peer-to-peer compute resources that are highly-performant and optimized for smart contracts and blockchain applications.

Decentralized storage — Storing every piece of data associated with a given web3 app directly on blockchain nodes is costly. Rather than storing data on a centralized database, web3 developers can use peer-to-peer data storage protocols like IPFS, Arweave*, and Ceramic Network* for certain data. For example, web3 blogging site Mirror is built on Ethereum, but stores actual blog content on Arweave.

Oracles — For a typical Ethereum application, the blockchain stores transaction history and “state” (balances, smart contracts, and other variables). It can’t, however, natively store and interact with data from external sources — i.e. transaction history from other blockchains or “real world” data like the weather in San Francisco. That’s where oracles like Chainlink or Flux*come in, connecting blockchains to on-chain and off-chain data sources.

Interoperability — many different blockchains exist but few have the ability to exchange value and make use of information cross-chain. Interoperability protocols like LayerZero* and Astar Network* provide SDKs and APis for developers to build dApps that are portable and can communicate with different blockchains.

Developer tools

Atop the infrastructure primitives that allow applications to interact with blockchain networks are tools that allow developers to more seamlessly interact with the above-named primitives.

Frameworks & IDEs — Developer frameworks consist of libraries of code that other developers have created that make development easier. Web3 frameworks like Truffle, Moralis*, Tatum, and ThirdWeb*, let developers leverage existing code for smart contract applications so they don’t have to build everything from scratch. They also let developers test and deploy applications. Integrated development environments (IDEs) like Foundry and HardHat combine common source code editors, and build automation and debugging tools into a single, easily accessible interface.

Low-code / No-code — These platforms enable user-facing applications to be quickly designed/deployed entirely via drag-and-drop interfaces. Companies like Settlemint provide developers with smart contract templates for NFTs to prevent web3 developers from having to reinvent the wheel.

Index & query — Data indexers help people locate and access specific data within an underlying database. In Web2, Google search is the most popular data indexing service that allows users to query data stored in online databases with sub-second response times. In Web3, decentralized indexing services are emerging to help dApp developers fetch, process, and query blockchain data. The Graph Protocol*, Covalent*, and Coherent* all provide APIs for extracting and making use of data from decentralized data storage providers and EVM-compatible blockchains.

Test, simulate, & monitor — It’s important to test and simulate web3 applications before they’re released into the wild. Companies like Tenderly* and Kurtosis* offer a variety of tools for simulating how smart contracts and transactions will behave once live, as well as tools for debugging any issues. Blocknative* provides dashboards and tools for monitoring transactions before they are submitted on-chain.

Security & audit — Given the potential for smart contract exploits, these platforms let developers apply security and audit best practices to their applications. OpenZeppelin*, Certik*, and Certora* all provide a variety of services, frameworks, and monitoring tools for developers to mitigate potential security risks and vulnerabilities.

Messaging — Web3 apps often involve sending various communications to end users. For example, a crypto wallet may want to push a user alerts regarding transaction confirmations. Companies like XMTP Labs* and EPNS are building secure messaging protocols and decentralized communication networks that drive user engagement and power these notifications within Web3 applications.

Analytics — There’s a host of platforms and services that let developers explore, analyze, extract, and visual blockchain data. Dune*, Nansen*, and Messari* each offer a variety of APIs and reporting capabilities to build data visualization features within web3 apps. Flipside Crypto* offers SDKs (software development kits) and APIs to create and share data insights on various crypto projects.

App Enablement Layer

The application enablement layer ties all of the above layers into specific web3 uses. NFTs, DAOs, DeFi, and gaming each have their own bespoke developer solutions.

NFT focused tools offer infrastructure for creating and managing NFT assets. DAO tools offer solutions for DAO creation (Syndicate*, Samudai*), governance (Snapshot*), and treasury management (Utopia Labs*). DeFi focused tools offer APIs that let developers access various DeFi primitives. Gaming focused tools ( Venly*, Joyride*, Horizon Blockchain Games*) provide solutions for creating virtual worlds and blockchain based games.

The ever-evolving dev stack

The protocols, infrastructure, and developer tools mentioned above make up the nascent, yet evolving web3 developer stack. The modular and interoperable nature of web3 means that the stack can be combined in endless ways to create new and interesting applications.

While the framework and layers we highlighted will likely remain unchanged, we continue to see new developer tooling primitives emerge and expect the entire stack to evolve dramatically in the coming years.

Coinbase Ventures will continue to invest in the next generation of platform and developer tooling that will ultimately onboard millions of developers into web3. If you’re as dedicated to building out the web3 dev stack as we are, we would love to hear from you — JK’s DMs are open!

Further Reading

• A simple guide to the Web3 stack, by Angie Wang, Connor Dempsey, and Justin Mart
• Electric Capital Developer Report 2021, by Electric Capital
• The Architecture of a Web 3.0 application, by Preethi Kasireddy

This website does not disclose material nonpublic information pertaining to Coinbase or Coinbase Venture’s portfolio companies.

Disclaimer: The opinions expressed on this website are those of the authors who may be associated persons of Coinbase, Inc., or its affiliates (“Coinbase”) and who do not represent the views, opinions and positions of Coinbase. Information is provided for general educational purposes only and is not intended to constitute investment or other advice on financial products. Coinbase makes no representations as to the accuracy, completeness, timeliness, suitability, or validity of any information on this website and will not be liable for any errors, omissions, or delays in this information or any losses, injuries, or damages arising from its display or use. Unless otherwise noted, all images provided herein are the property of Coinbase. This website contains links to third-party websites or other content for information purposes only. Third-party websites are not under the control of Coinbase, and Coinbase is not responsible for their contents. The inclusion of any link does not imply endorsement, approval or recommendation by Coinbase of the site or any association with its operators.

A simple guide to the web3 developer stack was originally published in The Coinbase Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

Tl;dr: The following post recaps this episode of Coinbase’s Around The Block podcast in which Viktor Bunin hosts Coinbase CEO Brian Armstrong and Ethereum co-founder Vitalik Buterin discuss decentralization, privacy, and a credibly neutral Ethereum.

By Viktor Bunin, Senior Protocol Specialist at Coinbase Cloud

After 7 years of research and development, the Merge is just around the corner. A crowning achievement, the Merge will finally transition Ethereum from Proof-of-work (PoW) to Proof-of-stake (PoS).

I encourage everyone to listen to the whole episode, but I wanted to take this opportunity to pull out what I believe are the key messages to take away from the conversation between two industry giants.

• The transition to PoS wasn’t immediately obvious. As Vitalik put it, even if the idea can be scary as if it’s a pond filled with sharks, once you figure the sharks out, you at least know what you’re going up against, which makes it possible to deal with the problem.
• Scientists and engineers are equally needed. Incredible researchers, like Vitalik, do the tough work of pushing the envelope on what’s possible, but it’s up to the builders to then take the baton, commercialize the products, and bring the technology to millions of users.
• Good times create centralized projects. Bull markets tilt the scale from principles to expediency until a bear market tilts them back. The reality is that principles aren’t just principles, they result in decisions that keep projects secure and mindsets that keep builders building.
• Decentralization is vital low in the stack. If the foundational layer breaks or is corrupted, everything built on top of it breaks as well.
• Ethereum is more robust and decentralized on PoS. Anyone can spin up an Ethereum validator anywhere in the world with much less capital and technical skills compared to mining. All you need is a computer with an internet connection.
• Ethereum will continue decentralizing its infrastructure operations. Proposer-Builder Separation will take away a validator’s ability to express a preference over the contents of the blocks they create, making censorship at the block level impossible.
• OFAC took its first action involving DeFi. The recent Tornado Cash action is the first time OFAC has sanctioned a technology (smart contract) and it has raised questions with many groups (CoinCenter, EFF, CCI, etc.) about whether this was an overstep of OFAC’s authority.
• Coinbase prioritizes and supports decentralization for Ethereum’s base layer. As mentioned earlier, decentralization is vital low in the stack, and there’s nothing lower than Ethereum’s base layer. In the hypothetical scenario where Coinbase is forced to censor, we would rather wind down our staking operation to preserve the integrity of the overall network.
• Privacy is solvable. We can solve swaths of the challenges with privacy through technological solutions that enable user privacy while minimizing privacy for criminals.
• We need to build the future we want to see. You need to make “stuff!” It doesn’t just magically appear. Decentralized identity must be created, it won’t spawn into being just because crypto becomes successful.
• Values and culture must be cultivated. Whether the community is centralized or decentralized, it’s crucial for leaders to set and encourage cultural alignment around a set of values. Without cultivation, undesirable characteristics may rise and cause community fragmentation.
• Crypto is global. The world is moving towards a global mindset and crypto is already there. One way in which Coinbase is adopting this mindset is by supporting global apps like Coinbase Wallet.
• There are still unsolved problems. The best currency, building the “freedom stack,” e-charter cities, VR, climate change, and so on must be decided upon and created.

There’s still a lot more to build and it’s important we continue working together to build the future of crypto, grow the entire ecosystem, and remain eternally optimistic and collaborative.

Decentralization, privacy, and a credibly neutral Ethereum was originally published in The Coinbase Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

tl;dr How we protect personal information while complying with existing laws and regulations.

Recently, we’ve received questions about why we occasionally review specific accounts and ask for more detailed personal information about the owners of those accounts. In short, we do this to meet our regulatory obligations. Here’s a more detailed explanation:

At Coinbase, we strive to be the most trusted platform for buying, selling, and exchanging digital assets. Trust is the best way to help more people participate in the cryptoeconomy and reach our goal of increasing economic freedom around the world.

Earning and maintaining trust requires us to ensure the integrity of all transactions supported by our platform. And an important part of doing that is abiding by relevant laws and regulations. We’ve always believed that for crypto to gain the legitimacy needed for mainstream adoption, compliance can’t be an afterthought — it is core to the way we operate.

In practice, this means following laws and regulations in different jurisdictions, some of which are more stringent than others.

Crypto is a highly regulated market, with various parts of it overseen by many different federal regulatory agencies, individual states and others — and that’s just in the U.S. If we want to offer Coinbase services in other countries, we also have to comply with local regulations. In some cases, this includes the Travel Rule, which requires companies like Coinbase to exchange information about the participants in crypto transactions under certain circumstances.

Over time, the advantages of web3 may allow people to create and own centralized identities, sharing much less information with third parties and keeping that information more secure. We’re also excited about advances in digital identity which may move us away from reliance on traditional forms of identification, like driver’s licenses and other paper documents. But for now, companies like Coinbase are required to follow existing regulations, some of which have been on the books since before the Internet even existed.

This means we have to ask our customers for basic information about themselves and their businesses. Sometimes, and for a very small percentage of our customer base, we need much more detailed information. This helps us to comply with “Know Your Customer” regulations and keep Coinbase and the cryptoeconomy safe. No matter what, we are committed to protecting our customers’ privacy and providing a smooth and intuitive customer experience.

As part of our ongoing efforts to keep our customers safe, we’ve also organized a coalition to help other companies comply with global regulations, following industry leading safeguards to protect customers’ privacy and security. To join this coalition, and receive Travel Rule information, all participants must meet anti-money laundering, security, and privacy requirements.

We’ve also developed proprietary blockchain analytics capabilities to help secure the crypto economy from bad actors. And we have ongoing dialogues with policymakers globally where we advocate for consistent and reasonable requirements that protect our customers’ privacy.

While some within the digital currency industry have questioned the application of more traditional Know Your Customer (“KYC”) requirements in this novel space, widespread adoption of crypto will depend on building and maintaining the trust and integrity of the ecosystem. For crypto to succeed, people need to be able to buy digital currency with common payment methods, and feel safe doing so. The only way that can happen is if companies like Coinbase follow local laws and regulations, while partnering with policymakers to guide the next generation of rulemaking in this space. Put simply, if we want crypto to be widely accepted, compliance can’t be optional.

That’s why we’ll keep working to be an industry leader in compliance — protecting our customers, preserving trust, and building the cryptoeconomy.

Compliance and Protecting Personal Information was originally published in The Coinbase Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

Tl;dr: The following post details how we measure client performance across products and cross-functional teams at Coinbase.

By Leonardo Zizzamia, Senior Staff Software Engineer

A lot has changed since 2018 when the Coinbase web team consisted of only a few engineers. Back then, while working on making our product faster with a small group across a single platform, we could rely on pre-existing open source tools.

In 2022, Coinbase now has engineers working across multiple product offerings and four platforms: React Web, React Native, Server Side Rendering and Chrome Extension. Performance across all four platforms had never previously been standardized, so we needed to address several aspects: a lack of sufficient, complete data for some platforms, the loss of efficiency when performance opportunities could not be identified, and consistent prioritization across all teams.

Knowing this, we introduced the Performance Vitals: A high-level scoring system that is clear, trusted, and easy to understand. Summarizing the performance health of an application into a reliable and consistent score helps increase urgency and directs company attention and resources towards addressing each performance opportunity.

Extending Google Web Vitals

The Web developer community has the Core Web Vitals standard to help measure client performance, which we have adopted and use actively at Coinbase.

Vital metrics are differentiated by thresholds that categorize each performance measurement as either “good”, “needs improvement”, or “poor”.

Below is one example of where the threshold could lie for one of the Web Vitals, Time to First Byte.

To classify overall performance of a client product, Coinbase follows best practices and uses the 85th percentile value of all measurements for that page or screen. In other words, if at least 85% of measurements on a site meet the “good” threshold, the site is classified as having “good” performance for that metric. This metric is 10 points higher than the Google Web Vitals standard, giving us enough bandwidth to fix potential regressions.

The primary tool we use to capture these metrics is the Perfume.js library, a wrapper around the Performance Observer API that helps us measure all Core Web Vitals. However, as we are the primary maintainer of this library, we used this opportunity to research and develop new solutions around web performance measurements and ways of attribution.

Today we introduce an innovative, in-house metric we call the Navigation Total Blocking Time (NTBT). The NTBT measures the amount of time the application may be blocked from processing code during the 2 second window after a user navigates from page A to page B. The NTBT metric is the summation of the blocking time for all long tasks within the 2s window after this method is invoked.

The image below is an example of an NTBT performance mark in coinbase.com helping a client engineer track down the long task and improve responsiveness when navigating between pages.

Another way it is helpful to use Perfume.js is that we are able to enrich all the metrics with the Navigator APIs info, to differentiate between low-end and high-end experiences.

After adopting and extending Web Vitals, the next step for us was to repurpose this knowledge throughout our stack.

Coinbase Performance Vitals

In addition to building web apps, we build React Native mobile apps and the services that provide their data. We re-used the Web Vitals best practices and created new metrics to serve React Native applications and our Backend services. Together, we call them “Performance Vitals”, and they give us a holistic view of the performance scores of all of our applications, from downstream (Browser & Apps) to upstream (Backend Services).

As seen in the chart below, the Performance Vitals are divided end-to-end, from downstream to upstream.

Creating React Native Vitals

When evaluating performance for React Native we developed the initial Vitals of App Render Complete and Navigation Total Blocking Time.

• App Render Complete (ARC): Measures the amount of time it takes to get from starting the application to fully rendering the content to the user without loading indicators. The Good threshold of 5s is based on guidance from the Android community official research.
• Navigation Total Blocking Time (NTBT): Measures the amount of time the application may be blocked from processing code during the 2s window after a user navigates from screen A to screen B.

For NTBT we used the existing knowledge around Total Blocking Time from Web Vitals to determine a threshold for mobile. Given that a good TBT on Web is 200ms and we anticipate mobile to take longer, we doubled the standard from Web to arrive at 400ms for mobile.

The following video shows how a product engineer can detect long-tasks, measure total blocking time when navigating between pages, and additional NTBT measurements.

This metric helps catch potential sluggishness in a user interface, usually caused by executing long tasks on the main thread, blocking rendering, or expending too much processor power on background processes.

Similar to the experience of Web, Coinbase built an in-house React Native Core Vitals library to measure this performance, with the goal of open sourcing our discovery back to the community in the coming quarters.

Creating Backend Vitals

As we did with Web and React Native Vitals, we extended the Vitals standard to backend services including GraphQL and Backend Services.

The two metrics we first created are:

• GraphQL Response Time (GRT): Round trip time for the GraphQL service to serve a request.
• Upstream Response Time (URT): Round trip time for the API Gateway to serve a backend service.

To determine a Good Score to represent backend latency, we considered several points:

1. From a user’s perspective, the system response time feels immediate when it is less than 1s.
2. We also have to take into account that the network cost could vary between 50ms-500ms, depending on which region a user is reaching our product from.
3. Based on points 1 and 2, GraphQL latency should not exceed 500ms, meaning the upstream services must respond in under 300ms because GraphQL queries have to await the slowest endpoint.
4. Therefore, we concluded that the threshold for a GRT Good score is 500ms, and URT Good score is 300ms.

For Backend Vitals we aim for at least 99 percent of measurements for each logged request to meet the “Good” threshold.

As we continue to improve our performance, we will revisit our Good scores annually, potentially even lowering them over time so we can further lower latency for our users.

The instrumentation for Backend Vitals is made up of three essential pieces. First, we use our in-house analytics library to define metadata like the product, platform, and pages. Then, we propagate this information into our APIs, and ultimately we co-locate the performance metrics with the Web or React Native metadata.

Performance Vitals discoverability and prioritization

Using the same metric scoring and attribution system across different specialties at Coinbase makes it easy to identify areas of opportunity and aligns both frontend and backend engineers in performance efforts.

All Performance Vitals are based on real-time data from our production applications and can be discovered by standardized filters, such as: product name, platform, page, is logged in, geo region, GraphQL operation, and backend service.

This level of accuracy becomes especially useful for Real Time Anomaly Detection. All teams are able to own the performance metrics for their product surface, giving them the ability to have automated monitors for performance changes and be alerted when regressions occur.

In case of a performance regression, we use the percentage of the regression to determine if it’s critical to open an incident and mitigate the issue as soon as possible, or create a bug that can be solved in the coming sprint.

Quarterly and annual planning

Performance Vitals are perfect for KR planning, as they measure a score from 0 to 100 and they can be easily stored for over a year. Common language for all performance KRs also makes it easier to create shared goals for teams across the organization.

A few examples of how you can frame your KRs are:

• [Year KR] Reach NTBT Good Score of 90%, up from 70% in the Coinbase Mobile App.
• [Quarter KR] Improve LCP Good Score from 70% to 85% in the Coinbase Web.

Up Next

Performance Vitals come back to finding a common language, whether it’s standardizing filters, setting quarterly KR’s, or unifying a scoring system. From a small team working on an API regression to large initiatives led by multiple organizations, speaking the same language helps all types of product prioritization.

In the future, we plan to open source some of our learnings and share more about measuring and driving impact for Critical User Journeys and how we use automation and internal processes to enable everyone at Coinbase to build performant products.

Performance Vitals: a unified scoring system to guide performance health and prioritization 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 Derivatives Exchange will launch its second listed crypto derivatives product on August 29th, 2022: Nano Ether futures contract (ET).
• ET futures will be accessible for trading via several leading third-party retail brokers and clearing firms upon its launch.
• Since launching on June 27th, the Nano Bitcoin futures contract (BIT) has traded a total of 2.9MM contracts as of August 24th.

By Boris Ilyevsky, Head of Coinbase Derivatives Exchange

Coinbase Derivatives Exchange will be launching a Nano Ether futures contract (ET) on August 29th as we continue to build an accessible futures market for the retail trader.

Sized at 1/10th of an ether, the contract unlocks another opportunity to trade the price of a popular digital asset with less upfront capital than traditional futures products. This will enable all types of traders to securely access regulated U.S. crypto derivatives markets to express their views or hedge their underlying crypto assets.

This launch follows the introduction of our Nano Bitcoin futures contract, which was made available on June 27th to the participants of six retail brokers through our CFTC-regulated Designated Contract Market (DCM). In the last 30 days, that contract has traded an average of 77,000 contracts per day.

While still in its early stages, we believe that product innovation and an accessible entry point for the retail market have contributed to its success. At 1/100th of Bitcoin, our Nano Bitcoin futures contract requires less upfront capital, allowing participants to easily go long or short the price of Bitcoin and manage risk in volatile markets.

Similar to the Bitcoin contract, the Nano Ether futures will be made available for trading via the following retail brokers EdgeClear, Ironbeam, NinjaTrader, Optimus Futures, Stage 5, and Tradovate, and clearing firms ABN AMRO, ADMIS, Advantage Futures, Dorman Trading, ED&F Man, Ironbeam and Wedbush.

Coinbase Financial Markets is awaiting approval for its license to operate a futures commission merchant (“FCM”) to offer futures directly to our clients as we take another step in creating an accessible and regulated U.S. crypto derivatives market.

For more information on our products, visit coinbase.com/derivatives.

Coinbase Derivatives Exchange to add Nano Ether Futures Contract was originally published in The Coinbase Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

By Faryar Shirzad, Chief Policy Officer

Tl;dr: We’re launching our U.S. crypto policy education initiative today, which includes a voter registration portal, to respond to our community’s strong interest in learning more about where their representatives and candidates for public office stand on issues of importance to the crypto community, and in finding ways to have their voices heard.

Today, Coinbase launched a voter registration tool as part of a broader education initiative to give the crypto community tools to participate in the critical policy discussions happening across the United States. We’ve heard loud and clear from our customers that they want to get involved in these debates and are looking for trusted resources, tools, and support to help them be heard.

Why Now?

Today, more than ever, crypto and web3 are cemented as topics of public interest and the political debate. Political candidates are talking about them, the public is interested in them, and the crypto community wants to help shape them. This is especially true as we approach the 2022 midterm elections in the United States, where nearly 1 in 4 households (24% to be exact) own cryptocurrency, according to a 2022 Morning Consult report.

We don’t regularly talk about politics here at Coinbase, but we’ve always said that we will engage in the political process at moments when it relates to our mission of increasing economic freedom in the world. The 2022 U.S. midterms are one of those moments. Being informed and being engaged are mission critical for the future of crypto.

In the next few years, legislation and regulations will be developed that will help shape the direction of our industry for the coming decades. In this Congress alone, more than 50 bills have been introduced aiming to shape some aspect of the crypto regulatory landscape. And policymakers are just getting started.

Put simply, this year’s U.S. midterm elections are the most important in crypto’s history. The leaders we elect in November will be making key decisions about how crypto, blockchain, and web3 are regulated. It is essential that our elected leaders understand the potential of crypto and support a policy framework that fosters continued innovation here in the United States and forward progress toward a future of economic freedom for everyone in the world. For our part, Coinbase will continue to be a partner to lawmakers and regulators as these conversations play out.

Why Voter Resources?

We’ve also heard from the crypto community and our customers that they want to understand how these ongoing debates will impact the future of crypto, and they’re eager for resources that help them engage in and shape these conversations. We know that two of the biggest barriers to participating in the political process are education on the issues and access to voting. Helping empower the crypto community by helping them overcome these barriers is at the heart of our voter registration and education program. We are eager to do our part by providing trusted resources for crypto voters on the issues, candidates, and political process that will define crypto’s future. With all this, we are calling on the crypto community to register and get involved this fall by learning about the candidates and the issues, by finding opportunities to talk to representatives and candidates, including at town halls and candidate forums, and, above all, by voting.

Sensible and workable crypto regulations are critical for maintaining U.S. competitiveness and unlocking innovation. Engaging in the 2022 U.S. midterm elections gives everyone a chance to be an important part of the conversation on the future of crypto.

Why We’re Launching a Voter Registration & Education Initiative was originally published in The Coinbase Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

Tl;dr: At Coinbase, our top priority is, and always will be, protecting you and your digital assets. That’s why we secure Coinbase with the latest industry-leading technology and work with the larger community to build a safer crypto ecosystem so that everyone is able to succeed.

In this blog post, we share how a contract with dangerous superuser roles is only as secure as the protections on those roles and discuss controls including multisig, a governance contract, or revoked privileges that asset issuers can implement to prevent a single actor from exercising privileges in a malicious way.

By The Coinbase Digital Asset & Protocol Security Team

At Coinbase, when considering assets for listing we define a risky function as any function that can impact user balance transfer or amounts — directly or indirectly. This can be as direct as a superuser being able to burn funds on anyone’s behalf, or as indirect as the ability to upgrade the token, which could change the token and/or user balances. Since Coinbase custodies assets on behalf of users, Coinbase Security needs to be able to provide users with the peace of mind that their tokens are safe. Therefore, any risky functionality within an asset reduces its eligibility for being listed on Coinbase.

That said, even a token with risky functionality can potentially be eligible for listing if it has sufficient protections in place. Common protections of this nature are multisigs, governance contracts and revoking privilege.

How to Secure a Risky Function with Access Modifiers

When projects need to use functions like burn() or upgrade(), developers must consider appropriate access controls to prevent a single user from calling the risky function. Any individual who holds a role that can perform risky functions exposes the asset to insider threats. Additionally, even if that user is trustworthy, an attacker compromising their key is another route by which token holders can be harmed by centralized superuser privileges.

Superuser Risk with Access Modifiers

A contract with dangerous superuser roles is only as secure as the protections on those roles. When a privileged user has their key compromised, an attacker may abuse that superuser role to call risky functions. Below we’ve outlined a compromised token project that uses an access modifier to restrict the project to a superuser controlled by a single individual.

Although Tim and his team restricted access to the risky function, the role was controlled only by a single key owned by Tim. Tim’s key was compromised and the attacker upgraded the contract, the attacker had full control of the project.

To mitigate superuser risk on access-restricted functions, token project teams can implement multisigs, governance contracts or revoke privileges behind the superuser role to decentralize/revoke access to call the function. Teams can assign privileged roles to a multisig/governance contract or the null address (0x00…) to prevent scenarios like Tim’s Downfall Token from occurring.

Protecting ERC-20 Assets from Malicious Actors

To better understand mitigations to superuser risk, we’ve outlined three (3) scenarios where the design of the privileged access mapped to the superuser role helped protect the token project when the original superuser’s key was compromised.

Why it Matters

The increased security offered by cryptocurrency is a big reason why digital money was created. Unlike traditional currencies, cryptocurrencies such as Bitcoin and Ethereum are open-source, meaning anyone can inspect the blockchains they run on, assuring that every transaction is accurate.

To create a fair and open financial system, we’ve developed a deliberate approach for adding new assets to our platform. Every ERC-20 asset on Coinbase goes through an extensive security review process to assess the custodial risk of funds and ensure that risky functions are appropriately mitigated. This gives token holders, whether they hold their tokens at an exchange like Coinbase or in a self-custodied wallet, stronger assurance in ownership of their tokens.

At Coinbase, we believe that everyone deserves access to financial services that can help empower them to create a better life for themselves and their families. If the world economy ran on a common set of standards that could not be manipulated by any one actor, the world would be a more fair and free place, and human progress would accelerate.

If you’re interested in listing your token with Coinbase, visit the Coinbase Asset Hub.

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.

Security PSA: Protecting ERC-20 assets from malicious actors was originally published in The Coinbase Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

Coinbase is pleased to share the addition of PayPal to the Travel Rule Universal Solution Technology (TRUST) network. TRUST is a global, industry-driven solution designed to increase compliance with a requirement known as the Travel Rule while prioritizing the security and privacy of customers.

PayPal has been a leader in digital payments for more than 20 years by leveraging technology to make financial services and commerce more convenient, affordable, and secure for more than 400 million consumers and merchants around the world.

By joining TRUST, companies become part of a rapidly growing coalition from around the world. Since TRUST launched last February, it has already expanded to include 38 members, including: Amber Group, Anchorage Digital, Balance, Binance.US, bitFlyer, BitGo, Bittrex, BlockFi, BlocPal, Cake DeFi, Circle, Coinbase, Coinhako, Coinsmart, Coinsquare, Crypto.com, Custodia, Fidelity Digital Assetsˢᵐ, Gemini, Kraken, Netcoins, Nexo, Paxos, PayPal, Prime Trust, Robinhood, sFOX, Shakepay, Standard Custody & Trust, Symbridge, Tetra Trust, TradeStation, Unbanked, VirgoCX, Voyager, Wealthsimple, Zero Hash, and Zodia Custody.

The addition of PayPal marks another milestone in TRUST’s journey to become the global, industry-standard solution for Travel Rule compliance.

For more information about how TRUST prioritizes customer privacy and security while providing top-tier Travel Rule compliance, or if you are interested in joining TRUST, please contact us.

PayPal joins the TRUST Travel Rule Solution was originally published in The Coinbase Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.