Passkeys are a new way of logging in to online accounts, services, and apps that are designed to be faster, easier to use, and more secure than passwords. They are a replacement for passwords that are designed to provide websites and apps a passwordless sign-in experience that is both more convenient and more secure.

## The Backdrop of WebAuthn
The emergence of WebAuthn as a web standard for passwordless authentication has played a pivotal role in the evolution of passkeys. Through its framework, WebAuthn facilitates the generation and authentication of cryptographic key pairs, forming the backbone of the passkey technology. This development is instrumental in advancing secure, passwordless authentication, thereby contributing to a safer and more intuitive user experience in the burgeoning web3 domain.

## Secure Enclave: Apple's Fortification
A notable mention in the security enhancement of passkeys is Apple’s Secure Enclave technology. Embedded as a dedicated microchip in Apple devices, Secure Enclave provides an isolated environment for secure data operations, including transaction signing and biometric authentication processes like Touch ID and Face ID. This robust security feature significantly elevates the security posture of passkeys, ensuring a secure generation, storage, and handling of cryptographic key pairs.

### Passkey Storage Challenges
Despite the advancements, challenges persist, particularly around the storage of passkeys. Traditional keychain storage, for instance, lacks hardware-level security and heavily relies on iCloud for passkey recoverability, presenting potential security risks.

## Device and Software Discrepancies
The effectiveness and security of passkeys can vary across different devices and software platforms. While Apple’s Secure Enclave provides a robust security framework for passkey management, not all platforms have an equivalent hardware-based security feature. For instance, Android devices and Windows platforms may employ different security architectures, which might affect the security level and user experience of passkey-based authentication systems. 

Moreover, software implementations and the integration of WebAuthn could also dictate the overall security posture and usability of passkeys across various platforms. Understanding these discrepancies is crucial for developers and platforms aiming to implement passkey technology and account abstraction effectively.

## Wallets with Passkey
In the context of wallets, passkeys can be used as the signers/owners for your wallets. This enables a powerful experience where users get to create self-custody wallets using biometrics, without having to remember any seed phrases. 

After authenticating via email or social, users are prompted to create a passkey with their device (e.g., biometrics). This grants them a wallet and enables transaction signing with that passkey. 

Passkeys work on straightforward identity verifications, like fingerprint scans, facial recognition, PIN, or swipe patterns. They leverage a familiar pattern of using a biometric (FaceID, or TouchID) to securely create and store a credential to the user’s device.

Here's are simple demos of passkey wallet with [Lit Protocol](https://www.openfort.xyz/integrations/lit-protocol) and [Turnkey](https://www.openfort.xyz/integrations/turnkey).

## Passkeys Signature Validation
Passkeys can be implemented both on-chain and off-chain, depending on the context in which they are used. Here are some examples of how passkeys can be implemented on-chain and off-chain:

### AA wallets to verify passkey signatures on-chain
- **How it Works:** The AA wallets are programmed to verify passkey signatures directly on the blockchain.
- **Pros:** Direct user transaction signing using passkeys without any intermediaries, ensuring a higher degree of decentralization.
- **Cons:** The most efficient on-chain passkey verification currently known demands around 300k gas per transaction. This is quite steep in terms of costs for most applications. A potential solution could involve an upgrade to the EVM, perhaps with a mechanism similar to EIP-7212.

### AA wallets to verify passkey with a Signing Service
- **How it Works:** Rather than directly signing with passkeys, users authenticate with a signing service which then produces ECDSA signatures. Depending on each architecture some leverage secure enclaves, decentralize networks and other approaches.
- **Pros:** It ensures compatibility with existing wallet infrastructure. More gas efficient due to the indirect nature of the signing. Users always have the flexibility to switch signers, making it adaptable.
- **Cons:** It might rewuerid a centralize service like iCloud or Drive.

Passkeys are becoming an ever increasing option for users to sign transaction with their hardware devices. Let’s explore how!

Group 389.svg

Passkeys in the context of Account Abstraction

In the rapidly evolving world of blockchain technology, Account Abstraction (AA) and Multi-Party Computation (MPC) have emerged as two key concepts that are revolutionizing the way developers approach blockchain-based game development. This article will explore these concepts, their benefits, and the potential challenges they present. 

## What are MPC and Account Abstraction solutions?
### Account Abstraction (AA)
Account Abstraction is a concept that aims to enhance the flexibility and usability of blockchain transactions. In traditional blockchain systems, transactions must be initiated by an Externally Owned Account (EOA), with the rules for validating these transactions hardcoded into the protocol. AA aims to change this by enabling transactions to be sent from [Smart Accounts](https://www.openfort.xyz/docs/guides/smart-accounts/why-smart-accounts), which can program their own rules for validating transactions. This opens up possibilities for features like [gas sponsorship](https://www.openfort.xyz/docs/guides/smart-accounts/policies), [transaction batching](https://www.openfort.xyz/docs/guides/smart-accounts/transactions), and automated transactions.
- AA uses smart contract (can be upgradable) is blockchain-specific
- AA is mostly concerned with onchain signature management
- AA enables programmable authorization logic and allows someone else to pay gas fees
- AA is a new way of thinking about the interfaces between accounts, smart contracts, and transaction execution

### Multi-Party Computation (MPC)
Multi-Party Computation (MPC) is a cryptographic protocol that enables multiple parties to jointly compute a function over their inputs while keeping those inputs private. In the context of blockchain, MPC allows for the distribution of a private key across multiple devices, eliminating the single point of failure created by having one key on one device. This enhances security by protecting users from phishing attacks and the risk of losing a seed phrase.
- MPC is blockchain-agnostic and non-upgradable
- MPC is mostly concerned with offchain key management
- MPC empowers developers with advanced key management mechanisms to manage keys by facilitating the division of keys into multiple shares, supporting distributed key generation, and enabling threshold signatures
- MPC is a cryptographic technique that enables multiple parties to jointly compute a function without revealing their inputs to each other

|  | MPC | AA | AA+MPC |
|---|---|---|---|
| Pros | (1)Off-chain cryptography.  (2)No cost to end users because MPC is off-chain. (3)Neutral to every chain.	 | (1)On-chain  (2)Ability to do atomic transactions (combine multiple actions into one transaction). (3)Ability to do gasless transactions via pre-funding.	 | (1)Combines the benefits of off-chain cryptography and on-chain transactions. (2)Enables atomic transactions and gasless transactions- Neutral to every chain and cost-effective for end users |
| Cons | (1)Harder to do atomic building of transactions. (2)Harder to pre-fund transactions programmatically on-chain, but you can always do this via meta transactions.	 | (1)On-chain costs can get expensive because of cost to deploy and to upgrade across every user & chain.  (2)AA implementations are different on a per chain per VM basis. This will hopefully change as things are standardized. (3)Logic upgrade process with AA becomes a smart contract upgrade process.	 | (1)Requires careful implementation to balance the complexities of both MPC and AA.   |

That being said, there are different type of solution in the market today:
- **Threshold Secret Sharing (TSS):**

This is a cryptographic method where a secret (like a private key) is divided into multiple shares. A predefined number of these shares, called the threshold, is needed to reconstruct the original secret. With fewer shares than the threshold, the secret remains hidden.

TSS enhances security because even if some of the shares are compromised, the secret remains safe unless the threshold number of shares is attained.

- **Shamir's Secret Sharing (SSS):**

Proposed by Adi Shamir, SSS is a specific type of TSS where a polynomial function is used to divide a secret into multiple shares.

The secret itself is the constant term of the polynomial, and the other coefficients are chosen randomly. Points on the polynomial serve as shares, and the secret can be reconstructed using a minimum number of these points (equal to the polynomial degree plus one).
- **Distributed Key Generation (DKG):**

DKG is a protocol where multiple participants collaboratively generate a public-private key pair without any single participant knowing the private key.

It is a way to ensure that a private key is never seen in its entirety by any party. Instead, each participant only has a share of the private key, and joint operations (like signing) can be performed without reconstructing the entire private key.

## Combining AA+MPC
While AA and MPC each have their unique strengths, combining them can unlock a level of user experience that's impossible to achieve with each technology alone. By integrating MPC and AA, developers can leverage the benefits of secure off-chain key management (MPC) and flexible on-chain transaction validation (AA). This synergy can lead to a more seamless and secure user experience, making it a compelling choice for game developers.

### Current implementations
- [Openfort and Web3Auth](https://www.openfort.xyz/integrations/web3auth).
- [Openfort and Particle Network](https://www.openfort.xyz/integrations/particle-network).
- [Openfort and Lit Protocol](https://www.openfort.xyz/integrations/lit-protocol).

If you have more questions/ideas/queries, join our [Developer Discord](https://discord.com/invite/t7x7hwkJF4) and let us know there. Furthermore, you can follow us on [Twitter](https://twitter.com/openfortxyz) for our updates as we keep shipping.


This article will explore these concepts, their benefits, and the potential challenges they present. 

Group 305.svg

The Synergies between AA and MPC: A practical approach for game developers

The terms self-custody, custodial, non-custodial, and others alike are casually thrown around in the industry by different products and protocols, leading to misunderstandings and a subsequent erosion of trust. It's high time we address and rectify this issue.

Although terminology aids in streamlining discussions, it can also pave the way for potential abuses, especially if the definitions are not watertight. 

The security and autonomy provided by different custody solutions are often contingent on the role of the 'signer'. A signer is an entity or mechanism authorized to approve transactions, which can vary from automated smart contracts to end-users themselves.
## Role of a Signer
Within your gaming application, the signer holds a key position as the gatekeeper of a player's smart account. Its duties encompass:

- Safeguarding the private key, which is the vault to a player's digital assets.
- Verifying player identity to ensure legitimacy of actions.
- Shielding the account from unauthorized access and phishing attempts.
- Executing in-game transactions and operations, contingent on player authentication.
- Providing optional account recovery solutions to maintain accessibility even in contingencies.

## Signers and Accounts
- **Custodial Accounts**
In this model, the organization becomes the signer with full authority to manage and execute transactions, which may simplify the process for users at the potential cost of centralization.

- **Non-Custodial Accounts**
Here, users appoint an external service to store their private keys but retain their role as the signer, maintaining control over transaction authorization.

- **Self-Custodial Accounts**
Users are the sole signers, holding complete authority and responsibility for their assets, without any intermediary.

|  | Custodial | Shared-Custody/Non-Custodial | Self-Custodial |
|---|---|---|---|
| KMS Hosted | Server Storage or KMS | Client Storage, 3rd-party KMS or MPC | Client Storage |
| Private Key Visibility | Encrypted | Encrypted or Sharded | Only owner |
| Private Key Control | Con execute anytime | Can't execute without owner | NA (Session keys) |
| Private Key Recovery | KMS | KMS or MPC | Social recovery (Guardians) |

## Security Implications
### The Importance of a Robust Security Model
When integrating wallets into Web3 games, the chosen security model can have far-reaching implications for both players and developers. It's essential to consider where and how private keys are stored. For instance, are they on a user's device, secured in the cloud, or with a third-party provider? The encryption of private keys is another critical factor, with questions about the type of encryption algorithm used and who holds the decryption keys being paramount. These considerations are not just technicalities—they are the bedrock of trust in the gaming ecosystem.

### Key Exportability and Recovery Options
The ability for players to export and recover their keys is another cornerstone of wallet security in gaming. Gamers need assurance that they can export their private keys, ensuring control over their assets regardless of the game's status or service provider's health. Moreover, should a player forget their credentials or lose access to their device, the recovery processes provided by the wallet can mean the difference between a temporary setback and a permanent loss. Game developers must prioritize these features to support their players’ asset security.

### Service Provider Continuity
The reliability of a signer service provider is critical. If the provider faces downtime, what happens to the players? Can they still sign transactions and access their in-game assets? In a dynamic gaming world, interruption in these services can break the immersion and potentially disrupt the game's economy. Therefore, outlining contingencies for such events is essential for maintaining a seamless gaming experience and sustaining player engagement.

## Criteria Selection in Gaming
![Custodianship.svg](https://blog-cms.openfort.xyz/uploads/Custodianship_90e1d8d65c.svg)

When selecting the right custody solution for a Web3 gaming platform, it is essential to weigh various factors that affect both the player experience and the game's integrity. These criteria should not be chosen lightly, as they determine how players interact with the game's economy, the security of their assets, and the overall trust in the gaming environment.

### Custody Model Choice and Player Autonomy
The choice between self-custodial, non-custodial, and custodial models has a direct impact on the level of control and autonomy players have over their in-game assets. Game developers should consider the target audience's technical proficiency and desire for control when choosing a model. Self-custodial options may appeal to players who value sovereignty over their assets, while custodial solutions could be more user-friendly for those less familiar with blockchain technology.

### Security Model Specifics
The specifics of the security model adopted by the wallet provider are crucial. Developers must consider where the private keys are stored and the encryption standards employed. The choice of security model should reflect the game's need for robust protection against unauthorized access while balancing the need for a seamless user experience.

### Authentication Methods and Accessibility
Authentication methods determine the ease with which players can access their wallets and, by extension, participate in the game. A balance must be struck between secure authentication and a frictionless user experience. Whether through traditional email and password combinations, social logins, or more advanced biometrics, the chosen method should facilitate secure and convenient access to the game.

### Key Export and Recovery Mechanisms
A well-thought-out approach to key export and recovery is fundamental. Players should be able to back up and recover their private keys with ease, ensuring they do not lose access to their in-game assets. This is especially relevant in gaming, where the loss of a key could equate to the loss of valuable and perhaps irreplaceable in-game items.

### Evaluating Provider Reliability and Continuity
The reliability of the wallet service provider is a non-negotiable aspect of the selection criteria. The ability of players to sign transactions and access their assets during downtimes is essential to maintain uninterrupted gameplay. Developers must ensure that the wallet solution they choose is backed by a provider with a strong track record of uptime and responsive customer support.

By meticulously evaluating these criteria, game developers can select a wallet integration strategy that aligns with their game’s design philosophy, ensures player retention, and fosters a secure and engaging gaming ecosystem.

More importantly, we enable you to offer consistent player experiences across all types of custodianship. 
- Offer [gasless transactions](https://www.openfort.xyz/blog/technical-dive-gas-sponsorship) for your players
- Safe transfer of [ownership](https://www.openfort.xyz/docs/guides/smart-accounts/transfer) that doesn't expose private keys.
-  [Session keys](https://www.openfort.xyz/blog/technical-dive-session-keys) to avoid wallet popups in your game.


We believe the best approach is having a flexible ownership model that offers a standardized player experience across the different types of ownership models. That’s why regardless whether you decide to [use MPC](https://www.openfort.xyz/blog/aa-and-mpc-a-practical-approach), [host a KMS](https://github.com/openfort-xyz/samples/tree/main/external-kms-game), or onboard users with [social recovery accounts](https://www.openfort.xyz/blog/recoverable-accounts), we'll offer your players an outstanding experience across the board with the best security and cast guarantees in the market.

If you have more questions/ideas/queries, join our [Developer Discord](https://discord.com/invite/t7x7hwkJF4) and let us know there. Furthermore, you can follow us on [Twitter](https://twitter.com/openfortxyz) for our updates as we keep shipping.

Both types of wallets have their own sets of benefits and limitations, and the choice depends on your preferences and priorities.

Group 289.svg

Custodial or Non-Custodial Wallets in Gaming?

Wallets, the cornerstone of blockchain transactions, have been a part of the crypto landscape since the inception of Bitcoin. Originally designed as a tool for holding keys and managing transactions, wallets have evolved significantly over the years. However, their foundational design and architecture have remained largely unchanged. Today, we're on the brink of a new era, one that calls for a reimagining of what wallets can be.

## The Evolution of Wallets

![Untitled-2022-08-31-2057.png](https://blog-cms.openfort.xyz/uploads/Untitled_2022_08_31_2057_578d7eb727.png)

From their humble beginnings as tools for transferring and holding BTC, wallets have come a long way. Today, they're not just about transactions; they're gateways to a myriad of decentralized applications, from trading ERC20 tokens to playing games like Axie Infinity.

As the industry matures, we're seeing new dynamics emerge. Wallets are evolving into identity managers, and protocols are going vertical, owning the wallet stack for their users. Wallets are also becoming super-apps or browsers for decentralized apps, adding a new layer of utility to the crypto ecosystem.

## The Future of Wallets

As we navigate this era of verticalization or unbundling, the dominance of monolithic wallet providers is being challenged. We're witnessing the rise of compelling products in different verticals, mirroring the expansion of digital payments that led to the emergence of a diverse stack of payment companies. MPC (multi-party computation) and AA (account abstraction) presents an opportunity to bring the industry up to par with other industries where current approaches might be ready for disruption (ie. marketplaces, communities, games, etc.).

All in all, we’re living through a time of verticalization or unbundling, where the dominance of monolithic wallet providers is threatened by the emergence of compelling products in different verticals, similar to the stack of payment companies that rose from the expansion of digital payments. 

This shift necessitates a rethinking of what it truly means to be the users' first entry point into crypto. While harder problems at the protocol level are being solved, we need infrastructure and middleware that can abstract away the complexities of crypto from both users and developers.

![Untitled-2022-08-31-2057 (1).png](https://blog-cms.openfort.xyz/uploads/Untitled_2022_08_31_2057_1_fa08ee29bb.png)

## Enabling Vertical Wallets at Scale

To meet the demands of this new era, wallets will need to evolve in several key ways:

- **Support and Abstraction for Multiple Verticals:** Wallets must be able to cater to a variety of use cases and industries, providing the necessary abstraction to make crypto accessible to all.

- **High Capacity and Programmable Permissions:** Wallets must be capable of generating thousands of wallets and handling millions of transactions per second (TPS), all while offering programmable permissions.

- **Accessibility via APIs and SDKs:** To ensure seamless integration and usage, wallets must be accessible via APIs and SDKs.

![Untitled-2022-08-31-2057 (3).png](https://blog-cms.openfort.xyz/uploads/Untitled_2022_08_31_2057_3_cb4dc2829c.png)

### A Time of Excitement and Innovation

We're arguably in the most exciting time to build in the crypto space. We can finally move from trying to do it all to developing real infrastructure categories that will support the creation of meaningful products. It's about time we embraced the potential of modular wallet architecture and the opportunities it presents for enabling vertical wallets at scale.

If you have more questions/ideas/queries, join our [Developer Discord](https://discord.com/invite/t7x7hwkJF4) and let us know there. Furthermore, you can follow us on [Twitter](https://twitter.com/openfortxyz) for our updates as we keep shipping.

Today, we're seeing trends like dapp and vertical-specific wallets, where crypto-aware products are becoming more like wallets.  How will all these shape in the future?

Group 296.svg

Modular Wallets: The Key to Scaling New Verticals

Wallets were originally created with an emphasis on buying tokens for speculation rather than for practical use cases. However, as crypto becomes more user-friendly, new use cases for them will emerge, making it easier to transmit them to end-users. 

The era of rewarding users for taking risks associated with wallet operations is coming to an end. While wallets continue to be the primary means of interacting with the blockchain, we b elieve there is plenty of room for improvement and starting to abstract the financial aspect of wallets to be more ubiquitous to other verticals.

## Evolution of Wallet Experience

1. Writing down private keys and using public keys to receive bitcoins
2. From custodial wallets to self-custody wallets
3. Self-custody wallets gave access to decentralized apps

Take the Axie Infinity example: it has plenty of flaws and awful UX, but it has become the biggest play-to-earn game, taking many in the crypto and gaming space by surprise. While the UX was definitely a roadblock, the fact that it was (i) fun and (ii) productive was enough reason for a whole generation to learn about crypto and get onboarded.

The primary issue with crypto lies not in its user experience, but in its lack of utility. While this may seem counterintuitive, it presents an opportunity to bring blockchain technology up to par with other industries where current methods fall short, such as marketplaces, communities, and games. 

By taking the premise that everyone will have multiple addresses, addressing its most challenging aspects will allow individuals to experiment and create new verticals and user behaviours that were previously unimaginable with blockchain technology. 

### Wallets as an abstraction layer

Similarly to how we access different websites on the internet today, we do not want the added complexity of using different wallets for different purposes. While wallets are set to gain popularity as an abstraction layer that will accrue the most value (read [fat wallet thesis]()). 

We believe wallets should act like Google Accounts, enabling access to new applications (like Google Suit as comparison) that provide new value for end-users.

You are probably already familiar with MetaMask, an External Owned Account (EOA). EOA consists of a cryptographic pair of keys: public and private keys that manage account activities. 

![SessionKeysExample (3).svg](https://strapi-oube.onrender.com/uploads/Session_Keys_Example_3_7b981920ba.svg)

The next evolution of EOAs are contract accounts (CAs). CAs don't have a private key. They are smart contracts that are governed by the code's logic within them. Each new iteration adds a new opportunity for wallets to increase the size of the market by serving new use cases (From hardware wallets, to chrome extensions, to mobile apps, to multisigs, executable NFTs, and more).

|                  | Externally Owned Account                                                                | Smart Contract Account                                                                                                      |
|------------------|-----------------------------------------------------------------------------------------|-----------------------------------------------------------------------------------------------------------------------------|
| Creation         | Created with an on-chain address linked to a private key. No fees required.             | Requires the deployment of a smart contract on-chain. Fees are applicable.                                                  |
| Control          | Managed with private keys.                                                              | Governed by the underlying smart contract code.                                                                             |
| Functionality    | Enables direct transfer of assets and interaction with dApps and other smart contracts. | Highly programmable due to the flexibility of smart contract and account abstraction.                                       |
| Transaction Fees | Mandatory balance in ETH is required for transactions.                                  | Can leverage gas-saving mechanisms. Fee payment possible in stablecoins or other tokens (depending on integrated networks). |
| Security         | Security depends on the user's private key management.                                  | More sophisticated with options for 2FA or Hybrid (multisig) security.                                                      |
| Recovery         | Account recovery is typically not possible.                                             | Supports account recovery options such as social recovery.                                                                  |

## The Future of Wallets

Understanding both types of wallets allows us to see their advantages and limitations and move one step closer to today's innovation in the space, represented by both the concept of Account Abstraction (AA) and Multi-party computational (MPC) wallets.

On one hand,account abstraction (AA) which requires the use of smart contract wallets (SCW), ranges from simply enhancing blockchain usability to unlocking an entirely new realm of functionality that could catalyze widespread adoption. Mostly represented by ERC4337, can be used for covering user gas costs or allowing users to pay fees in another token, partial/MEV reimbursement with alternative mempools.

On the other hand, MPC uses EOAs and off-chain programmability before you get to the signature part, so users do not need to deploy new addresses on any chain. Furthermore, MPC policies and their signature schemes can be private. 

While MPC and SCW have some overlap in use cases, both have their own benefits. For example, a scenario where one uses an MPC signing scheme to control a smart contract wallet.

The key takeaway is that code determines the action of contract accounts, whereas users manage EOAs. This is significant because smart contracts have the ability to execute anything that can be programmed, like [offering pop-upless player experience](https://www.openfort.xyz/blog/technical-dive-session-keys).

If you have more questions/ideas/queries, join our [Developer Discord](https://discord.com/invite/t7x7hwkJF4) and let us know there. Furthermore, you can follow us on [Twitter](https://twitter.com/openfortxyz) for our updates as we keep shipping.

Wallets were originally created with an emphasis on buying tokens for speculation rather than for practical use cases. However, as cryptocurrencies become more user-friendly, new use cases for them will emerge, making it easier to transmit them to end-users. 

Openfort blog

Passkeys in the context of Account Abstraction

Passkeys in the context of Account Abstraction

The Synergies between AA and MPC: A practical approach for game developers

Custodial or Non-Custodial Wallets in Gaming?

Modular Wallets: The Key to Scaling New Verticals

Understanding Crypto Wallets