As one of relatively few shipping crypto projects, we’ve found ourselves on the bleeding edge of user onboarding – which has become by far the biggest obstacle standing in the way of broad adoption of ours and others’ dApps.
Our discussions with many other project teams at conferences and the lively debates on reddit confirm that this is indeed a widespread and significant problem noticed by the majority.
New users currently need to jump through some very unfamiliar and technical hoops to try out dApps, and judging by the dismal marketwide DAUs (daily active users) and MAUs (monthly active users), they’re just not ‘buying it’!
The need to deal with browser plugins and extensions or even entirely new and unfamiliar crypto-enabled browsers, along with the steep learning curve of private key security and backup phrases, is too high a barrier for the vast majority of users.
The ease of use and broad compatibility we take for granted in a Web2 environment has not yet found its way to the world of dApps.
What’s needed is a way to ease people into the new Web3 world from their familiar Web2 environments – giving them a smooth transition to blockchain experiences and benefits.
Moreover, while the Web3 situation on desktop browsers is bad enough, 60-70% (and rising) of all web traffic comes from mobile devices. iPhone and Android dominate the mobile market, yet their default browsers are woefully incompatible with Web3 and can’t be ‘upgraded’ through the use of plugins such as are available on desktop.
If a potential customer has to download a whole new browser to try out a dApp they find attractive; it’s a problem – especially when their familiar browsing environment (bookmarks, history, password manager, etc.) is absent.
There are already some strong efforts in the mobile Web3 browser/wallet space, including Status.im, the Coinbase wallet and the Trust wallet. However, these all still suffer from the same problems of being yet another app that needs to be downloaded and therefore continuing to provide an unfamiliar environment to the user.
As a simple example, most current Web3 mobile browsers don’t currently support landscape mode, and yet the dominant applications on the internet are entertainment apps designed to be viewed in landscape. Examples like Netflix or Youtube showcase the truly awful experience that consuming media or playing games in a Web3 environment is. Web3 browser apps need to improve their support for the internet’s most popular activities, and it can’t come soon enough.
These chronic hurdles lead to frustration and a poor initial experience for new users trying out what is supposed to be a ‘revolutionary’ new breed of application. The first impressions are terrible, and it shouldn’t be underestimated how much this is damaging adoption.
Better and more dependable wallets are coming, however, and some demonstrate real innovation, such as Argent, Tokencard, Dapper and Gnosis Safe. Some also enable easier onboarding that doesn’t force users to write down seed phrases, with security and usability powered by smart-contract based wallets that support spending limits, use relayers to pay for gas and provide social recovery of lost private keys. Despite this, these new browsers are still in their infancy. They are also challenging to find but do have a small but encouraging growing number of users.
We see the trend towards contract wallets as a positive one – and arguably Argent is currently the best of the breed but is only in limited release. Argent’s decision to pay for its user’s gas costs via its relayer is ambitious and probably explains why there’s a queuing system for user installs, but to afford to do this sustainably will require upselling value-added services to the user, and it’s unclear at this time how scaleable that model will be. Gnosis Safe is also impressive and is catching up fast.
Dapper Labs, creators of Cryptokitties, came up with their solution consisting of an app & contract wallet but doesn’t run on native browsers at this time, something that we feel is important to be able to reach the most significant potential audience.
Universallogin.io is another with an interesting approach, using ENS domains as usernames and is trying to gamify the experience of creating an account by rewarding achievements. It seems somewhat similar to Argent in its goals but not as far along in its development.
One issue we’re aware of with contract wallets is that they require some on-chain transactions to create the ENS username and contract wallet which adds a small delay and cost to the initial creation of a user account. These transactions are subject to network delays and fluctuating gas costs, which someone somewhere will have to pay for. Many of the contract wallets also rely on relayers or guardians and its not clear who pays in that instance, or what relayers have to charge to operate their service in a sustainable way.
Some of the demos we’ve seen so far are running on test nets or side chains which operate faster and are less expensive than ‘main net’ and aren’t quite as representative of the real world where the network can become clogged by uncles, airdrops, kitties and ICOs, which might not make the experience so frictionless for a first time user.
Long-term we have high hopes for these and other new contract wallets, but in the meantime, a couple of billion people are using existing browsers and only single-digit thousands have downloaded these new Web3 browsers and wallets. To reiterate, anything the user doesn’t already own and use on their phone is ‘high friction’ and will put headwinds in the way of dApp use far more than if the dApp could somehow run on their existing browser without any download or requirement to install a new plugin or browse or wallet.
Other initiatives like WalletConnect are exciting and might be a temporary bridge to connect wallets with existing browsers, but these too are complicated and not particularly user-friendly. QR codes to bridge a wallet and dApp are still unnecessary friction.
We’re also interested in what Austin Griffith is doing with Kirby, allowing for instant onboarding via an ephemeral private key, which might work well for low-value use cases that don’t require much security, and we’re keen to see how it will cope with the security of running in an iFrame and not allowing a rogue parent site to steal user funds.
One additional problem facing all of these specialised mobile browser apps is potential App Store censorship. Both Apple and Google have a chequered past when it comes to arbitrary censorship of apps, especially those that are related to crypto (potentially eating into their current or future banking and credit card business models). This adds considerable uncertainty to the dedicated crypto mobile wallet/browser.
An example of this censorship had already happened in the EOS ecosystem, where a popular browser/wallet was taken out of the app store for offering discovery features of available dApps and was only allowed back in when the dApp discovery option was curtailed.
If we want to be able to onboard new users, en masse, with as little resistance as possible, we need our dApps to run on whatever browser the user already has, on whatever device they’re already using. The mountain must come to Mohammed.
How can we make dApps run on standard browsers on any device, you might ask? By building a bridge between the Web2 and Web3 worlds that will enable new users to quickly try our dApps using the devices and browsers they already own.
Our FunFair B2B-focused gaming tech launched almost a year ago allowing games of chance (provably fair) to be played for real money (in our case, through the use of our ERC20 FUN token) and is now available on a couple of initial sites with more coming.
During that time, we’ve collected scores of anonymous data points on where the user gets stuck in their onboarding journey. We can see plain as day where we lose people in the onboarding funnel, and much of the time its very early – at the start – the moment they’re asked to download a Web3 browser or wallet and to create an Ethereum account. We believe we could reach a lot more users for our dApp if there were far lower friction, no requirement to download or install anything new, and a UI that had a much more comfortable learning curve.
While we are first and foremost an online gaming platform company, we recognised the critical need for this ‘newbie friendly’ approach and decided about a year ago to embark on building our technology to provide an easy to use wallet that targets this significant onboarding friction.
Our FunWallet runs in any web browser inside an iFrame, on any device, mobile or desktop, Safari or Chrome. No plugin nor download nor install needed. Nothing to seek out in the App Store. Nothing that risks being censored by the App Store gatekeepers. So thus our users will now be able to run any of our partner casinos within their own comfortable and familiar environment with a smooth user journey.
While security is always front of mind for us across all elements of our ecosystem, we needed to make some tradeoffs between strong security and user familiarity and convenience. Every wallet needs to determine where they balance these two factors, and we think we’ve come up with a robust security offering, but packaged in an easy to use – and most importantly – browser and device-agnostic manner.
We avoided going down the route of using a device’s phone number or using SMS as a way to securely identify a user as clearly this is a massive security hole that has been broadly exploited in other applications.
Instead, we’ve built a non-custodial web wallet that enables Web3 applications such as FunFair to run within a conventional browser by signing in to their account, using an email address and password. This is the same familiar way they already do in every other web application from Netflix to banking to crypto applications like exchanges.
Non-crypto people appreciate the familiarity of this approach, but we realise that crypto-maximalists might be concerned about using logins. The reality is that we’re trying to reach mass-market customers – who’ve never deliberately sought out crypto dApps.
It’s perhaps a trojan horse to let them use our dApps without ramming ‘blockchain’ jargon down their throats while reducing friction and finding a happy medium that bridges Web2 browsers to Web3 dApps. If these new users go on to learn more about blockchain and gain the experience and comfort to become ‘power users’, then we’re thrilled that it might help introduce some new users to our blockchain world of dApps.
As a result, the FunWallet lets any Web3 application run on the standard browsers that everyone already uses, including Safari on iPhones and Chrome on Android phones. It runs on Web3 browsers as well, thus serving the largest possible addressable market – which opens up even more ways for users to try our dApps.
Security vs. Ease of Use
Users make mistakes; They forget passwords, They lose or change devices. They get phished, scammed and hacked. So the FunWallet needed to support password changes, recovery tools, and support multiple devices and device changes, as well as optional security features like 2FA (but not SMS)! Moreover, of course since its Web3, it must let them export or backup their private key if they want to migrate to a different wallet in the future, and that’s one of the reasons why we’ll have MetaMask support at launch and others integrated down the line.
Our security model has similarities to some secure password manager applications, Lastpass for instance or 1Password and Dashlane. It also has a resemblance to some existing and popular crypto wallets like Edge (formerly AirBitz) and Blockchain.com. It’s a non-custodial wallet and the user’s private key is held in encrypted form on the server, but the server doesn’t have access to the decryption key. The private key is only ever decrypted locally in the client’s browser at login time from information that the user has provided (username and password) combined with a’ secret’ (we call it a ‘master key’) in their browser cache that is generated and stored locally and unique to each of the user’s devices.
The server never has access to the user’s unencrypted private key, in much the same way that Lastpass, 1Password and Dashlane don’t have access to unencrypted user passwords on their servers. Therefore the server is not a honeypot of private keys like some onboarding solutions out there – the server never sees your unencrypted private key, your devices’ ‘master keys’ (browser’ secret), nor the credentials used to generate the master key.
A year later and we’re no longer the only group working to bridge the Web2 and Web3 worlds via user logins and browser/device independence. Authereum and Tor.us are tackling this need as well, and Tor.us have a slightly different take on it, generating a secure private key using MPC distributed methods, but alas relying upon Google, Facebook and other 0Auth login methods. There’s good and bad in that approach, especially when it comes to user privacy as some would argue that these mega-corporations have too much information about us already and knowing when, where and why we login has significant downsides.
We’re keen to see lots of different experiments that help with onboarding, and we think the more options are tried out, the better it will be for all of us in the space. We can’t wait to see what they all come up with and how they approach the nirvana of frictionless user adoption, that’s fast, inexpensive, reasonably secure and which will become the most convenient and accessible.
Our short term goal is to work with the new FunFair wallet in a controlled environment. Initially, it will support just FUN and ETH and only work with FunFair-powered sites. We’ll learn from our users’ experience and tweak the wallet to do whatever we can to reduce friction and improve usability.
Long term, if it looks like this solution will help with real-world adoption more broadly, then we will look to open it up to support other crypto assets, applications and Web3 dApps.
FunFair is just the first test environment, and if it works out the way we hope, then we can use the same solution to help many other dApps find their market. We might even spin it off as a separate project since it will likely need ongoing effort to address this broader, more general-purpose mission.
Further on, we will also explore other methods like MPC to further decentralise the wallet or, for example, consider using FileCoin or Swarm for managing off chain data (when they’re live and robust enough to rely upon).
We also love the direction that contract wallets and social recovery are taking and think they’re an excellent long term path for wallets to take and hope that they get some traction. We will be considering how we can best utilise those ideas or partner with those already building them. We also plan to support ENS domains, and of course, to further integrate our state channel tech (“Fate Channels”) into the wallet in a low-friction manner in the future.
Although we never wanted to be in the wallet business, our team recognised the importance of addressing this vital need. We are happy with the way the FunWallet has progressed and are anxious to see how it improves our user’s onboarding experience. We want to make it as easy as possible for new users to be able to discover and use dApps with reduced friction over what they have today. Perhaps one day, they might not even need to know they’re using ‘a blockchain’ when they use dApps, and that they ‘just work’.
We’d love to hear from the broader community! You’re now able to try the new sign up process out with TESTFUN on our showcase site, showcase.funfair.io or watch the video we’ve prepared . Very soon if you live in an approved jurisdiction, you’ll be able to play for real (with FUN tokens) on casinofair.com and cryptocasino.com, so stay tuned through our community channels on discord, telegram or reddit. There are more than 20 games so far to try out and generous promotions on offer for those playing.
And who knows, you might even have FUN!