Lessons learned from five years working in crypto

One of the things that got me into cryptocurrency five years ago was the prospect of building consumer products used by billions of people not controlled by a handful of big tech companies.

I envisioned these products leveraging decentralized technology to ensure that the rights of those who used them would be respected. This vision motivates me today and is a large part of why I continue to work at Coinbase and advise early-stage web3 startups.

Around late 2015 I decided to start a consultancy specializing in frontend development. Before my career in crypto, I worked in the Bay Area for over a decade. I worked mainly as a mobile engineer at startups of all scales and big tech companies like Apple and Facebook.

Typically, I’d work with the founders of early-stage startups. I’d help design and build out the initial version of whatever application they wanted, then source, hire and train a team to take over from me. After my initial engagement, I would be available on retainer for equity, cash, or tokens to advise or help further as needed.

In 2017 I became intrigued with cryptocurrency startups trying to build decentralized applications and started exclusively working with them as clients. This eventually informed my decision to join Coinbase, where I have been happily working as a tech lead and an engineering manager.

I feel we are very early on in this journey, and in this article, I’d like to share some lessons I’ve learned from working in this space over the years.

Lesson 1: App Store rules, not laws, are often the biggest impediments to innovation

One of the first products I worked on at Coinbase was integrating a version of earn.com into Coinbase’s Mobile applications. Earn allowed asset issuers who had tokens listed on Coinbase to educate people as to what the purpose of their tokens was and how to use them.

They would give us a bunch of tokens to distribute, pay us a fee, and we would produce a series of videos explaining different aspects of the token. These videos were accompanied by multiple choice questions, which, if answered correctly, would result in a small reward being paid out denominated in the issuer's token.

Occasionally there would also be a more complex on-chain task the user would have to perform, demonstrating how the token worked by utilizing it. Typically this would result in a larger reward.

At the time, Coinbase’s mobile applications were not written in React Native, so this integration required implementing it twice, once for iOS and Android. I was the only mobile engineer slated to work on this team, so before my arrival, the decision was made to prioritize implementation on iOS as it was the most lucrative of the two platforms.

The first thing I did upon starting at Coinbase was to look up the iOS App Store rules and guidelines. I immediately discovered and flagged to my boss that these rules specifically prohibited companies from paying people to perform tasks using cryptocurrency. This sounded a lot like the product we were building.

As a result of this decision, we decided to build the first version using an embedded web view on both platforms and prioritize shipping first on Android, whose app store did not have these restrictions and allowed users to sideload binaries onto their phones.

Eventually, Coinbase managed to come to an agreement with Apple about the Earn product, but this didn’t happen till many months after we shipped the Android and web versions.

To this day, iOS App Store rules around things like this, and NFTs are a major problem for cryptocurrency companies trying to build social and gaming products.

An example of an NFT-related iOS App Store issue is highlighted in my interview with Aleksandr Chichkanov, creator of OpenSea’s mobile application. In my interview, he talks about his experience getting approved for the iOS App Store. OpenSea is an NFT marketplace.

Lesson 2: A Blockchain's Ecosystem Matters

I have always been fascinated with the various blockchains that promised to give developers the ability to build distributed applications on top of them. To write a Dapp, you will need to pick a blockchain and related technologies to use to build it. This will require a significant investment in time as it will likely require you to learn a new programming language, design patterns, and tooling.

Around 2018, before joining Coinbase, I was aware of a number of these projects, such as Ethereum, Tezos, Cardano, and Solana. Which one should I pick to learn and why?

At the time, these projects seemed to have various pros and cons. It was hard to understand which ones had staying power and hence would be worth investing time to learn.

My transition to working at a company with a centralized exchange, like Coinbase, completely changed my perspective on how I assessed and thought about these blockchains.

I would argue that a blockchain's ecosystem, the number of developers, users, tooling, Dapps, and standards built around it, should be a key factor in deciding whether to invest the time in learning it.

A major milestone in the life of many tokens is being listed on an exchange. To understand my perspective shift, let’s consider what’s involved for this to happen.

At a minimum, the token and its underlying technology will likely need to be put through some form of technical due diligence. As a thought experiment, let's take a look at what this process might involve:

• A security review or audit of the underlying code and libraries supporting the token. The exchange might need to use some of these things to list the token by integrating them into its infrastructure.
• The scalability and reliability of the tokens underlying technology are also something that would need to be assessed. Networks going down will result in funds being frozen and in on-call engineers being paged.
• An assessment of the work required to build out core functionality like the ability to send and receive the token. The ability to receive the token and move it between hot and cold wallets is a necessary prerequisite for listing.
• The ability to monitor activity on the network. The ability to index transactions is necessary to be able to show a user's transaction history as well as to be able to use these transactions for tax, security, or compliance purposes.

This is not an exhaustive list, it’s only meant to give you a taste of the engineering processes that a centralized exchange might have for listing a token.

If the token in question is based on Ethereum or Bitcoin, you get most of the above for free, as all the infrastructure and processes have already been built.

If the token is not based on Ethereum, Bitcoin or an integrated token, this process will take much longer. The reason for this is that the engineering resources and time will need to be budgeted to review and integrate this technology into the exchange.

It should be noted that such engineering resources are scarce at an exchange and are usually either spent fighting fires during a bull run or paying off technical debt in a bear market.

This ecosystem advantage is even more pronounced regarding the infrastructure and tooling required to build dapps powered by smart contracts. If a blockchain is Ethereum Virtual Machine or EVM compatible, it can run Smart Contracts written for Ethereum and support its token standards and tools right out of the gate.

Consider, for example, the number of popular Ethereum competitor chains that are compatible with the EVM or are working on compatibility:

• Avalanche C-Chain
• NEAR’s project Aurora
• Binance Smart Chain (BSC)
• Solana’s NEON
• SmartBCH sidechain for Bitcoin Cash

Not to mention Ethereum side-chains or L2's:

• Optimism / Optimistic Ethereum
• MATIC / Polygon
• Arbitrum

The above is not an exhaustive list. This subject is explored in greater depth by my good friend and former Coinbase coworker, Niall O’Higgins, in his article Ethereum VM Supremacy: 4 Lessons From UNIX Which Explain It.

This ecosystem advantage extends to software wallets such as Metamask and Coinbase Wallet, hardware support (ledger wallets, etc), and the ability to find auditors, lawyers, and developers familiar with the ecosystem in question.

Lesson 3: Dapps are not just smart contract code

Despite what you might think, smart contract development is only a small part of the work involved in writing a successful Dapp. Most engineers working on a product that leverages smart contracts may not be smart contract engineers or even write a single line of solidity.

Often the majority of engineering time spent on such products goes into traditional DevOps, backend, and frontend engineering. However, a lot of this engineering work will be shaped by the fact that the product involves interacting with smart contracts and related on-chain data.

Let’s consider some of the things that you might need to deal with if you are an engineer working on a product that involves a smart contract:

Transaction data: A core part of blockchains like Ethereum is keeping a cryptographic immutable data record, including all historical transactions.

A typical part of a Dapp’s backend stack is an indexer, a service that indexes all of this information and keeps an up-to-date record of the latest activity.  Some of the things this information might be used for in your dapp is as follows:

• Business logic: You likely need to be able to show and possibly perform actions based on transaction history.
• State management: You need to know the current state of a given transaction, i.e, is the transaction, complete, pending or in a failed state.
• History: If the user sends a token in or out of the contract, you need to know where it has gone.

Access to price information: Many cryptocurrency products are financial services of one type or another. As such, you need to be able to display or use pricing information for a given NFT or token. That data needs to come from a reliable source, usually an oracle.

Ability to display images or access files: Storing data in a smart contract is typically expensive, and the amount of data you can store is often limited. As such, a common practice is to store ancillary data such as images, files or metadata in a distributed filesystem like IPFS or araweave and bake a url to said data into the smart contract.

Access to Metadata: Depending on the Dapp you are building, you might need to display metadata about the token or NFT being displayed, such as attributes, bids and perhaps sales history. This metadata might be fetched from an API such as OpenSea’s.

The ability to connect a wallet to your smart contract: A basic need that dapp’s have is to connect to a user's wallet in order to be able to do things like relay messages used to sign transactions and pay for things. This is usually done through an SDK, or third-party library integrated into the application.  

This is only a small sample of the engineering jobs that need to be done by a dapp that don’t involve writing any smart contract code. Today, the barriers to entry to producing a halfway decent dapp are quite high when compared to say a traditional web application. Hence today, most dapps or games that leverage smart contracts are basic.

Parting Thoughts

As I said at the start of this article, I am motivated by the prospect of building consumer products that leverage cryptocurrency that billions of people could use. If you are interested in reading more of my thoughts on what needs to be built for this to happen, please subscribe or follow me on twitter or Farcaster.