a16z: Analyzing the Accessibility Challenges of Blockchain from the Perspectives of Functionality, Economics, and Technology

Author: Shirley, Benjamin Ebner

Original Title: 《Blockchain Networks and the Human Factor: How to Know Whether They're Accessible》

Compiled by: Dong Yiming, Chain Catcher

As blockchain technology rapidly gains attention from a wide audience, the conversation remains focused on technical topics related to network scalability, such as transactions per second, latency, and throughput.
To successfully build consumer-level experiences, developers must move beyond a mindset that only considers performance metrics and pay more attention to user-related factors: for instance, accessibility (ease of adoption and use), which is crucial for both crypto development experts and new users. In the long run, only those projects that are committed to developing accessibility early on will win the favor of the public.
Accessibility is a performance metric that is harder to quantify than scalability. This article provides a systematic framework for organizations and individuals to reliably measure and assess the accessibility of blockchain projects.
1. Thoughts Beyond Scalability
For a long time, we have said that scalability is a necessary prerequisite for the mass adoption of blockchain applications. We understand that in 2017, Dapper Labs created CryptoKitties—collectible digital cats—which introduced the first non-fungible token (NFT) standard—ERC-721. While CryptoKitties heralded the enormous potential of consumer-grade blockchain applications across the industry, it also provided proof of Ethereum's technical limitations at the time.
The biggest debate quickly became the issue of scalability for blockchain applications—how can Ethereum and other blockchains accommodate an increasing number of users without getting bogged down or incurring excessive costs?
The scalability issue has led to the emergence of a wave of younger Layer 1 blockchains, such as Flow, Solana, Avalanche, and WAX. Layer 2 or sidechain solutions like zkSync, Optimism, or Polygon have also emerged. Ethereum itself focuses on achieving higher scalability through sharding and various upgrades.
However, mass user adoption is not just about scalability. Below, we draw on lessons learned from CryptoKitties and building Flow to share a framework. This framework can help builders focus solely on the accessibility of applications without considering the underlying protocols or the applications themselves.
2. Who Can Access and Why Do They Access?
Accessibility describes the ability of a blockchain network to be used by a large number of different entities in a frictionless manner. The easier it is for users to engage with a project's applications, protocols, or ecosystems, the higher the accessibility of a given blockchain. Accessibility applies not only to end users but also to developers, creators, product owners, and any other individuals interacting with the network.
Who should consider accessibility? Developers, architects, and executives actively building and managing blockchain-supported applications should conduct accessibility analyses when choosing which blockchain to build on. Anyone leveraging existing services within the blockchain ecosystem—creators, artists, and intellectual property holders—should also consider the accessibility of a given project, as it will determine the size and characteristics of the existing audience on the network.
Both groups need to ask the right questions: "What is the culture of this ecosystem?" "What kind of people will build projects here?" "What digital goods do the projects built on it offer, and how will the economy surrounding it develop?" Most importantly, "Is all of this suitable for the masses?" rather than merely playing digital games.
The perspective for answering these questions should come from three aspects: 1) functionality, 2) economics, and 3) technology, leading to the framework we hope to provide for builders in the crypto industry seeking mainstream recognition.

2. Functional Accessibility—Will You Use It?
Functional accessibility (also known as usability) describes whether a blockchain and its ecosystem can provide users with an easy onboarding experience, allowing interactions with protocols or applications to occur in a simple and effective manner—this is a great starting point for assessing any project.
1. New User Onboarding Process
Every user's journey begins with the new user onboarding process: the first stage of user interaction includes setting up an account, injecting capital into the account, and making the first network transaction. This stage should be as frictionless as possible, requiring users to complete a limited number of steps (preferably without needing technical expertise).
Lengthy new user guides with excessive steps represent poor accessibility. For example, users registering for an application, downloading a browser plugin wallet, writing down a 12-word mnemonic phrase, visiting an external exchange to purchase cryptocurrency, waiting for the exchange to perform KYC (Know Your Customer) checks, and returning to the application for re-authentication before proceeding with desired actions like swapping tokens or purchasing NFTs. This process requires at least six operational steps across three different service providers to complete the entire operation.
On the other hand, some projects have very integrated and streamlined processes that remove most of the complex steps, providing users with a high degree of "accessible" experience. If users can obtain a crypto wallet while registering for an application, that represents a highly integrated and streamlined onboarding process. Using iFrames can also eliminate the need for users to visit external exchanges to fund their accounts.
Between these two extremes, there are various applications and services that incorporate some of the processes. For example, some applications or services do not rely on browser plugin wallets (eliminating the need for a separate download process) or integrate fiat-to-crypto payment gateways.
Some applications manage users' private keys on their behalf. While this custodial architecture can reduce friction in the new user onboarding process by eliminating the need for external wallets, it comes at the cost of higher technical complexity and legal requirements. These implications are beyond the scope of this article, and teams choosing custodial architectures should thoroughly research the model to weigh the pros and cons.
Identifying the three most common onboarding routes for a specific blockchain is a great starting point for analyzing accessibility. We need to recreate these scenarios from the user's perspective and compile the steps taken into a separate document. Since individual protocols often have multiple onboarding experiences (depending on the specific application and wallet chosen by the user), this process should cover all common scenarios and user types.
2) Wallets
The new user onboarding process includes a user's interaction with the blockchain protocol. For everyday use, the signing and submission of user transactions are crucial. For this reason, analyzing the wallets available on this blockchain (which are essential for such transactions) is a very important method for assessing the accessibility of the application.
Any blockchain transaction needs to be verified by a given user using a digital signature—this prevents malicious actors from performing unauthorized actions. To create this signature, the user's private key is required. Since the private key plays this crucial role, it cannot (or should not) exist solely in our memory, so it needs to be stored in a secure and convenient manner. This is precisely what blockchain wallets provide. Additionally, wallets typically offer an access point for sending transactions to the network.
For functional accessibility, users must easily sign transactions using available wallets for the given blockchain. If users must download external plugins or manually set parameters for how much they are willing to pay for a given transaction, then each subsequent transaction will involve more friction.
To achieve maximum accessibility, wallets should not only be easy to use but also widely accepted across various applications within the project's ecosystem. If users need to set up multiple wallets from different providers to access different applications, the level of accessibility is significantly reduced. For example, if an NFT marketplace does not support the wallet that users use to trade tokens on decentralized exchanges, users essentially need to register for another wallet and track that account in the future.
This issue is directly related to application development: in most cases, developers need to add code for specific providers to their applications to support a new wallet. This creates technical overhead and slows down the integration and availability of multiple wallet providers across applications.
3) Fiat Payment On- and Off-Ramps
While some users conduct transactions almost entirely within the crypto ecosystem, mass user adoption will require users unfamiliar with cryptocurrencies to easily transfer crypto earnings into more familiar currencies. Therefore, functional accessibility also includes the ease with which end users can deposit or withdraw value from the network—the fiat payment on- and off-ramps are crucial for this. Allowing users to purchase a certain amount of cryptocurrency directly with fiat currency using credit cards or other convenient payment methods is vital for improving accessibility.
While using external trading platforms can also achieve currency exchange, dedicated integrated services ensure that users do not have to leave the given application to access payment gateways, significantly enhancing the application's accessibility.
A good starting point for analysis is to roughly screen the list of network tokens on major centralized exchanges. In doing so, you may want to include a list of stablecoins available on the given network. The next step is to systematically check the integrated entry tools of major wallets within the ecosystem; some user-friendly wallets have already integrated these features. For example, the multi-chain wallet Blocto utilizes the payment gateway provider Moonpay to allow users to recharge their cryptocurrency directly in the wallet using simple payment methods like credit cards.
Finally, you can check some of the most commonly used applications in the network that offer fiat payment entry options and note the providers of that service. This comprehensive analysis will detail how much value end users can derive from using the network.
To summarize all elements regarding functional accessibility, these are the main questions developers should ask themselves when deciding which blockchain to build applications on:

• How many steps does the onboarding process for newcomers typically involve? How much prior knowledge or technical expertise is required to complete them?
• How many steps are involved for users to sign transactions? How much prior knowledge or technical expertise is needed to complete these steps?
• Do the integrated wallets seamlessly connect with the user experience? Are they universally applicable across various applications?
• How many steps does it take for users to transfer fiat on-chain? Are there fiat payment on- and off-ramps? How are the project's blockchain-native tokens and stablecoins listed on centralized exchanges?

2. Economic Accessibility—Can You Afford It?
Economic accessibility is based 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 can prevent overuse of their network capacity, helping to avoid the tragedy of the commons. They also protect the underlying network from spam in the form of Denial-of-Service (DoS) attacks.
Transaction fees can be fixed, appearing as included fees when submitting transactions, or they can be dynamic, increasing with the complexity of a given request. Most popular blockchain protocols use one of these types of fees or a combination of them.
Transaction fees are where functional and economic accessibility overlap. In everyday use, transaction fees need to be low enough for everyone to participate while also being high enough to ensure network stability. Additionally, the predictability of these fees is important: if transaction fees exhibit unpredictable high volatility, this will deter under-equipped users from sending transactions to the network. Therefore, any accessibility analysis must consider not only the average transaction price but also the mechanisms that determine these prices on a daily basis.
While users can freely choose Gas prices, higher Gas prices are often selected for quicker execution because network validators need to choose which transactions they want to include in the next block. This process is essentially similar to an auction, where users bid for their transactions. Entire websites like EthGasStation have evolved into platforms for transaction pricing purposes.
This transaction fee model implies several issues:
Under this auction model, when demand is high, transaction fees can skyrocket. For example, sometimes a simple token transfer on Ethereum can incur Gas fees of around $50.
Due to the rapid fluctuations in Gas prices, accurately pricing transaction fees is a very important process. While the recently adopted EIP-1559 pricing mechanism and some user-friendly wallets may mitigate some of these issues, high transaction fees with complex mechanisms can hinder the overall accessibility of projects. Since Layer 1 blockchains and Layer 2 solutions typically offer higher throughput, transaction fees (for the most part) are also significantly lower.
This is precisely why these solutions often have higher accessibility. However, application architects must carefully weigh the pros and cons, as in some cases, faster throughput comes at the cost of reduced decentralization.
Products at the Application Layer:
In addition to transaction fees, the level of economic accessibility also involves the products offered at the application layer of blockchain projects. An important example is the floor price of popular NFT collections within a given ecosystem. The floor price is akin to the minimum price of collectibles, and this metric is often combined with the total volume of NFT collections (i.e., the sum of all collectible prices) to analyze the valuation of the collections.
High floor prices create an ecosystem that is sparsely populated, accessible only to economic elites, which hinders genuine community building and thus reduces the chances of future mass adoption. While high overall value is undoubtedly a good thing for blockchains, if a large number of transactions are mostly accompanied by high floor prices, it is likely that only a few wealthy users can drive economic activity within the ecosystem.
Some may argue that the concept of fractionalizing NFTs (splitting ownership of NFTs among many owners) will circumvent this issue in the long run. However, this comes at the cost of increased engineering overhead, added user complexity, and a lack of legal recognition.
Running Nodes:
Finally, economic accessibility is also a concern for node operators (validators that protect and verify the blockchain). Sufficient numbers of validators will only be incentivized to participate in the network if network nodes are operable under the conditions of meeting hardware requirements and minimum staking amounts (in proof-of-stake networks); only then can its decentralization and integrity be ensured.
Both Bitcoin and Ethereum are networks with a large number of node operators, indicating a high level of reliability and security for their protocols. However, accessibility analysis must take a more nuanced view. For example, the requirements for running a Bitcoin node are relatively low, but a disproportionate number of blocks are mined by mining pools with specialized equipment rather than individual miners, making it less feasible and accessible for someone to run their own Bitcoin node.
While Ethereum's design largely prevents the use of specialized equipment, mining still occurs in centralized mining pools, and the hardware requirements are noticeably higher than those for mining Bitcoin. Since Ethereum stores significantly more data than Bitcoin, new nodes take longer to catch up on this data—currently, it takes about 17 hours to set up a full Ethereum node. Since both time and hardware resources come at a cost, this reduces the economic accessibility for node operators.
When looking for alternatives, it is also important to closely monitor other non-technical factors affecting node operators. For instance, if a network plans to impose permanent rules on who qualifies to be a node operator, this will make it inaccessible to operators who do not meet those standards, leading to reduced decentralization of the network.
Key questions for economic analysis include:

• What is the maximum average transaction fee, and how predictable can users anticipate it to be?
• What is the floor price of popular products at the application layer in primary and secondary markets?
• Who are the main drivers behind the overall transaction volume of the protocol? Are they a small number of large institutions, or a large group of smaller traders?
• How stringent are the hardware requirements and minimum staking balances for node operators?

3. Technical Accessibility—Can You Develop Applications On-Chain?
Technical accessibility describes how easy it is for developers to build applications on a given chain. This concept is also referred to as developer ergonomics.
Programming Concepts:
A team's ability to quickly release blockchain-supported products largely depends on the state of technical accessibility of the project. The first thing to check is the general programming concepts: only if developers can reasonably and quickly understand them can they master them and start building rapidly. Ideally, programming paradigms should be rooted in pre-existing technologies to simplify the onboarding process for developers.
A good approach is to analyze the operations of the main clients of the blockchain. A blockchain client is an implementation of a specific language within the protocol, or simply put, it is the actual program that node operators run to control the blockchain. Some blockchains may have more implementations, which typically indicates a higher degree of accessibility; however, what is more important is the most commonly used language for the clients. First, it should be ensured that this is a well-known, usable, and maintainable language, such as C++, Golang, Rust, or Python. This will ensure the likelihood of these clients being continuously developed and maintained.
The next important consideration is the programming language for smart contracts. Some blockchains like Solana use existing languages such as Rust and C++, while others like Ethereum (Solidity) or Flow (Cadence) have created their own languages. Of course, using established languages with developers can make it easier for developers to get started, but for newcomers, this may come at the cost of learning all the intricacies of a general-purpose programming language, especially time-consuming for low-level languages like C++. Therefore, learning a lightweight new language designed with smart contract programming in mind may be easier.
For new programming languages, it is essential to analyze whether the language has well-known, established programming concepts and paradigms. For example, Solidity is heavily inspired by JavaScript and Java, while Cadence borrows many concepts from Swift and Rust.
Additionally, consider how many abstract concepts the language provides for its developers. Like the underlying protocol, the language should be as concise as possible for developers without sacrificing security or customizability. For instance, Cadence imposes rules on the handling of digital value automatically using a new resource data model, while Solidity requires manual implementation of these low-level checks.
Finally, to ensure the authority of the programming language used, reference relevant educational materials or documentation and provide implementation references. They should also be easily accessible.
Tools:
A good set of tools is crucial for developers, enabling them to build applications quickly, securely, and easily. If common issues are not covered by dedicated tools, it indicates a poor level of technical accessibility, as developers must handle these issues themselves.
Software Development Kits (SDKs) can be considered the most important among these tools. SDKs provide an abstract layer of specific languages for the underlying processes of the protocol, simplifying interactions such as authentication, querying, changing state, and listening for events. If all popular programming languages have SDKs, it indicates a high level of technical accessibility for the given project.
In addition to SDKs, many tools can greatly simplify the onboarding process and daily development for developers. We should check for the existence of text editors (IDEs), testing frameworks, and other extensions for automation, building, and debugging tools that make developing applications on a given blockchain simpler, faster, and more accessible.
Key Questions for Technical Analysis:

• Are the programming concepts of the project easy to learn? Do they allow for rapid, secure, and efficient development?
• Is there sufficient educational material and reference code? Does it also cover advanced concepts such as best practices and patterns?
• Are developer tools available to address the most common issues? Are these tools, along with the main project's source code, open source?

In addition to the considerations mentioned above, there are other factors to consider, such as the general understanding of ordinary users regarding a given blockchain project. If users can quickly enter the space without needing to learn a lot of new knowledge, accessibility will be enhanced. In this regard, the existence of accessible language aimed at end users that avoids technical jargon and buzzwords is very beneficial, but it is challenging to analyze across a broad ecosystem.
In any case, blockchain accessibility is not a nice-to-have that can be added later; it needs to be rooted in the project's DNA. Especially for technical accessibility, it must be considered from the outset when outlining the inner workings of the protocol.
Without accessibility—not just scalability—blockchains will not achieve mass adoption.