ERC-4337 smart accounts: when backing up your private key is not enough

I suddenly hit a wall while trying to access my smart account powered by ERC-4337 account abstraction. So, I built a tool (erc4337-driver) to help others facing the same issue I faced there.

The issue: The private key I correctly exported and backed up from an app was not returning the same 0x address holding my funds on that app when imported into any of the most popular EVM wallets (Rabby, Phantom, MetaMask).

This, I discovered, is an intentional behavior. Nevertheless, explicit and intuitive documentation and warnings were lacking in the app — leading to confusion and even a brief fear of having lost my funds. Proper education, documentation, and tools are very much needed to improve the user experience and self-custody assumptions, which is what this article will address.

Let’s talk about that!

Subscribe for free to 「thecoding」

In blockchain, we learned that exporting and backing up a private key equals self-custody and immediate, full access to our funds. However, tech is evolving and different wallet implementations sometimes break this mental model.

Account abstraction via ERC-4337 smart accounts is one of these models where a simple private key export + import may not work the way most OG crypto-native people (without this specific knowledge) would expect. I was a victim of that myself, despite having over six years of experience producing technical content for blockchain.

The usual self-custody assumption is really intuitive:

1. User creates a wallet account by generating a private key and a public key derived from it.

2. User receives and stores funds in this address (the public key) that can later be spent by signing transactions with the private key.

3. User can export the private key (or a seed) and back it up to guarantee permanent access to the funds even when the wallet app they were using stops working or clears the login data.

4. All the user needs to do is to import this seed (or private key) into a wallet that supports the same derivation/recovery path.

Easy, right?

However, it wasn’t easy enough for most Web2 users. So, blockchain devs started building account abstraction solutions like the ERC-4337 smart accounts to improve the user experience.

Now, apps like p2pdotme can implement solutions like thirdweb that allows users to create wallets with abstracted logins via Google, email, phone number, or other passkeys.

I’m using p2pdotme and thirdweb as examples, because these were the app and the implementation I was using when stumbled into the issue I’m describing here.

Sounds great, right? Users can now easily login into their wallets with digital credentials they are already used to, but with a problem: what happens if the user loses access to their Google account, email, phone (this may happen more often than most people realize — see post below)…

The Smart Ape 🔥@the_smart_ape

> use a google account for 15+ years > do everything with it: youtube: google, drive, playstore > launch a saas > stripe, slack, notion, vercel, ....: sign in with google > wake up and see: "your account has been suspended for ..." > can't open notion → 3 years of client files

9:30 AM · May 17, 2026 · 2.33M Views

245 Replies · 1.04K Reposts · 15K Likes

…Or if the app (p2pdotme) and/or the wallet provider (thirdweb) stop working or close?

Not that great anymore, right? This, however, is not a today’s issue. Crypto and blockchain emerged and gained popularity exactly as solution to this very problem by introducing self-custody and ownership primitives. Are we going backwards, then? Not really (technically speaking), but education (and proper documentation) is needed.

When presented this issue, many account abstraction enthusiasts will say: “actually, these are still self-custody wallets. you can still export and backup your private key. see? easy!”

They are not wrong, but they are not entirely right neither. The fact is that most of them have probably never really tried to recover their ERC-4337 smart account via the in-app exported private key. ACTUALLY, most of them would have had the same surprise I had a while ago when doing it for the first time: the address is not the same and no popular wallet app can easily find this address.

F*! Did I just lose my funds??!!

No, you did not. I’ll explain.

In a classic externally owned account (EOA), the relationship is simple and direct:

• One private key

• One public address derived from it

• That address holds the funds

• Whoever controls the private key controls the funds

When you export the key and import it into another wallet, you get the same address. No surprises.

ERC-4337 smart accounts (especially the ones created by in-app wallet providers such as thirdweb) work differently. There are two addresses involved:

1. The admin (or “personal”) account
   This is a regular EOA. Its private key is what the app lets you export. This key is the owner of the smart account.

2. The smart account itself
   This is a smart contract. It is the address the user actually sees in the app and the address that holds the funds, tokens, reputation points, etc.

When you log in with email, Google, or a passkey, the provider creates (or recovers) the admin EOA behind the scenes and uses it to control the smart account. The smart account is usually deployed through a factory contract using a deterministic address (CREATE2). The salt for that address is typically derived from the admin key (and sometimes some extra data).

thirdweb-dev/contracts/BaseAccountFactory.sol

This is the precise mechanism:

• The admin (the EOA whose private key you can export) is passed in.

• The salt is keccak256(abi.encode(admin, data)).

• The smart account address is deterministically predicted / deployed via Clones (CREATE2-style).

• The admin is then set as the owner of that smart account.

When data is empty (0x), which is the common case for standard thirdweb accounts, the address depends only on the admin key + the factory.

So the real ownership chain looks like this:

When you export the private key from the app and import it into Rabby, MetaMask, Phantom, or any other standard wallet, those wallets correctly show you the admin EOA address. They have no knowledge that this key also controls a completely different smart-account contract. That is why the address is different and why the funds appear to be missing.

The funds were never lost. You simply recovered the key that owns the smart account, not the smart account interface itself.

The personalAccount is the admin whose address is fed into the factory’s getAddress / createAccount under the hood.

This design is intentional. It allows gasless transactions, social login, session keys, and other UX improvements. But it breaks the mental model most people carry from years of using normal wallets: “I exported the private key → I should see my funds.”

In the next section I’ll show exactly how to reconnect to the smart account using the exported admin key — and why I ended up building a small open-source tool for it.

Once you understand the two-address model, the recovery path becomes clearer, but still not super intuitive.

You exported the private key of the admin EOA. That key controls the smart account. To use it you have two main options:

You can take the exported private key and feed it back into thirdweb’s own stack:

note that the exact import path can vary slightly between thirdweb SDK versions

This works. It is the official path. But it still requires:

• the thirdweb SDK

• a valid clientId

• knowledge of the correct factory / configuration

Most users who just exported a private key and opened Rabby or MetaMask will never do this. They expect the key itself to be enough.

Because the admin is allowed to call execute / executeBatch on the account contract (the onlyAdminOrEntrypoint path), you don’t actually need the full thirdweb stack. You only need:

1. The admin private key (or the key loaded in Rabby)

2. The factory address (or the already-known smart account address)

3. A way to call the account contract

That is the exact wall I kept hitting. There was no small, focused tool that would let me take an exported admin key, open it in a normal wallet, and immediately act as the smart account — without going back through the original provider’s SDK.

So I built one.

erc4337-driver is a thin TypeScript library (MIT) that does exactly what I needed:

• Predict the smart account address from factory + admin

• Verify the connected key is actually an admin (isAdmin — fail-closed)

• Attach via any EIP-1193 provider (wallets like Rabby, MetaMask, etc.)

• Call execute / executeBatch directly on the smart account

No thirdweb clientId required for the core path. No bundler required for the basic admin-driven flow.

The library is intentionally narrow. It is not a full wallet. It is a recovery/driver tool for an already-deployed ERC-4337 account whose admin key you control.

It’s also still in the version v0.1.0 and only tested against the thirdweb SDK and the p2pdotme implementation. I plan to build integrations with other ERC-4337 providers, cover edge cases from different apps, and add more functionalities that could be useful for devs and advanced users.

You can find it here:

github.com/vinibarbosabr/erc4337-driver
npmjs.com/package/erc4337-driver

Open for contributions!

This library is also being implemented in production by a project I’m building with Michael2xl: 0xramp. It is an on-ramp & off-ramp app built on top of NEAR Intents and the p2pdotme-sdk. You can follow our work at x.com/0xramplabs.

Ah, I recently made a contribution to p2pdotme/docs clarifying the self-custody and recovery path. This will help avoiding confusion from other users (like me), as the information (and FAQ) will now be properly documented.

Account abstraction improves onboarding. Social logins and gas sponsorship are real wins that we can’t ignore. But they also quietly change what “I backed up my private key” means.

The key is still sufficient on-chain. The recovery path, however, is not obvious enough to most users. When documentation and tooling lag behind the architecture, people experience that gap as lost funds — even when nothing is lost.

Better education, clearer warnings at export time, proper documentation, and small focused tools help close that gap. Self-custody only works when people can really exercise it.