Exploring EIP-7702: Part 1

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:

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.

Standards Complementing ERC-7702

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

How to map the adoption of 7702

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, 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