Despite the advancement of ’ capabilities over the past year, adoption has been slowed by terrible user experience. Users are required to complete a complicated and onerous series of steps—download a wallet, learn about gas costs, obtain tokens to pay gas, save seed phrases, and more. This poses a significant hurdle for users new to the blockchain, or those who are just uncomfortable with holding crypto. Often, they just give up. dApps To solve this problem, on Flow have emerged. With this approach, users can easily sign up for dApps using credentials they are already comfortable with (social logins, email accounts). This allows them to get started quickly, without needing to understand the complexities of wallets or blockchain. walletless dApps In this two-part series, we’ll explore how walletless dApps on Flow work. We'll look at some use cases and walk you through the steps of building and deploying your wallet-less web3 dApp using the Flow Wallet API and account abstraction. Here in part one, we'll focus on building the backend for our walletless dApp. In part two, we'll wrap up the walkthrough by building the front end. Content Overview How Flow Solves Web3 Onboarding Use Cases of Account Abstraction Building a Sample Walletless Login dApp Set up Flow Wallet API application Configure Environment Variables Update the File docker-compose.yml Test the Flow Wallet API Application How Flow Solves Web3 Onboarding Flow is a highly scalable blockchain with a design philosophy that prioritizes : easy user logins, mobile-ready, fast development time, 99.99% up-time, and more. It’s made for dApps that have real-world usage mainstream use Account abstraction (AA) on Flow falls right into this philosophy. AA, in combination with hybrid custody, creates a experience for users. What does this mean? walletless onboarding Typically, accounts on a blockchain are owned either by a user with a private key—called an externally owned account (EOA)—or by a smart contract—called a contract account. Account abstraction combines these ideas. It allows the user to control the wallet while abstracting away the idea of the wallet altogether by letting the contract also have control. On Flow, this is called Hybrid Custody. Use Cases of Account Abstraction There are lots of advantages to this “account delegation.” Since one account (the child/EOA account) can delegate control to another account (the parent/app account), developers can provide users with a seamless onboarding and in-app experience while giving them a sense of actual ownership and self-sovereignty. This is particularly useful for new users who are not familiar with the intricacies of blockchain technology and can help increase adoption and engagement with the application. For example, developers can build apps that create wallets for users, manage keys and transactions, and even abstract away the blockchain altogether. But in the end, the user still has control and ownership over any assets in the wallet. Other use cases include: Key recovery with multi-sig transactions An account may be set up to require multiple signatures to complete a transaction. This creates a wide variety of new use cases and enhances the usability of Web3 apps.\ Gasless experiences with sponsored transactions The stress that comes with paying fees—before newbies can use a Web3 app and execute a transaction—can be a barrier. Sponsored transactions give room for developers to subsidize these charges on behalf of users. Seamless experiences with bundled transactions Flow’s Cadence programming language, which introduces new features to smart contracts, also separates contracts from transactions. It supports bundling transactions from several contracts into a single transaction at the protocol level. Social logins with wallet-less onboarding + hybrid custody Flow enables its developers to deliver a familiar experience while progressively exposing new users to the benefits of Web3. Users can realize the benefits of both custodial and non-custodial experiences, which is what hybrid custody entails. All this together makes it much easier for users to get started with dApps. web3 Building a Sample Walletless Login dApp So let’s next walk through creating a walletless dApp. We’ll build a dApp that integrates Google social login/signup and creates a Flow wallet for the user on signup time. Here is a quick breakdown of what we’re going to do in part one of this walkthrough: Set up a dockerized Flow Wallet API application to use the Flow Testnet Test the Flow Wallet API Application Then, in part two: Create a new Next.js application Set up Prisma for backend user management Build the Next.js application frontend functionality Test our Next.js application Are you ready? Let’s go! Set up Flow Wallet API application To make our lives easier, we’ll use the . This is a REST HTTP service that allows developers to quickly integrate wallet functionality into dApps. This API was developed in Golang, so knowledge of Go will help you, though proficiency is unnecessary to make this app work! The Flow Wallet API is currently not maintained. However, at the time of writing, the API was working perfectly. Flow Wallet API Clone the project folder with the following command: $ git clone https://github.com/flow-hydraulics/flow-wallet-api.git To facilitate the development, we will use . If you don't have it installed on your OS, you can find instructions for it at this link: Docker https://docs.docker.com/engine/install/ From the terminal, navigate to the newly created directory. flow-wallet-api I recommend taking the time to review the folder structure. This API was very well done and is a complete code with unit tests included! To make this article as short as possible, we will focus on executing the code. MacOS M1 chip config Note: If your computer is a Mac using an M1 chip, you will need to change the file in the folder. If you are not using an M1, you can skip this section. Dockerfile docker/wallet/ In , edit the first line of code. We will change the Golang version used by the container to: Dockerfile FROM golang:1.20rc1-alpine3.17 AS dependencies You will also need to change the value of the field: GOARCH GOARCH=arm64 That's it! These are the required changes in Mac M1 operating systems. Configure Environment Variables Before we can spin up the Flow Wallet API, we need to make some configuration changes. The first step is to rename the file to . The application will use this file to import the environment variables. .env.example .env Within the file, we need to change some values. .env Flow network fields Since we will be running the application over Flow’s Testnet network, we need to change the environment variables and . In the file, comment out the following lines: FLOW_WALLET_ACCESS_API_HOST FLOW_WALLET_CHAIN_ID .env # emulator
# FLOW_WALLET_ACCESS_API_HOST=localhost:3000
# FLOW_WALLET_CHAIN_ID=flow-emulator Then, uncomment the following lines: # testnet
FLOW_WALLET_ACCESS_API_HOST=access.testnet.nodes.onflow.org:9000
FLOW_WALLET_CHAIN_ID=flow-testnet With this change, we’ve modified the configuration of the application to use the Testnet network. Flow admin account fields To use the Testnet, we need to create a Testnet account and update the and fields inside the file. FLOW_WALLET_ADMIN_ADDRESS FLOW_WALLET_ADMIN_PRIVATE_KEY .env To create a Flow Testnet account, you must first install the Flow CLI on your operating system. You can find instructions on how to do this . here With Flow CLI installed, run the command: $ flow keys generate This command will generate an asymmetric public-private key pair. Save the private key somewhere. Then, copy the public key—we will use it in the next step to create an account on the Flow blockchain! Create a Flow Testnet account Open the browser on the Flow faucet: https://testnet-faucet.onflow.org/ In the first input, paste in the public key you just generated. Leave the rest with the default settings, then perform the CAPTCHA verification and click the Create Account button. This will generate a Testnet Address. Copy the address and use it as a value for the field in the file. Also, update the field with the private key that you generated in the previous step. FLOW_WALLET_ADMIN_ADDRESS .env FLOW_WALLET_ADMIN_PRIVATE_KEY In my case, it would look like this: FLOW_WALLET_ADMIN_ADDRESS=0x7cc7be2796e8cf29
FLOW_WALLET_ADMIN_PRIVATE_KEY=73bc408436c14befd74cb01fa4c54217c6c860ff97df1a77a3063a2807c7067f We’re ready! Our Testnet account has been created. This is the admin account that will execute, sign, and pay for the creation of new wallets for our application. Proposal key field Within an account, it is possible to have several proposal keys. As we will call several transactions with the same account to avoid concurrency problems, we will need to create new proposal keys for the admin account. You can read more about proposal keys . here We’ll change the configuration in to create 10 new proposal keys. For our tests, this is a sufficient amount. However, if you start having concurrency problems when executing transactions, you can change this value and restart the application. .env FLOW_WALLET_ADMIN_PROPOSAL_KEY_COUNT=10 Idempotency middleware field We’ll also add a property to the file to disable idempotency middleware. Since we are just testing the application (and using it to facilitate our post requests), we will leave it disabled by setting the following value to . However, it is recommended to activate it in a production environment. .env true FLOW_WALLET_DISABLE_IDEMPOTENCY_MIDDLEWARE=true Update the File docker-compose.yml Since we made some changes to our (including using the Testnet network and disabling idempotency middleware), We can remove a few lines of unnecessary code in the file. Our application will not be using the and containers. So, we can remove them. .env docker-compose.yml redis emulator After removing them, your file will look like this: docker-compose.yml version: "3.9"

networks:
  private:

services:
  db:
    image: postgres:13-alpine
    environment:
      POSTGRES_DB: wallet
      POSTGRES_USER: wallet
      POSTGRES_PASSWORD: wallet
    networks:
      - private
    ports:
      - "5432:5432"
    healthcheck:
      test:
        [
          "CMD-SHELL",
          "pg_isready --username=${POSTGRES_USER:-wallet} --dbname=${POSTGRES_DB:-wallet}",
        ]
      interval: 10s
      timeout: 5s
      retries: 10

  api:
    build:
      context: .
      dockerfile: ./docker/wallet/Dockerfile
      target: dist
      network: host # docker build sometimes has problems fetching from alpine's CDN
    networks:
      - private
    ports:
      - "3000:3000"
    env_file:
      - ./.env
    environment:
      FLOW_WALLET_DATABASE_DSN: postgresql://wallet:wallet@db:5432/wallet
      FLOW_WALLET_DATABASE_TYPE: psql
    depends_on:
      db:
        condition: service_healthy that we also removed some lines from the service: Note api and in the environment section. FLOW_WALLET_ACCESS_API_HOST FLOW_WALLET_CHAIN_ID Lines for and in the section redis emulator depends_on We spin up our containers with the following command: $ docker compose up Test the Flow Wallet API Application When we run the above command, Docker will spin up the following: : This is the database container where all data will be stored, including the users’ private keys. Remember that we are only running the application in a test environment, using the . If you use this API in production (Mainnet), protect the users’ private keys. One option is to use key management system services. The Flow Wallet API has easy and fast integration with Google KMS and AWS KMS. flow-wallet-api-db-1 PostgreSQL Flow Testnet network : This is an application in Golang that connects to the Flow network and performs actions such as creating wallets, transactions, scripts, and much more. flow-wallet-api-api-1 ! Our application runs through these two Docker containers, We can make calls using (the default) port . Done 3000 All endpoints available in the application can be found in the documentation . here Check the Application’s Health The endpoint to check if the application is healthy is ready. /v1/health/ We send a curl request to check this endpoint, and this is what we receive as a response: $ curl -X GET -i http://localhost:3000/v1/health/ready


HTTP/1.1 200 OK
Vary: Accept-Encoding
Date: Fri, 05 May 2023 17:27:05 GMT
Content-Length: 0 With the response, we are assured that our application is up and running. 200 Create a Wallet Creating a new wallet via the API is very easy! We send a POST request to the endpoint. /v1/accounts $ curl -X POST http://localhost:3000/v1/accounts

{
  "jobId":"2876f90d-d9ec-4007-935b-4aba3cb8e45e",
  "type":"account_create",
  "state":"INIT",
  "error":"",
  "errors":null,
  "result":"",
  "transactionId":"",
  "createdAt":"2023-05-05T17:29:34.800299551Z",
  "updatedAt":"2023-05-05T17:29:34.800299551Z"
} Under the hood, the API creates an asymmetric key pair and executes a transaction on the Flow blockchain to create an account. Jobs Since a transaction takes a few seconds and can fail, the API creates . jobs These jobs are records/units that are stored in the database. Each time a transaction is called or queued, a job is created. The status of the transaction is stored in this job. Notice how the transaction returned by our call above is . The API is monitoring the account creation transaction. state INIT Get Job Data and Account Addresses To get the updated state of this job, we can send a GET request to the endpoint. /v1/jobs/{JOB_ID} $ curl -X GET \
  http://localhost:3000/v1/jobs/2876f90d-d9ec-4007-935b-4aba3cb8e45e

{
  "jobId":"2876f90d-d9ec-4007-935b-4aba3cb8e45e",
  "type":"account_create",
  "state":"COMPLETE",
  "error":"",
  "errors":null,
  "result":"0xb23d449bc23d9d04",
  "transactionId":
    "ab68527578c323b68caf9d1b1533ebf4a3486f22b0d6f7df4339c57e48d9c4ca",
  "createdAt":"2023-05-05T17:29:34.800299Z",
  "updatedAt":"2023-05-05T17:29:47.507803Z"
} We see the result, with a newly created address. It is also possible to check all addresses created by the application using the endpoint. /v1/accounts $ curl -X GET http://localhost:3000/v1/accounts

[
  {
    "address":"0xb23d449bc23d9d04",
    "keys":null,
    "type":"custodial",
    "createdAt":"2023-05-05T17:29:47.504906Z",
    "updatedAt":"2023-05-05T17:29:47.504906Z"
  },
  {
    "address":"0x7cc7be2796e8cf29",
    "keys":null,
    "type":"custodial",
    "createdAt":"2023-05-05T17:25:51.847239Z",
    "updatedAt":"2023-05-05T17:25:51.847239Z"
  }
] With our wallet API working, we can start implementing the application that will send requests to the wallet API to create new accounts. We'll cover this in part two of our walkthrough. Also published here.

Walkthroughs, tutorials, guides, and tips. This story will teach you how to do something new or how to do something better.

2022 - HackerNoon Contributor of the Year - Engineering

2022 - HackerNoon Contributor of the Year - Heroku

2022 - HackerNoon Contributor of the Year - Jobs

2022 - HackerNoon Contributor of the Year - Kubernetes

2022 - HackerNoon Contributor of the Year - Npm

2022 - No No No Nodejs

Nominated for 2022 - HackerNoon Contributor of the Year - Heroku

Nominated for 2022 - No No No Nodejs

Nominated for 2022 - HackerNoon Contributor of the Year - Jobs

Nominated for 2022 - HackerNoon Contributor of the Year - Npm

Nominated for 2022 - HackerNoon Contributor of the Year - Kubernetes

Nominated for 2022 - HackerNoon Contributor of the Year - Engineering

Too Long; Didn't Read

The Path to a Seamless Web3: Account Abstraction from Flow (Part 1)

The Path to a Seamless Web3: Account Abstraction from Flow (Part 1)

Too Long; Didn't Read

@alvinslee

Credibility

RELATED STORIES