Reflecting on Two Years of Openfort Smart Accounts: Supporting EIP‑7702

8 min read

Reflecting on Two Years of Openfort Smart Accounts: Supporting EIP‑7702

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:

StandardDescription
ERC-20 / 721 / 777/ 1155Token handling
ERC-173Ownership
EIP-712 & EIP-5267Typed data signing
ERC-1271On-chain signature validation (isValidSignature)
ERC-6551Token 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.

Standards Complementing ERC-7702

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

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

How to map the adoption of 7702

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

ResourceDescription
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-7702EIP-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 SupportOpenfort 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 TransitionBy 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 PreventionThe 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 AuthorizationAs 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.
Share this article