As blockchain technology rapidly gains the attention of a mass audience, the conversation is still centered solely around technical topics related to the scalability of a network — transactions per second, latency, and throughput, for example. To successfully build consumer-scale experiences, however, developers must think beyond performance metrics and consider the human factor: Accessibility — the ease of adoption and use, for both expert crypto developers and users new to the scene — is the key factor in bringing blockchain to billions. Only those projects that commit to accessibility early will win the masses in the long run.Accessibility is much harder to quantify than scalability. This article provides a systematic framework that allows organizations and individuals to reliably measure and evaluate the accessibility of a blockchain project.
The narrative for the longest time was (and sometimes still is) all about scalability as a necessary precondition for mass-adoption. And we get it: In 2017, Dapper Labs created CryptoKitties — digital collectible cats that introduced the first non-fungible token (NFT) standard, ERC-721. While CryptoKitties foreshadowed the tremendous potential that consumer-grade blockchain applications bear for the entire industry, it also gave a sobering testimony of Ethereum’s technical limitations at the time. The biggest debate quickly became scalability — how could Ethereum and other blockchains accommodate a growing number of users without getting bogged down or too expensive to use?The scalability issue ultimately led to the emergence of younger Layer 1 blockchains like Flow, Solana, Avalanche, and WAX, as well as Layer 2 or sidechain solutions from the likes of zkSync, Optimism, or Polygon. (Note: The authors are at Dapper Labs, the original creators of Flow.) Ethereum itself is focusing on higher scalability using sharding and a variety of upgrades. But mass adoption is not just about scalability. Below, we draw on our lessons learned from both CryptoKitties and building Flow, to share a framework for helping builders focus on accessibility — regardless of protocol or application.
Accessibility describes the general ability of a blockchain network to be used by a wide array of different entities in a frictionless way. The easier it is for a user to take part in a project’s applications, protocol, or ecosystem, the higher the accessibility of the given blockchain. Accessibility applies not only to end-users, but also to developers, creators, product owners, and any other parties interacting with the network. Who should be thinking about accessibility? Developers, architects, and executives who actively build and manage blockchain-enabled applications should conduct an accessibility analysis when choosing a blockchain to build on. And anyone who leverages the existing services of a blockchain’s ecosystem — creators, artists, and IP holders — should consider the accessibility of a given project, since it will determine the size and characteristics of the existing audience on the network.Rather than solely playing the numbers game, both of these groups need to ask the right questions: What does the ecosystem’s culture look like? What types of people are building here? What are the digital goods offered by the projects building on it, and how do the economies around it evolve? And most importantly: Is this all accessible for the masses? These questions should be asked from a 1) functional, 2) economic, and 3) technical perspective, which leads to the framework we propose here including questions for any crypto builders who desire mainstream adoption. (Click to expand chart, and read on.)
Functional accessibility (also referred to as usability) describes the ability of a blockchain and its ecosystem to provide an easy onboarding and user experience, such that user interactions with the protocol or applications can be carried out in a simple and efficient manner. It’s a great starting point for any evaluation.
Every user’s journey begins with the process of onboarding: the first phase of user interactions, including the setting up and funding of the account, up until the first network transaction. This phase should be as frictionless as possible, needing only a limited number of steps and ideally no technical expertise. A prolonged onboarding journey of many different steps across a dispersed array of non-integrated services speaks for poor accessibility. For example, it’s often the case that a user signs up for an application, downloads a browser plug-in wallet, writes down a 12-word mnemonic phrase, visits an external exchange to purchase crypto, waits for the exchange to conduct a know-your-customer check, returns to the application for re-authentication, and only then proceeds with the desired action, e.g. exchanging tokens or buying an NFT — that’s at least six steps across three different services.On the very other end of the spectrum, there are integrated and streamlined processes that abstract most complexity away from the user, promoting a highly accessible experience. That’s the case if users can sign up for the application and the wallet simultaneously, while payment on-ramp providers integrated via iFrame eliminate the need to visit external exchanges to fund the account.In between these two ends of the spectrum are manifold applications and services that partially include some of these processes, for example by not depending on a browser plug-in wallet (eliminating the need for a separate download process) or by integrating fiat-to-crypto payment on-ramps in some parts. Some applications manage their users’ private keys on their behalf. While this custodian architecture can reduce friction in the onboarding process by eliminating the need for an external wallet, it comes at the cost of higher technical complexity and legal requirements. Those implications are beyond the scope of this article — teams opting for a custodian architecture should do thorough research on the tradeoffs of this model.A good starting point for accessibility analysis is to identify the three most common onboarding routes for a specific blockchain, recreate these scenarios from a user’s perspective, and gather the steps taken into separate documents. Because there are usually multiple onboarding experiences for one single protocol, depending on the specific application and/or wallet a user chooses, this process should cover all common scenarios and types of users.
Onboarding covers the initial interactions of a user with a protocol. For day-to-day usage, the signing and submitting of user transactions are of central importance. For this reason, wallets available on the given blockchain (necessary for such transactions) become a highly relevant part of accessibility analysis. Any blockchain transaction needs to be verified by the given user with a digital signature — this prevents unauthorized actions from malicious actors. In order to create this signature, the private key of the user is needed. Because private keys play this hugely important role but can’t (or shouldn’t) reside in our memory banks alone, they need to be stored in a secure yet convenient way. This is precisely the functionality blockchain wallets offer, while often also providing an access point to send transactions to the network. In order to be functionally accessible, the signing of a user’s transactions has to be easily achievable with the available wallets of the given blockchain. If a user has to download an external plug-in or manually set up parameters for how much they’re willing to pay in fees for a given transaction, every consequent transaction involves more friction. This shows how interconnected and broad the analysis of accessibility with this framework is. Only such a holistic approach will take the user experience of the wallets that are available on the given chain into account.For maximum accessibility, wallets should not only be easy to use, but also widely accepted across all kinds of applications in the project’s ecosystem. If users need to set up multiple wallets from multiple providers to access different applications, the level of accessibility greatly decreases. For example, if an NFT marketplace does not support the wallet a user has used for trading tokens on a decentralized exchange, the user essentially needs to do the onboarding process again for another wallet, and keep track of this account in the future. This issue ties directly into the development of the application: In most cases, developers need to add vendor-specific code to their application in order to support a new wallet. This introduces technical overhead and slows down the integration and availability of multiple wallet providers across applications.
While some percentage of users will transact within the crypto ecosystem nearly exclusively, mass adoption will require that non-crypto-natives are able to easily transfer crypto earnings to more familiar currencies. Functional accessibility, then, also includes how easy it is for end-users to deposit or withdraw valuefrom the network. Fiat payment on- and off-ramps are essential to this, allowing a user to purchase some amount of cryptocurrency directly with fiat currency, using credit cards or other convenient payment methods. While external exchanges can certainly be used for this purpose, dedicated integration services ensure that a user does not have to leave the given application for the payment onramp, which greatly increases overall accessibility.A good starting point for analysis is the cursory screening of the network token’s listing on major centralized exchanges. In doing so, you might want to include the listings of stablecoins that are available on the given network. The next step is to systematically examine the major wallets of the ecosystem for integrated onramp tools, since some user-friendly wallets have these functionalities already integrated. The multi-chain wallet Blocto, for example, leverages the payment onramp provider Moonpay, allowing users to top up their cryptocurrency directly in the wallet itself, using easy payment methods like credit card. Finally, you can check some of the most-used applications of the network for fiat payment onramp options and note the provider offering the service. This combined analysis will paint a detailed picture of how accessible the value flows to and from the network are for the end user.
Economic accessibility is based on the general affordability of the protocol and the digital products built on top of them.
Blockchains are public resources, and transaction fees prevent overuse of the network’s capacity, helping avoid the tragedy of the commons. They also safeguard the underlying network from spamming in the form of Denial-of-Service (DoS) attacks. Transaction fees can be fixed — for example in the form of an inclusion fee that needs to be provided in order to submit a transaction — or, they can be dynamic, increasing with the complexity of the given request. Most popular blockchain protocols use either one of these fee types or a combination of them.Transaction fees are the place where functional and economic accessibility overlap. In everyday use, transaction fees have to be low enough for everyone to participate, yet high enough to ensure network stability. Also, the predictability of these fees plays a high role: If there is high unforeseeable volatility in transaction fees, this will keep less equipped users from sending transactions to the network. Therefore, any accessibility analysis will need to consider not only the average transaction prices, but also the mechanisms in which they are determined on a day-to-day basis.On Ethereum, transaction fees are denoted in a dedicated unit called gas in order to decouple the fees from the price volatility of the underlying token (Ether). For each transaction, a user has to include two specifications: gas limit, which describes the maximum amount of gas a user is willing to spend; and gas price, which denotes the price a user is willing to pay for a unit of gas. The gas limit has to be chosen according to the computational complexity of the request. For simple Ether transactions the value is 21,000 gas units, or about $6 at the current gas price (as of October 2021). If the gas limit is not sufficiently set, a transaction will run out of gas and revert. The gas price can be chosen freely. However, since network validators choose which transactions they want to include in the next block, a higher gas price will mostly lead to a faster execution. This process essentially resembles an auction with users bidding for their transaction to be included into the next block, and entire websites like EthGasStation have evolved for purposes of transaction pricing.There are a couple of issues with this kind of transaction fee model:
Since Layer 1 blockchains and Layer 2 solutions often provide a higher throughput, transaction fees are (mostly) significantly lower. This is precisely the reason why these solutions often have a higher level of accessibility. However, application architects have to closely identify the tradeoffs, since faster throughput in some cases comes at the cost of decreased decentralization.
Beyond transaction fees, economic accessibility also involves the products offered by the application layer of the blockchain project. A major example are the floor prices of popular NFT collections of a given ecosystem. A floor price resembles the lowest price of a collection item, and this metric is frequently used in conjunction with the overall volume (i.e. sum of all the collection items’ prices) to analyze the valuation of a collection. High floor prices create an ecosystem that is secluded and only accessible to an economic elite, actively hindering real community building and thus diminishing the chances for future mass adoption. While a great volume is definitely good for a blockchain, one always has to look beyond it and what the numbers imply: If great volumes are mostly accompanied by high floor prices, chances are that only few wealthy users drive the economic activity in the ecosystem.Some people may argue that the concept of fractionalized NFTs — the case where an NFT’s ownership is split up among many owners — will circumvent this problem in the long run. However, that comes at the cost of engineering overhead, increased complexity for users, and lack of legal clarity.
Finally, economic accessibility is also a concern for node operators — the validators who secure and verify a blockchain. Only if the running of a network’s node is feasible in terms of hardware requirements and minimum staking amount (in proof-of-stake networks) will a sufficient number of validators be incentivized to participate in the network, and only then is its decentralization and integrity ensured.Bitcoin and Ethereum are both networks with a high number of node operators, which speaks to good levels of protocol reliability and security. However, the analysis of accessibility has to take a more differentiated view. For example, the requirements of running a Bitcoin node are fairly low, but a disproportionately large number of blocks are mined by pools with specialized equipment rather than by individual miners, which makes running one’s own Bitcoin node less feasible and less accessible.While Ethereum’s design largely prevents the use of specialized equipment, mining still happens in centralized pools and hardware requirements are significantly higher than on Bitcoin. Since Ethereum stores considerably more data than Bitcoin, a new node takes significantly longer time to catch up on this amount of data — today it takes about 17 hours to set up a full Ethereum node. Because time and hardware resources come at a cost, these factors lessen the economic accessibility of those protocols for node operators.When looking for alternatives, one should closely monitor other non-technical factors for node operators, too. For example, if a network plans to permanently impose rules and regulations on who qualifies as a node operator, this makes the protocol inaccessible for those operators that do not fulfil these criteria and might be an indicator of less decentralization of the network.
Technical accessibility describes how easy it is for developers to build applications on the given chain. This concept is also known as developer ergonomics.
A team’s ability to ship a blockchain-enabled product fast depends heavily on the state of the project’s technical accessibility. The first thing to check are the general programming concepts: Only if they can be understood reasonably quickly will developers be able to pick them up and start building fast. Ideally, the programming paradigms are rooted in pre-existing technology to smoothen the developer onboarding. A good starting point is the analysis of the blockchain’s major client implementation. A blockchain client is a language-specific implementation of the protocol, or, put simply, the actual program that node operators run to power the blockchain. Some blockchains may have more implementations, and generally that is a good sign of accessibility; what’s more important, however, is the language of the most commonly used client. Make sure that this is a widely known, used, and maintained language, where pre-existing knowledge for a fair amount of developers can be assumed, e.g. C++, Golang, Rust, or Python. This will guarantee the likelihood of ongoing development and maintenance of these clients.The next important consideration is smart contract programming languages. Some blockchains like Solana use existing languages (Rust and C++), while other networks like Ethereum (Solidity) or Flow (Cadence) have created their own. Of course, using an established language has developers with pre-existing knowledge already onboarded; however, for novices this may come at the cost of learning a whole general purpose programming language in all its detail, which is especially time-consuming for low-level languages like C++. Here, it might even be more accessible to learn a lightweight new language that was designed with smart contract programming in mind. In the case of new programming languages, analyze the language for the existence of well-known and established programming concepts and paradigms. Solidity, for example, is heavily inspired by JavaScript and Java, while Cadence borrows many concepts from Swift and Rust. In addition, consider what abstractions a language offers for its developers. Just like the underlying protocol, a language should abstract away as much complexity from the developers as possible, without sacrificing on security or customizability. For example, Cadence automatically imposes rules on the handling of digital value using the novel data model of resources, while Solidity demands a manual implementation of these low-level checks. Finally, make sure that thorough educational materials, documentation and reference implementations for all of these aspects exist and that they are easily accessible. Assessing the accessibility of the programming concepts is all about considering the subtleties and tradeoffs that technical details imply.
A good set of tooling is paramount for developers in order to build applications fast, secure, and easy. If there are frequent issues that are not covered by a dedicated tool, this indicates a poor level of technical accessibility, since developers have to take care of these issues themselves. Software development kits (SDKs) are arguably the most important of these tools. SDKs provide a language-specific layer of abstraction to the underlying processes of the protocol; they simplify interactions like authentication, querying and mutating state, listening to emitted events, and much more. Check if there are SDKs for all popular programming languages, which speaks for a high level of technical accessibility of the given project. Beyond SDKs, there are many tools that can greatly simplify developer onboarding as well as day-to-day development. Check for the existence of extensions for text editors (IDE), testing frameworks, and other tools for automation, deployment and debugging that make developing applications on the given blockchain simpler, faster, and ultimately more accessible.
***
There are other considerations than those above, including a few less tangible signs of accessibility in conceptual terms like how easily understood the general concepts of the given blockchain projects are by a general audience. Accessibility is promoted if users can enter the space quickly without needing to acquire a considerable amount of new knowledge first. In this regard, the existence of educational material for end-users and an accessible language avoiding technical terms and jargon is highly beneficial, but can be hard to analyze across a wide ecosystem. In any case, blockchain accessibility is not a nice-to-have that can be added later, but rather needs to be rooted in the project’s DNA. Especially for technical accessibility, considerations have to be made at the very time of sketching out the protocol’s inner workings, at the outset. Without accessibility — and not just scalability — there won’t be mass adoption.
