Ethereum, the world's leading smart contract platform, is on the brink of a major upgrade that could revolutionize how users interact with the blockchain. Enter EIP-7702, a groundbreaking proposal set to transform Externally Owned Accounts (EOAs) by granting them smart contract capabilities. 

## What is EIP-7702?

[EIP-7702](https://ethereum-magicians.org/t/eip-7702-set-eoa-account-code/19923), proposed by Ethereum co-founder Vitalik Buterin and the co-authors of [EIP-3074](https://www.openfort.xyz/blog/4337-and-3074) in May 2024, introduces a new transaction type that allows EOAs to have smart contract code. Initially designed to set EOA account code for a single transaction, the proposal has evolved to allow the code to persist until the next EIP-7702 transaction.

### Key Features:
- Enables EOAs to function as smart contracts
- Introduces a new transaction type (0x04)
- Allows for persistent code changes
- Supports multiple EOA upgrades in a single transaction

## The Evolution of EIP-7702

The proposal has undergone significant changes since its inception:

1. **Initial Version**: Set EOA account code for one transaction
2. **Current Version**: Set EOA account code that persists until the next EIP-7702 transaction

This evolution addresses previous limitations and opens up new possibilities for account functionality and user experience.

## How EIP-7702 Works

EIP-7702 introduces a new mechanism that allows Externally Owned Accounts (EOAs) to behave like smart contracts. Let's break down the key components and processes:

### Signature Structure
An EIP-7702 signature requires four crucial fields:

1. **MAGIC**: A to-be-determined constant that identifies the signature as an EIP-7702 type.
2. **chain_id**: Either 0 (for cross-chain compatibility) or the current chain's ID.
3. **address**: The smart contract address containing the implementation code.
4. **nonce**: The current valid nonce of the EOA.

The signature is created by signing the keccak256 hash of these components:

```
sign(keccak256(MAGIC || rlp([chain_id, address, nonce])))
```

This structure ensures the integrity and authenticity of the upgrade request.

### Transaction Structure
EIP-7702 introduces a new transaction type (0x04) with the following format:

```
[
    chain_id,
    nonce,
    max_priority_fee_per_gas,
    max_fee_per_gas,
    gas_limit,
    destination,
    value,
    data,
    access_list,
    authorization_list,  // New field for EIP-7702
    signature_y_parity,
    signature_r,
    signature_s
]
```

The `authorization_list` is a new field that contains an array of EIP-7702 signatures and associated data, allowing multiple EOAs to be upgraded in a single transaction.

### Upgrade Process
The upgrade process for an EOA to gain smart contract functionality involves several steps:

1. **Signature Creation**: The EOA owner creates an EIP-7702 signature using their private key. This signature authorizes the upgrade and specifies the smart contract address to be used for the account's new functionality.

2. **Transaction Submission**: The EIP-7702 transaction is submitted to the network. This can be done by the EOA itself or by a separate relayer service. The transaction includes the authorization_list containing the EIP-7702 signature(s).

3. **Signature Verification**: Upon receiving the transaction, the Ethereum network verifies the EIP-7702 signature(s) to ensure they are valid and correspond to the EOAs being upgraded.

4. **Code Update**: If the signature is valid, the EOA's account code is updated. The new code is a special delegatecall proxy that points to the address specified in the EIP-7702 signature. This is typically represented as `0xef0100` followed by the 20-byte address of the implementation contract.

5. **Persistence**: Unlike earlier versions of the proposal, this code change persists until another EIP-7702 transaction is made for the same account. This allows the EOA to maintain its smart contract functionality across multiple transactions.

6. **Execution**: After the upgrade, when transactions are sent to the EOA, they are automatically forwarded to the implementation contract, allowing the account to behave like a smart contract while retaining its original EOA address.

### Multi-Account Upgrades
One of the powerful features of EIP-7702 is the ability to upgrade multiple EOAs in a single transaction. This is achieved through the `authorization_list` in the transaction structure. Each entry in this list corresponds to a different EOA, allowing for batch upgrades which can significantly reduce gas costs and simplify the upgrade process for service providers or wallet operators.

## Benefits of EIP-7702

1. **Enhanced Functionality**: EOAs gain smart contract capabilities
2. **Improved User Experience**: Enables features like [gas sponsorship](https://www.openfort.xyz/blog/technical-dive-gas-sponsorship) and transaction batching
3. **Cross-Chain Compatibility**: Signatures with chain_id 0 are valid across all EVM chains
4. **Efficient Upgrades**: Multiple EOAs can be converted to smart accounts in one transaction
5. **Flexibility**: EOAs retain their original functionality while gaining smart contract features

## [Compatibility with ERC-4337](https://github.com/openfort-xyz/openfort-7702-cli)

When an EOA is upgraded using EIP-7702, it can point to a smart contract implementation that is ERC-4337 compatible. This allows for the following workflow:

1. User initiates a transaction through a dApp interface.
2. The dApp creates a UserOperation with `userOp.sender` set to the EOA address.
3. The UserOperation is sent to a bundler.
4. The bundler packages multiple UserOperations and sends them to the EntryPoint contract.
5. The EntryPoint contract calls the upgraded EOA for validation and execution.
6. The EOA, now behaving as a smart contract, processes the UserOperation according to its ERC-4337 compatible implementation.


## Implications for Different Stakeholders

### For Users
- Seamless upgrade to smart account functionality
- Retention of EOA features and seed phrase importance
- Improved account security and recovery options

### For Developers
- New possibilities for dApp interactions
- Potential need to update smart contracts that rely on EOA checks
- Opportunity to leverage enhanced account features

### For Wallet Providers
- Need for robust security measures to prevent malicious upgrades
- Potential for improved user experience through smart account features

## Potential Concerns and Mitigations

While EIP-7702 offers significant benefits, it also introduces new considerations that need to be carefully addressed:

### 1. Storage Collisions

**Concern**: When an EOA upgrades from one smart contract implementation to another, there's a risk of storage collision. Different implementations might use the same storage slots for different purposes, leading to data corruption or unexpected behavior.

**Mitigation**: EIP-7201 (Namespaced Storage Layout) has been proposed to address this issue. It introduces a standard way of organizing contract storage:

- Each module or major component of a contract uses a unique namespace.
- Storage slots are calculated using a hash of the namespace and a local index.
- This approach significantly reduces the risk of collisions when switching between different implementations.

Example of EIP-7201 implementation:

```solidity
bytes32 private constant MAIN_STORAGE_LOCATION =
    keccak256(abi.encode(uint256(keccak256("example.main")) - 1)) & ~bytes32(uint256(0xff));

function _getMainStorage() private pure returns (MainStorage storage $) {
    assembly {
        $.slot := MAIN_STORAGE_LOCATION
    }
}
```

### 2. Security Risks

**Concern**: The persistent nature of the upgrade means that a single malicious EIP-7702 signature could potentially compromise an account indefinitely.

**Mitigation**:
- Wallet providers are expected to implement strict security measures around EIP-7702 signatures, potentially limiting them to one-time use during account initialization.
- Users retain the ability to submit new EIP-7702 transactions to update their account's code or revert to a standard EOA, providing a mechanism to recover from malicious upgrades.
- Education and clear user interfaces will be crucial to help users understand the implications of EIP-7702 upgrades.

### 3. Compatibility with Existing Contracts

**Concern**: Some existing smart contracts rely on checking whether an address is an EOA (often by using `tx.origin == msg.sender`). These contracts might behave unexpectedly with upgraded EOAs.

**Mitigation**:
- Developers will need to update contracts that rely on EOA checks to account for EIP-7702 upgraded accounts.
- New best practices will emerge for distinguishing between different types of accounts without relying on outdated methods.

### 4. Increased Complexity

**Concern**: The addition of upgradeable EOAs increases the overall complexity of the Ethereum ecosystem, which could lead to unforeseen issues or vulnerabilities.

**Mitigation**:
- Extensive testing and auditing of EIP-7702 implementations before mainnet deployment.
- Gradual rollout and adoption to allow time for the ecosystem to adapt.
- Ongoing monitoring and quick response mechanisms for addressing any issues that arise post-deployment.

### 5. Gas Costs and Network Load

**Concern**: If a large number of EOAs frequently change their implementation, it could lead to increased network load and higher gas costs.

**Mitigation**:
- Encouraging the use of modular smart account implementations (like those proposed in EIP-7579 and EIP-6900) that reduce the need for frequent upgrades.
- Potential future optimizations to reduce the gas cost of EIP-7702 upgrades.

## Future Outlook

EIP-7702 is expected to be included in the Pectra Hardfork, scheduled for early 2025. Its implementation could lead to:

- Rapid adoption of smart account features
- Evolution of dApp interactions to leverage new account capabilities
- Increased focus on [wallet UX](https://www.openfort.xyz/blog/understanding-crypto-wallets) and transaction simulation

## Conclusion

EIP-7702 represents a significant leap forward in Ethereum's [account abstraction journey](https://www.openfort.xyz/blog/understanding-native-account-abstraction-in-rip-7560). By bridging the gap between EOAs and smart contracts, it paves the way for a more flexible, user-friendly blockchain experience. As the Ethereum community prepares for this upgrade, developers, users, and businesses should stay informed about the potential impacts and opportunities that EIP-7702 will bring to the ecosystem.

## FAQs

1. **What is the main purpose of EIP-7702?**
   EIP-7702 allows Externally Owned Accounts (EOAs) to have smart contract functionality, enhancing their capabilities and improving user experience on the Ethereum network.

2. **When is EIP-7702 expected to be implemented?**
   EIP-7702 is anticipated to be included in the Pectra Hardfork, scheduled for early 2025.

3. **Will EIP-7702 affect my existing EOA?**
   EIP-7702 is opt-in, meaning your existing EOA will not be automatically affected. You can choose to upgrade your EOA to have smart contract functionality.

4. **Is EIP-7702 compatible with existing dApps?**
   Most existing dApps should remain compatible, but some may need updates to fully leverage the new features provided by EIP-7702.

5. **How does EIP-7702 improve security?**
   EIP-7702 enables advanced security features like multi-factor authentication and account recovery options, which were previously only available to smart contract wallets.

This article delves into the intricacies of EIP-7702, its potential impact on the Ethereum ecosystem, and what it means for developers, users, and the future of blockchain interaction.

EIP7702.svg

Technical dive: EIP7702 with ERC4337

## Intro to RIP-7560 and Account Abstraction

RIP-7560 improves Ethereum's native account abstraction. It tackles high gas costs and centralization, changing how we interact with the blockchain.

**Why RIP-7560 Matters**:
- **Gas Efficiency**: Cuts transaction costs, boosting usage.
- **Decentralization**: Reduces reliance on central entities, enhancing security.
- **User Experience**: Simplifies interactions through complex transactions and account recovery.

Developers and blockchain enthusiasts should pay attention to RIP-7560. It showcases Ethereum's evolution, highlighting how native account abstraction boosts efficiency and usability. This proposal enhances scalability and makes blockchain interactions simpler and more accessible.

RIP-7560 reflects the Ethereum community's drive for innovation. It tackles longstanding issues and enhances the blockchain. These upgrades pave the way for robust, flexible applications, propelling blockchain development forward.

## Understanding Native Account Abstraction

Native account abstraction in RIP-7560 integrates directly into Ethereum's protocol. This allows EOAs to start transactions more efficiently and securely.

**AA_TX_TYPE Transaction Type**: This new transaction type changes the consensus layer. It supports complex transaction structures and improves blockchain functionality and user experience.

**Benefits of Native Integration**:

1. **Enhanced Scalability**: Direct integration cuts the need for extra layers. This streamlines processes and boosts scalability.

2. **Security Improvements**: Direct integration reduces reliance on external infrastructure. This minimizes security risks and ensures safer blockchain operations.

3. **Efficiency in Transactions**: Native transaction initiation by EOAs creates smoother, faster, and more efficient transactions. This improves overall network performance.

For those interested in exploring how account abstraction can further enhance blockchain functionality, our [technical dive into combining Token Bound Accounts with Account Abstraction](https://www.openfort.xyz/blog/technical-dive-combining-token-bound-account-tba-with-account-abstraction-aa) offers insights into integrating ERC-6551 and ERC-4337 standards.

This native integration shows Ethereum's innovative approach. It tackles challenges and paves the way for advanced applications. This approach supports robust, flexible systems, aligning with our focus on using blockchain technology in gaming. RIP-7560's improvements in scalability and security make the blockchain more user-friendly for developers and end-users alike.

## Gas Cost Reduction with RIP-7560

RIP-7560 cuts gas costs by making Ethereum more efficient. It penalizes unused gas, pushing users to optimize their usage. This reduces waste and eases network congestion.

**How RIP-7560 Reduces Costs**:

- **Unused Gas Penalties**: Better gas use means network resources go further.
- **Smart Incentives**: More people can join the network, reducing reliance on big players.

These changes make blockchain transactions cheaper. RIP-7560 boosts Ethereum's speed and efficiency through smarter gas use, similar to the advancements seen in [EIP-7702, which enhances transaction flexibility and reduces gas costs](https://www.openfort.xyz/blog/4337-and-3074). This builds a stronger, more scalable network. We aim to make blockchain easy for developers and users alike.

RIP-7560 also helps decentralize Ethereum. More diverse participation makes the network safer and tougher. These upgrades create a more efficient, user-friendly blockchain that can handle complex apps with ease.

## ERC-4337 vs RIP-7560 Technical Comparison

ERC-4337 operates as a layer on top of Ethereum using smart contract wallets, while RIP-7560 involves protocol-level changes for native integration. This distinction is crucial in understanding their functionalities and impact on the Ethereum ecosystem.

**ERC-4337:**

- **Smart Contract Wallets**: Utilizes smart contracts to manage wallets, enabling features like social recovery and multiple signatories. For a deeper understanding of how these wallets have evolved and their future potential, explore our blog on [the evolution and future of crypto wallets](https://www.openfort.xyz/blog/understanding-crypto-wallets).
- **Layer 2 Dependency**: Relies on additional layers to provide account abstraction, which may introduce complexity and potential latency.
- **Gas Optimization**: Offers some gas-saving mechanisms but within the constraints of smart contract execution.

**RIP-7560:**

- **Native Integration**: Directly integrates into the Ethereum protocol, allowing for seamless account abstraction without additional layers.
- **Non-Sequential Nonces**: Supports non-sequential nonce usage, enabling more flexible transaction management and reducing potential bottlenecks.
- **Builder Fees**: Introduces efficient fee structures, enhancing transaction processing and network scalability.
- **Complex Transactions**: Facilitates more complex transaction types, improving functionality and user experience.

RIP-7560's native approach enhances network efficiency and supports advanced features like decentralized mempools. This native integration reduces reliance on external infrastructure, offering a more streamlined and secure solution. These protocol-level enhancements make RIP-7560 a robust advancement in Ethereum's evolution.

## Transaction Execution and Logic in RIP-7560

RIP-7560 enhances transaction execution by separating execution and verification processes. This separation allows transactions to be processed more efficiently, improving the scalability of the Ethereum network.

1. **Execution and Verification Separation**: This model streamlines transaction processing by allowing execution to occur without immediate verification. It enhances throughput and reduces bottlenecks.

2. **Compatibility with ERC-4337 Tools**: RIP-7560 supports existing tools, facilitating a smooth transition for developers. This ensures that current systems can leverage the benefits without extensive modifications.

3. **Improved Scalability**: By streamlining transaction validation, RIP-7560 reduces reliance on centralized entities. This decentralization enhances network efficiency and security.

The advantages of RIP-7560's approach include higher transaction throughput and reduced processing costs. These improvements make Ethereum more robust and adaptable to complex applications. The focus on efficient execution and logic separation aligns with the goal of creating a more scalable blockchain infrastructure, benefiting both developers and end-users. For developers looking to optimize transaction management, exploring [advanced nonce management and transaction parallelization](https://www.openfort.xyz/blog/parallalization-of-transactions-2d-nonce) can provide insights into enhancing performance and scalability.

## Transitioning From ERC-4337 to RIP-7560

Transitioning from ERC-4337 to RIP-7560 involves adopting an evolved framework that enhances Ethereum's capabilities. RIP-7560 builds upon the foundations of ERC-4337, offering native integration that simplifies account abstraction.

**Compatibility**: Projects can leverage existing ERC-4337 tools with RIP-7560. This ensures a smooth transition, minimizing development overhead while enhancing functionality.

**Coexistence**: Both standards can operate together. This allows gradual migration, enabling projects to adopt RIP-7560's features without immediate full-scale changes.

**Benefits of Transitioning**:
- **Native Integration**: Provides seamless account abstraction, reducing reliance on smart contracts and additional layers.
- **Improved Efficiency**: Enhances transaction processing speed and reduces gas costs, benefiting both developers and users. For insights on integrating account abstraction with secure key management, explore how [Account Abstraction and Multi-Party Computation can revolutionize blockchain game development](https://www.openfort.xyz/blog/aa-and-mpc-a-practical-approach).
- **Scalability**: Supports advanced transaction types and decentralized mempools, optimizing network performance.

**Challenges**: Migrating to RIP-7560 may require adaptation of existing systems. Developers need to understand protocol-level changes and adjust their applications accordingly.

**Steps to Transition**:
- **Evaluate Compatibility**: Assess current systems for compatibility with RIP-7560.
- **Incremental Adoption**: Gradually integrate RIP-7560 features while maintaining ERC-4337 operations.
- **Leverage Tools**: Utilize existing tools and resources to facilitate the transition.

This migration path offers enhanced efficiency and scalability, aligning with Ethereum's evolution and future growth.

## Key Takeaways on RIP-7560

RIP-7560 improves Ethereum's native account abstraction, boosting the blockchain's efficiency and scalability. It cuts gas costs and speeds up transactions. As part of Ethereum's protocol, RIP-7560 makes complex transactions easier, benefiting developers and users alike.

The changes RIP-7560 brings to the protocol encourage wider use of smart contract accounts. This upgrade to Ethereum opens doors for more creative and flexible applications. Better transaction speed and less reliance on central entities boost security and decentralization.

**Key Takeaways**:

- **Gas Cost Reduction**: Optimizes gas usage, leading to cheaper transactions and less network congestion.
  
- **Enhanced Scalability**: Streamlined processes and direct integration boost overall network performance.

- **Developer Experience**: Works with existing tools and eases the shift from ERC-4337, reducing development challenges.

RIP-7560 matters for anyone wanting to stay ahead in the fast-moving blockchain world. It tackles current issues and paves the way for future growth. Developers can leverage these improvements to create better, more efficient apps.

Explore how RIP-7560 transforms Ethereum's account abstraction, slashing gas costs and enhancing scalability. Can this protocol-level change redefine blockchain usability?

native_account_abstraction.svg

Understanding Native Account Abstraction in RIP-7560

At Openfort, our mission is to empower developers to create great games with seamless blockchain integration. Today, we're excited to share a significant milestone in our journey towards more secure and transparent infrastructure: the results of our recent security audit for our Shamir's Secret Sharing (SSS) library, implemented in Go.

You can find our [Go SSS library](https://github.com/openfort-xyz/shamir-secret-sharing-go) and the [full audit report](https://drive.google.com/file/d/1fQ5lCg-JgH_TcSt9hCwcIv-psP_8Nbze/view?usp=sharing).

## The Importance of Shamir's Secret Sharing

Shamir's Secret Sharing Scheme (SSS) is a cryptographic primitive that allows a secret to be divided into multiple parts, or shares, with a threshold number required to reconstruct the original secret. This technique is crucial for secure key management and distribution in various cryptographic applications, including blockchain wallets and secure multi-party computation.

Fun Fact: Shamir's Secret Sharing Scheme was invented by Adi Shamir, one of the creators of the RSA algorithm, in 1979. It's a testament to its robustness that it remains a crucial part of modern cryptography over four decades later!

### Deep Dive: How SSS Works

At its core, SSS relies on a fascinating property of polynomials: any degree-k polynomial can be uniquely identified by any set of k+1 distinct points. Here's how it works:

1. **Encoding the Secret**: The secret S is encoded into a polynomial f(x) of degree k-1 over a finite field Fp. The polynomial takes the form:

   f(x) = S + r₁x + r₂x² + ... + rₖ₋₁xᵏ⁻¹

   where S is the secret (constant term) and r₁, r₂, ..., rₖ₋₁ are random coefficients.

2. **Generating Shares**: n distinct shares are generated by evaluating f(x) at different points. Each share is an ordered pair (xᵢ, f(xᵢ)).

3. **Recovering the Secret**: Any k shares can reconstruct the original polynomial using Lagrange interpolation, allowing recovery of the secret S by evaluating f(0).

## Our Audit Journey

In our commitment to security and transparency, we engaged Cure53, a renowned security firm, to conduct a thorough cryptography review and source code audit of our Go SSS library. The audit, completed in August 2024, focused on ensuring the correctness and security of our implementation.

### Key Findings and Implemented Solutions

1. **Overall Soundness**: The audit revealed that our SSS library is generally sound and correctly implemented. The use of GF(2^8) for the underlying field was noted as a good choice for simplification and future-proofing.

2. **Timing Variance Resolution**: A low-severity issue (OFT-01-001) was identified, showing a small timing variance in the GF256 multiplication. We've addressed this by implementing a constant-time solution, enhancing the library's resistance to potential timing attacks.

3. **Enhanced Input Validation**: Following the auditors' suggestion (OFT-01-002), we've implemented more robust input validation during the reconstruction process. This improvement enhances the library's resilience against potential attacks and ensures smoother error handling.

### Technical Deep Dive: Ensuring Implementation Security

One critical aspect of SSS implementation that our library carefully addresses is the "zero share problem". This occurs when a share's x-coordinate is zero, potentially revealing the secret directly. Our Go implementation includes safeguards against common pitfalls:

- **Counter-based shares**: We ensure our share generation starts from 1, not 0, avoiding accidental zero shares.
- **User input handling**: Our library implements strict checks to prevent user-supplied values or identifiers that could lead to zero shares.
- **Secure random number generation**: We use Go's crypto/rand package to generate secure random numbers, mitigating the risk of zero or predictable shares.

These measures, along with the improvements suggested by the audit, make our SSS library a robust and secure choice for developers. If you're curious, check how we're combining the SSS library with [Shield](https://www.openfort.xyz/docs/guides/auth/recovery) and our [security approach](https://www.openfort.xyz/docs/security) at Openfort.

## Our Commitment to Open Source

We're excited to announce that we're open-sourcing both our SSS library and the full audit report. As the first of its kind implemented in Go, we believe this library will be a valuable addition to the cryptographic community.

By making our library and audit results public, we aim to:

1. Contribute to the broader understanding of secure SSS implementations
2. Invite peer review and continuous improvement of our codebase
3. Provide a valuable resource for developers and researchers in the field, especially those working with Go

Fun Fact: The concept of open-source security is often referred to as "Linus's Law", named after Linus Torvalds: "Given enough eyeballs, all bugs are shallow."

## Looking Ahead

The audit results have provided us with valuable insights, and we've already implemented the suggested improvements. We're committed to maintaining the highest standards of security and will continue to invest in regular audits and open collaboration.

We encourage the community to review our library, provide feedback, and contribute to its ongoing development. Together, we can build a more secure and robust foundation for the future of decentralized applications.

Join us in our mission to make blockchain integration safer and more accessible for game developers worldwide. Let's build the future of gaming, securely and transparently, together.

Today, we're excited to share a significant milestone in our journey towards more secure and transparent infrastructure

Audit Thumbnail Final-min.jpg

Securing the Future: Openfort's SSS Library Audit and Open Source Commitment

In the world of blockchain and Web3 development, efficient transaction management is crucial for creating responsive and scalable applications. This article delves into the intricacies of nonce management, exploring its evolution from traditional single-dimensional systems to more advanced two-dimensional approaches. 

## Understanding Nonces and Their Importance

Nonces are critical components in blockchain transactions, ensuring correct ordering and execution. They serve as unique identifiers for each transaction, preventing double-spending and maintaining the integrity of the blockchain.

### Traditional One-Dimensional Nonces

Externally Owned Accounts (EOAs) traditionally use a single-dimensional nonce system. Here's how it works:

1. Each account has a single nonce counter, starting at 0.
2. The nonce increments by 1 with each transaction.
3. Transactions are processed in strict sequential order based on the nonce.

For example, if a user initiates three transactions with nonces 1, 2, and 3, they must be executed in that exact order.

### Limitations of One-Dimensional Nonces

While simple to understand, this system has significant limitations:

1. **Sequential Execution**: All transactions must be processed in order, even if they're unrelated. This can lead to unnecessary delays.
2. **Bottlenecks**: If one transaction is stuck or slow, it blocks all subsequent transactions.
3. **Concurrency Issues**: Attempting to send multiple transactions simultaneously can lead to nonce reuse errors.
4. **Scalability Problems**: As transaction volume increases, these issues become more pronounced, potentially causing system-wide slowdowns.

## The Challenge of Nonce Management in Production

In production environments, nonce management becomes increasingly complex. Let's explore some common issues and their solutions:

### Problem: Nonce Reuse Errors

When multiple transactions are attempted simultaneously, they may try to use the same nonce, resulting in errors.

**Solution: Off-chain Nonce Tracking**

Implement an off-chain nonce tracking system using an atomic datastore like Redis:

1. Sync the off-chain nonce with the on-chain value initially.
2. Before sending a transaction to the RPC:
 - Fetch the current nonce from the off-chain store.
 - Set the transaction's nonce to this value.
 - Increment the off-chain nonce.
3. Submit the transaction to the RPC.

This approach allows for optimistic nonce assignment without waiting for previous transactions to complete.

```python
import redis

r = redis.Redis(host='localhost', port=6379, db=0)

def get_and_increment_nonce(wallet_address):
 nonce = r.incr(f"nonce:{wallet_address}")
 return nonce - 1 # Return the pre-incremented value

def send_transaction(wallet_address, transaction_data):
 nonce = get_and_increment_nonce(wallet_address)
 transaction_data['nonce'] = nonce
 # Submit transaction to RPC...
```

### Problem: Transaction Failures

Transactions can fail for various reasons, potentially disrupting the nonce sequence.

**Solution: Robust Error Handling and Retry Mechanisms**

1. **Simulate Before Sending**: Use a simulation endpoint to check if a transaction will succeed before sending it.
2. **Gas Management**: 
 - Set up alerts for low gas funds in the wallet.
 - Implement dynamic gas price adjustments based on network conditions.
3. **Retry Mechanism**: Implement a smart retry system for failed transactions.
 - For temporary issues (e.g., network congestion), retry with updated gas settings.
 - For permanent failures, cancel the transaction to unblock the nonce sequence.

```python
async def send_transaction_with_retry(wallet, tx_data, max_retries=3):
 for attempt in range(max_retries):
 try:
 # Simulate transaction
 simulation_result = await simulate_transaction(tx_data)
 if not simulation_result.success:
 raise SimulationFailedError(simulation_result.error)
 
 # Send transaction
 tx_hash = await wallet.send_transaction(tx_data)
 return tx_hash
 except (NetworkCongestionError, LowGasPriceError) as e:
 if attempt == max_retries - 1:
 raise
 # Update gas price and retry
 tx_data['gasPrice'] = await get_updated_gas_price()
 except SimulationFailedError:
 # Don't retry if simulation fails
 raise
```

## Introducing Two-Dimensional Nonces

To address the limitations of one-dimensional nonces, smart accounts and account abstraction introduce a more advanced two-dimensional (2D) nonce system.

### How 2D Nonces Work

A 2D nonce consists of two components:

1. **Nonce Key**: A unique identifier for a group of related transactions.
2. **Nonce Value**: The sequential counter within that group.

This structure allows for parallel execution of independent transactions while maintaining order within related transaction groups.

### Implementing 2D Nonces

Here's a simplified implementation of a 2D nonce system:

```solidity
mapping(address => mapping(uint256 => uint256)) private nonceSequenceNumber;

function getNonce(address sender, uint256 key) public view returns (uint256) {
 return nonceSequenceNumber[sender][key] | (uint256(key) << 64);
}

function incrementNonce(address sender, uint256 key) internal {
 nonceSequenceNumber[sender][key]++;
}
```

In this implementation:
- `nonceSequenceNumber` stores the current sequence number for each sender and key combination.
- `getNonce` combines the sequence number with a left-shifted key value to create a unique nonce.
- `incrementNonce` increases the sequence number for a specific sender and key.

## Enabling Parallel User Operations

With 2D nonces, we can now execute independent transactions in parallel. Let's look at some examples:

### Simple Parallel Transactions

1. Transaction 1: Swap 1 ETH for 4000 USDC (Nonce Key: 1)
2. Transaction 2: Swap 4000 USDC for 7000 NATION (Nonce Key: 1)
3. Transaction 3: Buy 1 NFT for 100 USDC (Nonce Key: 2)

In this scenario, Transactions 1 and 2 use the same nonce key as they're related (USDC swaps), while Transaction 3 uses a different key. This allows Transaction 3 to be executed in parallel with the others.

### Complex Parallel and Sequential Operations

1. Trade 1: Swap 100 USDC to DAI (Nonce Key: 1)
2. Trade 2: Swap 100 DAI to USDT (Nonce Key: 1)
3. Trade 3: Swap 1 WETH to USDT (Nonce Key: 2)

Here, Trades 1 and 2 are dependent and use the same nonce key, ensuring sequential execution. Trade 3 is independent and uses a different key, allowing parallel execution.

## Scalability and Performance Considerations

When implementing advanced nonce management systems, it's crucial to consider scalability and performance:

### Web3 vs. Web2 Performance

Web3 transactions are significantly slower than typical Web2 operations:
- Web2: Database calls < 10ms, network calls < 200ms
- Web3: Transactions can take 5+ seconds (at least 2 blocks)

This performance difference can lead to server overload during high traffic periods.

### Solution: Implement a Worker Queue

To manage high transaction volumes:

1. Use a queue system (e.g., Redis, RabbitMQ) to store incoming transaction requests.
2. Implement a pool of worker processes to handle transaction submission and monitoring.
3. Scale workers independently based on transaction volume.

```python
import asyncio
from redis import Redis
from rq import Queue

redis_conn = Redis()
q = Queue(connection=redis_conn)

async def process_transaction_request(tx_data):
 # Validate transaction data
 # Submit to worker queue
 job = q.enqueue(submit_and_monitor_transaction, tx_data)
 return job.id

async def submit_and_monitor_transaction(tx_data):
 # Submit transaction to blockchain
 # Monitor transaction status
 # Update database with results
 pass

# In your API endpoint
@app.post("/submit_transaction")
async def submit_transaction(tx_data: dict):
 job_id = await process_transaction_request(tx_data)
 return {"job_id": job_id}
```

## Additional Features for Production Systems

To create a robust, production-ready system, consider implementing these features:

1. **Transaction Status Tracking**: Implement a system to track the status of all submitted transactions.
2. **Webhooks**: Notify your application or users when transaction states change.
3. **Observability Dashboard**: Create a dashboard to monitor transaction throughput, success rates, and error types.
4. **Manual Intervention Tools**: Develop tools to manually retry or cancel stuck transactions.
5. **Multi-Wallet and Multi-Chain Support**: Extend your nonce management system to handle multiple wallets across various blockchains.

## Simplified Implementation with Openfort Cloud

While the techniques and strategies discussed in this article provide powerful tools for managing nonces and parallelizing transactions, implementing them from scratch can be complex and time-consuming. For developers looking for a ready-to-use solution that incorporates these advanced features, Openfort offers a comprehensive platform called "Cloud".

### Openfort Cloud: Advanced Nonce Management Made Easy

Openfort Cloud is a solution built specifically to manage, broadcast, and optimize blockchain transactions. It incorporates all the improvements and techniques discussed in this article, including:

1. Advanced nonce management with support for parallel transactions
2. Off-chain nonce tracking and synchronization
3. Robust error handling and retry mechanisms
4. Scalable architecture with built-in queue management
5. Multi-wallet and multi-chain support
6. Real-time transaction status tracking and webhooks
7. Observability and debugging tools

By leveraging Openfort Cloud, developers can focus on building their applications without worrying about the intricacies of nonce management and transaction optimization. This can significantly reduce development time and potential errors, while ensuring that your application benefits from best practices in blockchain transaction handling.

Whether you choose to implement these techniques yourself or use a solution like Openfort Cloud, understanding the principles behind advanced nonce management and transaction parallelization is crucial for building efficient and scalable Web3 applications.

The introduction of smart accounts and account abstraction brings a more advanced two-dimensional (2D) nonce system, enabling parallel execution of user operations (UserOps). 

Group 665.svg

Advanced Nonce Management and Transaction Parallelization with Cloud

## EIP-3074, the Predecessor

EIP3074 was introduced to enhance the interaction between EOAs and smart contracts on Ethereum by introducing sponsored transactions.

Sponsored transactions are achieved through the introduction of two new opcodes, `AUTH` and `AUTHCALL`, which allow EOAs to delegate their authority to smart contracts, enabling more flexible and efficient transaction types.

EIP-3074 initially faced increasing security challenges and technical limitations.

Key issues included potential authorization abuses and consequent security vulnerabilities, particularly when dealing with large-scale or high-value transactions.

![3074flow.svg](https://blog-cms.openfort.xyz/uploads/Group_620_3f3efd9dbb.svg)

## Understanding EIP-7702

This proposal introduces a transaction type that EOAs to temporarily operate as smart contract wallets during transactions, reverting to their original state afterward.

EIP-7702 highlights:
- **Account Abstraction**: It transforms how accounts operate.
- **Benefits**: It enhances user experience and security.
- **Scalability**: It supports Ethereum's expansion.

Unlike EIP-3074, EIP-7702 incorporates mechanisms that are designed to be forward-compatible with standards like ERC-4337, supporting more sophisticated AA functionalities without overcomplicating the underlying architecture.

### Core Mechanisms of EIP-7702

Here's what it does:
- User Operation: Allows EOAs to execute smart contract-like actions.
- Gas Sponsorship: Enables third parties to cover transaction costs. For a deeper understanding of how gas sponsorship can enhance user experience, explore our solutions for [gasless transactions](https://www.openfort.xyz/docs/guides/transaction-cloud/send#gas-sponsorship).
- Custom Logic: Supports tailored transaction rules.

To allow EOAs to temporarily act as smart contracts, two main components are used:

**Contract Code**

The `contract_code` field in a transaction specifies the smart contract code that the EOA will execute, temporarily enhancing its capabilities.

This allows the EOA to perform operations that are typically exclusive to smart contracts, like executing multi-step transactions or interactions with other contracts.

Once a transaction completes, the EOA discards the temporary code, reverting to its original, simpler state to ensure security and maintain its standard functionality.

**Signature**

A standard Ethereum signature (using v, r, s) accompanies the transaction to verify the identity of the account holder and authorize the temporary transformation.

The signature secures the transaction against unauthorized actions and confirms the account holder's consent for the temporary enhancement.

## Innovations and potential of EIP-7702

EIP-7702 introduces significant innovations and advancements for AA:

**- Enhanced Flexibility and Security:** By allowing EOAs to act temporarily as smart contracts, EIP-7702 facilitates complex operations while maintaining the security and simplicity of traditional transactions.

**- Reduction in Operational Complexity:** This proposal simplifies transactions by reducing the need for multiple transaction steps and interactions, thereby decreasing gas costs and enhancing UX.

**- Forward Compatibility:** EIP-7702 prepares a better underlying architecture for future developments in account abstraction.

### Final Thoughts

EIP-7702 represents a forward-thinking approach to solving existing challenges in Ethereum's account management and transaction execution.

By addressing the limitations of EIP-3074 and introducing robust mechanisms for account abstraction, the implementation of EIP-7702 in upcoming network upgrades, such as the Prague/Electra upgrade, remains promising.

This new proposal seeks to refine and expand upon the mechanisms introduced in EIP-3074, introducing a new transaction type aimed at enhancing the functionality and security of accounts.

Group 617.svg

From EIP-3074 to EIP-7702 - Reaching full account abstraction

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

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 is 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, which can program their own rules for validating transactions. 

This opens up possibilities for features like [gas sponsorship](https://www.openfort.xyz/docs/guides/dashboard/gas-sponsorship), [transaction batching](https://www.openfort.xyz/docs/guides/transaction-cloud/send), and automated transactions.
- AA uses smart contract and follow some standard like the ERC-4337.
- 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.

## What is 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). 

**[The Openfort solution](https://www.openfort.xyz/docs/guides/wallets).**

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

Practical Synergies between Account Abstraction and MPC

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.

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 transactions** and operations, contingent on player authentication.
- Providing optional **account recovery solutions** to maintain accessibility even in contingencies.

### Signers and Custodians
|  | 👤 Self custody | ⚙️ Self-managed custody. | 🏦 Institutional custody. |
|---|---|---|---|
| Private Key Technology | User-generated and controlled. Typically, keys are generated by the device or software the user controls (e.g., hardware wallet). | User controls the generation but may rely on external, less controlled infrastructure for storage or management (e.g., MPC, DKG, etc.). | Managed by the third party. Keys are typically generated and stored on secure, institutional-grade servers. |
| Private Key Visibility | Full visibility to the user. The user can directly access and view their private keys. | Limited visibility. The user might not directly view the keys but controls the environment in which they are used. | No direct visibility. The private keys are not accessible to the user; instead, they are held by the institution. |
| Private Key Control | Full control by the user. They decide when and how the keys are used. | The user retains control over the use of keys but doesn't manage the full lifecycle or infrastructure. | Limited to no control. The institution manages the use and application of keys. |
| Private Key Recovery | User is responsible for backup and recovery solutions. They must create and manage secure backups of their keys. | Mixed responsibility. The user may need to manage backup solutions, but some support might be available from the service. | Mostly managed by the institution. The institution often provides backup and recovery processes as part of their services. |
| Examples | The most popular are wallets like Ledger, Trezor, MetaMask, etc. | Some examples include Zengo Wallet, Dfns, Fireblocks, Turnkey. | Some examples include Coinbase, BitGo, Bitcoin Suisse AG. |
## Security Implications
### 1. 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.

### 2. 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.

### 3. 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. 

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

To properly evaluate each model, we need to understand the following concepts:

**- 🔑 Private key/seed generation.** Where are the underlying keys managing the assets being generated? Are they generated in a secure, trusted, isolated environment?
**- 📥 Key material export.** Is access to the underlying cryptographic primitives allowed? Can they be exported securely?
**- 🔐 Backup generation.** Can we generate backups for the private keys in a secure, encrypted way?
**- 🔓 Backup verification.** Can backups entirely restore the account in which the assets are being stored?


## Conclusion
Each strategy has its drawbacks. Giving more control to the user includes more responsibility but provides the most power with the least cost. The least amount of control comes at a higher price, yet it includes additional features such as insurance. Sometimes, you always have access to the private key (e.g., self-custody), but you need to handle backups yourself. If backups are not provided, then we need to guarantee that the custodian has enough controls in place to verify these themselves.

As we build Openfort, we're striking a across all these strategies around self-custody in gaming. We believe the best approach is having a flexible ownership model that offers a standardized player experience across the different types of ownership models. At Openfort we advocate for [smart wallets](https://www.openfort.xyz/docs/guides/wallets) as the optimal solution to onbaord people into games. 

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.

Understanding custody models in web3 gaming is an important decision when onboarding users.

Group 289.svg

Custody Models in Web3

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 Wallets

1. Writing down private keys and using public keys to receive bitcoins.
2. From custodial wallets to [self-custody wallets](https://www.openfort.xyz/blog/custody-for-web3-gaming).
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](https://medium.com/lightspeed-venture-partners/fat-protocols-vs-fat-dapps-vs-fat-wallets-4d33ead29130)). 

We believe wallets should act like Google Accounts, enabling access to new applications (like Google Suite 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)](https://www.openfort.xyz/blog/aa-and-mpc-a-practical-approach).

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](https://eips.ethereum.org/EIPS/eip-4337), 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. 

Technical dive: EIP7702 with ERC4337

Technical dive: EIP7702 with ERC4337

Understanding Native Account Abstraction in RIP-7560

Securing the Future: Openfort's SSS Library Audit and Open Source Commitment

Advanced Nonce Management and Transaction Parallelization with Cloud

From EIP-3074 to EIP-7702 - Reaching full account abstraction

Passkeys in the context of Account Abstraction

Practical Synergies between Account Abstraction and MPC

Custody Models in Web3

Modular Wallets: The Key to Scaling New Verticals

Understanding Crypto Wallets

Product

Resources

Company

Openfort blog

Technical dive: EIP7702 with ERC4337

Technical dive: EIP7702 with ERC4337

Understanding Native Account Abstraction in RIP-7560

Securing the Future: Openfort's SSS Library Audit and Open Source Commitment

Advanced Nonce Management and Transaction Parallelization with Cloud

From EIP-3074 to EIP-7702 - Reaching full account abstraction

Passkeys in the context of Account Abstraction

Practical Synergies between Account Abstraction and MPC

Custody Models in Web3

Modular Wallets: The Key to Scaling New Verticals

Understanding Crypto Wallets