Recently we launched bb3.xyz (BBC’s web3 universe) and airdropped early users an explorer badge. One of the problems that immediately arose was ensuring we reward legitimate early supporters instead of bad actors with fake accounts. There are several ways we can do this using current web3 authentication practices, notably Collab Land or discord roles. You can give access to your community if people have certain tokens and or have people do cool puzzles/community art to gain allowlist roles on discord. Then you collect their wallet addresses for minting. However, our situation is a little different, in that our partners are in the physical goods space and need emails as a way to communicate product shipment details. Current web3 authentication practices don’t solve email collection or verification and so we built our in-house authentication system called auth3. auth3 is a combination of web2’s authentication practices with web3’s wallet connection. It allows us to verify users via email and wallet connection.

Before we start, let’s get a run down on current authentication practices in the web2 and web3 space. From left to right we move from a centralized to a decentralized approach. auth3 sits in the middle of this spectrum.

We built auth3 to help us spin up new projects quickly. These new projects often start with a landing page where users can provide their email address and connect their wallet. After a user provides their information, we must verify it and prevent bad actors from entering the system. We built a similar system for STAPLEVERSE and saw an opportunity to abstract that logic into a reusable service. Our partners are in the street-fashion/physical goods space and need a way to connect to their community through email. If we only had a wallet connection, then a couple of immediate problems would arise.

The first problem pertains to bad actors. Thousands of wallets can be generated programmatically using SDKs such as web3.js. The wallets can be easily funded with something like disperse.app, where you can fund thousands of wallets from one wallet that holds ETH. All of which can be done within a few minutes. If you’re planning to do an NFT drop without any authentication, then you can potentially be giving all of your mints or free airdrops to one person. auth3 allows for better sybil resistance through email spam checking services and verification, although not 100% resistant (yet).

This leads to our next problem, how do we communicate with our users if we only have wallet addresses? There is discord with verified roles. However, coordinating shipping information through discord is less than ideal and can become chaotic quickly. Imagine keeping track of thousands of dm’s and having to send each person shipping information. Email allows us to send product information securely and tailored to our users and works with current e-commerce sites like Shopify. On top of that, collectors coming into the web3 space from streetwear, may not be familiar with wallets and such, so having email gives us a way to help onboard the new collectors.

auth3 is a service our team can use to quickly spin up a new project and authenticate users that fit the needs of each of the projects. Instead of setting up new infrastructure to store user information, we just hit 2 API endpoints and we’re ready to go. We were able to cut down a project’s setup time by 99.11%.

auth3 relies on 4 core components: an express server that is our API, Postgres database, BullMQ, and a worker service. The API handles user and project-related CRUD features, verification requests, authorization, and potentially admin features in the near future. Our Postgres database saves user information like email, wallet address, roles, and verification requests. The queue handles email verification requests, and the worker is used to process queue messages.

Architecture-wise, we choose to use a multi-tenant app with one database for our MVP. Having a single database saves dev time, manages complexity, and saves on costs. We can always shard our database by the `project_id` if we ever run into scaling issues. Being that we’re still in the MVP stage, we do not require the client to send along an API key for authorization. This could potentially be problematic as our servers and database can be hit with thousands of requests that can bloat our system. However, in favor of speed and time, we opted to not require API keys on requests for now. If you’re looking to learn more about SaaS architecture, check out this article here.

So far so good with STAPLEVERSE and the bb3 launch. Of total account creation requests, we were able to deter about 33% of bad actors from entering our system. This number was generated from the number of spam rejected emails and emails that never got verified in our system. We also noticed some spam emails successfully getting through our email verification and so we added a spam checker to the API to reject those emails. Beyond email spam checkers, we will be exploring on-chain analytics as a way to query different wallet transactions that may come from bad actors.

The next steps entail creating an admin dashboard so that future devs working on another partner project can easily spin up a new project to receive the host API, project_id, and api_key.

We hope to also gather some on-chain analytics to help our partners discern their current community portfolio. Since we already have the user's wallet addresses, we can run a wallet analysis on the most recent activities and their NFT holdings. If the wallet is flagged within our system for not having any transactions(txs) or crypto, we can deploy an educational program via email or dig deeper into txs leading to the wallet creation.

Another thing that we can do is create a React Provider component that handles the client state and API calls for connecting users to auth3. It will all be abstracted from the developer, thus cutting down boilerplate code.

By combining web2’s best practices and web3’s wallet connection, auth3 has helped us reach our goal of spinning up a project quickly to fit our business needs by cutting down our project setup time. It has also successfully gated bad actors from entering our communities. Hopefully, this article was helpful for anyone looking to onboard a new project or perhaps learn about merging web2 authentication practices with web3 wallet connection. We hope to try this out on new projects and extend its features in the near future.

• Typescript

• Express

• BullMQ w/ Redis as the queue

• Postgres

• Postmark

• Rainbow Kit

• Railway: As powerful and flexible as AWS is, we choose to use Railway for this project, as it was a much better developer experience, along with auto-scaling