As blockchain technology quickly draws the interest of a broad audience, the discussion still revolves entirely around technical subjects tied to network scalability — transactions per second, latency, and throughput, for instance.
To create consumer-scale experiences successfully, though, developers have to look past performance metrics and account for the human element: Accessibility — the ease with which both seasoned crypto developers and newcomers can adopt and use it — is the crucial factor in taking blockchain to billions. Only the projects that make accessibility a priority early will ultimately win over the masses.
Accessibility is far more difficult to measure than scalability. This article lays out a systematic framework that enables organizations and individuals to measure and assess the accessibility of a blockchain project with reliability.
Thinking beyond scalability
For a long time, the story was (and at times still is) entirely about scalability as a required condition for mass adoption. And we understand why: In 2017, Dapper Labs launched CryptoKitties — digital collectible cats that brought in the first non-fungible token (NFT) standard, ERC-721. Although CryptoKitties hinted at the huge promise that consumer-grade blockchain applications hold for the broader industry, it also delivered a stark reminder of Ethereum’s technical constraints at that time.
The central debate soon shifted to scalability — how could Ethereum and other blockchains handle a rising user base without becoming clogged or too costly to use?
The scalability challenge eventually prompted the rise of newer Layer 1 blockchains such as Flow, Solana, Avalanche, and WAX, alongside Layer 2 or sidechain options from projects like zkSync, Optimism, or Polygon. (Note: The authors are at Dapper Labs, the original creators of Flow.) Ethereum itself is pursuing greater scalability through sharding and a range of upgrades.
But mass adoption is about more than scalability. Below, we draw on what we learned from both CryptoKitties and building Flow to present a framework that helps builders concentrate on accessibility — no matter the protocol or application.
The why and the who of accessibility
Accessibility refers to the overall capacity of a blockchain network to be used smoothly by a broad range of different entities. The simpler it is for a user to engage with a project’s applications, protocol, or ecosystem, the greater the accessibility of that blockchain. Accessibility applies not just to end-users, but also to developers, creators, product owners, and any other parties that interact with the network.
Who ought to think about accessibility? Developers, architects, and executives who actively build and oversee blockchain-enabled applications should perform an accessibility analysis when selecting a blockchain to build on. And anyone who uses the existing services of a blockchain ecosystem — creators, artists, and IP holders — should weigh the accessibility of a given project, since it will shape the size and nature of the network’s existing audience.
Instead of only focusing on the numbers, both groups need to pose the right questions: What does the ecosystem’s culture look like? What kinds of people are building here? What digital goods are offered by the projects building on it, and how do the economies around it change over time? And most importantly: Is all of this accessible to the masses?
These questions should be approached from 1) a functional, 2) an economic, and 3) a technical angle, which brings us to the framework we propose here, including questions for any crypto builders who want mainstream adoption. (Click to expand chart, and read on.)
Functional accessibility — can you use it?
Functional accessibility (also called usability) describes how well a blockchain and its ecosystem can provide easy onboarding and user experience, so that user interactions with the protocol or applications can be completed in a simple and efficient way. It’s an excellent starting point for any evaluation.
Onboarding
Every user’s journey starts with onboarding: the opening phase of user interactions, including account setup and funding, through to the first network transaction. This stage should be as frictionless as possible, requiring only a small number of steps and ideally no technical expertise.
A drawn-out onboarding path with many steps spread across a scattered set of non-integrated services indicates 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 buy crypto, waits for the exchange to perform a know-your-customer check, returns to the application for re-authentication, and only then carries out the intended action, e.g. exchanging tokens or buying an NFT — that is at least six steps across three different services.
At the opposite end of the spectrum, there are integrated and streamlined processes that hide most complexity from the user, creating a highly accessible experience. That’s the case if users can sign up for the application and the wallet at the same time, while payment on-ramp providers embedded via iFrame remove the need to visit external exchanges to fund the account.
Between these two extremes are many applications and services that include some of these processes only partly, for example by not relying on a browser plug-in wallet (removing the need for a separate download process) or by integrating fiat-to-crypto payment on-ramps in certain parts.
Some applications handle users’ private keys on their behalf. While this custodian architecture can lower friction in the onboarding process by removing the need for an external wallet, it does so at the expense of greater technical complexity and legal requirements. Those implications are outside the scope of this article — teams that choose a custodian architecture should carefully research the tradeoffs of this model.
A solid place to begin accessibility analysis is to identify the three most common onboarding paths for a particular blockchain, recreate these scenarios from the user’s point of view, and collect the steps taken in separate documents. Since there are usually multiple onboarding experiences for one protocol, depending on the specific application and/or wallet a user selects, this process should include all common scenarios and user types.
Wallets
Onboarding covers a user’s initial interactions with a protocol. For everyday use, the signing and submission 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.
Every blockchain transaction must be confirmed by the relevant user through a digital signature — this stops malicious actors from carrying out unauthorized actions. To produce that signature, the user’s private key is required. Because private keys have this enormously important function but cannot (or should not) live only in our memory, they must be kept in a manner that is both secure and practical. That is exactly what blockchain wallets provide, while often also serving as an entry point for sending transactions to the network.
For signing to be practically usable, a user’s transactions need to be easy to approve with the wallets available on the blockchain in question. If a user must install an external plug-in or manually configure parameters for how much they are ready to pay in fees for a given transaction, each later transaction creates more friction. This illustrates how wide-ranging and interconnected accessibility analysis is within this framework. Only a holistic approach of this kind will account for the user experience of the wallets available on the given chain.
To achieve the greatest accessibility, wallets should be not only simple to operate, but also broadly supported across all types of applications in the project’s ecosystem. If users must create several wallets from several providers to use different applications, accessibility drops sharply. For instance, if an NFT marketplace does not accept the wallet a user has been using to trade tokens on a decentralized exchange, the user effectively has to go through onboarding again for a different wallet, and later remember to manage that account as well.
This problem is closely connected to how the application is built: in most situations, developers have to add vendor-specific code to their application so it can support a new wallet. That creates technical overhead and delays the integration and availability of several wallet providers across applications.
Fiat payment on- and off-ramps
Although some users will make transactions almost entirely within the crypto ecosystem, mass adoption will depend on non-crypto-natives being able to move crypto gains easily into more familiar currencies. Functional accessibility, therefore, also covers how easy it is for end-users to deposit or withdraw value from the network. Fiat payment on- and off-ramps are crucial here, since they let a user buy a certain amount of cryptocurrency directly with fiat currency, using credit cards or other convenient payment methods. External exchanges can certainly serve this purpose, but dedicated integration services make sure that a user does not need to leave the application for the payment onramp, which significantly improves overall accessibility.
A sensible place to begin is a cursory check of the network token’s listing on major centralized exchanges. When doing this, you may also want to include the listings of stablecoins available on the given network. The next step is to review the ecosystem’s major wallets in a systematic way for integrated onramp tools, since some user-friendly wallets already have these functions built in. The multi-chain wallet Blocto, for example, uses the payment onramp provider Moonpay, enabling users to add funds to their cryptocurrency directly inside the wallet itself with simple payment methods such as credit card.
Lastly, you can look at some of the network’s most-used applications for fiat payment onramp options and record which provider offers the service. Taken together, this analysis will give a detailed picture of how accessible the value movements to and from the network are for the end user.
Bringing together all of these elements of functional accessibility, these are the main questions developers should ask when deciding which blockchain to build on top of:
- How many average steps make up the onboarding process? How much prior knowledge or technical expertise is required to complete them? How many steps must a user take to sign a transaction, and how much prior knowledge or technical expertise is required to complete them? Is wallet integration smooth with the user experience, and are wallets generally available across different applications? How many steps must a user take to move fiat money on chain? Do fiat payment on- and off-ramps exist? What about listings of the blockchain’s native token and stablecoins of the project on centralised exchanges?
Economic accessibility — can you afford it?
Economic accessibility rests on the general affordability of the protocol and the digital products built on top of it.
Transaction fees
Blockchains are public resources, and transaction fees stop the network’s capacity from being overused, which helps prevent the tragedy of the commons. They also protect the underlying network from spamming in the form of Denial-of-Service (DoS) attacks.
Transaction fees may be fixed — for instance as an inclusion fee that must be supplied in order to submit a transaction — or they may be dynamic, rising with the complexity of the given request. Most widely used blockchain protocols rely on one of these fee types, or on a combination of them.
Transaction fees are where functional and economic accessibility meet. In daily use, they must be low enough for everyone to take part, yet high enough to keep the network stable. Predictability also matters a great deal: if transaction fees are highly and unpredictably volatile, less well-equipped users will be discouraged from sending transactions to the network. For that reason, any accessibility analysis must consider not only average transaction prices, but also the mechanisms by which they are set from day to day.
On Ethereum, transaction fees are expressed in a special unit called gas in order to separate the fees from the price volatility of the underlying token (Ether). For every transaction, a user must provide two specifications: gas limit, which states the maximum amount of gas a user is prepared to spend; and gas price, which states the price a user is prepared to pay for one unit of gas.
The gas limit must be selected 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 set high enough, a transaction will run out of gas and revert.
The gas price may be chosen freely. However, because network validators decide which transactions they want to place in the next block, a higher gas price will usually result in faster execution. This process is basically like an auction, with users bidding for their transaction to be included in the next block, and entire websites such as EthGasStation have appeared for transaction pricing purposes.
There are a few issues with this transaction fee model:
- The auction model can drive transaction fees sharply upward during periods of heavy demand; for example, there have been times when a simple token transfer cost roughly $50 in gas fees on Ethereum. Because gas prices change rapidly, setting transaction fees correctly is a non-trivial task. While the recently adopted EIP-1559 pricing mechanism and some user-friendly wallets may avoid some of these issues, high transaction fees with complex mechanisms can reduce the project’s overall accessibility.
Because Layer 1 blockchains and Layer 2 solutions often deliver higher throughput, transaction fees are (mostly) much lower. That is exactly why these solutions often provide a greater degree of accessibility. Still, application architects must closely weigh the tradeoffs, since faster throughput in some cases comes at the expense of reduced decentralization.
Application layer products
In addition to transaction fees, economic accessibility also depends on the products offered by the blockchain project’s application layer. One major example is the floor prices of popular NFT collections in a given ecosystem. A floor price is the lowest price of an item in a collection, and this metric is often used together with the overall volume (that is, the sum of all the collection items’ prices) to assess the valuation of a collection.
High floor prices build an ecosystem that is isolated and reachable only by an economic elite, directly obstructing genuine community formation and thereby reducing the odds of future mass adoption. Although strong volume is certainly positive for a blockchain, one must always look past it and consider what the figures mean: if high volume is mainly paired with high floor prices, it is likely that only a small number of wealthy users are responsible for the ecosystem’s economic activity.
Some may contend that fractionalized NFTs — where ownership of an NFT is divided among many holders — will solve this issue over time. Yet this brings engineering overhead, greater user complexity, and a lack of legal clarity.
Running nodes
Lastly, economic accessibility is also an issue for node operators — the validators that protect and check a blockchain. Only when operating a network’s node is realistic in terms of hardware needs and minimum staking amount (in proof-of-stake networks) will enough validators be encouraged to join the network, and only then are decentralization and integrity guaranteed.
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 evaluating alternatives, one should also keep a close eye on other non-technical considerations for node operators. For example, if a network intends to permanently enforce rules and regulations about who is allowed to act as a node operator, this renders the protocol inaccessible to operators who do not meet these requirements and may signal less decentralization of the network.
Key questions for economic analysis:
- How high are the average transaction fees and how well can they be predicted by users in advance? What are the floor prices of popular products offered by the project’s application layer in primary and secondary markets? Who are the main drivers behind the protocol’s overall volume? Are there only a few large entities, or a large group of smaller-value transactions? How demanding are the hardware requirements and minimum staking balances for node operators?
Technical accessibility — can you build on it?
Technical accessibility describes how easy it is for developers to build applications on the given chain. This concept is also known as developer ergonomics.
Programming concepts
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 solid place to begin is the review of the blockchain’s main 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 offer more implementations, and in general that is a positive sign of accessibility; what matters more, however, is the language of the most widely used client. Ensure that it is a widely known, used, and maintained language, where existing knowledge from a fair number of developers can be assumed, e.g. C++, Golang, Rust, or Python. This will support the likelihood of continued 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.
Tooling
A strong tooling stack is essential for developers to build applications quickly, securely, and easily. If recurring issues are not addressed by a dedicated tool, this points to weak technical accessibility, because developers must handle these issues on their own.
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.
In addition to SDKs, many tools can greatly ease developer onboarding and everyday development. Look for extensions for text editors (IDE), testing frameworks, and other automation, deployment and debugging tools that make building applications on the given blockchain simpler, faster, and ultimately more accessible.
Key questions for technical analysis:
- Are the programming concepts of the project easy to learn? Do they allow for fast, secure and efficient development? Is sufficient educational material and reference code available? Are higher-level concepts like best practices and patterns also covered? Are developer tools available for the most common issues? Are these tools, as well as the source code from the main project, all open-sourced?
***
There are additional factors besides those mentioned above, including some less tangible indicators of accessibility in conceptual terms, such as how readily the general audience can understand the core ideas of a given blockchain project. Accessibility improves when users can join the space quickly without first having to learn a large amount of new information. In this respect, having educational resources for end users and using clear language that avoids technical terminology and jargon is very helpful, though it can be difficult to assess across a broad ecosystem overall.
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.