Layer 2 First Developer Flow: The first 2 minutes
People want to use a great dapp. You want to build a great dapp. Sounds simple, but current execution proves otherwise.
Introduction
Previous posts gave a proper introduction to the emerging pattern of Incremental Decentralization and our launch of Abridged to bring usability to Web 3. We now want to turn our attention to concrete ways a developer can apply Incremental Decentralization in their dapps. Layer 2 solutions lie at the heart of the actual execution of the core ideas so we offer concrete suggestions for a developer flow centered around efficient layer 2 design. Our discussion will comprise two posts covering two distinct parts of the user lifecycle: the first 2 minutes a new user spends upon landing on your dapp, and then the rest.
The first 2 minutes a new user spends upon landing on your dapp are incredibly precious. They represent disproportionately high-leverage opportunities for your dapp to stand out with a delightful layer 2-centered UX. However, contrary to what you may think, architecting your dapp to turn layer 2 solutions into first class citizens involves much more than just the layer 2 solutions themselves.There are a number of critical support tools emerging to form a layer in between layers 1 and 2 which we’ll refer to as layer 1.5 (we know, this layer analogy is going to suffer from overuse sooner or later). Layer 1.5 does most of the heavy lifting in propelling your user through the Web 3 entry process so that your dapp actually has a chance of being used.
Onboarding
When a new user lands on your dapp, you’re going to need to onboard her with an account and a wallet. It’s only the first step and you’re already faced with a mountain of a challenge. Do you ask her to download MetaMask? Do you use Universal Login instead? You might counter by punting the signup process down the road until your user needs to take action that absolutely requires some form of identity. We acknowledge that any of these can be viable options depending on the circumstances, but let’s pause and take a step back to look at the bigger picture.
As a dapp developer, it’s important to distinguish the subtle difference between entirely new behavior patterns and friction around existing behavior patterns. The established behavior pattern of Web 2.0 onboarding is to create a username, password, and go through mobile or email verification to enter. Using MetaMask imposes a tremendous amount of new behaviors a user must learn just to gain entry for a dapp. Universal Login is much closer to the established behavior pattern, but the lack of a password and .eth suffix still introduces new elements that could decrease a new user’s sense of security. Punting the signup process may feel like a clever solution, but most likely it’s just a poor attempt to run from the problem (spoiler: you can’t). So what if we used the existing behavior pattern and ran the blockchain stuff so deep under the hood that your dapp doesn’t elicit user comments on the onboarding flow because it’s so… normal?
Our suggestion:
Use a signup UI that pairs a user-ID management tool like AWS Cognito with Abridged’s implementation of account contracts.
AWS Cognito offers a familiar signup process for your user with basic inputs being username, password, and email verification. You can make your signup process more robust by enabling multi-factor authentication. It’s the same thing she’s done countless times to sign into any other Web 2.0 app, and her expectations are met.
All the magic happens when you integrate Abridged account contracts into your codebase to be triggered upon successful completion of the Cognito flow. The contracts are counterfactually instantiated, which means that when your user successfully completes the signup flow, she is automatically given a reserved account address that she can immediately receive funds with. She’s none the wiser because she doesn’t see the address nor download ancillary software nor hit a separate button to create this address — it’s just there. Her existing behavior pattern did not change one bit, and yet she has gained unfettered entry into the Web 3 ecosystem in under 30 seconds.
Buy In & Self Custody
Let’s apply the same rationale with buy in and self custody. The existing Web 2.0 behavior pattern here is for your user to either enter her credit card information or hook up a provider like Apple Pay. The prevalence of in-app purchasing models set the bar high for all developers to provide a seamless UX for fund transfers. In the Web 3 world, fiat-to-crypto onramps typically put your users through an arduous KYC/AML process with an exchange and then require them to transfer funds into whichever wallet is hooked up with your dapp. Getting users to spend money is already hard enough, why make it nearly impossible by forcing them to learn all these extra new behaviors?
Our suggestion:
Integrate the Wyre widget to appear on the screen right after your user successfully creates and verifies her new account.
Wyre is a fantastic project that enables users to purchase up to $40 in eth without going through a long KYC/AML process. Your user punches in her credit card information, provides a few more standard inputs like the billing address and phone number, and obtains her eth. Here, we acknowledge that the use of a credit card means the involvement of a centralized provider aka the bank and the $25 limit is definitely on the low end. However, in the spirit of Incremental Decentralization, it’s the existing behavior pattern that matters. This step will probably take a minute and half, tops. It’s so normal it’s almost boring.
The magic happens when you hook up your user’s newly generated account contract to be the recipient of any crypto purchase that occurs through the Wyre widget. Instead of prompting your user to manually input an Ethereum address, you can edit the Wyre widget logic to automatically grab the account address associated with your user. The transaction from Wyre to your user’s account contract, which is still counterfactually instantiated, happens on-chain. The on-chain nature of the transaction is significant because your user has full custody of her funds, regardless of any potential failure of centralized components within your dapp.
Access
Finally, your user should be able to access her funds at any time. The expectation is that when your user puts funds into your dapp, she should immediately be able to use it however she pleases whether that’s to send it to another address, exchange it for another token, or withdraw it all. There is no concept of “activation” or “deployment” when it comes to in-app funds in the Web 2.0 world. The existing behavior pattern here is… to do nothing. That poses a challenge to our suggested flow so far because your user’s account contract is counterfactually instantiated and therefore must be deployed in order for the funds to be accessible.
Our suggestion:
Integrate the Gas Station Network to automatically deploy your user’s account contract via meta transactions when funds first hit the contract.
The original intention of a meta transaction relayer network was to allow users to engage in Web 3 interactions from ether-less accounts. This is achieved by relaying a signed transaction from your user to a secondary miner network that pays the gas fee to execute the transaction. This intention can still be realized within your dapp (read: it should, given the chance that your user could choose to skip the Wyre funding step).
We suggest a slightly different way to think about the Gas Station Network: use it as a way to automate the deployment of your user’s counterfactually instantiated account contract. You can bake into the Wyre deposit summary a confirmation message for your user to accept a nominal one-time fee. When your user confirms this fee, what she’s actually doing under the hood is signing a transaction that is sent to the Gas Station Network. The transaction is executed by a network miner, and the fees associated with contract deployment is paid with the funds she receives via the Wyre deposit. This replaces the need to create a separate button for your user to click and manually deploy her account contract once she’s entered your dapp. The end result is that your user can use the funds in her account contract to do whatever she pleases without having to take any additional steps, preserving the established user behavior pattern of doing nothing for access.
Conclusion
Crafting a thoughtful and delightful experience for your user’s first 2 minutes is one of the highest leverage things you can do as a developer. The bar for good dapp onboarding is extremely low and that leaves ample opportunity to make a lasting positive impression by incorporating the suggested developer flow. Since each step applies the core principles of Incremental Decentralization, you end up enlarging your user’s comfort zone instead of taking her out of it.
The next part to this developer flow series will be about the rest of your user’s journey through your dapp after the first two minutes. Successfully onboarding your user will not do much to keep her coming back if you don’t have a scalability solution integrated into your dapp so much of the focus will be on layer 2 tools like state channels. Future posts will then go through hands-on tutorials that take you through the flows step-by-step with real code so you can take the learnings and directly apply it to your dapp using Abridged’s SDK! Make sure to request access if you are interested in getting your hands on it early!
