The Thin Wallet Thesis

Wallets Have Become Too Fat

What started as a relatively simple piece of software for holding keys, signing transactions, and broadcasting them to a network has gradually turned into something much larger.

Modern wallets resolve names, display token portfolios, show transaction histories, integrate swaps and bridges, offer staking, support perpetual trading and prediction markets, manage NFTs, provide address books, detect scams, price assets, and increasingly try to become full financial applications.

Each individual feature may sound useful. Together, however, they raise a more fundamental question:

What is a wallet actually supposed to be?

We believe that a wallet should have four core responsibilities:

Verify. Authorize. Sign. Broadcast.

Everything else belongs at the application layer.

Applications Should Construct. Wallets Should Verify.

Financial applications and wallets should have clearly separated responsibilities.

The application provides the user experience and constructs the transaction. The wallet independently verifies what that transaction actually does, asks the user to authorize it, signs it, and broadcasts it.

The application answers:

What does the user want to do?

The wallet independently answers:

What does this transaction actually do?

That independence is important. A wallet should not simply trust an application's description of a transaction. It should derive its meaning independently from the transaction it is being asked to sign.

The wallet should therefore not be the financial application itself. It should be the independent verification and authorization layer between applications and the blockchain.

Applications Should Resolve Names. Wallets Should Verify Them.

Name resolution provides a good example of why this separation matters.

Suppose a user wants to send 500 USDC to alice.xns.

In a dedicated payment application such as x2xPay, the user enters:

500 USDC → alice.xns

The application performs forward resolution:

alice.xns → 0xABC

It then constructs a transaction sending 500 USDC to 0xABC.

The wallet receives that transaction.

But instead of trusting the name supplied by the application, it examines the actual recipient encoded in the transaction and independently performs the opposite operation:

0xABC → alice.xns

The wallet can now display:

Send 500 USDC
To: alice.xns

The two pieces of software approach the transaction from opposite directions:

Application: Name → Address
Wallet: Address → Name

This creates an independent verification layer.

If the application were compromised and constructed a transaction sending the funds to another address, the wallet would reverse-resolve that actual address. It would either display another name or no verified name at all.

This leads to a simple security principle:

The wallet should not create the transaction it is supposed to verify.

If the user instead enters alice.xns directly into a wallet's own payment interface, the wallet resolves the name, constructs the transaction, verifies it, and signs it.

The same piece of software is effectively checking its own work.

A dedicated payment application preserves the separation: the application constructs the payment and the wallet independently verifies its meaning before authorization.

The Same Principle Applies to Calldata

Names are only one example of independent verification.

Applications also turn human intentions into calldata when users interact with smart contracts. A wallet can independently decode that calldata back into a human-readable description before asking for authorization.

The application might tell the user:

Swap 1 ETH for at least 3,200 USDC

But the wallet should not simply repeat that description. It should inspect the actual transaction and independently determine that this is indeed what the calldata instructs the smart contract to do.

There are already efforts toward standardized machine-readable metadata that can help wallets interpret contract interactions (see ERC-7730 or ERC-8213).

The broader principle is the same:

Applications encode intent into transactions. Wallets independently decode transactions back into human-readable intent.

Users should not need to understand hexadecimal calldata. The wallet should do the technical verification and present only the information necessary for a meaningful authorization decision.

Name Systems Become Security Infrastructure

This architecture changes how we should think about blockchain naming systems.

Names are no longer merely a UX convenience that replaces hexadecimal addresses. They can become part of the transaction verification layer.

For this to work well, a naming system should support reliable resolution in both directions:

Name → Address
Address → Name

Ideally, that relationship should be canonical and unambiguous.

A permanent 1:1 mapping between a name and an address like in XNS provides a particularly simple model: if the wallet reverse-resolves an address to a name, there is no ambiguity about which identifier represents that address within the system.

Interestingly, independent reverse verification can also provide an additional safeguard for expiring payment identifiers like ENS.

Suppose an application resolves a name and constructs a payment transaction, but the identifier expires or changes before the user authorizes the transaction.

When the wallet independently reverse-resolves the actual recipient, it may receive a different name or no name at all.

The wallet should therefore never display the name claimed by the application as verified. It should only display a name if its own independent resolution confirms it.

This does not make permanence irrelevant. Stable identifiers make the security model simpler and remove an entire category of state changes that users and applications otherwise need to consider. But independent reverse resolution provides an additional defense even for naming systems whose records can change.

Thin Wallets Can Be Safer Wallets

There is a broader security argument for keeping wallets thin.

Every additional wallet feature introduces more code, more dependencies, more APIs, more network requests, and more potential for supply chain attack vectors, each of which increases the risk that something can go wrong.

Wallets occupy an unusually sensitive position because they control authorization.

That suggests we should apply the opposite philosophy:

Put as little functionality as possible next to the keys.

Instead of spending engineering resources building swaps, portfolio dashboards, payment applications, NFT galleries, staking interfaces, perpetual trading, prediction markets, and other application features, wallet developers can focus on making the four core functions exceptionally robust:

1. Verify what the transaction actually does.
2. Authorize it through an understandable user interaction.
3. Sign it securely.
4. Broadcast it to the network.

The wallet can become better at its most important security function.

Financial Applications Need Space

There is also a practical reason for moving functionality outside wallets: good financial software needs space.

Trying to squeeze an entire financial experience into a browser extension or mobile wallet does not make much sense.

Consider payments alone.

A dedicated payment application can provide human-readable payment identifiers, payment requests, invoices, contacts, recurring payments, delayed payments, transaction annotations, accounting classifications, exports, spending analysis, transaction search, reporting, and much more.

Trading can be another application.

Accounting can be another.

Staking can be another.

Lending can be another.

Prediction markets can be another.

A single application can combine some of these functions where that makes sense, but there is no reason the wallet itself needs to absorb them all.

Take a web browser as an example.

A web browser does not need built-in accounting software because accounting applications can run inside it. It does not need built-in banking software because banking applications can run inside it.

Crypto should embrace the same separation.

Opening a crypto financial application should feel more like opening e-banking.

You enter an environment designed around what you actually want to accomplish. You can see your transactions, counterparties, balances, notes, invoices, reports, or whatever else is relevant.

Only when authorization is required does the wallet appear.

It verifies the transaction, you authorize it, and the wallet signs and broadcasts it.

Then you return to the application.

The wallet should be something you briefly open for verification and authorization, not somewhere you spend your financial life.

Hardware Wallets Already Point in This Direction

Hardware wallets provide the clearest example of the thin-wallet idea.

At their core, they do remarkably little.

They protect keys, receive transaction requests, obtain physical authorization, and sign them.

The thin-wallet thesis applies essentially the same principle to software wallets.

A mobile phone can become the authorization device. A browser extension can serve as the authorization layer. A dedicated hardware device can provide even stronger isolation.

This is not only a design preference. Hot wallets remain a major source of loss. As pcaversaccio recently noted, SEAL 911 saw more than $2 million drained in a single day through device compromises. The usual advice is to move to cold storage.

One way to make that the default, rather than an afterthought, is to build wallet software that cannot create a hot wallet at all.

Its entire purpose would be to connect an external hardware signer, independently interpret transaction requests, present them to the user, and broadcast the resulting signed transaction.

The form factor can differ. The principle remains the same:

Keep the authorization environment small and move the financial experience outside it.

Onboarding Should Start With the Application

This also changes how we should think about onboarding.

Today, crypto onboarding often starts with:

Download a wallet.

But most users do not actually want a wallet.

They want to make a payment, trade an asset, earn yield, manage their finances, or use some other application.

So onboarding should start there.

A user might open a payment application and create or connect a wallet through a simple, well-designed flow.

The wallet should feel almost like setting up a payment authorization device: quick, secure, and understandable.

After that, the user returns to the application.

The wallet does not need to become the user's home screen for crypto.

Wallets could still help users discover applications. A wallet could effectively provide a small app store for financial applications: payments, trading, lending, accounting, staking, and other services.

But there is an important architectural difference between pointing users toward applications and becoming those applications.

Conclusion

The wallet does not need to be the center of the crypto experience.

It needs to be an exceptionally good verification and authorization layer.

As Ethereum matures, we may therefore want to reconsider the direction wallets have taken.

Instead of asking:

What else can we put into the wallet?

Perhaps we should start asking:

What can we take out?

The future may not belong to the wallet that does the most.

It may belong to the wallet that does the least — and does those few things exceptionally well.