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.
\nModern 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.
\nEach individual feature may sound useful. Together, however, they raise a more fundamental question:
\nVerify. Authorize. Sign. Broadcast.
\nEverything else belongs at the application layer.
\nApplications Should Construct. Wallets Should Verify.
\nFinancial applications and wallets should have clearly separated responsibilities.
\nThe 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.
\nThat 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.
\nThe wallet should therefore not be the financial application itself. It should be the independent verification and authorization layer between applications and the blockchain.
\nApplications Should Resolve Names. Wallets Should Verify Them.
\nName resolution provides a good example of why this separation matters.
\nSuppose a user wants to send 500 USDC to alice@xns .
\nIn a dedicated payment application such as x2xPay , the user enters:
\n500 USDC → alice@xns
\nalice@xns → 0xABC
\nIt then constructs a transaction sending 500 USDC to 0xABC .
\nThe wallet receives that transaction.
\nBut instead of trusting the name supplied by the application, it examines the actual recipient encoded in the transaction and independently performs the opposite operation:
\n0xABC → alice@xns
\nThe two pieces of software approach the transaction from opposite directions:
\nWallet: Address → Name
\nThis creates an independent verification layer.
\nIf 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.
\nThe wallet should not create the transaction it is supposed to verify.
\nIf 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.
\nThe same piece of software is effectively checking its own work.
\nA dedicated payment application preserves the separation: the application constructs the payment and the wallet independently verifies its meaning before authorization.
\nNames are only one example of independent verification.
\nApplications 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.
\nBut 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.
\nThere are already efforts toward standardized machine-readable metadata that can help wallets interpret contract interactions (see ERC-7730 or ERC-8213 ).
\nApplications encode intent into transactions. Wallets independently decode transactions back into human-readable intent.
\nUsers 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.
\nThis architecture changes how we should think about blockchain naming systems.
\nNames are no longer merely a UX convenience that replaces hexadecimal addresses. They can become part of the transaction verification layer.
\nFor this to work well, a naming system should support reliable resolution in both directions:
\nAddress → Name
\nIdeally, that relationship should be canonical and unambiguous.
\nA 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.
\nInterestingly, independent reverse verification can also provide an additional safeguard for expiring payment identifiers like ENS .
\nSuppose an application resolves a name and constructs a payment transaction, but the identifier expires or changes before the user authorizes the transaction.
\nWhen the wallet independently reverse-resolves the actual recipient, it may receive a different name or no name at all.
\nThe 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.
\nThis 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.
\nThere is a broader security argument for keeping wallets thin.
\nEvery 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.
\nWallets occupy an unusually sensitive position because they control authorization.
\nPut as little functionality as possible next to the keys.
\nInstead 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:
\nVerify what the transaction actually does.
\nAuthorize it through an understandable user interaction.
\nSign it securely.
\nBroadcast it to the network.
\nThe wallet can become better at its most important security function.
\nThere is also a practical reason for moving functionality outside wallets: good financial software needs space.
\nTrying to squeeze an entire financial experience into a browser extension or mobile wallet does not make much sense.
\nConsider payments alone.
\nA 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.
\nTrading can be another application.
\nAccounting can be another.
\nStaking can be another.
\nLending can be another.
\nPrediction markets can be another.
\nA 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.
\nTake a web browser as an example.
\nA 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.
\nCrypto should embrace the same separation.
\nOpening a crypto financial application should feel more like opening e-banking.
\nYou 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.
\nOnly when authorization is required does the wallet appear.
\nIt verifies the transaction, you authorize it, and the wallet signs and broadcasts it.
\nThen you return to the application.
\nThe wallet should be something you briefly open for verification and authorization, not somewhere you spend your financial life.
\nHardware wallets provide the clearest example of the thin-wallet idea.
\nAt their core, they do remarkably little.
\nThey protect keys, receive transaction requests, obtain physical authorization, and sign them.
\nThe thin-wallet thesis applies essentially the same principle to software wallets.
\nA 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.
\nThis 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.
\nOne way to make that the default, rather than an afterthought, is to build wallet software that cannot create a hot wallet at all.
\nIts 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.
\nKeep the authorization environment small and move the financial experience outside it.
\nThis also changes how we should think about onboarding.
\nDownload a wallet.
\nBut most users do not actually want a wallet.
\nThey want to make a payment, trade an asset, earn yield, manage their finances, or use some other application.
\nSo onboarding should start there.
\nA user might open a payment application and create or connect a wallet through a simple, well-designed flow.
\nThe wallet should feel almost like setting up a payment authorization device: quick, secure, and understandable.
\nAfter that, the user returns to the application.
\nThe wallet does not need to become the user's home screen for crypto.
\nWallets 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.
\nBut there is an important architectural difference between pointing users toward applications and becoming those applications.
\nThe wallet does not need to be the center of the crypto experience.
\nIt needs to be an exceptionally good verification and authorization layer.
\nAs Ethereum matures, we may therefore want to reconsider the direction wallets have taken.
\nThe future may not belong to the wallet that does the most.
\nIt may belong to the wallet that does the least — and does those few things exceptionally well.
\nRegister a Name
","headings":[{"level":1,"text":"The Thin Wallet Thesis","id":"the-thin-wallet-thesis"},{"level":2,"text":"What is a wallet actually supposed to be?","id":"what-is-a-wallet-actually-supposed-to-be"},{"level":2,"text":"We believe that a wallet should have four core responsibilities:","id":"we-believe-that-a-wallet-should-have-four-core-responsibilities"},{"level":2,"text":"The application answers:","id":"the-application-answers"},{"level":2,"text":"What does the user want to do?","id":"what-does-the-user-want-to-do"},{"level":2,"text":"The wallet independently answers:","id":"the-wallet-independently-answers"},{"level":2,"text":"What does this transaction actually do?","id":"what-does-this-transaction-actually-do"},{"level":2,"text":"The application performs forward resolution:","id":"the-application-performs-forward-resolution"},{"level":2,"text":"The wallet can now display:","id":"the-wallet-can-now-display"},{"level":2,"text":"Send 500 USDC","id":"send-500-usdc"},{"level":2,"text":"To: alice@xns","id":"to-alice-xns"},{"level":2,"text":"Application: Name → Address","id":"application-name-address"},{"level":2,"text":"This leads to a simple security principle:","id":"this-leads-to-a-simple-security-principle"},{"level":2,"text":"The Same Principle Applies to Calldata","id":"the-same-principle-applies-to-calldata"},{"level":2,"text":"The application might tell the user:","id":"the-application-might-tell-the-user"},{"level":2,"text":"Swap 1 ETH for at least 3,200 USDC","id":"swap-1-eth-for-at-least-3-200-usdc"},{"level":2,"text":"The broader principle is the same:","id":"the-broader-principle-is-the-same"},{"level":2,"text":"Name Systems Become Security Infrastructure","id":"name-systems-become-security-infrastructure"},{"level":2,"text":"Name → Address","id":"name-address"},{"level":2,"text":"Thin Wallets Can Be Safer Wallets","id":"thin-wallets-can-be-safer-wallets"},{"level":2,"text":"That suggests we should apply the opposite philosophy:","id":"that-suggests-we-should-apply-the-opposite-philosophy"},{"level":2,"text":"Financial Applications Need Space","id":"financial-applications-need-space"},{"level":2,"text":"Hardware Wallets Already Point in This Direction","id":"hardware-wallets-already-point-in-this-direction"},{"level":2,"text":"The form factor can differ. The principle remains the same:","id":"the-form-factor-can-differ-the-principle-remains-the-same"},{"level":2,"text":"Onboarding Should Start With the Application","id":"onboarding-should-start-with-the-application"},{"level":2,"text":"Today, crypto onboarding often starts with:","id":"today-crypto-onboarding-often-starts-with"},{"level":2,"text":"Conclusion","id":"conclusion"},{"level":2,"text":"Instead of asking:","id":"instead-of-asking"},{"level":2,"text":"What else can we put into the wallet?","id":"what-else-can-we-put-into-the-wallet"},{"level":2,"text":"Perhaps we should start asking:","id":"perhaps-we-should-start-asking"},{"level":2,"text":"What can we take out?","id":"what-can-we-take-out"},{"level":2,"text":"Want to get an XNS name?","id":"want-to-get-an-xns-name"}]}}