What is Blockchain Accessibility?
If you've done any frontend development, you've probably had to think about the accessibility (or a11y) of your apps.
- Is this text large enough for people to read?
- Is the color contrast high enough?
- Will color-blind users be able to see this?
- What about people using screen readers?
And on and on. These are all critical concerns that carry over to the UIs you'll build for blockchain apps, but that's not what I mean by "blockchain accessibility."
Today, only a tiny percentage of the population uses dapps. Over 60% of the world uses the internet, but only ~1-4% of people use blockchain. Why? I believe this mostly comes down to the accessibility of four factors: fees, wallets, education, and scams.
Fees
To use blockchain apps, you have to pay gas fees, which exist to prevent network spam. Some of the fees go to the people running the network nodes, but that's not its purpose. The Ethereum network destroys a good portion of the fees. The fees don't even go to the app owner or developer. If you want to monetize your apps, users will have to spend additional money on top of gas.
Depending on how simple your app is and where you deploy it, gas fees could be $1 or $100. But as we know from traditional web experiences, if users have to give up their payment information to use an app, you're going to lose a large percentage of potential customers. That's why most websites don't ask for your credit card until the last possible moment (and, if possible, not at all).
Wallets
On a blockchain, you don't create an account with a username and password on every different website that connects to that chain. You own your identity. Your public address on the blockchain identifies all your cryptocurrencies, NFTs, and other data. You prove that you're the owner by signing a message with your private key. You never expose your private key--that's how you get robbed.
For typical users, remembering a password is hard enough. Having to manage a private key is harder. This is where wallet software comes in (like Metamask on Ethereum or Kondor for Koinos). Until blockchains become commonplace, most people won't have a wallet set up when they hit your app. So you'll need to either guide them through the wallet setup or support custodial accounts.
Education
Most people have no idea what a blockchain is. Fortunately, they don't have to understand it to benefit from it. Don't bog down your users with technical jargon. Help them understand why it matters, not how it works (for advanced users, you can hide that in a linked page).
Scams
Crypto is the wild west. If you're going to hold your own private keys, you have to be careful. Users will be hesitant to take risks. As the app developer, always try to build can't-scam systems instead of making won't-scam promises.
If you can make these things super easy for your users, your app will be ready for mass adoption. After that, traditional app monetization and marketing rules apply.
The Elephant in the Room: Gas Fees
If you want to charge substantial direct fees every time someone uses your app, then gas fees are additional costs that make using your app more expensive, but your target audience may be okay with that. If you build something just for people with lots of money, gas probably won't matter.
Gas fees are a problem when you want to build something that can be used frequently and inexpensively by people who aren't already big spenders on a blockchain. Many decentralized apps (dapps) are worth thousands of dollars to a small group of people. There's a larger group of people that would happily pay a couple of bucks for a similar experience. If you can offer the experience for free, your potential audience grows exponentially.
If you want to offer a cheaper experience, you can do this with many alternative L1 blockchains (Binance, Solana, etc.) or even on L2 (Arbitrum, zkSync, etc.). Their fees aren't guaranteed to stay low forever, but it's still a significant improvement over Ethereum. The problem with "cheaper" and not "free" is that requiring users to pay anything will exclude a large potential audience.
Don't get me wrong, you can build a profitable business this way, but there is extremely little competition right now to convert "people who like the idea of blockchains, but don't want to pay $100 to use it" into loyal customers. If you can work around gas fees entirely, your app can achieve mass adoption. There's a reason most web2 apps are free to use.
To work around gas fees, you have two options: pay the fee for your users or use a blockchain without fees.
Pay the Fee
On Ethereum, paying the fees yourself likely isn't economically feasible for your app. You could incur severe costs. Unless you're planning on making a hefty profit off of every interaction with your app, this may not be a good way. At that point, your users probably don't care about the gas fee too much anyway.
On cheaper L1s or L2s, you can make this work. You just need to make enough money on average to cover your gas costs. This is still tricky, though, because most blockchains don't provide a way for you to pay for your users. Most apps get around this by using centralized services (aka traditional Web2 backends & databases) and only interacting with the blockchain when absolutely necessary.
Use a Blockchain Without Fees
Koinos is the only fee-less smart contract platform I'm aware of (if there's another, please let me know). Instead of paying for gas with tokens, you pay an opportunity cost by locking your Koin for a couple of days. To power your dapps, you can either own your own Koin tokens or ask the Koinos community to share resources with you (Koinos will let you "try before you buy" on mainnet). There's a lot of free support available to get you started until you decide whether you want to hold your own Koin.
Full disclosure: Don't trust me. I own $KOIN but am unaffiliated with Koinos Group. The opinions expressed here are for information purposes only and should not be construed as investment advice.
Regardless of whether you use Koinos, you'll need to monetize your app to cover your costs. If you're stuck with gas fees, it's hard to make most traditional monetization models work. If you don't have to worry about gas, you can charge a monthly subscription, use a freemium model, run ads, etc.
If you just want to target high rollers, more power to you. Blockchain accessibility is about making decentralized experiences enjoyable for everyone.
Wallets -- "I need to set up a what?"
Wallets are critical for decentralization. If your users don't control (take custody of) their private keys, you are a centralized point of failure for their account. But requiring a potential user to stop using your app and set up a wallet is at odds with accessibility. Imagine your app is for non-technical users, but the only way to access the app is to "sign in with GitHub." There are three main ways to handle wallets for your app.
Centralized Accounts
This is the default approach of Web2. Your typical email/password. Centralized exchanges like Coinbase and Binance do this for their users. You make the account's public key known but hold the private key yourself. This opens you up to hacking and puts a lot of responsibility on you as the developer. Not to mention it defeats the purpose of decentralization. I don't recommend this approach.
Non-custodial Accounts
The default approach of Web3. Wallet hardware/software for users to manage their private keys. If you're only targeting users already using blockchains, just do this. It's decentralized, but it puts the burden on the end-user. If your users don't properly manage their private keys, they could lose access to their account and have no way to recover it. If you want to offer an experience ready for mass adoption, you need an improved user experience over the default. At the very least, help your users set up a wallet without leaving your app and warn them of the responsibility.
Supporting Both
Offering more than one method for wallet management is a workaround to provide the UX your users want. Technical users who care about decentralization can use their wallets. Non-technical users who just want to use the app can create a centralized account on your platform. On blockchains with high gas fees, this is probably the best option. The downside is it requires you to implement authorization both ways and still take on the responsibility of managing accounts for your users.
Smart Contract Wallets
What users really need is a safe way to use dapps and manage their accounts. Holding tokens inside a smart contract lets you map ownership to private keys and a typical email login without a centralized dependency. You can provide account recovery features and a lot of other security precautions as well. This option isn't popular on Ethereum because it would cost more Ether than the default non-custodial wallet. Fee-less blockchains like Koinos allow you to use smart contract wallets without spending money. This is my preferred option for setting up new accounts for non-technical users because it's decentralized and safer. You'll be able to support "normal" wallets with little or no effort.
You probably don't want to build your own smart contract wallet for your dapp (but you could). The Kondor wallet is currently being developed for Koinos and should support the capabilities I describe here.
Sorry, You're Not the Center of the Universe
When you build typical Web2 apps, you own everything you create. Your users don't talk to each other. They speak to you. This is true even if you build a social network--if you shut down your app, you take everyone's connections with you. In this case, you created a centralized app by definition.
Decentralized experiences are peer-to-peer. Your users use your dapp to interact directly--they don't come through you. When you deploy your smart contracts, they're no longer a part of your app. Other developers can create their own UI on top of your contracts. They could even create bots that interact with your contracts on their behalf. It's like creating an API and a database that you don't own.
This is open-source, taken to its logical limit. Your app's business logic is not a competitive advantage. It's freely available to anyone and everyone. There's no point in patenting it. It's not your intellectual property. It belongs to the community.
You might be wondering: how do I build a business around that? Your specific answer is going to vary depending on what you want to develop, but generally, it boils down to two things:
Your Brand
Your brand is your competitive advantage. You can't expect to make a profit off of 100% of the people who use your app, but as soon as you launch, you're everyone's favorite. You did it first--everyone else is just a copycat. You've probably heard the phrase "imitation is the sincerest form of flattery." If you want to remain the top brand, learn from your competition, be humble, and be generous.
With any business, having a loyal customer base is everything. If people are excited to use your app and tell their friends, you will do well. If they feel like a part-owner of the brand, you will do very well. Tokens on a blockchain are an ideal way to incentivize community involvement. You can reward your users for participating, and they'll be that much more likely to stay with you.
The same factors determine your long-term success as a developer and business in Web3 as everything else in life: honesty, transparency, humility, kindness, etc. Put your community above yourself.
There are ways to write your smart contracts, so you don't hand over ownership to the community, but I generally don't recommend that.
Don't Sacrifice Decentralization
Blockchain apps are called dapps. They're decentralized because no one owns or controls the smart contracts. Sure, you built it, but it's out of your hands once deployed. At least that's the default behavior.
There are ways to opt out of decentralization for your app. You can launch an upgradeable contract without governance, take too much of your token for yourself, write your smart contracts so only you can use them, and even build a centralized app that users have to go through. There are valid reasons to use these approaches, but it's my opinion that you shouldn't do this for serious projects. Here's why:
Centralization Requires Trust
The whole point of blockchain is that you can use it without trusting other users. We can call a smart contract independently to trade your tokens for mine without needing to meet in a dark alley or involve an escrow agent. If the smart contract is centralized in any way, then it's not trustless. I won't use your contract unless I trust you.
Creating a token for your dApp that hands over control to token holders is probably the most common way to decentralize. This comes with the added benefit of allowing you to raise money. However, if your smart contract isn't upgradeable, there's not really anything to govern. Be clear about what control token holders will have and don't complicate your app with a token if you don't need to.
Don't Add Centralized Layers
Even if you lay a good foundation for your dapp on the blockchain, you can still make centralized choices on top of that. By default, you only need a frontend single-page app to talk directly to the blockchain. The only backend infrastructure you need is the frontend hosting (Vercel and Netlify are probably the easiest to use) and a blockchain node that exposes its API (prefer hosting your own, but it's okay to use someone else's node if you trust them).
That's it. You can add other centralized infrastructure, but most of the time, you should avoid it. If you have data, images, video, etc., that would be too much to store on-chain; look for decentralized options for hosting (IPFS, for example). At the very least, store a hash of the data on-chain so it can be verified and trusted by your frontend.
The one exception to this is performance. Your app still needs to be fast. No one wants to use a slow website, no matter how cool the technology is behind it. It's okay to use caching, pre-fetching, and other typical performance tricks with centralized infrastructure. Just treat the performant results as "optimistic" representations of the actual data. Everything should eventually resolve to the correct blockchain data.
Simplifying your off-chain dependencies will also make it easier for other developers to build clients that use your smart contracts. This helps build further trust and a vibrant community.
Resources to Help You Start Building
So, now you know everything you need to do to be ready for mass adoption of your dapps:
- Don't expose your users to gas fees
- Make it easy for people who don't have wallets yet
- Build a community and don't expect to be the center of it
- Avoid centralized points of failure
Simple right? The hardest part starts now. Take your idea and start working on it. Don't be afraid to talk to people about it--everyone has their own ideas to worry about. You'll gain more by talking to people than risk people copying your ideas. Besides, copycats signal that you're doing something that matters.
Suppose you don't have an idea you're excited about. In that case, I'm currently developing a list of "100 profitable dapp ideas" -- if you're interested, shoot me an email, and I'll send you an advance copy for free.
If you're a fullstack or frontend developer, you have most of your skills to build your app. There's relatively little work that actually goes into your smart contracts. If you want to learn how to write smart contracts, I highly recommend:
- LearnWeb3 DAO
These resources focus on Ethereum and Solidity. If you're looking to build on alternative blockchains (like Koinos), the best option is to join their community chat and start talking about what you want to develop. Join the Koinos discord server (and say hello 👋)
One last thing: don't put everything on the blockchain. You might be tempted to treat it as your database, image host, personal file store, etc., but don't. The easiest way to think about the blockchain's role is for metadata and peer-to-peer computing. The bulk of your data and computation (at least a lot of the time) should most likely move off-chain. Store hashes of your data on-chain, and run code in your frontend when appropriate.
About the Author
Luke Willis has been a traditional fullstack web dev for close to 10 years -- working in various languages, frameworks, and platforms. I consulted for companies large and small across many industries, led and coached teams of developers, and built some pretty exciting software along the way.
Last year, I started learning, writing, and podcasting about blockchain at TheKoinPress.com. I'm building dapps of my own and sharing my experience. I will soon offer coaching services and products to help you move faster with Web3; if you want to build decentralized applications that are ready for mass adoption (and run a profitable business doing so), subscribe to my newsletter and email me any time.
