The Next Wallet Debate Isn't About Keys

Published for technical and conceptual discussion.

Embedded wallets have become easy to integrate. You can spin one up in minutes, wire it into an agent, and start moving money programmatically.

Most of the conversation around these systems still revolves around a familiar question: where is the key?

Is it on the device? Is it split across MPC nodes? Is it inside a TEE?

That question mattered a lot over the past few years, and the industry has made real progress there. But a different question is starting to matter more:

Who can actually cause a transaction to happen?

From Key Custody to Execution Authority

There are two distinct layers in any wallet system.

The first is key custody; whether any party holds or directly controls the private key material or the means of access to it. This is where most modern wallet infrastructure has focused its effort.

The second is execution authority; whether a system can produce a valid transaction on behalf of a user, and under what conditions.

These two are related, but not the same.

You can design a system where no one ever has direct access to a raw private key, yet transactions can still be initiated without the user being present. Conversely, you can have strong guarantees that every transaction requires explicit user involvement, regardless of how keys are stored.

Regulatory frameworks tend to look at both. MiCA frames custody in terms of safekeeping or controlling the means of access. FinCEN looks at whether an intermediary has independent control over user funds, based on how the system behaves in practice. These are not purely technical tests, they are functional ones and will heavily affect the industry if not discussed now.

Why This Becomes Real With Agents

This distinction becomes obvious as soon as you build anything agentic. A user deposits funds and gives an instruction like: "Find me a subscription under $30/month." A few days later, your system executes the payment while the user is offline.

Nothing unusual from a product perspective. But technically, something important has happened: the system has acted on behalf of the user without their real-time involvement.

That doesn't automatically make it custodial. Financial systems have long supported pre-authorized actions: subscriptions, card-on-file payments, standing orders. But it does raise a more precise question:

Can the system act beyond what the user explicitly authorized and who enforces that boundary?

It's Not Custodial vs Non-Custodial

The common framing of "custodial vs non-custodial" is too coarse for modern systems. In practice, most wallet infrastructures support a spectrum of execution models.

User-in-the-loop systems require the user always to be present at the moment of execution.

Delegated systems let the user define a scope in advance; limits, counterparties, time windows and the system operates within that scope.

Service-controlled systems allow backend or application credentials to initiate transactions without fresh user involvement. These are powerful and often necessary for automation, but they introduce a clear execution authority outside the user.

The important nuance is that many providers support multiple modes. The same SDK can be used in a strictly user-controlled way or in a fully automated, server-driven way.

So the relevant question isn't "Is this wallet custodial?" It's: "Which execution model am I actually using?"

The Overlooked Layer: Policy Enforcement

There is a third layer that often gets less attention: where policy is enforced.

Agentic systems almost always involve constraints; spend limits, approved counterparties, frequency caps. Those constraints define what the system is allowed to do. But the critical detail is where that enforcement lives.

Backend enforcement means the server evaluates the rule before calling the signing API. The server decides whether a transaction is within scope before allowing it to proceed. That server becomes a control point in the execution path.

Enclave enforcement shifts the control boundary into provider infrastructure inside a TEE, but still leaves an intermediary in the execution path.

Onchain enforcement moves the rules into a smart contract. The transaction can still be created and submitted, but it will only succeed if it passes contract-level checks. This removes backend discretion, but It is also inherently public, which can reveal policy details such as spending patterns, counterparties, or behavioral constraints.

Cryptographic enforcement means out-of-scope transactions simply cannot produce a valid signature. Enforcement no longer depends on any runtime decision-maker.

The difference is not whether delegation exists, delegation is necessary and legitimate. The difference is whether the system can exceed that delegation, and who or what prevents it.

Where Current Designs Land

Most existing approaches solve one or two parts of this problem well, but not all three simultaneously.

Systems focused on key protection; MPC, TEEs reduce key exposure but often still rely on infrastructure participation in every signing event.

Delegation models improve usability but frequently enforce limits at the API or backend layer, leaving a runtime control point in place.

Audit-oriented designs provide strong evidence of what was authorized, but operate after the fact rather than preventing invalid actions.

None of these are inherently wrong. They reflect different trade-offs between usability, control, and complexity. But they do mean that in many real-world configurations, there is still an entity in the system that plays a meaningful role in determining whether funds move.

A Different Direction

Instead of asking how to store keys more safely or how to enforce rules in a backend, the question becomes what if neither is needed?

This leads to systems where keys are derived Just In Time on-device rather than stored, signing requires user presence or device-bound input, and authorization rules are embedded directly into the signing process. In these designs, enforcement is not a runtime decision, it is a property of the key. If a transaction falls outside the allowed scope, it simply cannot be signed.

This does not remove delegation. It changes how delegation works. The question is no longer whether an agent can act, but whether it can exceed what the user authorized, and whether any server can override that boundary.

This is the direction we are building toward with Unforgettable and BLISK (ePrint 2026/088). In this model, the user key is never stored, It exists only to create and authorize agent keys. When a user delegates, they do it once on-device, defining a clear scope of what the agent is allowed to do. The server never holds the user key and cannot expand permissions. It can only use the already delegated agent key within its limits.

With BLISK, those limits are embedded directly into the key itself. Spend caps, approved vendors, and time windows become cryptographic constraints. An agent holding a key that says “$100 per transaction, approved vendors only” cannot exceed those bounds, not because a server blocks it, but because a valid signature cannot be produced outside them.

Taken together, the three control points most systems rely on, key custody, execution authority, and policy enforcement, are moved out of servers and condensed into cryptography.

Regulatory frameworks for agentic systems are still evolving and this approach does not guarantee a specific outcome. But it reduces the number of places where control can exist, regardless of how those frameworks develop.

What Builders Should Actually Check

If you're building an agentic payment flow today, the most useful questions are not about labels, but about mechanics.

• Can any backend yours or a provider's initiate a transaction beyond what the user explicitly authorized?

• Where are policy constraints enforced: in your server, in provider infrastructure, onchain or in the cryptography itself?

• Does signing or recovery require an external party to actively participate?

The answers to these questions define your system more clearly than whether it is described as "self-custodial."

Where This Is Heading

The industry has spent the last cycle solving how to store keys safely. The next phase is about who holds execution authority, who sits on the path between user intent and transaction finality.

As software agents become more capable and more autonomous, that distinction becomes harder to ignore.

Because at some point, the question is no longer:

"Where is the key?"

It becomes:

"Who, or what, is actually in control when money moves?"