The Death of the Wallet

Why the future of digital identity isn’t a container you hold, but an Agent that represents you

Chapter 1: The Skeuomorphic Trap

The history of digital interface design is often a history of comfort blankets—visual metaphors designed to soothe our transition from the physical to the virtual. When Apple first launched the iPhone, the “Notes” app mimicked yellow legal paper, and “Books” sat on wooden shelves. We call this skeuomorphism: the practice of dressing new technology in the skin of the old to help terrified users navigate the unfamiliar. While most of these visual crutches have long since been abandoned, the most critical layer of the internet—trust and finance—remains tethered to the best-known skeuomorph of them all: the Wallet.

For the past decade, the industry has attempted to convince banks, governments, and enterprises that the future of high-speed, automated global trade lies in a digital simulation of a folded piece of cowhide. This represents a fundamental category error. By clinging to a metaphor rooted in physical custody, we have inadvertently designed a system that cannot scale.

Consider the nature of a physical wallet: it is, by definition, a passive container. It sits inert in your pocket, entirely dependent on its owner to perform any action. To use it, one must retrieve it, select the credential, present it, and await approval. The wallet itself verifies nothing and negotiates nothing; it simply holds things. When we build “Digital Wallets” for the enterprise, we are merely digitizing this passivity. Even when we modernize this concept—moving the keys from a physical device to a secure cloud environment backed by Hardware Security Modules—the fundamental architectural flaw remains. A cloud-based wallet is still a wallet. It is a passive object, a “secure pocket” hosted on a server, that awaits an operator to tell it what to do.

While this passive model might be acceptable for a consumer buying a coffee, it is rather useless for an enterprise. Global trade is not a series of isolated, human-speed purchases; it is a continuous, high-velocity stream of liability and compliance checks. A single supply chain transaction might require dozens of distinct verifications—checking if the supplier is solvent, if the shipping container is insured, if the carbon tax has been paid, and if the driver is licensed. If our digital architecture relies on a “Wallet”—even a cloud wallet—that inherently demands an external operator (a human or a script acting like a human) to initiate every signature, we have not truly automated business. We have simply digitized our bureaucracy.

This problem becomes acute when we consider the “Client” nature of the wallet. In computing terms, a wallet is a Client in a Client-Server architecture. It speaks only when spoken to, or when driven by a user. By forcing a corporation to use a wallet, we are forcing a sovereign entity to act as a subordinate client. We are building a system where a billion-dollar logistics company must “log in” to a portal to prove its identity, rather than asserting its identity as a peer.

Ultimately, the argument against the wallet comes down to throughput and agency. The wallet metaphor imposes a hard architectural limit on business operations. Whether the bottleneck is a human approving a transaction on a phone, or a brittle script logging into a cloud wallet API, the friction is the same: the identity layer is waiting for instructions. The Internet Trust Layer (ITL) should be built for a machine-speed economy, moving toward a world of streaming finance and continuous compliance. We cannot run such an economy on passive clients. We cannot have a “Cloud Wallet” standing idle in the middle of a millisecond-level API call, waiting for a driver. By forcing the wallet metaphor onto the enterprise, we are placing a conceptual bottleneck at the center of our digital infrastructure.

Chapter 2: The Rise of the “Person Agent”

If we accept that the “Wallet” is a digital simulation of a leather pocket, then its successor, the “Person Agent,” is best understood as a digital simulation of a lawyer that represents you. The fundamental flaw of the wallet model is its passivity; it relies on a distracted, fatigued human owner to make split-second decisions about complex cryptographic permissions. Humans are notoriously poor at this. When faced with a pop-up requesting access to cookies or location data, the vast majority will simply click “Accept” to remove the obstruction. We trade our privacy for convenience because we lack the cognitive bandwidth to negotiate every digital interaction individually.

The Internet Trust Layer (ITL) addresses this cognitive deficit by replacing the passive container with an active representative. Your Person Agent is not merely a storage location for your ID; it is a sophisticated piece of software that knows who you are and acts autonomously on your behalf according to the rules of the context of interaction. When the interaction requires a signed approval from you to proceed, then the agent gets it from you. The shift is profound: we move from a model of storage to a model of negotiation.

In the wallet era, a website requesting your date of birth required you to manually select and share a credential. In the agent era, that request is sent to your Agent, which then consults the rules of interaction specific to the context at hand. The Agent might determine that because the requester is a verified e-commerce site executing a purchase transaction, it can generate a Zero-Knowledge Proof confirming you are over 18 without ever revealing your actual birth date. Conversely, if an unknown ad network requests location data, the Agent can unilaterally reject the request and terminate the connection. This negotiation happens milliseconds faster than a human could read the prompt, automatically enforcing the principle of “Least Privilege.”

Perhaps the most critical feature of the Person Agent is its ability to say “No.” The modern internet is designed to extract consent through dark patterns, confusing interfaces, and legalistic terms of service, all engineered to trick the user into acquiescence. A wallet leaves the user as the last line of defense against these tactics. An Agent, however, is immune to fatigue and manipulation. It ignores the bright green “Accept” buttons and hidden “Reject” menus, reading only the raw protocol request and comparing it strictly against your policy. For an enterprise, this fiduciary code is essential, preventing employees from accidentally consenting to phishing attacks or data leaks.

This model also fundamentally changes the nature of identity itself. While traditional wallets can store Verifiable Credentials, they ultimately fail at the ‘last mile’ of presentation because they demand that the user manually assemble the proof. If a bank requires a complex verification—checking that you are over 18, a resident of the EU, and creditworthy—a wallet forces you to act as a database administrator, manually selecting and combining attributes to satisfy the query. The Agent removes this cognitive load almost entirely. It treats identity not as a collection of signed files to be sorted by a human, but as a Service to be queried by a machine. When the bank’s computer asks for a risk assessment, your Agent receives the query in the context of the loan application, computes the answer locally using the credentials it holds, and returns a cryptographic attestation. The bank receives the assurance it needs to reduce risk, without the user ever having to manually construct the evidence.

This leads to an interesting paradox: the better the Agent works, the less visible it becomes. The ideal user interface for the ITL is not a slick app with a dashboard of credentials, but rather the absence of friction. It is the experience of walking into a hotel where your Agent has already negotiated check-in, payment, and key delivery with the hotel’s Agent before you reach the front desk. All you need to do is to review the outcome and sign. The wallet was designed to be looked at; the Agent is designed to be trusted as your representative.

Chapter 3: The “Organization Agent”

While giving a digital wallet to a human is inefficient, giving one to a corporation poses a structural contradiction. The industry is attempting to solve the obvious security risks of “corporate wallets” by moving them to the cloud. We can have sophisticated “Web Wallets” and “Cloud Signers” where keys are generated and stored in Hardware Security Modules (HSMs) and never leave the secure enclave. The custody problem is effectively solved; there is no physical device to steal, and no single employee holds the root key on a USB stick.

However, while the custody risk is managed, the agency problem remains. Even the most secure cloud-based wallet is still, architecturally, a Client. It is a tool that sits dormant until an authorized operator—be it a human logging into a web portal or an automated script using an API key—tells it to sign something. It does not have a mind of its own. It does not have governance logic encoded into its very existence; it only has access control lists (ACLs) determining who is allowed to drive it.

This distinction between a tool and an actor is critical. A cloud wallet is a digital stamp; it requires a hand to hold it. An Organization Agent is a digital signatory; it holds the pen itself. In the Internet Trust Layer, we need the latter. We need a server-side process that runs 24/7, acting not as a client fetching data or waiting for instructions, but as a Sovereign Peer accepting connections and making decisions based on internal policy and the rules of interaction of the context at hand.

Consider the implications for automation. If a smart contract triggers a payment based on sensor data, a wallet-based architecture requires an external “driver” to notice the event, log in to the wallet, and authorize the signature. This creates a fragile dependency chain. The Organization Agent, by contrast, acts on Policy-as-Code. It holds a mandate, not just keys. Its logic might dictate: “I am authorized to sign purchase orders up to €5,000 if the supplier presents an Approved Vendor credential and the goods have been verified by an employee of the organization.” When the request comes in, the Agent verifies the conditions and signs immediately. The logic is intrinsic to the identity, not external to it.

This shift allows us to move from simple delegation of access to true delegation of authority. In a wallet model, you give an employee a username and password to access the company wallet—a crude form of sharing the keys. In the Agent model, the Organization Agent issues a Verifiable Credential to the employee’s personal agent, stating, “This person is authorized to represent Acme Corp for transactions under $50k.” The employee signs with their own keys, backed by the corporate attestation. If the employee leaves, the Organization Agent simply revokes the credential. The authority is withdrawn instantly, without needing to rotate passwords or reconfigure the cloud wallet. We are not just digitizing the signature; we are digitizing the Board Resolution.

Chapter 4: The EUBW Paradox

To understand why the European Business Wallet (EUBW) initiative risks obsolescence before it even launches, one need only look at the underlying protocol: OpenID Connect (OIDC) and its credential issuance and proof presentation extensions. While OIDC is the standard for consumer logins like “Log in with Google,” applying it to business-to-business (B2B) trade reveals a fatal structural flaw. The EU has built its digital economy foundation on the assumption that a business acts as a Client, when in reality, it must act as a Peer.

OIDC is inherently a Client-Server protocol where the Client is passive and subservient to the Sovereign Server. This works perfectly for a citizen checking tax returns, but it fails for a logistics giant negotiating a freight contract. When major entities like Maersk and Siemens trade, neither is a subordinate client; they are peers who interact in a context and who both hold state, issue demands, and need to initiate connections at any time. Forcing them to use an OIDC-based wallet strips them of this sovereignty, reducing them to passive fetchers of data.

The most damaging consequence of this “Client Trap” is the ceiling it places on automation. A client-based wallet requires a driver—either a human tapping a screen or a complex script simulating one. This architecture prevents the creation of truly autonomous supply chains. The ITL approach, by contrast, utilizes Peer-to-Peer protocols like DIDComm, where the Organization Agent is a daemon that sleeps until triggered by a contract event, acting as its own driver.

The main issue of the current EUBW specification is that it constructs a high-security infrastructure (eIDAS 2.0) but restricts it to low-value, administrative use cases like checking government portals. The real economic value—the trillions of Euros in daily trade and supply chain settlement—requires agents that can participate, negotiate and settle in a peer-to-peer manner without a portal in sight. The EU is building an expensive client app for a problem that requires a smart server, creating a digital economy that moves at the speed of paperwork rather than the speed of silicon.

Chapter 5: The Ephemeral Context

In the current digital landscape, every transaction leaves a permanent trail, whether in some centralized database or on a public blockchain. This creates the “Honeypot Problem”: massive, toxic lakes of metadata that are vulnerable to hackers, competitors, and regulators. The wallet model, if implemented poorly, may exacerbate this by acting as a persistent tracker, a single identifier that links a user’s entire digital life. The use of e.g. sector-specific pseudonyms does not really count as a good solution here.

The Internet Trust Layer proposes a radical alternative to solve the privacy-transparency dilemma: the Ephemeral Context. We can liken this to a secure diplomatic channel. When two or more parties meet to negotiate, they do so in a secure, swept room where they verify credentials and sign documents. Crucially, once the deal is done and contract finalised, the room is destroyed. No centralized record of the private conversation or correlateable metadata of the negotiation survives, unless specifically agreed in the context; only the result—the signed treaty held by both parties and the cryptographic proof that the contract was executed as advertised—remains.

In the ITL, transactions are handled by “Context Agents,” temporary, encrypted micro-servers spun up solely for a specific deal. They enforce the rules of engagement and establish secure peer-to-peer connections (“trust links”) with the participants. Once the contract is signed and settled, they dissolve. This disposable infrastructure ensures that while the proof of the transaction is permanent, the infrastructure used to create it is not.

This approach addresses the liability of Linkability—the ability to correlate a user’s behavior across different services. If a business uses a persistent ID wallet, it creates a visible map of its commercial relationships. With Ephemeral Contexts, there is no graph. A supplier sees a verified entity in Context A, and a bank sees a verified entity in Context B, but these contexts are mathematically unlinkable. The final architectural shift is the “Vanishing Ledger.” Rather than striving for a global ledger of history, the ITL provides a record of truth. The cryptographic receipt in your local storage is all that is needed to prove a deal is valid, much like a title deed in a safe. By moving from permanent platforms to ephemeral contexts, we can build a digital economy that is as private as cash but as accountable as a wire transfer.

Chapter 6: Conclusion

We are currently witnessing a significant allocation of capital as governments and consortia invest tens of millions into building “Wallet Apps,” debating user interfaces and button colors. While these tangible applications offer political wins, they are a distraction for the industrial economy. The Internet Trust Layer will not be experienced through a screen, but through speed—invoices settling in milliseconds and cargo clearing customs autonomously.

For CTOs and strategy heads, the directive is clear: seriously consider the effort spent on building wallets. Let governments handle the citizen-facing apps. The real task for corporate world is to build the Agent. This involves adopting a Peer Architecture that moves beyond client-based solutions to allow for autonomous negotiation, and preparing for Ephemeral systems that verify data instantly and then delete it.

We are transitioning from an era of Digitized Bureaucracy—defined by PDFs, portals, and manual approvals—to an era of Computational Trust. In this new paradigm, the wallet is merely a pipe, a conduit for credentials. The true value lies not in the pipe itself, but in the logic that flows through it.

The Wallet is dead; long live the Agent. With or without AI.