Login | Register

Coinbase online payment system

Coinbase
https://coinbase.com/

Updated on October 11, 2012
Views: 7463 | Clicks: 275


Website Screenshot



General Information

 

 

Glyphicons_055_stopwatch
Instant Payments

Payments arrive at the speed of an email (just a few seconds) and are confirmed within the hour. No more waiting three business days for checks.

Glyphicons_037_credit
Low Transaction Fees

Coinbase charges just 0.5% when you buy or sell bitcoin via bank account transfer. After that all bitcoin-to-bitcoin transactions are free.

Glyphicons_163_iphone
Pay By Phone

Our website works great on modern smartphones (iPhone, Android, etc). Just visit coinbase.com from your mobile browser.

 

Glyphicons_263_bank
Simple Transfers

Use your bank account to purchase bitcoins. Transactions are processed within two to three business days. (coming soon)

Glyphicons_280_settings
Merchant Tools

Easily create "buy now" or donate buttons. We also offer full shopping cart integration. (coming soon)

Glyphicons_040_stats
Widespread Adoption

About $2 million a day (USD) is already being transacted in bitcoin. It's quickly becoming an international currency.

Currencies

Bitcoin

Countries of use

USA

Users

private and business

Fees

0.5% when you buy or sell bitcoin via bank account transfer

Recent news

Posted on August 19, 2019
Coinbase at Violet Hacks

Recently, Coinbase had the honor of partnering with The Violet Society, an organization whose mission is to build community and career mentorship for women and gender-nonbinary professionals in the tech industry, by sponsoring Violet Hacks, a hackathon where a group of about 200 of these professionals gathered to design, build, and pitch various products to a panel of judges in a friendly competition.

Members of the Coinbase Engineering and Talent teams at Violet Hacks in San Francisco.

Over the course of the event, we witnessed many amazing and talented engineers, designers, and product managers hack on a wide range of projects including an AI skincare product recommendation system, a GitHub productivity suite, a customized makeup tutorial app, and even a pet adoption matching app. It was incredible to see how much ground these teams covered in less than 24 hours.

Violet Hacks kicked off with an opening keynote address from Katia Ameri, founder of Mirra, and went on to provide a full slate of informational sessions, panels, and workshops for hackathon participants to attend throughout the weekend. They could take a quick break from hacking in order to learn about UX design from Laurel Beyers, a principal product designer at Nyansa, product management from Ana Pischl, a lead product manager at Zeus, or even attend an “Intro to Blockchain” workshop facilitated by Gloria Kimbwala, founder of Shule. Throughout the weekend, we had great conversations with attendees about Coinbase, who we are and what we do, and about the challenges that we face as women in engineering, in tech, and in this current financial system.

Coinbase is proud to support endeavors like this that empower and support underrepresented minorities in the tech industry and are a critical step towards breaking down the barriers and stereotypes that still inhibit fair representation.

At some point in your career, you will probably find yourself interacting and working with people who do not share life experiences and world views similar to your own. At these times, it's important to work on expressing your thoughts and ideas clearly to them and, most importantly, listening to them and understanding where they are coming from. Building a team that is welcoming to those of all different perspectives, ideas, and backgrounds is in large part about fostering a culture where we focus on self-awareness and empathy as muscles to grow.

At Coinbase, our mission is to leverage cryptocurrencies to build an open financial system which promotes economic freedom and financial inclusion. In this system, access to financial services should be equal, easy, effective, and secure. This is a future wherein the availability and opportunity for access to financial services transcend socioeconomic, educational, geopolitical, cultural, racial, and gender divides.

For this reason, the topic of inclusion is top of mind at Coinbase as we strive to define the role we play in influencing the cryptoeconomy. We recognize the need to build out a team that can help represent the myriad perspectives of the populations we are aiming to serve.

In our recently published Culture Doc, our CEO Brian Armstrong outlined six tenets of our culture, one of which is to “Focus on the Customer.” Building a more heterogeneous team enables us to be more sensitive and empathetic towards all of our customers’ needs and concerns as we continue to scale. With intention and deliberation, we can focus our efforts on building products that will speak to customers with a multitude of backgrounds, life stories, and experiences all across the globe.

If you’re curious about crypto, finance, technology, or security, and would like to work with some of the amazing engineers here at Coinbase on some of the ambitions outlined here, get in touch with us!

This website contains 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.

All images provided herein are by Coinbase.


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

Read more on Coinbase
Posted on August 16, 2019
Post Mortem: A closer look at a password storage issue affecting 3,420 customers

We recently began emailing 3,420 Coinbase customers to let them know that a bug on our signup page resulted in some registration details being stored in clear text in our internal web server logs. While we are confident that we’ve fixed the root cause and that the logged information was not improperly accessed, misused, or compromised, we are requiring those customers to change their passwords as a best-practice precaution.

Here’s what happened

Under a very specific and rare error condition, the registration form on our signup page wouldn’t load correctly, which meant that any attempt to create a new Coinbase account under those conditions would fail. Unfortunately, it also meant that the individual’s name, email address, and proposed password (and state of residence, if in the US) would be sent to our internal logs.

If the individual reloaded the page and then submitted the form for a successful registration, their registration information would (correctly) not be logged, and the password would be securely hashed. However, in the 3,420 instances referenced above, the user successfully registered using a password with a hash that matched the one previously logged.

Here’s how we responded

After we identified and fixed the bug, we traced back all the places where these logs might have ended up. We have an internal logging system hosted in AWS, as well as a small number of log analysis service providers. Access to all of these systems is tightly restricted and audited. A thorough review of access to these logging systems did not reveal any unauthorized access to this data. Additionally, we triggered a password reset for impacted customers, even though a password alone is not sufficient to access a Coinbase account — our device verification emails and mandatory 2FA mechanisms would both have been triggered and blocked any unauthorized login attempts.

The technical details

The Coinbase front-end web app is built using the React.js framework and leverages React’s Server Side Rendering (SSR) for key pages (including /signup). SSR means that, instead of sending a barebones HTML page and depending on React to fully populate it in the browser, we send a partly rendered page from the server and let React put the finishing touches on in the browser. We use SSR in order to give searchable content to search engine crawlers, which generally don’t run Javascript. Any user attempting to register needs to have JavaScript enabled, and needs to have that JavaScript load correctly. In virtually all circumstances, both of these things are true, and React handles form validation and submission to the server. However, if a user had JavaScript disabled or their browser received a React.js error when loading, there was enough pre-rendered HTML that a user could fill out and attempt to submit our registration form.

The HTML form itself was extremely basic, since we expected that the details would be filled in by React: <form>[list of fields]</form>. This had two implications for default behavior:

  1. Because no “action” attribute was set, the official behavior defined in the W3C specification was “undefined”. In practice, however, some browsers will set “action” to the current URI and make a best effort to submit the form.
  2. Because the “method” was not set, per W3C specification the browser defaulted to GET, which meant that, all form variables were URL encoded and appended as a query string to submit data to the server, e.g in the pattern /signup?first_name=Alice&last_name=Smith&email=alice%40example.com&password=password

This query string then ended up in our logs. The fix itself was simple and straightforward: we changed the default form method to POST, as data submitted in the request body (instead of a query string) is not logged: <form method=”POST”>[list of fields]</form>. We also searched the rest of our repository for any other forms with that problematic behavior, and did not identify any. We’re also in the process of implementing additional mechanisms to detect and prevent the inadvertent introduction of this sort of bug in the future.

Conclusion

We maintain incredibly high standards for securing the Coinbase platform, and any time we fall even slightly short of those standards, we mobilize a team to figure out what went wrong, and how we prevent it from happening again. We also believe in being transparent with our customers, which is why we’re sharing the results of our investigation today.

As a reminder, Coinbase also maintains an active bug bounty program on HackerOne, which has paid out over a quarter of a million dollars to date: https://hackerone.com/coinbase. While this particular bug was discovered internally, we welcome security researchers to submit reports any time they believe they may have uncovered a flaw in one of our systems.


Post Mortem: A closer look at a password storage issue affecting 3,420 customers was originally published in The Coinbase Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

Read more on Coinbase
Posted on August 15, 2019
Coinbase Custody acquires Xapo’s institutional business, becoming the world’s largest crypto…

Coinbase Custody acquires Xapo’s institutional business, becoming the world’s largest crypto custodian

Crossing $7 billion in assets under custody, Coinbase Custody is now the most popular and trusted choice for institutions to store cryptocurrency.

Today, we are announcing that Coinbase Custody has completed an acquisition of Xapo’s institutional businesses. This acquisition caps off a tremendous period of growth and innovation for Coinbase Custody. In just over one year since launch, Coinbase Custody has grown to over $7 billion in Assets Under Custody (AUC) stored on behalf of more than 120 clients in 14 different countries, making it the largest, most globally recognized and most trusted institutional custodian in the world. From the start, our goal has been to build the trusted foundation for institutional investment in Bitcoin (BTC) and crypto assets in general. We’re thrilled to help enable some of the tremendous demand for this emerging asset class.

Xapo has long been a pioneer in the storage of crypto assets, leading the industry in the creation of security techniques that have kept their customers’ cryptocurrency safe since 2014. Xapo was founded with the mission of making Bitcoin more secure and accessible. Coinbase will extend Xapo’s legacy and bring it yet another step closer to achieving its mission.

Since 2012, Coinbase has served as the world’s onramp to Bitcoin and many other cryptocurrencies. Through our consumer products, Coinbase has helped more people experience their first crypto transactions than any other company. Like Xapo, we share the goal of making Bitcoin and other cryptocurrencies accessible in a way that’s secure, safe and compliant with local laws. Through the acquisition of Xapo’s institutional businesses, we’re now proud to act not only as the gateway for millions of people to cryptocurrency, but also as the world’s largest and most trusted steward of digital assets. Xapo has been a tremendous flagbearer for Bitcoin and the economic equality it can offer to billions across the globe. We’re honored to carry this flag onward.

Looking forward, our focus will stay on our clients. We work every day to provide them true peace-of-mind in knowing that their assets are safe and accessible. In addition to custody, we’re excited to explore new ways to monetize and leverage crypto assets such as staking, borrowing against crypto portfolios and lending crypto to trusted counterparties.

Coinbase is committed to serving a wide spectrum of institutional clients including hedge funds, family offices, endowments and proprietary trading desks as they decide to onboard crypto. Our institutional range of products provides a seamless, powerful and compliant ecosystem for our clients to trade, store and interact with their crypto. The suite combines access to the world’s largest pool of regulated, verified crypto liquidity through Coinbase Pro with high performance APIs and a high-touch coverage team. Paired with access to our global OTC trading desk and Coinbase Custody’s highly secure and insured storage platform, Coinbase delivers the trust, security, and performance needed by investors to trade with confidence.

It’s with huge pride that we welcome Xapo’s Institutional customers to Coinbase. Their legacy, knowledge and experience will help to make our mission of creating an open financial system for the world a reality.

About Xapo: Xapo is a New York DFS-regulated entity (NY Bitlicense holder) and a Gibraltar-licensed E-money institution, that offers a multi-currency digital wallet and card that operates in the global market. Their mission is to give users from all over the world the ability to send, receive, spend and store their money, globally and safely. Their team value proposition ‘Impact Globally, Work Remotely’ is represented by a workforce of over 250 team members, who are globally distributed across more than 50 countries.

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.


Coinbase Custody acquires Xapo’s institutional business, becoming the world’s largest crypto… was originally published in The Coinbase Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

Read more on Coinbase
Posted on August 14, 2019
USDC payment processing in Coinbase Commerce

Using non-custodial smart contracts to process ERC20 payments at scale

Table of Contents

Intro
 — How Coinbase Commerce works — 30k foot overview
 — Non-custodial by design
 — Naïve solution — Forwarding contracts
 — Reducing transaction sizes
 — Optimizing for off-chain whenever possible
 — Minimizing deployment costs
 — Conclusion

Coinbase Commerce’s mission is to be the easiest way for businesses to accept cryptocurrencies. We launched in February of 2018 supporting BTC, ETH, LTC, and BCH, making it simple for anyone to start accepting cryptocurrencies in a couple of minutes. While our merchants love the ability to instantly transact with customers anywhere in the world, many have expressed concerns with the volatility of cryptocurrencies given fiat-denominated business costs.

Unlike traditional cryptocurrencies, stablecoins such as USD Coin (USDC) are explicitly designed to avoid this volatility. We released USDC support a couple months ago, enabling a volatility-free way for our merchants to accept cryptocurrencies. USDC is backed one-to-one by US dollars, giving it a stable price and making it a great option for commerce. USDC is implemented as an ERC20 token, living on the Ethereum blockchain. Here, I will discuss the approach we took to support USDC on our platform. This post is aimed for anyone who is interested in the internals of Coinbase Commerce. It is particularly useful for dapp developers that might find the ideas and implementations around create2 and minimal proxy contracts relevant to their work.

A customer paying with USDC using Coinbase Commerce’s point of sale

How Coinbase Commerce works — 30k foot overview

When a customer wants to pay to a Coinbase Commerce merchant, we create a charge object that keeps track of what the customer wants to buy, how much it costs, the blockchain address they need to pay to, and other metadata. We generate a unique blockchain address for each charge, which serves as a canonical identifier for the charge and the payments made to it. When a customer pays a charge, they do so by sending funds from any wallet or exchange to one of those addresses. By continuously monitoring the blockchain for payments to these addresses, we know if the customer paid the charge and how much they paid, which drives the charge’s completion and the sending of the appropriate webhooks and emails.

diagram explaining the life-cycle of a charge
This chart represents the life-cycle of a charge where Coinbase Commerce generates unique addresses for each charge. Once a payment is detected on the blockchain, Coinbase Commerce detects it and sends the appropriate notifications.

Our workflow — generating a unique address, having the customer pay to that address, and having our system detect that payment on the blockchain — is only one way a blockchain payments processor can be engineered. Other workflows are based on the JSON Payment Protocol, where the customer’s wallet sends an RPC call to the processor’s servers and exchange the necessary info to conduct the payment. Yet another approach would be to use the ETH’s Web3 interface to ask the customer to sign a custom, non-standard transaction. While these approaches have unique benefits, for us it was very important to keep the simple, address-only interface. A vast majority of our customers use an exchange or a hosted wallet, and therefore can only send funds to an address — they do not have the option to initiate RPC calls or sign custom transactions. It was therefore paramount for us that our solution cannot require anything but simple address that everyone can use and send their payments to.

Non-custodial by design

Part of Coinbase Commerce’s value proposition is that we operate as a non-custodial service, meaning that we do not act as a middle man and that all transactions are directly between the customers and our merchants. Being non-custodial means that no one (including Coinbase Commerce) can prevent the movement of funds once a payment has been initiated. We never let any private keys hit our servers, and therefore we do not have the ability to censor or revert a transaction. There are some tradeoffs that come with being a non-custodial solution. On the positive side, this means that:

  • It increases the decentralization
  • It increases interoperability with other wallets and tools
  • It lowers the risks of using the service

However, there are some downsides that we’ve tried to mitigate:

  • Accidental loss of private keys (recoverable if you use the encrypted backup feature)
  • Hard to automate certain activities such as refunds or scheduled withdrawals
diagram representing a withdrawal flow
The Coinbase Commerce servers never have access to the private keys (ie. mnemonic). All sensitive actions are performed locally on the merchant’s device. Only signed transactions are sent back to the servers for broadcasting to the blockchain.

Given this context on how Coinbase Commerce works, let’s dive into the design and implementation of our USDC solution. I will start with a naïve solution that conveys the general idea, and iteratively address its short-comings, ultimately getting to the production version we use today at Coinbase Commerce. I’ll introduce a couple of techniques — factory pattern, create2 opcode, minimal proxy contracts — which make deploying ETH contracts feasible at scale. These techniques could be used in a variety of business settings.

Naïve solution — Forwarding contracts

Our solution is based on the following idea: We create smart contracts that can accept funds as if they were ordinary accounts, with the sole functionality of forwarding the accepted funds to a fixed, predetermined address that belongs to the merchant. That way, the customers can still use the simple address-only interface to pay, and the merchants can be certain that their funds cannot be misused by anyone. In fact, both the customers and the merchants might not be aware that a smart contract logic is involved at all! Here is one such Forwarder contract:

While the contract achieves our requirements, creating a production system out of these Forwarders is infeasible. For each merchant who has enabled USDC payments, we would need to preemptively deploy multiple forwarders to the blockchain to ensure that there is an available pool of addresses when a customer initiates a payment flow. After we detect a payment to one of the deployed contracts, we (or the merchant) can call the flush function to forward the tokens to the merchant’s destination and finalize the movement of funds.

diagram explaining the life-cycle of a naïve ERC20 payment forwarding
The life-cycle of a naïve ERC20-based payment flow. We eagerly deploy Forwarders that can later be used in charges. Once a Forwarder receives tokens, anyone (in this case Coinbase Commerce) can call its flush function to move the funds to the final destination and finalize the funds movement.

However, managing these pools is quite expensive (each contract creation requires gas fees to be published on the blockchain), very cumbersome and causes unnecessary congestion of the network, making them a non-starter for any production setting.

Reducing transaction sizes

The cost of an Ethereum transaction is primarily tied with the complexity of the logic executed in that transaction — the more CPU time a transaction needs to process its logic, the more gas the transaction will consume. However, for contracts that perform repetitive, simple tasks, the transaction costs are dominated by the space used by the transaction, rather than its runtime logic.

The factory pattern significantly helps reduce the cost of these transactions. Instead of encoding the same logic multiple times when deploying a new Forwarder, we can deploy a single ForwarderFactory that knows how to instantiate new Forwarders. We no longer need to duplicate the full source code every time we deploy a Forwarder — instead we can encode only a pointer to the already deployed code. This results in 47% reduction of gas cost; and indeed, the naïve transaction with its full implementation weighs 1783 bytes, where the factory transaction that contains only the function arguments weighs only 175 bytes.

Optimizing for off-chain whenever possible

A byproduct of the factory that deploys the Forwarders is that we are now able to compute the addresses of the Forwarders before we deploy them to the blockchain. This enables the same user experience as preemptively deploying a forwarding contract for each merchant, without incurring the expense of deploying these contracts on the blockchain.

In Ethereum, the addresses of the created contracts are deterministic — they can be computed from the sender’s address (i.e. the account that created the contract, in our case the factory) and the sender’s nonce (a counter tracking how many transactions originated from that account). However this does not work well in practice because the nonce is an ever increasing global counter. If a customer pays to the 100th generated address, we’d still need to deploy the initial 99 contracts so we can deploy the expected, 100th Forwarder, and we’d need to do that in a determined order. Gaps like these, when we’d need to deploy contracts just to get to the expected nonce, are inevitable because customers might create a charge but never pay a charge.

This is a problem that has plagued the Ethereum community for a long time and has been on the wishlist for many dapp developers. Fortunately, the introduction of the create2 opcode in the Constantinople network upgrade addressed this issue. Unlike create, which uses the ever-increasing sender’s nonce, create2 uses an argument-specified salt. This enables a number of workflows that were impossible or impractical before — we can now simulate complex workflows completely off-chain; without needing to track any state beyond the self-generated salt. We can safely interact with the blockchain only when we need to do an on-chain settlement. Here is how we can use the create2 opcode to deploy a Forwarder.

Note that now initForwarder takes additional salt where before its functionality was performed by the implicit nonce. This allows us to explicitly decide which contracts to deploy on the blockchain, so if the 100th customer pays but the initial 99 do not, we can deploy the 100th forwarder in the sequence without needing to deploy the initial 99 first.

It’s informative to see the code that calculates the addresses:

In addition to the use of a salt, a crucial safety feature in the address generation algorithm is the use of the bytecode. Having the bytecode as one of the arguments ensures that it is impossible to deploy the “wrong” contract at the indicated address. For our example, this implies that there is exactly one combination of destination and salt that can lead to a contract being deployed at a computed address. It is impossible for a malicious attacker to deploy a contract of their own logic or their destination to an address we already computed. Therefore, we can present these non-deployed addresses to the customers and be certain that an attacker could not out-race us by deploying a contract of their own choosing to that particular address.

This enables novel workflows like the one we use at Commerce. It is now possible to create and simulate immutable workflows fully off-chain, and only do the “settlement” stage on the blockchain, after the customer has already paid for their invoice.

Minimizing deployment costs

We can further reduce the cost of our solution by using another novel technique called minimal proxy contracts. The minimal proxy contracts allow the deployment of a contract that is an exact copy of another existing contract, but is extremely light-weight to deploy. They represent the symlinks of the Ethereum blockchain — they have their own address, but they defer all of their functionality to the original contract they point to. These proxy contracts include carefully crafted, “magic” bytecode that changes the execution stack and uses the delegatecall opcode to delegate the implementation to the target contract. In our case, instead of deploying a new Forwarder whenever a customer pays to the same merchant, we can deploy a single Forwarder for that merchant and use its clones from that point onwards. Using clones reduces the gas cost by further 61% over the factory solution.

You can see the contracts we use in production here. The link hints at a couple of the downsides of the approach we have taken:

  • Reduced privacy due to the singleton factory
  • Increasing the minimal settlement time due to the extra flush call
diagram showing the final architecture of the smart contracts
This chart shows the final architecture of the forwarding contracts. Each merchant has their dedicated Forwarder (initialized with their destination), and a number of Forwarder clones (each clone associated with a particular charge). The contracts can be deployed (blue) or not deployed (yellow), but we can still safely calculate and use their addresses.

The factory, create2 opcode, and the minimal proxy contracts are patterns that can be applied for a wide range of circumstances. At Coinbase Commerce, we applied these patterns to make the movement of funds as simple and cheap as possible, but any other workflow that needs to simulate interactions with a number of contracts while only deploying a subset could benefit from them.

A lot of patterns in blockchain engineering enable novel workflows, but these patterns come with their own gotchas and surprises. As a young ecosystem, its documentation and best practices lag behind the advancements made at the protocol level.

The USDC forwarding is a great example of our daily work on crypto technologies as well as the interesting challenges of building complex, production systems. If you enjoy working in a fun, high energy environment and want to work on making accepting cryptocurrencies easy, then checkout all open positions here. We’d love to hear from you.

This website contains 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.

All images provided herein are by Coinbase.


USDC payment processing in Coinbase Commerce was originally published in The Coinbase Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

Read more on Coinbase
Posted on August 9, 2019
Algorand (ALGO) is launching on Coinbase Pro

On Wednesday, August 14 after 10am PT, transfer ALGO into your Coinbase Pro account ahead of trading. Support for ALGO will be available in Coinbase’s supported jurisdictions, with the exception of New York State. Additional regions may be added at a later date. Per previous launches, transfers will open during business hours, Pacific time.

On Wednesday, August 14, 2019 after 10am PT, we will begin accepting inbound transfers of ALGO to Coinbase Pro. We will accept deposits for at least 12 hours prior to enabling full trading, which will occur during business hours, Pacific time.

Once sufficient supply of ALGO is established on the platform, trading on the ALGO/USD order book will start in phases, beginning with post-only mode and proceeding to full trading should our metrics for a healthy market be met. Support for ALGO will be immediately available in Coinbase’s supported jurisdictions, with the exception of New York State. Additional jurisdictions may be added at a later date.

Founded by cryptographer and Turing award winner Silvio Micali, Algorand aims to solve some of the technical barriers of existing blockchain infrastructure. In particular, the project seeks to improve decentralization, scalability and security. Launched in June 2019, Algorand provides a foundation for existing businesses and new projects to operate globally in the emerging decentralized economy. Algorand’s permissionless, pure proof-of-stake protocol supports the scale, open participation, and transaction finality required to build scalable blockchain projects.

Please note that ALGO is not yet available on Coinbase.com or via our consumer mobile apps. We will make a separate announcement if and when this functionality is added.

The Stages of the ALGO Launch

There will be four stages to the launch as outlined below. We will follow each of these stages independently for each new order book. If at any point one of the new order books does not meet our assessment for a healthy and orderly market, we may keep the book in one state for a longer period of time or suspend trading as per our Trading Rules.

We will send tweets from our Coinbase Pro Twitter account as each order book moves through the following phases:

  1. Transfer-only. Starting on Wednesday, August 14, customers will be able to transfer ALGO into their Coinbase Pro account. Customers will not yet be able to place orders and no orders will be filled on these order books. Order books will be in transfer-only mode for approximately 12 hours. We will communicate the exact timing for this phase via Twitter closer to the date.
  2. Post-only. In the second stage, customers can post limit orders but there will be no matches (completed orders). Order books will be in post-only mode for a minimum of one minute.
  3. Limit-only. In the third stage, limit orders will start matching but customers are unable to submit market orders. Order books will be in limit-only mode for a minimum of ten minutes.
  4. Full trading. In the final stage, full trading services will be available, including limit, market, and stop orders.

One of the most common requests we receive from customers is to be able to trade more assets on our platform. Per the terms of our listing process, we anticipate supporting more assets that meet our standards over time.

You can sign up for a Coinbase Pro account here to start trading. For more information on trading ALGO on Coinbase Pro, visit our support page.


Algorand (ALGO) is launching on Coinbase Pro was originally published in The Coinbase Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

Read more on Coinbase

See all news of Coinbase

Coinbase Comments:

Add your comment