The recent surge in L1s and rollups has led to increased complexity in user experience, specifically in managing wallets, keys, and assets across all these ecosystems.

Key Management

While shared custody solutions, which divide the key between a user and the solution provider, have significantly enhanced onboarding they don’t fully solve the key management problem -

• Not Truly Seedless - the user is still required to keep track of key shares (recovery and/or a device share)

• Inflexible - it’s challenging to customize authentication/recovery policies and innovate on the signing experience (UX) because any key operation (signing, etc) always requires user input.

Fragmentation

The emergence of rollups, chains, and embedded wallets undeniably brings a new problem into focus - fragmentation of a user's accounts and assets.

• Wallet Management - Users need to set up new wallets for every chain and dapp they adopt (if it uses an embedded account).

• Asset Fragmentation - User assets are dispersed across dapps, rollups, appchains, and other ecosystems.

• Cold Start - Users must understand concepts such as gas tokens and bridging before they can even begin in a new ecosystem.

User Journey

Suppose you're a user exploring four different dapps on Base and Solana that support embedded wallets. Your current experience might include:

• Managing keys for four different accounts

• Funding all these accounts and transferring assets between them

• Figuring out how to bridge from one chain to another, or using a Centralized Exchange (CEX) for this purpose

• Ensuring each account has sufficient gas for transactions

These actions are just a few of the many potential tasks. The time and effort required to navigate these steps can significantly impact conversion rates for projects and builders.

With Passport Protocol, our aim is to simplify this process into three steps across any dapp and any chain: Create, Fund, and Transact.

A Dedicated Ecosystem For Users

Our goal at 0xPass after distributed key management will be to power chain abstraction with universal accounts.

These are gasless, seedless, and programmable accounts that can transact on any dapp across all chains.

We will achieve our goal through the following phases, executed in parallel when feasible.

Phase 1 - Key Management

Our focus in phase 1 is MPC-based and distributed key management.

Passport will provide seedless onboarding experiences, programmable keys and authenticate users in a trustless way through enclaves.

Distributed MPC Network

Unlike shared custody solutions that split the key shares between a user and a provider, Passport Protocol spreads key shares entirely among nodes in our network. Enclaves and our MPC protocol ensure key shares are shielded from node operators and that the private key is never reconstructed in whole.

Programmable Private Key

Since the entire key resides within the network, it’s also now fully programmable. Developers can programmatically customize auth, recovery rules as well as signing logic.

Trust-Minimized Authentication

User authentication today relies on centralized providers - either a developer’s own backend or a third party solution. But since the authenticator maps the end-user to a key, it’s crucial that this layer is not malicious.

Authentication within Passport, is trust-minimized. Since our authenticator nodes run enclaves, Passport’s network cannot interfere with or maliciously operate on incoming authentication requests.

Phase 2 - Universal Account

In Phase 2, Passport will feature a universal account, chain abstracted and secured by our MPC network. This account will be managed by an intent-driven solver network for handling cross-chain interactions.

Further enhanced by relayers and decentralized messaging protocols, the solver network will make the universal account gasless and capable of even auto-bridging assets.

Representing The Universal Account

The universal account, located within the MPC network, will store user credentials, authentication, recovery policies, and will consolidate child accounts. These child accounts are wallets that have the ability to sign transactions across different chains and ecosystems.

Private keys for these accounts, when linked with relevant web2 authentication methods, will be securely retained through our distributed MPC network developed in phase 1.

Intents - Powered by a Solver Network

Operations at the universal account layer, which include auto-bridging, gas sponsorships/abstraction, and auto swapping, are organized as intents which in turn are processed by our solver network.

When a user intends to perform a certain action, the solver network processes this intent and constructs a series of complete transaction requests. The solvers interact with our MPC network, obtain signatures for the transactions from the correct account, and forward them to the appropriate chains for settlement.

Relayers and decentralized cross-chain messaging protocols, also run within the solver network, will provide users with a gasless and bridgeless experience as they navigate through web3.

Phase 3 - Ecosystem Development

At its core, Passport Protocol is a network of nodes that can sign transactions and trustlessly run any off-chain compute.

During phase 3, our goal is to expand on these capabilities by opening up the network to developers who wish to create new use cases on Passport:

• Network Participation - Increase incentives for third parties to participate in our key management and solver networks.

• Passport Apps - Motivate developers to create a new category of applications for universal account holders. These Passport Apps include:

  • UX Plugins - These plugins enhance the user experience and function within the parameters of the global account. Examples include pre-built authentication and signing flows, privacy-preserving KYC plugins, zk-based login experiences, new gas sponsorship models, and more.

  • Agents - Programs and bots within the network that can act independently and operate securely on behalf of a user, within the boundaries set by them.

Build With Us!

Want to build on our distributed key management network? Make sure to sign up on our site for access and we will follow up immediately - https://0xpass.io/

Today we finally announced our $1.8M pre-seed round from earlier this year :)

Check out our announcement on Twitter here and show us some support!

We also got featured on TechCrunch, so if you’re curious about our iterations and how we got where we are, learn more here!

In a non-custodial manner, Passport lets devs customize authentication and key recovery rules and fully automate and program transactions.

Get access at https://passport.0xpass.io/

Now, let’s dive in!

Crypto has a user experience problem.

From authentication to transactions, the crypto landscape is encumbered with friction at every layer. Incremental improvements in onboarding and authentication won’t cut it for bringing in the next billion users, for that, we need to rethink the entire user experience.

Improving flexibility while ensuring user control calls for a fundamental redesign of our key management infrastructure, from there we can build a frictionless experience, requiring minimal human interruptions

Key Management Today

Self-Custody

While self-custody remains the gold standard to ensure complete ownership, it comes with onboarding-related challenges that limit web3 applications from expanding their audiences.

Custodial Solutions

Custodial solutions, on the other hand, grant that flexibility but require enormous amounts of trust to be placed on custodians.

MPC: The "Middle Ground" Solution

Traditional non-custodial, MPC-based solutions represent a "middle ground" partially solving the problem of key storage and recovery.

However, since they split key shares between end users and providers’ backends and networks, they come with limited flexibility around programming auth and recovery mechanisms and cannot reimagine the post-onboarding, transaction experience - requiring the user to always manually initiate transactions.

Programmable and Network-Managed MPC

We're excited to introduce our vision for Passport Protocol - a programmable, and MPC-based distributed key management network.

Passport Protocol separates itself from traditional MPC models by distributing key shares solely among network nodes. The core innovation lies in programmable, immutable rules for authentication and transaction governance, providing an entirely non-custodial infrastructure that makes use of MPC algorithms and secure enclaves.

Passport Protocol fundamentally rearchitects the entire onboarding process - making authentication and recovery rules, entirely customizable. In addition, it also fundamentally reimagines the post-authentication, transacting experience making it entirely programmable.

For the first time, developers can specify the rules around what, when, and how signing should take place and choose to even completely automate that process.

Highlights and Implications

Non-Custodial and Secure By Design

Using secure enclaves and MPC algorithms we ensure that no one - not the dapp, nor our wallet adapter 0xPass, nor the node operators, nor the infra providers we use - can see even one share of the private key.

Customizable Authentication and Social Logins

Developers now have full customizability over the rules that govern how to authenticate users. While this enables social logins, it goes even beyond that - enabling even the chaining of multiple authentication rules or custom auth logic depending on a developer’s use case.

Programmable Transactions

Unlike traditional key management protocols and services, developers can program multiple authentication and recovery methods and enable superior UX through automated and scheduled transactions. Transactions can even be pre-approved and governed by immutable off-chain programs that dictate when and how signing takes place!

Seamless Key Recovery

Since authentication and recovery methods can be programmed, users can recover their keys across devices without having to handle a user share, a code, or being tied to their device in any manner like it’s necessary with existing MPC solutions.

Programmable Interoperability

Through the notion of “scopes,” developers can choose to create wallets that are interoperable, ensuring end-users don’t have to onboard or top up assets into their wallets every single time they use a new app.

Protocol Architecture

How Keys are Created and Managed

Passport Networks divide the creation and storage of private keys across multiple nodes. Each node in the network generates a "share" of the private key, which is then stored in an encrypted database through secure enclaves. This distributed approach ensures that:

• Keys are never stored in one location, reducing single points of failure.

• No one, not even the node operator has the access to the key share in any process.

• The network offers strong fault tolerance and resilience.

By dividing private keys into multiple shares and scattering them across nodes, Passport achieves an extra layer of security, ensuring no single node can compromise the entire system.

Programmability Through Scopes

Passport Networks' architecture enables programmable key pairs, governed by authentication and verification rules defined by the scope owner. This feature empowers developers to:

• Enable user-controlled keys through OAuth.

• Offer custom recovery options.

• Establish a variety of authentication rules.

Utilizing network custody, wallets function under these immutable "rules," accessible only to the owner. This design not only grants unparalleled control and flexibility in wallet creation and key management but also ensures trustlessness by eliminating reliance on centralized elements like relayers.

Additionally, Passport's event handler orchestrates the cadence of transactions, enabling scheduled and automated operations as well as facilitating bot development.

Security and Performance

Passport Network employs peer-reviewed algorithms and audited implementations. Specifically, it uses DKLS23 for threshold signatures. This algorithm offers:

• High performance with the lowest latency possible in Multi-Party Computation Threshold Signature Schemes (MPC-TSS).

• Robustness by avoiding the computationally-intensive Paillier operations commonly found in traditional MPC solutions.

Metadata and Node Operation

In its early stage, Passport utilizes replicated internal databases in each node for managing metadata and states. This ensures improved performance and data integrity. Future iterations plan to increase decentralization by using external node operators and on-chain state managers. This will fortify the network's resilience and transparency.

How To Use Passport Protocol

For those that want a drop-in “Connect Wallet” component, social logins and embedded wallets powered by Passport Protocol will be made accessible through our wallet adapter 0xPass.

For those that want to use it alongside existing authentication solutions, we will be providing client side SDKs as well as APIs.

However, Passport Protocol is meant to be a trustless, public good. Over time, our team will focus on building an ecosystem allowing for other wallets, apps, and infra providers to easily build on the protocol.

A Future Beyond Key Management

While Passport Protocol today only handles key management, our ambitions go way beyond that.

Future versions of Passport Protocol will also look to allow developers to trustlessly authenticate, manage, and authorize users - thereby and in conjunction with key management, opening up not only web3 use cases but also traditional web2 ones.

A significant overarching trend that we anticipate will propel widespread adoption is the emergence of "contextual dapps" - these are contemporary web3 applications designed with a similar look and feel to web2 applications.

Contextual Applications:

Contextual dapps transcend specific sectors and exhibit the following characteristics:

1. They actively seek to expand their Total Addressable Market (TAM), catering to both crypto-native and non-crypto-native users.

2. Consequently, they prioritize optimizing their onboarding processes, aiming for the highest conversion rates by incorporating multiple login methods.

3. They emphasize maintaining user context. This involves authenticating user wallets through the Sign In With Ethereum feature, which establishes user sessions, thereby enabling secure data storage, including user profiles, referral systems, user preferences, and more.

Instances of contextual dapps abound across various domains, such as Opensea, Goldfinch, Zed Run, and others.

Traditional Dapps:

In contrast, more conventional applications like Curve or Uniswap primarily target crypto natives and rely predominantly on on-chain transactions. Consequently, they do not place as much emphasis on onboarding processes or user preferences.

Engineered to Cater to Contextual Apps:

Our goal at 0xPass is enabling contextual dapps by providing robust infrastructure and tools. Our platform facilitates the integration of "Sign In With Ethereum," ensuring secure authentication and session management.

By equipping dapps with the means to create a seamless and secure user experience, we contribute to the broader goal of onboarding the next wave of users into the blockchain ecosystem.

Here’s a high-level breakdown on how we build the gasless mint on Polygon. Hopefully this helps you build similar projects as well!

If you’d rather read this as a tweet, check out our post on “X” here :)

The Components

0xPass

For login method aggregation, authentication, and user management

0xPass handled the login flow that end-users were exposed to. We opened up multiple login methods (web3 and web2) and leveraged our KMS connectors to Magic to allow for web2 logins. At the end of the login flow, every user had an EOA tied to them (either one they brought themselves or one created through 0xPass).

If your dapp stores any user context, 0xPass also helps by authenticating wallets and providing a single user ID that all login methods point to, making user management a breeze.

Biconomy

For account abstraction infra - smart contract wallets, paymasters, and bundlers

We then built a connector to Biconomy’s smart contract wallet tying any created EOAs to smart wallets under the hood.

These smart wallets then leveraged Biconomy’s AA infra - the paymasters and bundlers - to allow for gas sponsorships.

At the end of this connection, every user now had a smart wallet which in turn was tied to an EOA that acted as its signer.

Decent

For NFT infrastructure - NFT smart contracts and one-click mint/checkouts powered by “The Box” SDK

Once the smart wallet was created, we leveraged Decent’s infrastructure to setup the NFT contract and build the checkout experience.

This meant that any mints now went into the user’s associated smart wallet directly and not their EOA.

Overview

Here’s an overview of all the components and the flow!

Build It Yourself!

Want to build a similar project yourself? We’ve open sourced the GitHub repo so you can get started when and how you want!

GitHub Repo

Community Sneak Peak

I can’t wait to share what we’ve been cooking up at 0xPass with all of you very very soon :D

For now, I’ll leave you with this meme -

0xPass’s commemorative gasless mint in collaboration with Decent and Biconomy is now live on Polygon!

Show us some love and check out the experience here.

I will also be following up with a technical deep dive into how we built this project.

Thanks!

Krish

Excited to share that we’ve partnered with Decent and Biconomy for a gasless NFT mint showcase on Polygon!

This project is now live here!

Subscribe now

Witness 0xPass’s login flow, Biconomy’s smart wallets and Decent’s NFT infrastructure in action!

More importantly however, we will be open sourcing the code so you can get easily started with similar projects on your own

Ever wonder how smart wallets, MPC, auth, etc., work together to enhance dapp UX?

In this post, we'll explore their interactions and a stack that seamlessly integrates (0xPass, ZeroDev, and Alchemy).

Also, check out all of the new features we’ve launched with 0xPass here!

Account Abstraction - An Introduction

The Era of EOAs

Externally Owned Accounts (EOAs), such as Metamask and Ledger, have played a pivotal role in driving the growth of dapps. However, as we enter the next phase of web3 and aim to onboard the next billion users, it is becoming increasingly clear that EOAs, in their current state, have inherent limitations that may hinder mass adoption. Let's explore a few challenges for which we need better solutions:

Reliance on private keys:

If a user loses their private key, they lose access to their funds. This is especially problematic considering that mainstream users may not be as crypto-savvy. Therefore, we need a way to minimize dependence on a single key while still adhering to the principles of decentralization.

User-friendly transaction experiences:

To truly abstract away the blockchain, end-users should not have to know which blockchains they are transacting on or what native tokens they need. The existing clunky transaction approval processes need to be automated and streamlined while ensuring high levels of security.

Smart Wallets and Account Abstraction

By utilizing programmable smart contract wallets, the account abstraction standard ERC-4337 offers more frictionless user experiences. Programmable wallets provide features such as:

• Account Recovery: Smart wallets can be made recoverable through multiple signers, reducing dependence on a single private key.

• Gas Sponsorships: The cold start problem of users not having a chain’s native token can be solved by allowing developers or dapps to sponsor gas.

• Session Keys: Transactions can be securely automated, enabling a "blockchain-abstracted" in-app experience.

The Developer's UX Stack - Part 1

Let's walk through the components and tools (0xPass, Alchemy, and ZeroDev) that work together to bring frictionless user experiences.

Step 1 - Choose a Smart Wallet

Select a smart wallet implementation that suits your use case. Some available implementations in the space include Safe, Kernel, Soul Wallet, Biconomy, and more. 0xPass's first smart wallet connection is built for ZeroDev's Kernel, which you can read more about here.

ERC-6900: The case of interoperability

Multiple smart wallet implementations such as Kernel allow for a plugin system that allows third-party developers to enhance the contract’s features. EIP-6900 by Alchemy accounts for this by providing a common interface between smart contract accounts and plugins allowing for interoperability. Kernel and Biconomy are moving towards compatibility with Soul Wallet exploring a similar direction as well.

Step 2 - Smart Wallets and Signers

Smart contract wallets are controlled by signers, which can cryptographically sign messages and transactions.

As shown below, different signing schemes and key management methods can be paired together to control smart wallets.

For simplicity, we can also have traditional EOAs control these smart wallets.

So, once you have chosen a smart wallet implementation for your users, you will need to connect it to a signer (in this example, an EOA) that can control it.

So for instance, let's consider a scenario where a new user has a Metamask wallet connected to a smart wallet. Whenever they attempt to make a transaction with the smart wallet, their Metamask account will prompt them for a signature.

Tools -

To address this, wallet adapters like RainbowKit or ConnectKit can be used to aggregate EOAs (Externally Owned Accounts). However, this approach only caters to users who already have a wallet!

Step 3 - Enabling Social Logins

It is likely that you also want to onboard users who do not already possess an EOA. This necessitates finding a way to convert social accounts into signers.

Tools -

Key management service providers such as Magic, Web3Auth, or other "Wallet-as-a-Service" providers can be of assistance in this regard.

Furthermore, depending on your implementation, you may need to merge wallet-based and social logins into a unified sign-in process.

Step 4 - Authentication and User Management

Modern dapps are becoming contextual. So if you’re creating any sort of user profiles, or building any contextual user experiences, you will need to authenticate the user using the “Sign In With Ethereum” standard and manage user profiles and sessions on your backend.

Tools -

To make this happen, you can leverage tools such as Next-Auth, Firebase, Clerky or others.

Simplify the Login Experience with 0xPass

Instead of paying for or gluing together 3+ tools to build your own wallet and login management system, you can use just 0xPass to simplify your wallet management and authentication infrastructure.

0xPass offers an advanced wallet adapter that enhances your "Connect Wallet" or login flow for your dapp.

0xPass serves almost as an upgraded version of RainbowKit, providing several benefits for your dapp:

• Aggregate both web2 and web3 login methods

• Seamless integration with embedded wallets or Key Management Service (KMS) providers

• Management of user authentication and sessions.

For more information about 0xPass, you can refer to our documentation and explore the demo.

Connecting to the Kernel Smart Wallet (Made by ZeroDev)

With 0xPass's connector, you can establish the connection between the signers and ZeroDev's Kernel smart wallet using just a single line of code as shown here.

Alternatively, you can also use ZeroDev’s SDK to establish the same connection.

To learn more about ZeroDev and their offerings, you can explore their documentation here.

Kernel Connector Deep Dive: Alchemy AA SDK

The Kernel Connector provided by 0xPass is integrated into our "Account SDK," which in turn is built on top of Alchemy's open-source AA SDK. You can find the AA SDK on Alchemy's GitHub repository here.

0xPass's Account SDK provides two wrapper methods: 'smartConnector' and 'smartWallet.' These methods are compatible with any existing WAGMI connectors (including 0xPass’s wallet connectors).

They create a proxy that enhances the internal WAGMI connectors with smart wallet features, while preserving their core functionality.

This means that as a developer, you can seamlessly integrate these smart wallet connectors into your workflow without any changes.

To learn more about the smart wallet connectors, you can refer to our documentation here.

Why Alchemy's AA SDK?

We prioritized finding a highly composable system with the potential for future integrations of multiple paymasters and bundlers. Alchemy's AA SDK met these criteria, making it the ideal choice for our development. With its open-source nature, the Alchemy AA SDK encourages community contributions, ensuring constant evolution and improvement.

Why Kernel?

At 0xPass, we believe in building systems that evolve and improve over time. We chose to build a connector to ZeroDev's smart wallet, Kernel, because it aligns with this philosophy. Kernel supports plug-ins, empowering developers to personalize and expand their smart wallets according to their specific requirements.

The Developer's UX Stack - Part 2

While we have covered authentication and smart wallet systems, there is one final piece to the UX puzzle: bundler and paymaster infrastructure.

Smart contract accounts themselves cannot directly initiate transactions on chains that don’t have native account abstraction support. Instead, they send an object called a "user operation."

These user operations are monitored and packaged by bundlers, which have their own EOAs (Externally Owned Accounts), into a transaction that can be sent to the blockchain. Bundlers initiate and send these transactions, paying for the gas. They are later compensated either by the sender or a paymaster, which is a contract that allows for gas-sponsored transactions.

Companies like Alchemy, Stackup, Pimlico, and others serve as bundlers and paymasters for developers.

In the context of Account Abstraction, Alchemy provides crucial infrastructure components, including Bundlers and Paymasters, along with a readily deployable SDK. These tools greatly simplify the implementation process, enabling developers to quickly access account abstraction features.

By leveraging the combined strengths of 0xPass, ZeroDev, and Alchemy, the entire UX stack can be simplified, significantly easing the lives of developers.

As a result, alternative authentication methods with a seamless user flow are the need of the hour. Sign-in with Ethereum (SIWE) is one such innovative solution that harnesses the Ethereum blockchain to offer superior user onboarding and secure authentication. 

Subscribe now

Introducing Sign-in With Ethereum (SIWE)

Sign-in With Ethereum (SIWE) is an authorized authentication convention allowing developers to authenticate securely with off-chain services. It enhances seamless compatibility among off-chain services based on Ethereum and improves user experience. Additionally, it offers wallet vendors a cohesive message format to streamline authentication management. 

How does SIWE Work?

SIWE leverages the features of the ERC-191 signed data format. This enables users to sign a standard message format using their Ethereum wallets. Here is a breakdown of the process: 

When a user intends to authenticate with a service, it creates a message that includes relevant information, such as the user's account details, the specific service being accessed, and the authentication scope. This message is then forwarded to the user’s Ethereum wallet, which triggers a prompt requesting them to sign the message using their private key. 

The signature is generated utilizing the ERC-191 signed data format. ERC-191 is popular among Ethereum blockchain users for its robust approach to data signing. Once signed in by the user, the wallet returns the now-signed message to the service for validation. The service grants access to the requested resources or services upon successful validation.

Parameters of SIWE Message Format

The SIWE message format embraces various parameters to ensure secure and flexible authentication. 

• Scope: The scope element defines the permissions that the off-chain service has to access the user's data. This means that the service can only access the data that the user has authorized it to access.

• Session Details: Session details contain information such as a nonce, which is a randomly generated number, to prevent replay attacks. Services leverage nonce to identify and prevent unauthorized reusing of previously signed messages.

• Security Mechanisms:  The security mechanisms parameter includes nonces, signatures, encryption, and other mechanisms that ensure the confidentiality of the entire process. 

How is the Flow and User Experience with SIWE?

One of the primary reasons SIWE is gaining popularity is its seamless user experience without compromising security. The flow of the SIWE authentication process is straightforward. Check the step-by-step breakdown of the flow below.  

• Step 1: Create an Ethereum account. You will need to sign up with Ethereum by creating a digital wallet that gives you a unique address and a set of cryptographic keys (private key). 

• Step 2: Application Integration: Following step 1, you must integrate the application you want with the Ethereum blockchain. This is possible through various techniques, including Ethereum Name Service (ENS). ENS assigns human-readable names to Ethereum addresses, simplifying the identification and connection of users' Ethereum accounts.

• Step 3: User Authentication: When signing in with Ethereum on a cohesive service, it generates and sends a request to your Ethereum wallet for authentication. The application triggers a unique request message containing elements such as Nonce.

• Step 4: Wallet Interaction: Your Ethereum wallet prompts you to verify and approve this action. The application validates the signature once you verify using the private key. You are now granted access to the service. 

Security Considerations

As with any digital tool or platform, ensuring the security of your SIWE authentication is integral. We have put together several security considerations that you can consider to guarantee a secure journey for your users. 

• Identifier Reuse: Refrain from using the same identifier across all services to hinder identity theft and unauthorized access. 

• Key Management: You must store private keys securely at a location not accessible to other parties. 

• Wallet and Relying on Party Combined Security: Security measures such as user identity data protections should be strictly implemented and adhered to by both the user and the off-chain service. Robust encryption and secure communication channels are a few ways to meet this requirement. 

• Minimizing Wallet and Server Interaction: It is highly recommended to limit the exchange of information between the user’s wallet and the server to prevent any possible data exposure. 

• Preventing Replay Attacks: Techniques such as Nonces can efficiently protect user data from replay attacks. 

• Verification of Domain Binding: It is paramount that the relying part ensures that the message originated from an authentic domain to ensure the credibility of the service request. 

• Channel Security: Secure the communication channel using encryption, such as HTTPS, to protect against data tampering.

• Session Invalidation: Implementing session invalidation after a certain period helps mitigate the risk of unauthorized access to user identity data.

• Maximum Lengths for ABNF Terms: Setting maximum lengths for Abstract Syntax Notation One (ABNF) terms helps prevent potential denial-of-service attacks.

Takeaway

SIWE has been rapidly gaining recognition in the Ethereum ecosystem. It offers a promising potential to become a standardized authentication method. Without a shadow of a doubt, it is a robust and reliable solution for developers that prioritize self-custodial identity and seek secure authentication. By employing ERC-191 signed data format, SIWE improves compatibility, user control, and authentication management. SIWE offers developers a seamless journey to creating their dApp without worrying about user flow & complex steps. 

With the emergence of SIWE, there’s also the emergence of more powerful solutions, such as 0xPass built on top of SIWE. 0xPass is a featured packed & harnesses the benefits and reliability of SIWE to ensure that you, as a developer, can streamline your focus on creating your next dApp while ditching all your worries regarding security and authentication. 

Experience the revolutionary features like building user profiles, user management & account abstraction with 0xPass's reliable authentication solution today. Get started here

We’re excited to finally unveil 0xPass, an advanced wallet adapter to help you build the highest converting “Connect Wallet” flow in the least amount of time.

Support On Twitter

Web3 developers are constantly striving to create frictionless user experiences that cater to both crypto-native enthusiasts and mainstream users. However, the process of connecting wallets, managing different wallet types, and adhering to authentication standards can be time-consuming and divert attention from core development tasks.

While there are already great solutions available, such as RainbowKit and ConnectKit, they only address one aspect of the problem: providing UI components to help users connect their existing wallets.

0xPass offers a comprehensive solution for simplifying and enhancing web3 user authentication processes. By seamlessly integrating web2 and web3 login methods, connecting with preferred KMS providers, and delegating user authentication and management to 0xPass, developers can focus on building exceptional decentralized applications.

Let’s dive in -

1. Mixing Web3/Web2 Login Methods: One of the primary benefits of 0xPass is the seamless integration of both web2 and web3 login methods. By utilizing the prebuilt web3 wallet and web2 sign-in connectors provided by 0xPass, developers can empower users to choose their preferred authentication method. This flexibility enhances user experience and accommodates a wide range of preferences and comfort levels.

2. Choosing Preferred Embedded Wallet Providers: To cater to the needs of crypto newcomers, 0xPass offers effortless integration with user-friendly embedded wallets. By connecting with top-tier embedded providers like Magic, Web3Auth (soon), AWS KMS (soon), and others, developers can effortlessly onboard crypto newcomers without delving too deep into any integration work. This integration ensures a secure and user-friendly authentication experience, while also expanding the available options for wallet selection.

3. Simplified User Authentication and Management: With 0xPass, the burden of user authentication and management is significantly reduced. With a unified identity for users across multiple wallets and social accounts, developers can rely on 0xPass to handle intricate authentication processes, freeing up valuable development time and resources to focus on core product features.

4. Building User Profiles from Verifiable Social Accounts: By prompting users to connect their social accounts (such as Google or Twitter), 0xPass enables the creation of comprehensive user profiles. This functionality leverages verified information from social platforms, empowering developers to offer personalized experiences and tailored interactions within their web3 applications. Furthermore, this streamlined onboarding process enhances user engagement and establishes a stronger connection with the user base.

5. Account Abstraction through Smart Wallet Integrations: With its built-in connectors to smart wallets like Kernel, 0xPass takes user experience to the next level by enabling account abstraction capabilities.

Partnership Success Stories: Curious about real-world applications and the effectiveness of 0xPass? Here’s a case study on how we helped an upcoming consumer dapp streamline their authentication workflows, improve user experiences, and accelerate development cycles.

As web3 developers ourselves, our goal is to provide seamless user experiences while maintaining a high level of technical sophistication. Join the 0xPass community and unlock the true potential of seamless user authentication in your web3 projects.

Check out 0xPass here.

As you may know, we’ve been thinking about authentication and identities for a long time now.

In a world that's rapidly embracing the user-owned web ecosystem, it's crucial for us to rethink and reinvent the methods we employ for user authentication and authorization.

The Challenge

Now, let's say you're working on the next big dApp, and you're considering how to authenticate your users. You understand the importance of security, but you also don't want to alienate non-tech-savvy users. You're looking for something that has the cryptographic security of the blockchain but is as accessible as logging in via Facebook or Google.

An innovative blend of decentralized identifiers (DIDs), verifiable credentials, OAuth integrations with social platforms and threshold signatures can help tackle this challenge.

Let’s breakdown each of these first.

Building User Identities with Decentralized Identifiers & Verifiable Credentials

Envision a future where the user has the power and control over their identity - the credentials they possess are not just entries in a database but a part of a cryptographically secure, decentralized network that can communicate across platforms.

Breaking Down DIDs

Think of DIDs as sleek, modern alternatives to traditional passports. They’re identifiers that are created, owned, and controlled by users. Unlike traditional identifiers, such as usernames, a DID doesn’t require a centralized registry, authority, or intermediary.

For a developer, this means that you can verify the user's identity based on cryptographic proofs, such as digital signatures, which are inherently secure and don't require you to trust a third party.

The Role of Verifiable Credentials

Now, having a DID is great, but how do you, as a developer, allow users to prove certain attributes or claims about themselves? Enter Verifiable Credentials.

Going back to the passport analogy, think of Verifiable Credentials like the stamps or visas in your passport. They're a standardized way to represent information about a DID. For instance, a a as simple as their email address or ownership of a web2 social account can be represented as a Verifiable Credential.

Bridging the Gap with Centralized Protocols

OAuth and Social Identity Providers

In the web2 domain, using OAuth via third-party authentication providers is the norm. OAuth powers services such as "Sign in with Google" or "Log in with Facebook." It revolutionizes user convenience by allowing third-party apps to access users’ information on other platforms without password sharing, but it still relies on centralized identity providers like Google or Facebook.

Integrating DIDs with OAuth for Authentication

Combining the self-sovereignty of DIDs with the convenience of OAuth can yield a harmonized authentication mechanism. Here’s how it can work:

1. A user authenticates through a social identity provider (e.g., Google) using OAuth.

2. The application receives an OAuth token.

3. The application requests the user’s DID and associated Verifiable Credentials.

4. The user’s agent or wallet provides the requested information (DID and VCs).

5. The application verifies the DID and Verifiable Credentials independently of the social identity provider.

What we have now is a hybrid model where a user can leverage the ease of social logins and also provide verifiable credentials through DIDs. This is particularly useful in scenarios where a user might want to utilize a service with both their social identity and decentralized credentials.

Also - adding one more step to create an embedded wallets through threshold signature schemes (TSS) allows you to create wallets authenticated by your DID.

Advantages of Combining Decentralized and Centralized Approaches

This integration has several advantages:

• User Experience: Users can continue to use familiar authentication methods while also taking advantage of the benefits of decentralized identity systems.

• Data Minimization: By using Verifiable Credentials, users can choose to share only the information that is absolutely necessary.

• Enhanced Security: DIDs add an additional layer of security, as they do not rely on centralized repositories of user information that are vulnerable to breaches.

• Greater Control and Privacy: Users have greater control over their identity and data, as they can provide verifiable claims without the involvement of a central authority.

This hybrid approach is powerful, as it seeks to provide the best of both worlds, addressing the limitations of centralized systems while leveraging the innovations in decentralized identity management.

The Potential Unleashed

Streamlined Identity Management

The integration of DIDs and Verifiable Credentials with OAuth paves the way for streamlined identity management. Users can have a single, self-sovereign identity that can be used across platforms, thus reducing the need for managing multiple accounts.

Enhanced Security and Privacy

Since DIDs leverage blockchain infra, they are secure from the common vulnerabilities that centralized databases face. Additionally, with Verifiable Credentials, users have fine-grained control over the information they share. This means not only more privacy but also less liability for the businesses, as they don’t have to store sensitive data.

Seamless User Experience

Users can use familiar authentication mechanisms such as "Sign in with Google," and still leverage the security and privacy of DIDs and Verifiable Credentials. This duality brings the best of both worlds to the user’s fingertips.

Secure Embedded Wallets

With existing embedded wallet solutions, it is impossible to recover a wallet if the central auth provider is compromised. However with DID, the control is in your hands. Paired with Threshold Signature Schemes (TSS), a user can spawn a new wallet upon a successful authentication through DID.

Programmable Access Control

One of the most powerful aspects of using DID is the ability to have programmable access control. This means that smart contracts can be employed to define complex permissions and access structures, which could dynamically evolve based on context. For instance, a user’s profile might have different access permissions in a professional setting compared to a social setting.

Scalability and Interoperability

DIDs and Verifiable Credentials are standardized, and hence, promote integration across different platforms and services. This level of interoperability is key to creating a more open and connected web.

The Road Ahead

The integration of Web3 authentication with social identities is an exciting development in the realm of digital identities. As technologies continue to evolve, we are moving towards a more secure, private, and user-centric web. The journey, however, is just beginning. It will require collaboration, innovation, and an unwavering commitment to prioritizing user empowerment.

So, let's dive in and explore what RainbowKit has to offer.

What is RainbowKit? RainbowKit is a frontend React library designed to simplify wallet connectivity in your dApps. It assists developers in adding a "Connect Wallet" button to their dApps and seamlessly integrating new wallets into their flow.

Key Features:

1. Wallet Management: RainbowKit enables connection and disconnection with multiple wallets. It can fetch the user's name from ENS, display the balance, and even provide the option to add an avatar.

2. Customization: The "Connect Wallet" button built using RainbowKit offers high levels of customization. Developers can choose from a variety of predefined accent colors and border-radius options. You can align it perfectly with your dApp's branding using custom themes. Additionally, you can select optional features such as displaying balance, avatar, or ENS name.

Why use Rainbowkit?

RainbowKit is commonly used by devs who prioritize fast development and is ideal for small-scale projects or teams that aim to support multiple wallets right out of the box.

Here are some advantages of using RainbowKit:

1. Easy Integration: RainbowKit seamlessly integrates into your dApp, making it super easy to get started.

2. Improved Onboarding: By offering multiple wallet options, RainbowKit facilitates the onboarding of users from diverse crypto backgrounds.

3. Time Savings: By using RainbowKit, development teams can save valuable hours that would otherwise be spent building their own wallet connection modules and managing the ever-changing needs of different wallets.

Now, let's examine the limitations of RainbowKit to help you make an informed decision as a developer.

Limitations of RainbowKit

While RainbowKit is a popular library with a significant market share and is used by many top companies, it may not be suitable for dApps aiming to scale to non-crypto native users. Here are some reasons that may weaken the case for RainbowKit:

1. Great Alternatives: RainbowKit has legacy alternatives like Wallet Connect and Metamask, as well as feature-rich alternatives like 0xPass.

2. Wallet Compatibility: RainbowKit is compatible with only a few wallets, which may require additional wallet connectors to cover a wider range and reduce user bounce rates.

3. Limited User Options: RainbowKit primarily caters to crypto-native users and does not provide all possible login options. An ideal dApp should serve users with or without wallets, offering a range of experiences including social login + embedded wallets, social login only, and traditional connect wallet options.

4. Social Profile Connection: RainbowKit lacks the ability to connect users' social profiles, which is crucial for consumer web3 dApps that aim to construct comprehensive user profiles. 0xPass's user profile feature comes in handy for such consumer web3 dApps, but it is not available in RainbowKit.

5. Weak User Management: RainbowKit does not include user management functionalities, making it challenging to handle complex flows such as sign-in with Ethereum and session management.

6. Frontend Library Only: RainbowKit is solely a frontend library and offers limited ways to efficiently connect with the backend.

7. Lack of Account Abstraction Support: RainbowKit does not natively support advanced wallet features like account abstraction or embedded smart wallets.

Considering these points, choosing RainbowKit as your preferred wallet connector may present challenges. However, at 0xPass, we are building on top of RainbowKit and Wagmi to address these limitations while retaining its best features.

With 0xPass, you can connect to various wallets while enjoying powerful customization options and robust user management features. Additionally, we are working on enabling account abstraction and smart contract wallets in the near future.

For more information, feel free to check us out here.

We've been working on 0xPass with our early customers! We're also gearing up for a public launch in July across our social media channels.

Today, we're excited to highlight our partnership with Strikers. Strikers is revolutionizing the MLS prediction game by harnessing the power of NFTs, with 0xPass as their go-to authentication system.

🔗 Explore Strikers: Strikers.xyz

Check out our Twitter Spaces with the team here.

TL;DR: By integrating with 0xPass, Strikers can accommodate users with and without wallets, build user profiles with verified sources, streamline user management and authentication. They also look forward to future enhancements for a seamless web3 experience.

The 0xPass Impact: Boosting Conversions and Unlocking Savings

The integration of 0xPass is yielding positive results for Strikers, driving -

• Increased conversion rates for end-users

• Zero development hours required

• $60k in annual savings in developer hours and time

increased conversion rates and delivering an estimated annual savings of $30k in developer effort and time.

🔗 Explore 0xPass: 0xPass.io

Embracing users of all crypto backgrounds

Strikers aimed to cater to both seasoned crypto enthusiasts and newcomers. To achieve this, they needed to offer multiple login options, including traditional wallets (Metamask, Coinbase, etc.) and social login providers (Google, Twitter, etc.).

Initially, they experimented with Magic Connect but quickly realized it only served users without wallets.

By integrating with 0xPass, Strikers gained the ability to connect with traditional wallets and embedded wallet providers like Magic through their API key.

As a result, Strikers chose 0xPass for their "Connect Wallet" or login flow, enabling them to seamlessly mix and match various login options (both traditional and social) while leveraging the convenience of Magic's API keys.

Discover how we support multiple wallet connection/login methods in our docs here.

Building user profiles with verified sources

After successfully connecting wallets, Strikers sought to create comprehensive user profiles to:

1. Establish the authenticity of wallet owners/users.

2. Foster seamless communication with their user base.

3. Deliver personalized and context-driven user experiences.

Thanks to 0xPass's identity linking feature and social account connectors, Strikers effortlessly sourced information from platforms like Google and Twitter, allowing them to bootstrap user profiles.

Learn more about our social account integrations here.

Streamlined User Management and Authentication

User authentication and wallet ownership verification are essential prerequisites for tailoring user experiences and building user profiles.

Originally using next-auth, Strikers made the transition to 0xPass's authentication and user management system. They were thrilled to discover that 0xPass offered a unified user ID that spanned across wallet addresses and social accounts.

This seamless integration ensured consistency in user sessions while significantly reducing operational overheads and development efforts and time.

Account Abstraction and Enhanced User Experience

With 0xPass's upcoming support for account abstraction, embedded smart wallets, and UX features like on and off-ramps, Strikers found a reliable infrastructure partner that they can rely on to enhance consumer experiences.

If you're a web3 developer looking to create rich, contextual user experiences with support for account abstraction, you'll need to be familiar with the following authentication and signature validation standards:

• ERC-4361: Sign In With Ethereum

• ERC-1271: Standard Signature Validation Method for Contracts

• ERC-6492: Signature Validation for Predeploy Contracts

In this post, we'll delve into each of these standards.

If you find this content helpful, please consider sharing it with others and checking out our product, 0xPass.

We're also hiring a Founding Engineer [JD here] and possibly a Head of Growth too! Please let me know if you or someone you know would be interested :)

Share 0xPass’s Substack

Wallet Connection vs Authentication

Connecting your wallet to a dapp lets it identify which account you're using without retaining any information about your identity. This used to be sufficient since dapps required users to sign every on-chain transaction.

However, with the evolution of dapps, there's a need to store user preferences and information to provide more contextual user experiences, which requires wallet authentication.

ERC-4361 → Sign In With Ethereum

Sign-In with Ethereum offers a solution for dapps to authenticate and create user sessions for wallets in a self-custodial manner.

By adopting this standard, dapps can improve the user experience while ensuring that the user remains in full control of their data.

The flow is simple: the user connects their wallet, then they're prompted to sign a message that proves they truly own the wallet they're claiming to hold, which in turn creates a user session.

However, there's a catch - SIWE works with EOAs but not with smart wallets which account abstraction relies on. This is where ERC-1271 comes into the picture.

ERC-1271 → Standard Signature Validation Method for Contracts

We went over this standard in an earlier post as well, which you can find here.

Smart wallets can have arbitrary signature validation logic. Thus, ERC-1271 requires the verifier or the dapp to call a function called isSignatureValid on the smart wallet for validation purposes.

Quoting ERC-1271 -

isValidSignature can call arbitrary methods to validate a given signature, which could be context dependent (e.g. time based or state based), EOA dependent (e.g. signers authorization level within smart wallet), signature scheme Dependent (e.g. ECDSA, multisig, BLS), etc.

This function should be implemented by contracts which desire to sign messages (e.g. smart contract wallets, DAOs, multisignature wallets, etc.) Applications wanting to support contract signatures should call this method if the signer is a contract.

Awesome - problem solved! Or is it?

Smart wallets are counterfactual contracts, which means that contract deployment is deferred until the first user transaction for UX purposes.

So how will dapps authenticate users with an undeployed smart contract wallet? They can't access the isValidSignature function! This is where the latest proposal, ERC-6492 comes into play.

ERC-6492 → Signature Validation for Predeploy Contracts

At its core, ERC-6492 proposes a contract called the UniversalSigValidator, which validates smart wallet signatures.

There are two possibilities here -

• Signature ends with a sequence of magic bytes

  • If a signature ends with a sequence of magic bytes we know that the smart wallet is undeployed.

  • At this point, the verifier, or the dapp in this case, can later simulate a deployment of the smart wallet and then validate the signature.

• Magic bytes are undetected in signature

  • Proceed with ERC-1271

However, this ERC is still in review and in the process of being peer-reviewed.

Should dapps implement these standards?

Yes, they should. To bring all the account abstraction benefits to life, dapps need to implement all these standards. However, as a dapp developer, you can use open source libraries like Ambire’s Signature Validator.

How 0xPass handles these standards

Think of 0xPass as a wallet connector like RainbowKit but with built-in support for authentication, identity management, and account abstraction.

This allows us to hide all of the signature validation work from developers using our product, so they don't have to worry about implementing all these standards themselves! This is especially important as these standards evolve - as might be the case with ERC-6492.

Thank you for reading!

Feedback

If you’ve read this whole post, please give me some feedback! What do you like about these posts? How can we improve? Any other topics you want us to dive into?

References

1. Ethereum Improvement Proposal 6492. Retrieved from https://eips.ethereum.org/EIPS/eip-6492

2. Ethereum Improvement Proposal 1271. Retrieved from https://eips.ethereum.org/EIPS/eip-1271

3. Ethereum Improvement Proposal 6492. Retrieved from https://eips.ethereum.org/EIPS/eip-6492

4. ERC-6492 and Why it's Important for AA. Zero Dev. Retrieved from https://docs.zerodev.app/blog/erc-6492-and-why-its-important-for-aa

5. AmbireTech. Signature Validator. GitHub. Retrieved from https://github.com/AmbireTech/signature-validator

6. Sign in with Ethereum is a Game Changer (Part 1). Spruce. Retrieved from https://blog.spruceid.com/sign-in-with-ethereum-is-a-game-changer-part-1/

Confirming transactions on the blockchain can be a cumbersome process, requiring users to review and authorize each individual transaction.

However, what if there was a way to streamline this process while still ensuring security and control? That's where session keys, powered by Account Abstraction, come in.

If you like the content we’re bringing you, consider sharing this post with others and checking out our product 0xPass!

Share

TL;DR

If you want a shorter version, take a look at our threads on Twitter. We went over what session keys are, how they work, and why they can revolutionize UX in web3.

What are session keys?

Session keys are essentially pre-approved signatures that users can create based on specific policies and parameters. For example, a user could create a session key that is only valid for a certain function within a smart contract or for a specific time period.

Once the session key is created and authorized, a dapp can use it to sign transactions on behalf of the user without requiring their explicit confirmation for each transaction.

The key benefit of session keys is that they provide a seamless user experience, while still maintaining control and security. Permissions for session keys can be revoked at any time, which means users are always in control of their funds and can prevent unauthorized transactions from occurring. Additionally, since session keys can be set up to only allow certain types of transactions, users can have greater confidence that their assets won't be compromised by malicious actors.

Session keys offer a wide range of possibilities for use cases. For example, blockchain gaming platforms can use them to create a more fluid in-game experience, allowing players to make purchases and transactions without interrupting their gameplay. Similarly, DeFi dapps can use session keys to automate certain actions on behalf of their users, such as rebalancing portfolios or executing trades based on pre-defined parameters.

Several projects in the blockchain ecosystem have already adopted session keys, including Cartridge and Argent. The latter has pioneered "trusted sessions" on the consumer side, allowing end-users to take actions without their guardians' approvals.

How do session keys work?

It's a simple 3-part system: the user's smart wallet/account, the session request, and the dapp.

First, the dapp creates a "session request" that includes its own key, expiry timeline, and list of policies.

These policies contain a contract address and selectors, specifying the smart contracts and their accompanying functions that apply to the session key being created.

Once the session request is created, the dapp prompts the user to authorize and approve the request.

This leads to the creation of a session key that is valid for the specified time period and policies. This key can then be used to sign transactions in accordance with its policy rules, without requiring the user to approve every single transaction.

You can also dig into Argent’s implementation of session keys here.

I'm Krish, one of the co-founders of 0xPass. We hope you're doing well and appreciate your interest in our product or for being a user already!

We enjoy exploring authentication and UX standards and want to share this knowledge with you. It's also an excellent way to keep you informed about our product development.

In this issue, we'll discuss the EIP-1271 standard. You may have heard of the advantages of account abstraction and how it can benefit your dapps. However, to achieve these benefits, you may need to support EIP-1271.

So, what exactly is EIP-1271, and how does it work? Let's explore it together!

Authentication in Web3

Before we delve into EIP-1271, let's understand how dapps authenticate wallets. When you connect to Opensea with your wallet, you see a message like this -

DApps today can use the Sign In With Ethereum (ERC-4361) standard to authenticate EOAs like this. This method allows dapps to authenticate the wallet's owner securely, while also allowing off-chain interactions.

Essentially, this is the authentication mechanism that permits Opensea to store information about you, such as your preferences and social accounts (Twitter, etc.).

However, the ERC-4337 standard relies on smart contract wallets or smart accounts that can't solve this problem since they lack a private key.

How do we authenticate the owner of a smart account then? That's where EIP-1271 comes in.

Authenticating Smart Accounts

EIP-1271 proposes an interface for signature verification when a user's account is a smart account. The smart account has to implement an isValidSignature function.

Once implemented, dapps need to call this function when the owner of a smart account tries to connect their wallet.

If you're deploying a smart wallet for your dapp's users to support account abstraction, you must authenticate them this way.

EIP-1271's significance for account abstraction and UX has led to a movement to make dapps compatible with it. For more information, visit https://eip1271.io!

Native Support

At 0xPass, we're building an auth and login-focused solution that natively supports EIP-1271 and Sign In With Ethereum. So, you don't have to worry about supporting it yourself. If you're interested in checking us out, please join our Telegram group for support and play with the docs here.

Thank you for being part of our journey. We look forward to learning and growing with you!

Krish