You are watching news of Coinbase. Go back to all news.
-
View all news of Coinbase
Posted on May 23, 2019Dai (DAI) is now available on Coinbase
Starting today, Coinbase supports Dai (DAI) at Coinbase.com and in the Coinbase Android and iOS apps. Coinbase customers can now buy, sell, convert, send, receive, or store DAI.
DAI will be available for customers in most jurisdictions, but will not initially be available for residents of the state of New York.
According to the DAI whitepaper, DAI is a decentralized stablecoin running on Ethereum that was designed with a goal of maintaining a target value of approximately US$1.00. Unlike most centralized stablecoins, DAI isn’t backed by US dollars in a bank account. Instead, it’s backed by collateral on the Maker (MKR) platform. The relevant whitepapers explain that MKR and DAI tokens form a paired set of assets in which MKR provides governance, and DAI is a decentralized, collateral-backed stablecoin.
One of the most common requests we receive from customers is to be able to trade more assets on our platform. With the announcement of our listing process last year, we anticipate listing more assets over time that meet our standards. We are also investing in new tools to help people understand and explore cryptocurrencies. We launched informational asset pages (see DAI here), as well as a new section of the Coinbase website to answer common questions about crypto.
You can sign up for a Coinbase account here to buy, sell or convert DAI today.
Dai (DAI) is now available on Coinbase was originally published in The Coinbase Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.
-
View all news of Coinbase
Posted on May 23, 2019What the technology hype cycle tells us about the future of crypto
Coinbase VP of Engineering shares his perspective on where we are in the crypto lifecycle, drawing from his experience leading AWS Lambda
One of the interesting opportunities I’ve enjoyed in my career is getting a ringside seat to innovative technologies that have changed the world. Being at companies that have a huge impact on their industry, including Microsoft, Amazon, and now Coinbase, means I get to experience and work on disruptive technologies every day. One particular aspect of that is experiencing the Hype Cycle up close and personal multiple times. At Amazon I got to see the entire lifecycle of a service — from writing the initial business plan for AWS Lambda to launching it at re:Invent to ultimately building it into one of the largest enterprise-grade cloud businesses on the planet. As VP of Engineering at Coinbase, I’m struck by some of the parallels between Serverless computing and crypto as they go through their respective lifecycles.
How is innovation perceived over time? How do you gauge the success of ideas that have large potential for change before they’re fully adopted?
Let’s look back at Lambda and Serverless computing as a way to better understand where Crypto has been, where it’s headed, and how (and when) it’s being adopted.
Lambda’s Innovation Trigger and the Peak of Inflated Expectations
Every significant new technology almost inevitably suffers from being overhyped; in early days, nascent implementations, immature tooling, and emerging processes haven’t yet caught up to customer and developer needs. Let’s look back at Lambda’s initial launch in November 2014. At that time it only allowed a single minute of execution time, 1 GB of memory, operated in a single region, had no ability to connect to customer Virtual Private Clouds (VPCs), and didn’t even allow for synchronous (direct) invocations. It had two event sources, Amazon S3 and Amazon Kinesis, and a (very) rough “double beta” of Amazon DynamoDB change stream events.
Meanwhile, the hype was incredible — the press talked about how this new computing model could replace existing computation and applications. Customers’ excitement was unbounded as they imagined a world without servers, with the promise of infinite cloud capacity, and with perfect utilization. The initial launch presentation was standing room only, as was the repeat session added the following day. It seemed that cloud nirvana had arrived. Back in Seattle, the team toasted our launch, confident in a bright future filled with customer success and a new, growing business for Amazon.
Lambda’s Trough of Disillusionment
In the ensuing months, reality set in: Running time and memory limitations, the lack of access to SQL databases (virtually all of which sat behind VPCs), the limited number of event sources, and other limitations became more apparent. Articles, posts, and tweets stopped talking about hope and excitement and began lamenting the then-current problems and limitations. Initially limited capacity in new regions and throttles on calls due to limits angered some customers. “Cold starts” and other friction from those early days caused some early adopters to declare the entire approach a failure. By the time the term “serverless” entered the popular lexicon, it was already being described as DOA by some of the very people who had initially raved about it. On the business side, adoption was growing, but volumes were modest in the first few months, and on the team we began to doubt ourselves — had we really done something unique and exciting, or was it an expensive flop?
Hockey Stick Growth and the Slope of Enlightenment
Meanwhile, the Lambda team was working hard to remove limitations and deliver features: synchronous invocations, dozens of new event sources, larger memory, longer running times, new regions…the service quickly grew into the enterprise-grade offering that customers needed to really get value from it. And they did: In a little more than a year after launch, enterprise users became a significant customer segment. Customers who had dismissed the idea came back to reevaluate. Revenue, volume, and adoption were all growing rapidly, just like we’d been waiting for.
It wasn’t just the technology itself that needed to grow up — meeting customer expectations as a full-fledged solution required an ecosystem. For Lambda, that looked like AWS Solutions Architects who could train customers on best practices, new conferences being established, and lots of examples to help explain this new way of writing applications.
Growing into its shoes took time, in part because new technologies, like Firecracker, which enables multiple hypervisors on a single EC2 instance, had to be developed in order to break through some of the limitations. This “second wave” of R&D was actually more involved than what we originally launched, in part because along the way Lambda had grown so much, so every change had to keep the “production promise” for hundreds of thousands of customers.
Plateau of Enlightenment
Meanwhile, the ecosystem was growing up, too. Application modeling and deployment tools were created, Lambda achieved compliance with major assurance programs like SOC and PCI, and formal SLAs were introduced. Third party tools and services emerged for everything from security to monitoring to support. Today, Lambda performs trillions of executions per month and has hundreds of thousands of active customers. It’s found a place in the technology portfolios of many Fortune 500 companies, with 60% of IT departments already using it or planning to deploy, and is considered an essential part of best practice cloud architectures. Reality caught up with that exciting initial hype — it just took time!
Crypto’s Hype Cycle
If you’ve been watching the crypto space, this all sounds rather familiar. Lots of initial hype (‘fiat money will be replaced!’) followed by painful reality. Falling prices in 2018 for popular assets like Bitcoin were roundly equated with crypto’s failure as a concept; a moment commonly referred to as “crypto winter” sent a palpable chill through the broader ecosystem. Meanwhile, legitimate limitations of the early technical expressions of crypto and blockchains were (and still are) mistaken for their eventual outcomes. Comparisons of Bitcoin’s 4.6 transactions per second versus Visa’s average of 1,700 called into question the idea of using blockchain as a payment processing platform. Scalability, latency, and throughput limitations, proof-of-work’s high economic costs, and the challenges some companies experienced as they grappled unsuccessfully with the realities of handling customer funds all diminished the initial luster of the approach.
But as with Serverless, the underlying technologies (along with their ecosystems of tools and processes) are growing up. Just as the hype cycle might be ready to declare crypto dead, fundamental innovation is broader than ever, and growing rapidly on every front:
- Scalability and throughput are being addressed through classic optimizations, like sharding, as well as new, crypto-native techniques including batching, STARKS, and Layer 2 protocols. Proof-of-stake and related governance mechanisms provide a complementary model to proof-of-work, offering lower latency and aggregate power consumption.
- Smart contracts and built-in application platforms are raising the level of abstraction to create a “distributed cloud” that reimagines application architecture and economics.
- At the same time technology and performance fundamentals are being optimized, innovative founders are exploring expansions of the business model. Including how real estate, art, and other assets and activities can be expressed in a crypto-centric way.
- And true to crypto’s origins, conventional finance is being reimagined and reinvented. Both the technology, and the businesses bringing it to market, are growing into their (very big) shoes at last.
You Are Here
Crypto’s “Hype Cycle”
The Gartner Hype Cycle model, applied to crypto What determines the length of time it takes to move through the hype curve? The larger the impact of a change, the broader its market reach, and the more disruptive it is versus what came before, the longer it takes to reach the final stages, where the technology reaches its full maturity in both implementation and adoption. With Lambda, that took about three years from the initial launch. Lambda is now firmly in its “productivity plateau,” having been adopted by a third of all enterprises, with serverless now representing the fastest growing cloud computing technology.
Crypto as a technology, meanwhile, has the potential to change how everyone on the planet experiences financial services — its reach is broader than software development and IT efficiency, and its economic impact runs deeper than the cloud. As a result, there’s still more time to go before we reach the stage where crypto is as ubiquitous as fiat currencies and as easy to program as Serverless. It hasn’t reached its productivity plateau yet, but we’re close enough now to see what some of those improvements could look like across the entire cryptoeconomy. (Note, these are innovations we look to support both via Coinbase and our investment arm, Coinbase Ventures):
- Scaling to aggregate global payment transactions per second so that every individual and commercial transaction can be captured in a blockchain.
- Per-transaction latency (through L2 solutions and other mechanisms) in low-digit milliseconds, regardless of geography.
- Compute and storage costs that reflect the underlying costs of cloud infrastructure and which are independent of the distribution scale of a blockchain’s network.
- Tools, business processes, user interfaces, and vibrant third party ecosystems for both developers and finance workers that rival those of cloud and mobile solutions today.
Blockchains and cryptocurrencies today are where the public cloud was 10 years ago, but they’re on an amazingly fast ramp, with core R&D, customer-centric engineering, and ecosystem enablement all happening simultaneously. The innovative implementation work going on in the many open source communities and at companies like Coinbase to create new capabilities, remove restrictions, and bring compelling technologies to market is one of the most amazing things I’ve seen in my career. Hype curve, meet reality!
PS. We’re always looking for talented folks to share this amazing journey with us, so if this sounds like an adventure you want to be part of, check out our open roles to learn more!
All links to third-party websites are for convenience and informational purposes only (“Third-Party Sites”). Coinbase is not responsible for the content of any Third-Party Site, and the inclusion of any link does not imply endorsement, approval or recommendation by Coinbase.
Unless otherwise noted, all images provided herein are by Coinbase.
What the technology hype cycle tells us about the future of crypto was originally published in The Coinbase Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.
-
View all news of Coinbase
Posted on May 22, 2019Introducing Coinbase Watchdog: A new approach to UI and code-driven automation for Datadog
At Coinbase, we use Datadog to collect system and application metrics, implement SLIs and SLOs, create dashboards, and more. As the number of dashboards and monitors grew, we began to see the need to codify them. We were worried that we didn’t have tools to detect accidental or malicious modification. Imagine a production incident that was not noticed by engineers because of an accidentally muted monitor.
Codification solves this because modifications are explicit (through code) and are stored in version control (benefitting from notification and code review systems).
One way of solving this problem would be to store the Datadog components (e.g. Datadog timeboards, screenboards, and monitors) in a version control system and apply changes done through code. The downside of this approach is that managing screenboards or timeboards though the code is not convenient or friendly.
Another way of solving this problem would be to use a Datadog UI-driven approach. This would be much more convenient and friendlier to use. This would require detecting changes, creating a request to submit it back to a version control system and the ability to revert/rollback changes that were not approved.
To achieve the best of both potential solutions (code and UI-driven approaches) we first started by reviewing existing projects we could find:
- https://github.com/trueaccord/DogPush
- https://github.com/codenize-tools/barkdog
- https://github.com/rapid7/dogwatch
- https://github.com/grosser/kennel
Each project had their pros and cons but this came down to two issues: not being able to codify dashboards in addition to monitors (even if we forked and contributed back) or being too complex for our customers.
Introducing Coinbase Watchdog
Coinbase Watchdog is a GitHub app and a Golang service that uses the Datadog API to watch for changes in Datadog, achieving the best of both a code and UI-driven approach. When it sees a change, it automatically creates a Pull Request (PR) with the changes in a dedicated Datadog GitHub repository. We have control and consensus mechanisms (you can read more about Heimdall here) that provide us the guarantees that a sufficient number of people have reviewed the change before it can land on master. If a PR was not approved and closed by a customer, Watchdog will call Datadog APIs to restore the components from the master branch in source control.
This approach gives us a UI-driven codification bot. All changes made in the Datadog UI will be automatically picked up by the bot and corresponding Pull Requests will be created. Watchdog can also detect if a user modified the code (Datadog component JSON) and apply the change to Datadog.
The two workflows are pictured here:
Coinbase Watchdog workflows Configuring Watchdog
The Watchdog service has two types of configuration:
- System configuration: this configuration includes all required parameters such as Datadog API/APP keys, GitHub application private key, GitHub project URL, GitHub app installation ID, etc. This configuration is passed to the service with environment variables.
- User configuration: this is used by customers. Simple YAML files with a list of Datadog component IDs and metadata such as team, project name, etc. You may have many YAML files in the configuration directory and a configuration folder can have any arbitrary number of subfolders.
This is an example of a User configuration YAML file:
The components that you see above are:
- meta: team: An arbitrary team name identifier.
- meta: slack: A Slack room name to notify of changes.
- dashboards: A list of dashboard IDs to watch.
- monitors: A list of monitor IDs to watch.
- screenboards: A list of screenboard IDs to watch.
How does Coinbase Watchdog detect changes?
The Watchdog service is completely stateless. There are two ways in which Watchdog detects changes: Full sync and Incremental.
Full sync
When the Watchdog service starts for the first time, it will query all components by ID and check each against the components stored in GitHub. If some component files are different, new PRs will be created per user configuration file. Depending on users’ configuration files, this step could potentially make many Datadog API calls. However, this will only happen once on service startup to verify that the current state in Datadog is consistent with the source in GitHub.
Watching for incremental changes
This is a fairly straight-forward task, and consists of several steps:
- The Datadog APIs conveniently expose a field “modified” which contains a component modification date. Watchdog polls the APIs https://api.datadoghq.com/api/v1/monitor, https://api.datadoghq.com/api/v1/screen, https://api.datadoghq.com/api/v1/dash . every N minutes (in our case every 10 minutes) and checks if the current time minus modified field value is less then 10 minutes.
- Watchdog uses a git implementation written in Golang under the hood. If step 1 was successful, Watchdog will pull the latest changes from the master branch, create a new local branch, make an HTTP GET request to retrieve the Datadog component from the Datadog API, save the component to a file, and run the equivalent of the git status command to see if the file in the master branch is different from the API response.
- Watchdog will then query GitHub APIs to find if duplicate PRs have been opened and if so it will ignore the current one.
An example API response from the Datadog API showing the “modified” key:
Notifications
When Watchdog creates a new PR it is important to notify the relevant team so that they can review the PR. We use a GitHub’s CODEOWNERS feature for that. In the GitHub repository root we have a CODEOWNERS file with the following lines:
config/reliability/ @engineering/reliability
data/infra/reliability/ @engineering/reliability
If a PR affects files in config/reliability/* or data/infra/reliability/* the Reliability Engineering team will be notified by email.
Furthermore, a team can opt-in to Slack notifications by setting a “slack” field under “meta” in user config file with a slack channel (see above picture).
Future features
In the future, we would like to add more features and are already working on a way to automatically revert changes based on PR expiration. We’re also looking forward to see if others who use Datadog find this service useful and are able and willing to contribute.
Datadog introduced new dashboard APIs which is currently not supported by Watchdog. We are planning to add this feature soon and meanwhile PRs are highly appreciated ;)
If you’re interested in contributing to this project, check it out on GitHub here!
If you’re interested in helping us build a modern, scalable platform for the future of crypto markets, we’re hiring in San Francisco!
This website may contain links to third-party websites or other content for information purposes only (“Third-Party Sites”). The Third-Party Sites are not under the control of Coinbase, Inc., and its affiliates (“Coinbase”), and Coinbase is not responsible for the content of any Third-Party Site, including without limitation any link contained in a Third-Party Site, or any changes or updates to a Third-Party Site. Coinbase is not responsible for webcasting or any other form of transmission received from any Third-Party Site. Coinbase is providing these links to you only as a convenience, and the inclusion of any link does not imply endorsement, approval or recommendation by Coinbase of the site or any association with its operators.
Unless otherwise noted, all images provided herein are by Coinbase.
Introducing Coinbase Watchdog: A new approach to UI and code-driven automation for Datadog was originally published in The Coinbase Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.
-
View all news of Coinbase
Posted on May 20, 2019Accept USD Coin with Coinbase Commerce
Today we’re excited to announce that businesses can now accept USD Coin with Coinbase Commerce. USD Coin (USDC) is a US dollar-backed stablecoin brought to you by Circle and Coinbase. Accepting USD Coin gives our merchants many of the benefits of accepting cryptocurrency but at a stable price: no transaction fees, no chargebacks, and full control over funds.
Coinbase Commerce is a service launched early last year that enables merchants to accept multiple cryptocurrencies directly into a user-controlled wallet. Coinbase Commerce can be directly integrated into a merchant’s checkout flow or added as a payment option on all popular e-commerce platforms such as Shopify or WooCommerce. It’s easier than ever to start accepting cryptocurrency and setup takes just a few minutes.
Adding USD Coin to Coinbase Commerce enables businesses to accept payments online in the same way they’re able to accept cash in-store. Unlike accepting credit card payments, merchants can accept USD Coin without geographical limitations or the need for a traditional bank account. Merchants can accept payment in USDC from customers around the globe in minutes with zero transaction fees.
How to Get Started
If you’re new to Coinbase Commerce, simply sign up to start accepting USD Coin. If you’re an existing user, then there’s no action required.
Accept USD Coin with Coinbase Commerce was originally published in The Coinbase Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.
-
View all news of Coinbase
Posted on May 17, 2019Coinbase Earn now allows users in 100+ countries to earn their share of $100M+ in cryptocurrency
Beginning today, users in more than 100 countries can start earning cryptocurrency by completing educational tasks at coinbase.com/earn.
Introduced in 2018, Coinbase Earn enables Coinbase users to earn crypto for answering quizzes, completing tasks, and trying new decentralized protocols. Asset issuers likewise use Coinbase Earn to teach people how to use their new cryptocurrencies and blockchain projects. Earn opportunities are currently publicly available for Stellar Lumens (XLM), ZCash (ZEC), Basic Attention Token (BAT), and 0x (ZRX), with many more coming soon.
As of today, we’re opening up Coinbase Earn to a much larger number of users. Specifically, users from the United States, United Kingdom, many countries in the European Union (Belgium, Switzerland, Denmark, Ireland, Germany, Iceland, Luxembourg, Netherlands, Norway, Sweden), Canada, Singapore, Australia, Hong Kong, New Zealand, South Korea, and Taiwan can now sign up to Coinbase and start earning immediately upon ID verification and meeting Earn eligibility criteria. Users in other countries where Coinbase is available can get verified and then join a waitlist to become eligible for Coinbase Earn. To see our full list of eligibility criteria, please click here.
The rationale behind Coinbase Earn is that as we progress from mining cryptocurrency to buying it to earning it, we open up new opportunities for people to learn about blockchain technology. With this international expansion, anyone with a smartphone in a supported country can now earn crypto while they learn about crypto just by setting up a free Coinbase account. This means millions more people now have a trusted, safe, and legal bridge to the cryptoeconomy — even if they don’t have a credit card or bank account with which to buy cryptocurrency.
To start earning crypto, check out a Coinbase Earn page like coinbase.com/earn/stellar.
Coinbase Earn now allows users in 100+ countries to earn their share of $100M+ in cryptocurrency was originally published in The Coinbase Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.
-
View all news of Coinbase
Posted on May 16, 2019Bitcoin is on the move: What’s happening in crypto now
A conversation with Coinbase CEO Brian Armstrong and crypto investor Fred Wilson
On May 14th, as part of Blockchain Week in NYC, Coinbase CEO Brian Armstrong joined Union Square Ventures’ Fred Wilson to discuss their visions for building the cryptoeconomy. Watch below to see them discuss the following topics:
- What is the cryptoeconomy?
- The future of crypto
- The role of institutional investment in crypto
- Interesting projects and signals that inspire them
Click here to subscribe to the Coinbase YouTube channel
Bitcoin is on the move: What’s happening in crypto now was originally published in The Coinbase Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.
-
View all news of Coinbase
Posted on May 14, 2019Expanding USDC crypto trading globally
Coinbase now supports over 100 countries, adding trading between cryptocurrencies to 50 new countries; USDC stablecoin crypto trading now available in 85 countries
Today we’re deepening our support for crypto-to-crypto trading globally by adding USD Coin (USDC) trading to customers in 85 countries on Coinbase and Coinbase Pro. We’re welcoming more people around the world to trade between different cryptocurrencies on a trusted platform. This helps accelerate the global adoption of crypto trading, and with USDC, enables access to a stable store of value.
Stablecoins like USDC have a number of advantages over cash: they can be transferred near-instantly and globally, used in a wide variety of dapps, and stored securely and privately in a crypto wallet. Unlike other cryptocurrencies, each USDC is backed by $1 USD with monthly transparency audits showing 100% USD backing. There are more than 300 million USD Coins in circulation today, supported by +100 ecosystem supporters. For these reasons, we see USDC as an important step towards a more open financial system.
Stablecoins are beneficial to anyone who trades crypto, but also have the potential to materially improve the lives of people in countries where inflation is eroding wealth.
For new customers in countries like Argentina and Uzbekistan, where consumer prices are expected to inflate by 10–20% in 2020, stablecoins like USDC could provide an opportunity to protect against inflation. We won’t fully realize this vision without increasing the number of traditional fiat on-ramps, which we are committed to expanding where possible. We also work with projects like Airtm, through our investing arm Coinbase Ventures, to increase access to fiat payment rails.
Today’s news is an important milestone for Coinbase and crypto adoption everywhere. A year ago, Coinbase was only available to customers in 32 countries. Over the last 12 months, we’ve reinforced our foundational work to better scale our trusted, safe and legal bridge to crypto. Today, we serve customers in 103 countries across every major continent, 50 of which we’re announcing today.
Millions more people in the countries below can sign up for a Coinbase or Coinbase Pro account and access the cryptoeconomy today:
Angola, Armenia, Aruba, Bahamas, Bahrain, Barbados, Benin, Bermuda, Botswana, Brazil, British Virgin Islands, Brunei, Cameroon, Cayman Islands, Costa Rica, Curaçao, Dominican Republic, Ecuador, El Salvador, Ghana, Guatemala, Honduras, Jamaica, Jordan, Kazakhstan, Kenya, Kuwait, Kyrgyzstan, Macau, Maldives, Mauritius, Mongolia, Montenegro, Namibia, Nepal, Nicaragua, Oman, Panama, Paraguay, Rwanda, Serbia, South Africa, Taiwan, Trinidad and Tobago, Tunisia, Turkey, Uganda, Uruguay, Uzbekistan, Zambia
This website may contain links to third-party websites or other content for information purposes only (“Third-Party Sites”). The Third-Party Sites are not under the control of Coinbase, Inc., and its affiliates (“Coinbase”), and Coinbase is not responsible for the content of any Third-Party Site, including without limitation any link contained in a Third-Party Site, or any changes or updates to a Third-Party Site. Coinbase is not responsible for webcasting or any other form of transmission received from any Third-Party Site. Coinbase is providing these links to you only as a convenience, and the inclusion of any link does not imply endorsement, approval or recommendation by Coinbase of the site or any association with its operators.
Unless otherwise noted, all images provided herein are by Coinbase.
Expanding USDC crypto trading globally was originally published in The Coinbase Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.
-
View all news of Coinbase
Posted on May 9, 2019Technical Retro: MakerDAO Voting Contracts Vulnerability
Technical Retro: Remediating the Vulnerability in MakerDAO’s Voting Contracts
In partnership with Zeppelin Solutions, the Coinbase and Coinbase Custody security teams found a critical vulnerability in MKR voting contracts. In the piece below, we discuss the steps we took to identify the issue and how we worked closely with our partners and the MKR team to remediate the vulnerability—leading to no loss of customer funds.
This is a companion piece to Zeppelin Solutions’ own technical audit.
Coinbase regularly conducts security audits of smart contracts we write, or assets we list or are evaluating for listing. Most of the time we come away with minor, if any, concerns. Every now and then, we run across something we feel needs to be disclosed directly to the project but is of a relatively low severity. Very, very rarely we’ll discover an issue we believe poses a critical risk to an asset. Our recent review of MakerDAO voting contracts is one such example.
Below, we share the process we followed to identify and remediate the issue and ensure that all participants in this ecosystem were protected. We’ve also extracted a few specific things we think are worth learning from for anyone building a blockchain-based asset. It’s worth highlighting right up front that we’re not the only organization that takes on this kind of effort. There are a number of examples of asset audits and responsible disclosure across the industry, with varying results.
This story starts with smart contracts. We’ve historically stayed away from smart contracts as part of our infrastructure as we see the smart contract ecosystem as still fairly young. While there are some amazing innovations going on in the realm of formal verification and security tooling for smart contracts, we don’t see the same level of toolchain maturity as we’d expect to see in a traditional programming language. With Coinbase Custody’s push to provide governance services to its clients, however, along with our increased pace of listing smart contract-based assets, smart contract security expertise became something we had to develop, and we’ve done some through a blend of external partnerships and internal expertise.
In both our asset listing process and before any internal use of smart contracts, we put a number of safety measures in place, one of which is requiring a security review of all production smart contracts. As part of our project to integrate MakerDAO voting directly with our cold storage system, we built a custom VoteProxy smart contract. Once we had what we thought was a good version, we submitted it to one of our external audit partners, Zeppelin, and made sure the review scope included the inter-contract interactions in the MakerDAO voting ecosystem (mainly, the interactions between our contract and the DS-Chief contract). We expected to get a few suggestions back and to work with the Zeppelin team to implement fixes and move forward. This time around, however, we got a touch more than we’d expected. A key takeaway here is that we strongly encourage anyone writing production smart contract code to make comprehensive third-party security review a regular part of your development lifecycle. If you’re building an asset, we’d encourage you to go one step farther and make those reviews public. One of the key inputs we look for when evaluating assets for listing on Coinbase is a regular cadence of 3rd party audits from credible firms.
We knew something unusual was happening when Zeppelin scheduled an unplanned check-in. At this point, they briefly let us know they’d found a critical bug in MakerDAO voting. We reached out to the MakerDAO team and we all got on a call together within hours of the initial findings. Of note here, and a suggestion for other companies in similar situations, Zeppelin didn’t disclose vulnerability details to us until we’d coordinated a call and had the MakerDAO team on the line. This ensured that all parties had equal access to information and that the interests of all parties were protected.
On a video conference with both the Coinbase and MakerDao security teams, Zeppelin went over the vulnerability details, shared example exploit code, clarified a number of assumptions and proposed some mitigations. The MakerDAO team had the right people on the line to evaluate the report and start to dive into the technical details. We established a joint communications channel and set a next check in time, and the MakerDAO team went off to explore the report in detail. Once the MakerDAO team was ready to propose a had a path forward, we convened again and provided feedback. This is a good example of a positive, engaged response to a vulnerability disclosure. If you are writing code that touches money in an environment as new as a smart contract language, you should fully expect to be on the receiving end of critical vulnerability reports. Build a policy and plan. Conduct tabletops. Publish your plan. Make sure you have an easy, secure vulnerability reporting mechanism. Conduct more tabletops.
With a shared game plan in place, the teams set out to develop a fix. On the Coinbase Custody side, that included making sure we had communications ready to go for all of our clients, that we’d added detection for this activity in our blockchain monitoring tool (the same tool that detected the ETC 51% attack) and that we actively prevented customer harm by blacklisting the old contract addresses and delaying the rollout of our MakerDAO voting feature.
There were a couple of catches, however.
First, as soon as MakerDAO announced that a critical vulnerability had been found and pointed folks at the new DS-Chief contract, it would only be a matter of time until folks had de-compiled the new contract and reverse-engineered the vulnerability. At the same time, MakerDAO couldn’t force existing network participants to withdraw their MKR from the old vulnerable smart contract. This put network participants at risk of loss if an attacker had started to attack the old contract before all network participants had withdrawn their MKR. However, the MakerDAO team was able to come up with a suite of mitigations that would significantly reduce the impact of any active exploitation. We think this is a fairly interesting corner case in vulnerability management in this kind of environment. On the blockchain, all code (at least, all bytecode) is public and unlike the traditional software development world (e.g. when Microsoft ships patches) smart contract patches are going to tend to be smaller and less obfuscatable. We need to assume that the gap between patch and general vulnerability discovery is going to be very short and build our vulnerability response plans with that in mind.
Second, MakerDAO had released the vulnerable smart contract as open source. If other projects had picked up and were using that smart contract, they could also be vulnerable to the same issue. This, unfortunately, is a common problem in open source software development without a great general solution. We do see point solutions in specific ecosystems, for example, Ruby’s bundler-audit, where there are more robust library systems. On the other hand, open source software can be safely leveraged when integrating extensively used and battle-tested libraries such as OpenZeppelin. It is our hope that, as the smart contract ecosystem matures, we see more mature library systems evolve that will enable effective dependency monitoring and security alerting.
In the end, MakerDAO was able to ship a new contract, get network participants moved over and avoid any loss. This was only possible because of the outstanding work in discovering the vulnerability by Zeppelin and the rapid, collaborative involvement of all three parties in reviewing and addressing the issue. This should serve as an example of how to handle a critical vulnerability disclosure in any industry. If you’re involved with writing production smart contract code, I’d encourage you to think through the scenario above in the context of your project and ask yourself how your team would respond? Explore the corner cases, the edge scenarios and see where your plan could use some tuning. Don’t have a plan? No better time to start writing one than right now.
Technical Retro: MakerDAO Voting Contracts Vulnerability was originally published in The Coinbase Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.
-
View all news of Coinbase
Posted on May 7, 2019A Guide to Coinbase Account Security
Best Practices for Protecting Your Crypto
Because cryptocurrency transactions are irreversible, security is an important component of a trustworthy platform. Of course, no single security mechanism is perfect, but following the best practices we share in this post can help reduce the likelihood that you’ll experience an account compromise — not just on Coinbase, but on your other digital accounts as well.
Protecting Your Passwords
If you’ve been using the same password on all your online accounts for years, right now is a great time to switch it up! Virtually all the top common passwords are known to hackers, which makes it easy for them to guess and get into your accounts.
Picking a strong password for your Coinbase account is important, but it’s equally important to have a strong password for the associated email address too. If an attacker gains control of your email address, they can send themselves a password reset request for your Coinbase account.
Rather than try to remember all these passwords yourself, we recommend using a password manager (e.g., 1Password, LastPass) to securely generate and store passwords for you.
When you sign up for a Coinbase account, we’ll give you feedback on how strong your password is based on our Password Requirements:
Password strength ratings provided at signup If you’re unsure about the strength of your current password, log in to your Coinbase account then visit our Password FAQ page. At the bottom of the page, you’ll see the score for your current password:
Adding a Second Factor
Now that you’ve got strong passwords everywhere, the next step is adding 2-Step Verification (also referred to as 2-Factor Authentication, or 2FA) to all your accounts. 2FA adds an additional layer of security to your account by ensuring that knowledge of your password isn’t enough to let an attacker in.
By default, all new Coinbase accounts come with SMS-based 2FA enabled. Each time you log in, we send you an SMS with a unique, short-lived verification code. While this is more secure than no 2FA at all, SIM swapping and phone porting attacks (where a fraudster fools your mobile carrier into giving them control of your phone number) are becoming increasingly common. If an attacker can receive SMS messages sent to your phone number, they can receive your SMS 2FA codes as well.
Apple iPhone and iCloud users should also consider disabling Text Message Forwarding (and protecting your iCloud account with 2FA as well!)
Rather than SMS-based 2FA, we recommend using something stronger, like an authenticator app. When you pair an authenticator app with your Coinbase account, it generates the 2FA codes locally on your mobile device, which means they can’t be redirected like an SMS. Be careful though — anyone who can access your authenticator backup (the technical term is a “TOTP seed”) can also generate 2FA codes with it, so don’t save pictures of your QR code or back up your authenticator app to an unencrypted cloud service.
You can enable Google Authenticator (or any compatible authenticator app) in your Security Settings.
Two-factor authentication isn’t just for login. In your security settings, we recommend requiring a 2FA code for all outbound transactions.
To learn more about your 2-factor options, please read our 2-Factor Authentication FAQs.
Checking for Suspicious Account Activity
On the same Security Settings page, you can manage third-party applications that you’ve granted access to your account, as well as review active sessions and recent activity. It’s a good idea to review your Coinbase account activity regularly to ensure that you don’t see anything unusual or suspicious.
Using Vaults and Whitelisting
If you HODL, you should consider using a Vault. Vaults require multi-email approval to start a withdrawal, and the withdrawal itself has a 48-hour time delay, during which you can cancel the withdrawal at any time if you change your mind or if the withdrawal was initiated by an unauthorized party. You can create a vault for any supported cryptocurrency by clicking + Create Vault at the bottom of your Accounts Page. Once your vault is set up, you’ll receive a notification reminding you of the required verifications and withdrawal delay.
For our Pro users, Address Whitelisting allows you to create a predefined set of cryptocurrency addresses that are allowed to accept outbound transactions from your Coinbase Pro account. Because your Pro account will only send funds to whitelisted destinations that you trust, any attempts by an attacker to send those funds elsewhere will be blocked.
We encourage all Coinbase Pro users to take advantage of this extra security feature.
In the security world, we talk a lot about the concept of “defense in depth” — the notion that no single line of defense will ever permanently keep out an attacker, so it’s important to have multiple layers of protection. By implementing the best practices described here, you can add some layers of defense to your online accounts, as well as adding additional protection for your Coinbase funds.
If you have a security concern or suspect your account is at risk, please notify us through the Coinbase Support page.
All links to third-party websites are for convenience and informational purposes only (“Third-Party Sites”). Coinbase is not responsible for the content of any Third-Party Site, and the inclusion of any link does not imply endorsement, approval or recommendation by Coinbase.
Unless otherwise noted, all images provided herein are by Coinbase.
A Guide to Coinbase Account Security was originally published in The Coinbase Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.
-
View all news of Coinbase
Posted on May 6, 201930+ assets now supported on Coinbase Custody
Since the start of 2019, Coinbase Custody has rolled out support for 20+ new cryptocurrencies. It’s our goal to offer a safe, regulated and insured storage platform for all the assets our clients request and that pass our internal evaluations.
Over the first half of 2019, Coinbase Custody has been busy adding new features and support for the assets that our clients have requested. We recently became the first institutional-grade, qualified custodian to offer staking services for assets held offline. We’re also among the first to offer OTC trading directly from cold storage. These offerings are allowing our clients to participate in all facets of the cryptoeconomy — trading, staking, governance — all while keeping their assets securely offline and protected by our comprehensive insurance policies.
On the asset front, we’ve added support for nearly 20 new assets over the first few months of 2019, taking our total asset support to more than 30. These assets include popular cryptocurrencies like Augur (REP), ZCash (ZEC) and Tezos (XTZ), but also smaller-cap projects like FOAM (FOAM), Kin (KIN) and Maker Dai (MKR).
The number-one driver of our decision to support assets is client demand — we prioritize the assets our clients need. In addition to client demand, we have developed a robust internal process to evaluate and approve assets for Coinbase Custody. Over the coming months, you should expect to see more assets supported on Coinbase Custody, but please keep in mind that asset additions to Coinbase Custody have no bearing on whether they will be added to other Coinbase products. Asset additions for trading must pass our Digital Asset Framework.
Coinbase Custody is building the world’s leading crypto-native custodian. If you’re interested in helping to build the utility phase of crypto, the team is hiring.
30+ assets now supported on Coinbase Custody was originally published in The Coinbase Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.
