This guide provides a step-by-step process to migrate your React (Wagmi-based) dApp from RainbowKit to [Openfort Kit](https://kit.openfort.xyz/) for wallet connection and modal management.

## 1. Install Openfort Kit

Install the required package and its peer dependencies:

```zsh
yarn add @openfort/openfort-kit
```

> **Note:** Ensure you have compatible versions of `wagmi`, `viem`, `@tanstack/react-query`, and `react` as required by OpenfortKit.


## 2. Swap Wallet Provider

Swapping to openfortkit is very simple! Just replace your RainbowKit provider with OpenfortKit provider.

**From:**
```tsx
import { RainbowKitProvider } from "@rainbow-me/rainbowkit";

// ... your configuration

export default function WalletProvider({ children }) {
  return (
    <WagmiProvider config={config}>
      <QueryClientProvider client={client}>
        <RainbowKitProvider /* Your configuration */ >
          {children}
        </RainbowKitProvider>
      </QueryClientProvider>
    </WagmiProvider>
  );
}
```

**To:**
```tsx
import { OpenfortKitProvider } from "@rainbow-me/rainbowkit";

// ... your configuration

export default function WalletProvider({ children }) {
  return (
    <WagmiProvider config={config}>
      <QueryClientProvider client={client}>
        <OpenfortKitProvider /* Your configuration */ >
          {children}
        </OpenfortKitProvider>
      </QueryClientProvider>
    </WagmiProvider>
  );
}
```


## 3. Configure OpenfortKit

Openfortkit comes with various configuration options, like what auth methods you want to use, the policy to sponsor your transactions and more. 

Create the configuration, and add it to the OpenfortKitProvider as follows:
```ts
const openfortKitOptions = {
  skipEmailVerification: true,
  authProviders: [
    AuthProvider.GUEST,
    AuthProvider.EMAIL,
    AuthProvider.WALLET,
    AuthProvider.GOOGLE,
  ]
};

const walletConfig: OpenfortWalletConfig = {
  createEmbeddedSigner: true,
  embeddedSignerConfiguration: {
    shieldPublishableKey: "Your shield api key",
    recoveryMethod: RecoveryMethod.PASSWORD,
    shieldEncryptionKey: "Your encryption share",
    ethereumProviderPolicyId: "Your sponsor policy",
  }
};

export default function WalletProvider({ children }) {
  return (
    <WagmiProvider config={config}>
      <QueryClientProvider client={client}>
        <OpenfortKitProvider
          publishableKey={"Your publishable key"}
          walletConfig={walletConfig}
          options={openfortKitOptions}
        >
          {children}
        </OpenfortKitProvider>
      </QueryClientProvider>
    </WagmiProvider>
  );
}
```


## 4. Update Modal Usage in Components

Using OpenfortKit hooks the same way you would use RainbowKit's hooks. The full list of hooks can be found [here](https://www.openfort.io/docs/products/kit/react/hooks)

For example, to **open the modal**, with Rainbowkit you would use `useConnectModal`. With openfortkit is you would use `useModal`, as follows:

**RainbowKit:**
```tsx
import { useConnectModal } from "@rainbow-me/rainbowkit";
const { openConnectModal } = useConnectModal();
...
<Button onClick={openConnectModal}>Connect Wallet</Button>
```

**OpenfortKit:**
```tsx
import { useModal } from "@openfort/openfort-kit";
const { setOpen: openConnectModal } = useModal();
...
<Button onClick={openConnectModal}>Connect Wallet</Button>
```


## 5. Handling Disconnect/Logout Logic

If you used `useDisconnect`, replace it with OpenfortKit's `useLogout`, so the openfort user is logged out and disconnected:

**Before:**
```tsx
import { useDisconnect } from "wagmi";
const { disconnect } = useDisconnect();
```

**After:**
```tsx
import { useLogout } from "@openfort/openfort-kit";
const disconnect = useLogout();
```


## 6. Remove RainbowKit Imports and Dependencies

```zsh
yarn remove @rainbow-me/rainbowkit
```

Also, remove all `@rainbow-me/rainbowkit` imports and related code from your project files.


## 7. Test Your Application

- Run your app and verify wallet connection, modal, and logout flows work as expected.
- Check for any remaining RainbowKit usage and update as needed.


## References
- [Openfort Documentation](https://openfort.io/docs)
- [Wagmi Documentation](https://wagmi.sh/)

**Migration complete!**


This guide provides a step-by-step process to migrate your React (Wagmi-based) dApp from RainbowKit to Openfort Kit for wallet connection and modal management.

RainbowKit.png

How to Migrate from RainbowKit


When you're building modern dApps, user onboarding and ongoing interaction are critical. Let's be honest, the traditional Web3 experience – juggling seed phrases, managing gas tokens – can scare off even enthusiastic users. That's where passwordless wallets come in, and you're about to learn how to build one that's both secure and refreshingly simple for your users.

This guide, inspired by Openfort's slick demonstration of [EIP-7702 with ERC-4337](https://7702.openfort.xyz/), will walk you through creating a wallet experience where users interact with the blockchain using familiar WebAuthn credentials (like Passkeys). Think of it: no more "write this down and keep it safe" lectures! But before you jump into the code and start wiring things up, it’s essential to grasp the core components. Getting these concepts clear from the outset will make your development journey smoother and your final product much more robust.

>If you want to check the code directly here is the [repo](https://github.com/openfort-xyz/sample-7702-WebAuthn).

### Key Concepts & Glossary: The Tech You Need to Know

Before you start building, let's break down the essential tech powering this passwordless revolution. Understanding these terms isn't just academic; it's about knowing the tools that will let you deliver a top-tier user experience.

*   **Externally Owned Account (EOA):** This is your starting block – the standard Ethereum account controlled by a private key. While it's the most common account type, we're about to give it some serious upgrades.
*   **EIP-7702:** Think of this as the EOA "empowerment" proposal. It allows an EOA to temporarily grant specific permissions to a smart contract. This is key because it lets your EOA gain smart contract-like abilities without the immediate overhead of deploying a full smart contract wallet for every user.
*   **Delegation Contract:** This is the trusted smart contract your EOA (via EIP-7702) authorizes to act on its behalf. It’s the intermediary that will execute actions based on the EOA’s approved instructions, enabling more complex operations.
*   **ERC-4337 (Account Abstraction):** This is the standard that brings true "Account Abstraction" to Ethereum without needing deep protocol changes. For you, this means unlocking powerful features like gas sponsorship and improved transaction flows, making your dApp far more accessible.
*   **UserOperation (UserOp):** With ERC-4337, users (or their accounts) don't just send plain old transactions. Instead, they submit `UserOperation` objects to a special, alternative mempool. This is how we tap into the advanced features of Account Abstraction.
*   **Bundler:** These are the workhorses of the ERC-4337 ecosystem. Bundlers pick up UserOps, package them efficiently into a single on-chain transaction, and get them executed. They handle the complexity so your users don't have to.
*   **WebAuthn / Passkeys:** This is the heart of the "passwordless" experience. A web standard that lets users authenticate using biometrics (Face ID, Touch ID) or physical security keys. For your users, this means maximum security with minimal friction – a huge win.
*   **RIP-7212 P256 Precompile:** For WebAuthn to be useful on-chain, signatures need to be verifiable. This precompile makes verifying the P256 signatures (common in WebAuthn) efficient and standard on Ethereum, securely linking Passkeys to blockchain accounts.
*   **Paymaster:** An ERC-4337 smart contract that can pay gas fees on behalf of your users. This enables **Sponsored Transactions**, a game-changer for onboarding.
*   **Session Keys:** To avoid "signature fatigue" (users constantly having to approve transactions), you can implement session keys. These are temporary, limited-permission keys that can be authorized for a certain number of actions or time, allowing for smoother, uninterrupted interactions within your dApp.
*   **Batch Transactions:** Another win for user experience, enabled by Account Abstraction. This allows multiple distinct operations (e.g., approve a token and then swap it) to be combined and executed as a single, atomic transaction.
*   **IndexedDB:** A browser-based database. In our context, it's a practical example of where you might securely store non-extractable session keys locally in the user's browser, keeping them handy but safe.


## How It All Clicks: Your Passwordless Architecture Blueprint

So, how do these pieces – EOAs, EIP-7702, ERC-4337, WebAuthn – actually combine to deliver that seamless passwordless flow? It's not just about individual components; it's their smart integration:

Traditional wallets expose private keys to the application layer, creating multiple attack vectors. Traditional wallets expose private keys to the application layer, creating multiple attack vectors. Then, using **EIP-7702**, you'll empower this EOA by allowing it to designate a **Delegation Contract**. This contract becomes a trusted agent, ready to execute operations based on your EOA’s authority.

Next, you'll bring in **WebAuthn (Passkeys)** for authentication. Users will use their familiar device biometrics or security keys, and thanks to the **RIP-7212 P256 Precompile**, these credentials can securely control the EOA via the Delegation Contract.

The **ERC-4337** standard then kicks things into high gear. User intentions become **UserOperations**, processed by **Bundlers**. This is your gateway to features that truly differentiate your dApp:
*   **Sponsored Transactions** (via **Paymasters**): Onboard users without them ever touching gas.
*   **Session Keys**: Let users perform multiple actions within a session without constant signature prompts.
*   **Batch Transactions**: Simplify complex multi-step processes into single clicks.

By thoughtfully combining these technologies, you’re not just building a wallet; you’re crafting a user experience that’s years ahead of the curve. You're setting up a secure, trustworthy, and incredibly intuitive way for users to engage with the decentralized web.

With these foundational concepts in place, you’re well-prepared to tackle the code and bring your passwordless wallet to life. Let's get building!

## Setting Up WebAuthn Authentication

### Creating Your First Passkey

The journey begins by creating a WebAuthn credential that will serve as the primary authentication method for your smart account. This credential is tied to your device and protected by biometric authentication or a PIN.

```javascript
import { Bytes, WebAuthnP256 } from "ox";

// Create a WebAuthn credential using the account address as the user ID
const credential = await WebAuthnP256.createCredential({
  authenticatorSelection: {
    requireResidentKey: false,
    residentKey: "preferred",        // Store credential on device when possible
    userVerification: "required",    // Require biometric/PIN verification
  },
  user: {
    id: Bytes.from(account.address),
    name: `${account.address.slice(0, 6)}...${account.address.slice(-4)}`,
  },
});

// Store the credential ID for future authentication
const credentialId = credential.id;
```

This process prompts the user to authenticate (via Face ID, Touch ID, Windows Hello, etc.) and creates a unique key pair bound to their device. The private key remains in secure hardware, while the public key is returned for smart account initialization.

### Initializing the Smart Account

With the WebAuthn credential created, we can now initialize a smart account that recognizes this passkey as its primary signer:

```javascript
// Prepare the initialization call data
const callData = encodeFunctionData({
  abi: accountABI,
  functionName: "initialize",
  args: [
    {                               
      pubKey: {                         
        x: toHex(x),                   // The WebAuthn public key x coordinate
        y: toHex(y),                   // The WebAuthn public key y coordinate
      },
      eoaAddress: zeroAddress,         // address(0)
      keyType: KEY_TYPE_WEBAUTHN,      // WEBAUTHN key type identifier
    },
    spendTokenInfo,                    // Token spending configuration
    [                                  // Function selectors this key can call
      '0xa9059cbb',                    // transfer(address,uint256)
      '0x40c10f19'                     // mint(address,uint256)
    ],
    messageHash,                       // Verification message hash
    signatureInit,                     // Initial signature for verification
    validUntil,                        // Key expiration timestamp
    nonce + 1n,                        // Account nonce
  ],
});

// Create the user operation with EIP-7702 authorization
const userOperation = await smartAccountClient.prepareUserOperation({
  callData,
  authorization: signedAuthorization,  // EIP-7702 authorization signature
});
```

The EIP-7702 authorization allows an EOA to temporarily act as a smart contract, enabling the initialization process. Once this UserOperation is executed, your smart account is ready for WebAuthn-based transactions.

## Executing Transactions with WebAuthn

### Preparing the Transaction

Let's demonstrate by minting some ERC-20 tokens. The process involves preparing a UserOperation with a placeholder signature, then replacing it with the actual WebAuthn signature:

```javascript
// Encode the mint function call
const data = encodeFunctionData({
  abi: erc20ABI,
  functionName: "mint",
  args: [
    smartAccountClient.account.address,
    parseEther("10"),  // Mint 10 tokens
  ],
});

// Prepare UserOperation with stub signature
const userOperation = await smartAccountClient.prepareUserOperation({
  calls: [
    {
      to: erc20Address,
      data,
    },
  ],
  signature: webAuthnStubSignature,  // Placeholder signature
});
```

### Signing with WebAuthn

Now we generate the actual signature using the WebAuthn credential:

```javascript
// Get the UserOperation hash that needs to be signed
const userOperationHash = getUserOperationHash(userOperation);

// Sign with WebAuthn - this triggers biometric authentication
const webauthnData = await WebAuthnP256.sign({
  challenge: userOperationHash,
  credentialId,                      // The credential we created earlier
  rpId: window.location.hostname,    // Relying party identifier
  userVerification: "required",      // Require user verification
});

// Replace stub signature with the actual WebAuthn signature
userOperation.signature = encodeWebAuthnSignature(webauthnData);

// Send to bundler for execution
await bundlerClient.sendUserOperation(userOperation);
```

The user experiences a familiar biometric prompt (Face ID, fingerprint, etc.), and once authenticated, the transaction is signed and submitted.


>Hint: The stub signature has to be different for P256 and WebAuthn. The actual webauthn signature is significantly different from the P256 signature, so the stub signature has to be different as well.


## Implementing Session Keys for Seamless UX

While WebAuthn provides excellent security, requiring biometric authentication for every transaction can impact user experience. Session keys solve this by creating temporary, limited-privilege keys for routine operations.

### Creating a Session Key

Session keys are also non-extractable P256 keys, but they're created using the WebCrypto API and stored locally:

```javascript
import { WebCryptoP256 } from "ox";

// Generate a new P256 key pair for the session
const keyPair = await WebCryptoP256.createKeyPair();
const publicKey = await WebCryptoP256.getPublicKey({ 
  publicKey: keyPair.publicKey 
});

// Store the key pair securely (e.g., in IndexedDB)
await storeSessionKey(keyPair);
```

### Registering the Session Key

The session key must be registered with the smart account, defining its permissions and validity:

```javascript
const callData = encodeFunctionData({
  abi: accountABI,
  functionName: 'registerSessionKey',
  args: [
    {
      pubKey: {
        x: toHex(publicKey.x),         // The P256 public key x coordinate
        y: toHex(publicKey.y),         // The P256 public key y coordinate
      },
      eoaAddress: zeroAddress,         // address(0)
      keyType: KEY_TYPE_P256,          // P256 key type identifier
    },
    validUntil,                        // Session expiration
    0,                                 // Nonce
    limits,                            // Spending/call limits
    true,                              // Authorized flag
    erc20Address,                      // Contract this key can interact with
    spendTokenInfo,                    // Token spending configuration
    [                                  // Function selectors this key can call
      '0xa9059cbb',                    // transfer(address,uint256)
      '0x40c10f19'                     // mint(address,uint256)
    ],
    ethLimit                           // ETH spending limit
  ]
});

// This registration requires WebAuthn approval
const userOperation = await smartAccountClient.prepareUserOperation({
  callData,
  signature: webAuthnStubSignature,
});

// Sign with WebAuthn (one-time approval for session key)
const webauthnData = await WebAuthnP256.sign({
  challenge: getUserOperationHash(userOperation),
  credentialId,
  rpId: window.location.hostname,
  userVerification: "required",
});
```

>Hint: `Webauthn rpId` is crucial. It binds credentials to a specific domain for strong phishing protection. If you don't provide it, the browser will throw an error.


### Using Session Keys for Transactions

Once registered, session keys can sign transactions without requiring biometric authentication:

```javascript
// Prepare the transaction as before
const userOperation = await smartAccountClient.prepareUserOperation({
  calls: [
    {
      to: erc20Address,
      data: encodeFunctionData({
        abi: erc20ABI,
        functionName: "mint",
        args: [smartAccountClient.account.address, parseEther("10")],
      }),
    },
  ],
  signature: P256StubSignature,        // Different stub for P256 keys
});

// Sign with the session key (no user interaction required)
const { r, s } = await WebCryptoP256.sign({
  privateKey: sessionKey.privateKey,
  payload: getUserOperationHash(userOperation),
});

// Format and attach the signature
userOperation.signature = encodeP256Signature({ r, s });

// Submit the transaction
await bundlerClient.sendUserOperation(userOperation);
```

## Conclusion

WebAuthn with P256 signatures represents a significant leap forward in Web3 user experience and security. By eliminating private key exposure and leveraging familiar authentication methods, we can build smart accounts that are both more secure and more user-friendly than traditional wallets.

This guide, inspired by Openfort's demonstration of EIP-7702 with ERC-4337, will walk you through creating a wallet experience where users interact with the blockchain using familiar WebAuthn credentials (like Passkeys).

passkeys_demo.svg

Building a Passwordless EVM Wallet

After introducing the technical dive on [EIP7702](https://www.openfort.io/blog/eip-7702-with-erc-4337) and the [V1 smart account](https://www.openfort.io/blog/erc7702-part1), we're now ready to introduce the new account. The Openfort delegator account effectively enables EOAs to function like smart contract accounts, unlocking features such as batch calls, transaction sponsorship by third parties (like sequencers or wallet servers), the use of arbitrary signing keys (e.g., WebAuthn, P256), and the implementation of session or scoped keys with specific lifespans and permissions.

## Core Features of Openfort's EIP-7702 Account

Openfort's implementation highlight several key advancements and features, primarily centered around modularity, advanced session key management, and compatibility with existing account abstraction standards.

### Delegation Contracts

![7702_delegator.png](https://blog-cms.openfort.xyz/uploads/7702_delegator_0844925701.png)

>Check the [Openfort delegator contract](https://github.com/openfort-xyz/openfort-7702-delegator)

Openfort’s EIP-7702 solution features a modular delegator contract. This design allows developers to attach various features to an EOA, upgrading it to a smart account. The base delegator account includes functionalities such as access control, initialization, signature verification, and options for both single and batch transaction executions. Developers can add modules for features like session keys and integration with the ERC-4337 account abstraction infrastructure, supporting guardians and account recoverability.

The purpose of this delegation contract was to enable the EOA to authorize WebAuthn public keys for call delegation, allowing a third party (like a sequencer) to execute calls on behalf of the account using a WebAuthn signature.

*   **Secure Initialization**: The account initialization function is executable only once, verifies the initiator, and clears specific storage slots to prevent collisions if the EOA had prior state.
*   **Unique Storage Allocation**: The contract uses a unique storage layout to prevent overwriting pre-existing storage on the EOA.

### Session Key Management with WebAuthn

Openfort supports EOA-based session keys and WebAuthn-based session keys. WebAuthn keys allow users to authenticate or sign messages using biometrics, passkeys, or hardware keys, utilizing the P256 elliptic curve. The user's public key (derived from the WebAuthn credential) is registered as a session key, and transactions can then be executed using this passkey without needing the primary private key for each action. 

Openfort categorizes session keys into:
-   **Master Keys**: WebAuthn or EOA-based, with broad permissions, acting like a primary or secondary owner.
-   **Limited Session Keys**: WebAuthn or EOA-based, operating under strict, predefined policies including active status, validity period, whitelisted contracts, allowed function selectors, and spending limits for ETH and tokens.

An interesting flow you can unlock is the ability to create an WOA controlled by a WebAuthn key (e.g., Passkey), with signatures verified using the RIP-7212 P256 Precompile. The process involved generating an EOA, prompting the user for a WebAuthn key, signing an EIP-7702 authorization to designate the Delegation contract, and then sending an EIP-7702 transaction to authorize the WebAuthn public key on the account. Notably, in this flow, the EOA's original private key was disposed of after the initial authorization.

Some of the security considerations are: 

*   **Access Control**: Only the owner, a registered session key, or the ERC-4337 entry point can execute transactions.
*   **Session Key Security**: For WebAuthn session keys, a `useChallenges` mapping acts as a nonce to prevent replay attacks. The system validates policies for limited session keys.
*   **Re-entrancy Guard**: Protects against re-entrancy attacks.


## Transaction Batching with EIP-7702 Accounts

One of the most compelling advantages EIP-7702 brings to Externally Owned Accounts (EOAs) is the ability to perform transaction batching. By delegating its functionality to a smart contract, an EOA can execute multiple operations atomically within a single transaction. This not only streamlines user experience by, for example, combining an `approve` action with a subsequent `transferFrom` or contract interaction, but also enhances efficiency and can offer a more predictable execution environment.

### How Transaction Batching Works

At its core, transaction batching allows a user to bundle several distinct actions-each typically defined by a target address, a value (ETH to send), and data (the function call)-into one overarching transaction. When this EIP-7702 transaction is processed, the authorized delegate contract executes these bundled calls sequentially. If any one of the batched operations fails, the entire set of operations can be reverted (depending on the batch execution logic), ensuring atomicity.

### Implementing Batching: The Role of the Delegate

The design of the EIP-7702 delegate contract is crucial for enabling batching.
*   **Direct Implementation:** The most secure and straightforward approach is for the batching logic to be implemented directly within the delegate contract itself. This gives the EOA, through its delegate, full control over how multiple calls are processed, ensuring that `msg.sender` remains consistent as the EOA's address for each internal call. This approach avoids the complexities and potential security risks associated with using external helper contracts via `DELEGATECALL` for batching, such as those historically seen with generic `MultiSend` contracts, which could inadvertently grant unintended permissions if not carefully managed.
*   **Standardized Interfaces:** To promote interoperability and ease of integration for dapps, delegate contracts can implement standardized batching interfaces.
    *   **ERC-7821 (Simple Batch Calls):** This standard offers a straightforward way to define batch calls, focusing on an array of destinations, values, and calldata. Its design intentionally omits support for `DELEGATECALL` within batched operations, which simplifies validation and enhances security, making it a robust option for common batching needs. An EIP-7702 delegate can easily expose an ERC-7821 compliant execution function.

### Batching in the ERC-4337 Ecosystem

For EIP-7702 accounts designed to be compatible with ERC-4337 (Account Abstraction), batching is a native concept.
*   **UserOperations with Multiple Calls:** Within the ERC-4337 framework, a `UserOperation` (the user's transaction intent) can contain `callData` that instructs the smart account (which the EOA effectively becomes via EIP-7702 delegation) to execute multiple actions. The delegate contract, acting as the smart account logic, would parse this `callData` and perform the batched executions. This allows EIP-7702 empowered EOAs to leverage the full suite of ERC-4337 features, including its batching capabilities, seamlessly.

## Transaction Sponsoring for EIP-7702 Accounts

Transaction sponsoring, or gas abstraction, is another transformative feature that EIP-7702 helps bring to EOAs. By allowing a third party to cover the gas costs of a transaction, it significantly lowers the barrier to entry for new users (who may not hold native tokens) and vastly improves the user experience by making transactions feel "gasless."

### Evolution of Sponsorship

*   **Early Approaches (Meta-Transactions):** The concept of transaction sponsorship isn't new. Before widespread account abstraction, "meta-transactions" were a common pattern. Users would sign a message off-chain, and a third-party relayer would submit this message as part of an on-chain transaction, paying the gas. Standards like **ERC-2771** emerged to define trusted forwarder contracts, allowing destination contracts to correctly identify the original signer rather than the relayer. An EIP-7702 delegate could be designed to interact with such systems, allowing the EOA to benefit from established meta-transaction infrastructure.

### ERC-4337: The Standard for Decentralized Sponsorship

The most robust and standardized way to achieve transaction sponsorship for EIP-7702 accounts today is through compatibility with ERC-4337. Once an EOA delegates its operations via EIP-7702 to become a smart account, it can tap into the ERC-4337 ecosystem:
*   **Paymasters:** The cornerstone of ERC-4337 sponsorship is the **Paymaster** contract. This is a specialized smart contract that agrees to pay for a user's `UserOperation` gas fees, provided certain conditions are met. These conditions can be highly flexible: a dapp might sponsor all transactions for its users, users might pay with ERC-20 tokens, or sponsorship could be offered for specific actions.
*   **Decentralized Flow:** The EIP-7702 account (acting as a smart account) crafts a `UserOperation`. If a Paymaster is willing to cover the fees, it signs the `UserOperation`. A **Bundler** then picks up this UserOperation from an alternative mempool and includes it in a transaction on-chain, with the EntryPoint contract orchestrating the execution and gas payment via the Paymaster. This system offers a decentralized and censorship-resistant pathway for gas sponsorship.

## Horizon: The Rise of Intents

Looking ahead, the concept of "Intents" is gaining traction. Intents represent a higher-level abstraction of user desires (e.g., "I want to swap X token for Y token at the best possible rate") rather than specific, low-level transactions.
*   **ERC-7683 (Cross-Chain Intents):** This ERC, for example, explores how intents can be structured, particularly for cross-chain scenarios. Fulfilling an intent often involves multiple steps and potentially complex routing, where sponsorship can be seamlessly integrated by "solvers" who execute the intent on behalf of the user. While still an evolving area, EIP-7702 equipped accounts are well-positioned to leverage intent-based systems as they mature, further simplifying user interactions and abstracting complexities like gas payments.

By leveraging EIP-7702, EOAs can access these sophisticated batching and sponsorship mechanisms, fundamentally upgrading their capabilities and paving the way for a more intuitive and accessible Web3 experience.


Openfort has developed a new delegator contract leveraging EIP-7702, aimed at augmenting Externally Owned Accounts (EOAs) with smart contract capabilities. 

7702-part2.svg

What does the Openfort Delegator Account (7702) include?

It’s been two years since we at Openfort set out to build one of the most advanced smart contract wallets available at the time. Back then, account abstraction was gaining momentum, and the Ethereum community was abuzz with possibilities far beyond the constraints of Externally Owned Accounts (EOAs). We saw a simple but powerful vision: transform wallet tech to unlock truly seamless UX for dApps, games, and onchain products.

**EOAs were holding the space back:** They forced users to grapple with private keys, clunky seed phrases, and confusing flows. If crypto was to scale, wallets would need to become smarter, more flexible, and more secure. That’s why we built Openfort Accounts.

## What We Built: The Openfort V1 Account

At the core of our effort was ERC‑4337 compatibility. By embracing the emerging “userOp” paradigm, we could leverage alternative mempools, batched transactions, and gas sponsorship to give projects turnkey meta‑transactions. But we didn’t stop there. From day one, each Openfort account was “supercharged” with:

* **Batch Transactions**: Allowing multiple calls in a single atomic operation.
* **Gas Sponsorship**: Letting deployers or dApps underwrite gas fees on behalf of end users.
* **Session Keys**: Ephemeral sub‑keys that could be granted limited, time‑bound authority.
* **Social Recovery**: Pre‑defined guardians to help users recover lost access.

## A Robust, Upgradeable Architecture

Building this wallet “felt like hardware.” We invested heavily in smart‑contract audits, formal verification, and gas‑cost optimizations-because, like firmware in a device, once deployed, our contracts needed to work flawlessly for the long haul. To support forward‑compatibility, we implemented:

* **CREATE2 Factories (EIP‑1014)** for deterministic, counterfactual address generation.

* **Proxy Patterns (ERC‑1967 & ERC‑1822)** to enable seamless contract upgrades.

## Standard Interfaces Implemented in V1

Instead of a bulleted list, here's a table summarizing the interfaces supported by Openfort V1 Accounts:

| Standard | Description |
| :---- | :---- |
| ERC-20 / 721 / 777/ 1155 | Token handling |
| ERC-173 | Ownership |
| EIP-712 & EIP-5267 | Typed data signing |
| ERC-1271 | On-chain signature validation (`isValidSignature`) |
| ERC-6551 | Token Bound Accounts |

Since launch, we’ve never had to patch the core logic-because the proxy‑upgrade mechanism means the implementation can always evolve without breaking existing addresses. In other words, “it just works.”

## Learning from Limitations: Setting the Stage for V2

Over the past two years, the industry has matured. The modularity narrative-pioneered by SAFE’s module system and formalized in ERC‑6900 and ERC‑7683-enabled accounts to mix-and-match capabilities (WebAuthn passkeys, gas paymasters, signature modules) like Lego bricks.

At Openfort, we began to notice a few areas for enhancement in V1:

1. **Pre‑Deployment Signing**: Allowing users to sign meta‑transactions before their smart account exists on‑chain.
2. **On‑Chain Session Key Storage**: Eliminating reliance on external databases or local storage.
3. **Customizable Guardians**: Letting owners choose their own recovery guardians.
4. **WebAuthn as Owner**: Anchoring account ownership in passkeys/biometrics.
5. **Built‑in Multisig**: Native multi‑signature policies without external contracts.

These learnings drove us to explore next‑generation standards-chief among them, EIP‑7702-to leap beyond these V1 constraints.

## Why ERC-7702? Why Now?

If you look at where wallets are headed, it’s not just about sending tokens-it’s about becoming **the digital passport**: seamless authentication, secure payments, and smooth recovery, without the old headaches.

**ERC-7702** (and its ecosystem) is the next giant leap. It introduces a new transaction type that lets you set account code on an EOA, effectively retrofitting any regular address into a smart account-**without breaking compatibility**. Refer to our analysis on [7702 with 4337](https://www.openfort.io/blog/eip-7702-with-erc-4337).

## Standards Complementing ERC-7702

Here's a table outlining the standards working in concert with EIP-7702 to enhance wallet functionality:

| Standard | Description |
| :---- | :---- |
| EIP-7702 | Enabling EOAs to temporarily become smart contracts, adding flexibility without permanent changes. |
| RIP-7212 | Introducing secp256r1 signature verification via a precompiled contract, supporting passkeys for secure authentication. |
| ERC-7677 | Facilitating communication between apps and wallets about paymaster services. |
| EIP-6963 | Standardizing wallet provider discovery through window events. |
| EIP-5792 | Enabling batch processing of onchain calls with status tracking. |
| ERC-6492 | Allowing signature verification for undeployed smart contracts. |
| Transaction Simulation | Preventing blind signing by letting users preview transactions. |

## How to map the adoption of 7702

![decision_tree_7702.jpg](https://strapi-oube.onrender.com/uploads/decision_tree_7702_f3ee92b585.jpg)

Navigate the transition, referencing the ecosystem diagram:

* **Standalone Wallets**: Some will fully embrace ERC-7702, others will require users to opt-in, and some will wait and see. Security and adoption will be key drivers.

* **Embedded Wallets** (built into dApps): The fastest adopters. Dapps can leverage 7702 for seamless onboarding, session keys, and gasless transactions.

  * *Open apps (e.g., Uniswap, AAVE)*: These will detect wallet capabilities (via `wallet_getCapabilities`). If a feature like ERC-7702 is required (e.g., for an AI trading agent), the dapp may refuse to function without it; if optional (e.g., in a Web3 game), it can revert to EOA mode.

  * *Closed apps (e.g., Gamp, Beam)*: These can choose between a “smart EOA” (interoperable and flexible) or a regular smart account (offering passkeys and key rotation but tied to specific infrastructure).

Over time, a **virtuous cycle** is likely: as more users experience next-gen UX in leading apps, demand will push all wallets and Apps to embrace ERC-7702, standardizing the “crypto-power account” experience.

## Simplifying Adoption: Openfort's Role

Openfort's move towards V2, centered on EIP-7702, directly addresses key friction points in Web3 adoption. This simplification stems from:

* **Reduced Smart Contract Overhead:** By leveraging the native EOA structure with EIP-7702's temporary smart account capabilities, Openfort minimizes the need for complex smart contract deployments for basic functionalities. This translates to lower gas costs for users, particularly during onboarding.

* **Enhanced Compatibility:** EIP-7702's design ensures backward compatibility with existing EOA infrastructure. This allows Openfort to seamlessly integrate with a wider range of dApps and services, reducing fragmentation and improving the user experience. As the resources highlight, EIP-7702 complements ERC-4337, enabling Openfort accounts to leverage standardized relayers and gas sponsorship modules.

* **Streamlined User Experience:** Features like passkey integration (via RIP-7212) and transaction simulation reduce the cognitive load on users. Openfort is making Web3 interactions more intuitive and secure, aligning with the "digital passport" vision.

* **Developer Focus:** By providing a modular and extensible account architecture, Openfort empowers developers to build customized wallet solutions tailored to their specific needs. This reduces development time and complexity, fostering innovation in the Web3 ecosystem.

We see EIP-7702 as the key to unlocking a more accessible and user-friendly Web3. The Openfort V2 account architecture is designed to abstract away the complexities of blockchain technology, allowing users to focus on the value and utility of decentralized applications.

## Looking Forward

Openfort’s next chapter is about **embracing these new standards**, building accounts that not only meet today’s best practices but anticipate tomorrow’s user needs. ERC-7702 will be a cornerstone of this journey. In the next article, we’ll go deep into our new account’s architecture, the features it unlocks, and how developers and users can benefit.

**Next Up:**

In [Part 2](https://www.openfort.io/blog/erc7702-part2), we break down the technical details of our 7702-compatible account, showcase new features, and explore what’s possible for developers, users, and the next generation of Apps.

### FAQs

| Resource                                                      | Description                                                                                                                                                                                                                                                                                                    |
| :------------------------------------------------------------ | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| What is EIP-7702? | EIP-7702 is a proposal that allows EOAs to become smart accounts. It is going live in the Pectra hard fork on Ethereum Mainnet on May 7.                                                                                                |
| [ERC-4337 vs EIP-7702](https://www.openfort.io/blog/eip-7702-with-erc-4337) | EIP-7702 allows for a way for EOAs to become smart accounts, while ERC-4337 creates a standard for smart accounts to plug into a standardized set of relayers and gas sponsorship modules (paymasters).                                                                                                    |
| Openfort's EIP-7702 Support                                    | Openfort supports EIP-7702 by allowing an eip7702Auth object to be included in eth\_sendUserOperation and eth\_estimateUserOperationGas requests. You can read more about how to use it on the relevant reference pages for eth\_sendUserOperation and eth\_estimateUserOperationGas.                         |
| EOA to Smart Account Transition                               | By submitting a set code transaction (transaction type 4) that includes an authorization\_list, an EOA can transition to a smart account under EIP-7702.                                                                                                                                                 |
| EIP-7702 Frontrunning Prevention                             | The smart account factory is able to make the check require(msg.sender == entryPoint.senderCreator()); to ensure only the EntryPoint's senderCreator is calling it.  In addition, the userOpHash now also depends on the delegate address so users also sign over the 7702Auth object.                       |
| Chain Agnostic Authorization                                  | As per the spec, by signing over a chain ID of 0, it is possible to make an authorization tuple that is valid for all chains and can be applied on all chains that support EIP-7702. With this, it is possible to generate an ephemeral private key, sign over the 7702Auth object with it, and discard it. |

Learn about EIP-7702, a next ethereum wallet upgrade for secure, flexible smart contract wallet usage

7702-part1.svg

Exploring EIP-7702: Part 1

Ethereum is on the verge of a significant evolution with the upcoming implementation of EIP-7702, a proposal that will fundamentally transform how Externally Owned Accounts (EOAs) function on the network. Expected to launch as part of the Pectra upgrade in early 2025, this enhancement represents a critical step toward Ethereum's vision of full account abstraction by enabling EOAs to leverage smart contract functionality directly. This technical deep dive explores the mechanisms, implications, and integration possibilities of EIP-7702, with special attention to its compatibility with the ERC-4337 standard.

## The Genesis and Purpose of EIP-7702

EIP-7702, proposed by Ethereum co-founder Vitalik Buterin and the co-authors of EIP-3074 in May 2024, introduces a new transaction type that allows EOAs to execute smart contract code directly from their addresses. This proposal emerged as an alternative to the [controversial EIP-3074](https://www.openfort.xyz/blog/4337-and-3074), aiming to address forward-compatibility concerns while providing a more cohesive path toward account abstraction.

The fundamental concept behind EIP-7702 is straightforward but revolutionary: it enables any EOA to temporarily or persistently adopt the functionality of an existing smart contract. As described in the official EIP documentation, it "gives superpowers to EOAs" by allowing them to "set its code based on any existing smart contract." This represents a significant departure from the traditional Ethereum account model, where EOAs and smart contracts have maintained strictly separated capabilities.

## Technical Architecture and Mechanism

At its core, EIP-7702 introduces a new transaction type (0x04), commonly referred to as the "set code" transaction. This transaction type includes a novel field called the "authorization_list," which contains the necessary signatures and data to enable an EOA to delegate to a smart contract implementation.

The transaction payload structure follows this format:
```
rlp([chain_id, nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_limit, destination, value, data, access_list, authorization_list, signature_y_parity, signature_r, signature_s])
```

The authorization_list consists of tuples containing:
```
authorization_list = [[chain_id, address, nonce, y_parity, r, s], ...]
```

Each tuple represents a signature authorizing the EOA to adopt the code from the specified smart contract address. The signature is created by signing the keccak256 hash of these components, ensuring the integrity and authenticity of the upgrade request.

When an EOA owner wants to leverage smart contract functionality, they sign an authorization designating a specific smart contract address as their implementation. This authorization, verified through the signature, allows the EOA to execute code from that contract while maintaining its original identity and state. The code designation persists until replaced by another authorization, giving the EOA continuous access to smart contract capabilities.

At the bytecode level, the implementation involves a special prefix `(0xef0100)` followed by the 20-byte address of the implementation contract. This creates a delegatecall proxy that points to the designated contract, allowing the EOA to execute that contract's code in its own context.

## Key Features and Capabilities

EIP-7702 unlocks several powerful capabilities for EOAs that were previously exclusive to smart contract accounts:

### Transaction Batching

Perhaps the most immediate benefit is the ability to bundle multiple operations into a single atomic transaction. For example, a common DeFi workflow involving an ERC-20 approval followed by a token swap can be executed in one transaction instead of two separate ones. Advanced batching scenarios can even incorporate dependencies, where the output of the first operation serves as input to [subsequent actions](https://viem.sh/docs/eip7702).

### Gas Sponsorship

EIP-7702 enables sponsored transactions, where one account can pay for another account's gas fees. This feature significantly enhances user experience by removing the requirement for users to hold native ETH for transaction fees. Instead, fees could be paid in ERC-20 tokens or sponsored by application operators seeking to reduce friction for their users.

### Permission Management

The proposal introduces sophisticated permission management capabilities, allowing EOA owners to implement privilege de-escalation through subkeys with specific permissions. For instance, users could create limited-access keys that can only spend certain tokens, interact with specific applications, or utilize a restricted percentage of the account balance.

### Cross-Chain Compatibility

EIP-7702 supports cross-chain authorizations, where a signature with `chain_id` set to 0 is valid across all EVM chains. This feature simplifies the user experience across multiple networks and reduces the complexity of managing different account configurations per chain.

### Flexibility and Extensibility

The proposal offers considerable flexibility, allowing users and wallet providers to choose implementation contracts based on their specific needs. While most wallet implementations would likely implement sensible restrictions, the standard itself remains open to various implementations and innovations.

## EIP-7702 and ERC-4337 Integration

A critical aspect of EIP-7702 is its complementary relationship with ERC-4337, the account abstraction standard implemented in 2023. Rather than competing with ERC-4337, EIP-7702 enhances it by providing a bridge that allows existing EOAs to [leverage ERC-4337](https://github.com/openfort-xyz/openfort-7702-cli)'s features without creating new accounts.

### Complementary Standards

ERC-4337 serves as the foundational framework for creating Smart Accounts with features like transaction batching, account recovery, and gas sponsorship. It provides a standardized approach to account abstraction without requiring changes to the Ethereum protocol. However, ERC-4337 primarily targets new accounts created as smart contracts.

EIP-7702, on the other hand, addresses the limitations of existing EOAs by enabling them to adopt smart contract functionality This means users can maintain their original addresses while gaining the benefits of account abstraction, eliminating the need to transfer assets to a new smart contract account.

### Technical Integration

When an EOA is upgraded using EIP-7702, it can point to a smart contract implementation that is ERC-4337 compatible. This [creates a workflow](https://www.youtube.com/watch?v=9vbpdfudQwk) where:

1. A 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

This integration allows existing wallets and infrastructure built around ERC-4337 to work seamlessly with EOAs upgraded through [EIP-7702](https://eip7702.io/). Wallet providers can implement both standards simultaneously, giving users the benefits of account abstraction without requiring them to create new accounts or transfer assets.

### Practical Implementation Examples

Several projects are already developing implementations that combine EIP-7702 with ERC-4337. For example, Openfort has created a proof of concept demonstrating how the two standards can work together. These implementations typically involve creating an ERC-4337 compatible smart contract that can be designated as the implementation for an EOA through EIP-7702.

The integration is particularly valuable for existing wallet providers looking to add account abstraction features without disrupting their users' experience. Ambire Wallet, for instance, already supports ERC-4337 and plans to implement EIP-7702 once it becomes part of the Ethereum protocol.

## Implementation Considerations and Challenges

While EIP-7702 offers significant benefits, implementers should be aware of several technical considerations:

### Storage Collisions

When an EOA switches between different smart contract implementations, there's a risk of storage collision where different implementations might use the same storage slots for different purposes. [EIP-7201 (Namespaced Storage Layout)](https://eips.ethereum.org/EIPS/eip-7201) has been proposed to address this issue by introducing a standard way of organizing contract storage using unique namespaces for each module or component.

### Security Implications

The persistent nature of the upgrade means that a malicious EIP-7702 signature could potentially compromise an account until it's replaced with a new authorization. Wallet providers will need to implement strict security measures around EIP-7702 signatures, potentially limiting them to trusted implementation contracts and providing clear user interfaces for managing these authorizations.

### Compatibility with Existing Smart Contracts

Some existing smart contracts rely on checking whether an address is an EOA (often using `tx.origin == msg.sender`). These contracts might behave unexpectedly with upgraded EOAs, requiring developers to update their contract logic to account for EIP-7702 upgraded accounts.

### Gas Costs and Network Load

If a large number of EOAs frequently change their implementation, it could lead to increased network load and higher gas costs. Implementations should encourage the use of modular smart account implementations that reduce the need for frequent upgrades.

## Future Implications and Roadmap

EIP-7702 represents a significant step in Ethereum's journey toward complete account abstraction, but it's important to understand its place in the broader roadmap:

1. The proposal is expected to be included in the Pectra Hardfork, currently scheduled for early 2025.

2. It serves as a transition step toward Ethereum's long-term goal of transforming every EOA into a smart account.

3. While EIP-7702 brings smart contract functionality to EOAs, the private key still holds full authority to sign transactions.

4. [Complete account abstraction](https://www.openfort.xyz/blog/understanding-native-account-abstraction-in-rip-7560) will require further changes to Ethereum, such as potentially disabling the private key and introducing additional transaction types.

5. The standard prepares for an "endgame" scenario where all EOAs transition to [smart contract wallets](https://www.openfort.xyz/blog/understanding-crypto-wallets), potentially driven by advances in cryptography and quantum computing challenges.

## Conclusion

EIP-7702 represents a watershed moment in Ethereum's evolution, bridging the long-standing divide between EOAs and smart contracts. By enabling EOAs to execute smart contract code, it paves the way for enhanced user experiences through features like transaction batching, gas sponsorship, and sophisticated permission management.

The proposal's compatibility with ERC-4337 makes it particularly valuable, allowing existing accounts to benefit from account abstraction without the friction of creating new addresses or transferring assets. This complementary relationship between the two standards demonstrates Ethereum's thoughtful approach to evolving its account model while maintaining backward compatibility.

Upgrade Ethereum EOAs to smart EOAs and understand extra functionality with ERC-4337 compatibility accounts. 

EIP7702.svg

EIP-7702 Deep Dive: Transforming Smart EOAs 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.io/docs/products/embedded-wallet/javascript/signer/recovery) and our [security approach](https://www.openfort.io/docs/development/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.

Discover how Openfort's Shamir’s Secret Sharing (SSS) cryptography library passed audit testing to ensure a more secure wallet infrastructure

Audit Thumbnail Final-min.jpg

Shamir Secret Sharing Library Audited


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.

See how Openfort’s 2D nonce model helps developers execute multiple blockchain transactions in parallel without compromising order or finality

Group 665.svg

2D Nonce: Transaction Parallelization

## 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:
- Batch transactions: 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.io/docs/products/embedded-wallet/javascript/smart-wallet/send).
- 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.

Explore EIP-7702, the innovative upgrade refining EIP-3074. Uncover how temporary smart contract roles enhance Ethereum security and simplify transactions.

Group 617.svg

EIP-3074 to EIP-7702: Advancing Ethereum 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 develop wallets. 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.io/docs/development/gas-sponsorship), transaction batching, 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.  <br/> (2) No cost to end users because MPC is off-chain. <br/>(3) Neutral to every chain.                                                  | (1) On-chain  <br/>(2) Ability to do atomic transactions (combine multiple actions into one transaction). <br/>(3) Ability to do gasless transactions via pre-funding.                                                                                                                                                   | (1) Combines the benefits of off-chain cryptography and on-chain transactions. <br/>(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. <br/>(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.  <br/>(2) AA implementations are different on a per chain per VM basis. This will hopefully change as things are standardized. <br/>(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). 

**Start building with Invisble wallets [MPC+AA](https://www.openfort.io/docs/products/embedded-wallet/javascript).**


Explore the real-world benefits of account abstraction and multiparty computation (MPC) in delivering secure and scalable crypto applications

Group 305.svg

AA and MPC: A Practical Approach to Security

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 your project, the chosen security model can have far-reaching implications for both users 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 users to export and recover their keys is another cornerstone of wallet security in gaming. End users need assurance that they can export their private keys, ensuring control over their assets regardless of the app'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. App developers must prioritize these features to support their users’ asset security.

### 3. Service Provider Continuity
The reliability of a signer service provider is critical. If the provider faces downtime, what happens to the users? Can they still sign transactions and access their assets? What happens if the wallet disappears? Is the solution open-source?

## Criteria Selection
![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. 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.io/docs/products/embedded-wallet/javascript) as the optimal solution to onbaord people onchain. 

Understanding custody models in crypto is an important decision when creating wallets and executing transactions. 

Group 289.svg

Custody and Wallets: How to understand the Custody of Assets

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.


Discover how modular wallet architecture transforms crypto wallets into scalable vertical solutions for diverse applications. 

Group 296.svg

Modular Wallets: Enabling Vertical Wallets at Scale

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://blog-cms.openfort.xyz/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).


Discover how crypto wallets evolve from speculation tools to user-friendly, multi-functional solutions. Embrace innovation and unlock blockchain potential.

How to Migrate from RainbowKit

How to Migrate from RainbowKit

Building a Passwordless EVM Wallet

What does the Openfort Delegator Account (7702) include?

Exploring EIP-7702: Part 1

EIP-7702 Deep Dive: Transforming Smart EOAs with ERC4337

Understanding Native Account Abstraction in RIP-7560

Shamir Secret Sharing Library Audited

2D Nonce: Transaction Parallelization

EIP-3074 to EIP-7702: Advancing Ethereum Account Abstraction

Passkeys in the context of Account Abstraction

AA and MPC: A Practical Approach to Security

Custody and Wallets: How to understand the Custody of Assets

Modular Wallets: Enabling Vertical Wallets at Scale

Understanding Crypto Wallets: Evolution & Future Trends

Product

Industries

Resources

Company

Openfort blog

How to Migrate from RainbowKit

How to Migrate from RainbowKit

Building a Passwordless EVM Wallet

What does the Openfort Delegator Account (7702) include?

Exploring EIP-7702: Part 1

EIP-7702 Deep Dive: Transforming Smart EOAs with ERC4337

Understanding Native Account Abstraction in RIP-7560

Shamir Secret Sharing Library Audited

2D Nonce: Transaction Parallelization

EIP-3074 to EIP-7702: Advancing Ethereum Account Abstraction

Passkeys in the context of Account Abstraction

AA and MPC: A Practical Approach to Security

Custody and Wallets: How to understand the Custody of Assets

Modular Wallets: Enabling Vertical Wallets at Scale

Understanding Crypto Wallets: Evolution & Future Trends