Smart Vault: non-custodial custody with rules

The problem a plain account does not solve

A plain blockchain account — an EOA — has a property that is simultaneously its greatest virtue and its greatest flaw: whoever holds the key can do everything, immediately. No value limit, no delay, no second confirmation.

That is excellent while the key is only yours. The moment it leaks, the same property works against you: the attacker does not need to break anything, only to sign. In practice, the window between a leak and a zeroed balance is usually minutes.

Self-custody does not eliminate risk — it transfers responsibility for the key to the user. What can be changed is what happens after the key leaks.

The Smart Vault concept

The design VKX is working on is hybrid: it separates who authorizes from where the asset lives.

• Signer (EOA). Your key remains the primary identity. Nothing changes in what you already use.
• Vault (contract). A contract holds the assets and applies rules. It does not replace your key; it obeys it within limits you defined.
• Relayer. The layer submitting the operation, which allows the network cost to be sponsored.

The difference from a plain account is that the key's power stops being absolute and immediate. It becomes absolute within rules.

Which rules change the outcome

The ones that matter are few, and all attack the time window:

• A delay for large amounts. A transfer above a threshold does not execute right away; it enters a queue with a wait. That buys time to react — and reacting is possible because the rule itself can allow cancellation.
• A second factor on signing. Sensitive operations require an additional confirmation (biometrics or a device key) that an attacker with the seed does not have.
• A per-window limit. A value ceiling per period turns an instant drain into a slow, detectable leak.
• A list of known destinations. Sending to a new address can require more than sending to one you have used before.

None of them stops a determined attacker with infinite time. All of them turn "I lost everything in five minutes" into "I had time to act", which is the difference that matters.

What this rests on technically

Two specifications underpin this kind of architecture, and it is worth distinguishing them because they solve different things:

• ERC-4337 introduces smart accounts and contract-validated operations, with the reference implementation in account-abstraction. It is what lets an account have its own validation rules.
• EIP-7702 lets a plain account delegate to a contract without changing address, removing migration from the equation.

The comparison between both models, and why the choice changes the experience, is in what is a paymaster.

What this design costs

Being honest about the cost is part of evaluating the idea:

• Complexity. A contract between you and your assets is one more piece that can have bugs. The attack surface moves, it does not vanish.
• Friction. Rules that protect also annoy. A withdrawal delay protects against theft and irritates in a legitimate emergency.
• Network cost. A contract-mediated operation consumes more gas than a simple transfer.
• Infrastructure dependency. If the operation depends on a relayer, that relayer's availability starts to matter.

That is why the model makes more sense for holding than for using: a reserve with rules, and a plain account for daily activity.

Current status

This is an architecture project, not a feature announced as available. VKX's smart-account infrastructure is under development, and what is published about the current security design is at security architecture.

FAQ

Does this take away my sovereignty over the funds? No. The rules are set by you and authorization still comes from your key. The contract limits what the key does, not who is in charge.

If my seed leaks, am I safe? Better protected, not safe. The goal is turning an instant drain into something slow enough for you to react.

Do I need to change addresses? In the EIP-7702 model, no — delegation keeps the same address.

Does this replace a hardware wallet? No. They are different layers: one limits what the key can do, the other protects where the key lives. More on the second in the hardware wallet study.

Is it available already? It is an architecture project. Do not treat it as a production feature.

Next step

If your main risk is key leakage, the measure with immediate effect today is not architecture: it is reviewing approvals and security habits.

Disclaimer: this content is informational and educational and does not constitute investment advice.