Skip to main content

ERC-5792 and EIP-7702: wallet communication

Early success, slow growth​

In May 2025, the Pectra hardfork went live. One of the most eagerly awaited changes was the introduction of EIP-7702, which allowed EOAs to set code in their account. This would allow any account on Ethereum to benefit from the UX improvements such as batching, gas sponsorship and sub-keys. At the same time there was a concerted community push behind ERC-5792, which extended the standard app-wallet interface to allow apps to benefit from these new account features, via wallet_sendCalls and wallet_getCapabilities . Multiple high-profile incumbent teams such as Metamask, Uniswap, Walletconnect and Privy were ready on day one, most rollups and EVM chains were quick to add EIP-7702 support, and there was hope that soon there would be broad adoption, for the benefit of all Ethereum’s users.

But that didn’t happen. Multiple apps and wallets added support for ERC-5792, and adoption of EIP-7702 has continued to increase across chains, but as of February 2026, the UX on Ethereum still mostly feels the same as it did a year ago.

There is a temptation to blame awareness, that it’s just that wallet and app developers are not aware of these new capabilities. But these changes received significant airtime in the community, with specific outreach to high-profile teams who haven’t yet adopted these standards.

Another reason might be inertia, that developers simply haven’t got around to it yet, or don’t want to. But that doesn’t stand up to scrutiny - we should assume that wallets and apps are rational actors, who would implement things if they were sufficiently impactful.

With that lens, why have these standards not been more broadly adopted?

Multistakeholder chicken and egg​

One of the initial challenges is that 5792 is only useful for apps to implement if wallets support it, and similarly, wallets will only be interested if sufficient apps are actually going to be sending them batch calls and enquiring about other capabilities. We have this chicken and egg situation where, without sufficiently broad support from both sides, the 5792 standard is less useful.

This should be mitigated on the app side by early Metamask support, given that Metamask is still one of the leading wallets. But a lack of an overall adoption could still be a hindrance for further adoption, at this stage.

This is certainly a contributing factor, but it feels like a relatively unsatisfactory root cause, so it's worth further considering why apps and wallets haven't implemented these standards.

If it ain’t broke, don’t fix it​

In some cases, enterprising applications have already solved the user experience problem using existing tools.

This can be done via off-chain signatures, for example Polymarket's hybrid CLOB model signs orders off-chain while an operator handles settlement, Ethena's minting and redemption flow works through EIP-712 signed messages and Uniswap has Permit2 support which users may already have approved.

Others have implemented contracts which provide batching capabilities, for example Pendle routes multiple operations (wrapping, minting, liquidity provision) through its PendleRouter and PendleMulticallV2, grouping them into a single transaction. In these cases, the upside of sendCalls is relatively limited - there is little benefit to adopting the standard. Apps solved the problem for themselves.

Apps are embedding wallets​

The extension of that trend is the rise of embedded wallets. Privy, Magic, and Coinbase Smart Wallet allow applications to control the user’s full experience. Since the application provides the wallet, no communication standard is needed, so there is no need for ERC-5792. Embedded wallets do support EIP-7702, but the overall user benefit is smaller.

Almost all new consumer-facing apps today leverage embedded wallets, with external wallets becoming a secondary consideration.

Wallets are embedding apps​

At the same time, wallets are increasingly focused on internalising app functionality, from in-wallet swaps, to perps, launchpads and prediction markets. This allows wallets to give their users a more streamlined user experience (compared to the conventional “Connect Wallet” approach), while also giving wallets meaningful monetisation opportunities (as they take fees on swaps etc).

The UX is not the bottleneck​

As well as these cases, there are also situations where there is just not that much benefit to implementing these new standards. This could be for apps where the audience is highly crypto native (who have ETH to pay for transactions, who are used to approvals, for example). It could also be apps where there is just a single transaction per action, so there isn’t a benefit to batching. And it could also be that there are more substantive “user value” issues which are the top priorities for the app, above and beyond its usability.

👉 Arguably this is another iteration of “if it ain’t broke, don’t fix it”

A highly flexible gadget​

Finally, it is worth reflecting on the design of EIP-7702. While elegant in many ways, it pushed quite a significant burden onto wallet developers, who were responsible for deciding on a user’s delegated smart account. This inevitably led to each wallet developer creating their own specific implementation, based on their priorities and preferences - while some wallets simply chose not to participate. EIP-7702 is incredibly flexible, in that you can delegate to a smart account that does anything, but you get nothing “out of the box”, and it is possible that this complete flexibility was a hindrance in solving the majority of mainstream user problems (while giving criminal users a new tool for their armoury).

What does it all mean?​

Given all that, how should we assess EIP-7702 and ERC-5792? While both are still not broadly adopted by developers, they are undeniably useful additions to the Ethereum developer’s toolbox, they have been leveraged to create more streamlined user experiences by a variety of apps and wallets. The tools are in place to facilitate adoption; there are no obvious gaps or blockers. We can expect to see continued growth in their usage

But these standards did not “save Ethereum”.

What can we learn?

  • Developers on Ethereum today have the tools available to create good user experiences on an individual chain.
  • Developers need to see a real benefit to adopt new things, particularly when they have already solved the problem a different way.
  • Changes that require lots of stakeholders to change their behaviour will inevitably be slow.
  • External wallet connection is no longer the primary form-factor for developers building on Ethereum, as both apps and wallets are creating verticalised experiences.
  • EIPs which introduce highly flexible gadgets can underdeliver, as the complexity is pushed into the application layer. There may be benefit to ensuring that the main problems are accessibly solved, at the expense of flexibility.

These lessons are relevant to the decisions the EF is making today, as it looks to Improve UX on Ethereum:

  • The OIF requires adoption by multiple stakeholders (interop providers, solvers, wallets, apps); we can expect that will take time, and will not happen organically (i.e. without concerted effort).
  • The OIF is also a “substitute” for existing interop providers, and does not provide a “step change” in crosschain functionality. We can therefore expect stickiness to preclude adoption by some wallets and apps who have already integrated existing providers.
  • Frame Transactions introduce another flexible gadget for post-quantum readiness, and to enable account abstraction; this may encounter some of the same challenges as ERC-7702, if too many implementation details are left up to the tooling, wallet & app layer.
  • As we are working with teams across the ecosystem, we need to bear in mind that both wallets and apps are increasingly verticalised, and we should proactively engage with the infrastructure providers building embedded wallets to keep them in the loop.