Delayed Ownership on Ethereum: A Different Custody Model

Delayed Ownership on Ethereum: A Different Custody Model

Most Ethereum assets assume a simple rule:

once a transfer is confirmed, ownership changes immediately and irreversibly.

This model is extremely efficient, but it also creates a specific category of risk.

Mistakes, phishing, coercion, compromised devices, incorrect addresses and rushed decisions become final within seconds.

For many use cases this is acceptable.

For others it may not be.

Ownership and time

Traditional ERC20 transfers couple two events:

1. assignment of value


2. spendability of value

Both happen at the same moment.

The recipient receives the asset and can immediately transfer, trade or dispose of it.

An alternative approach is to separate these two concepts.

Value may be assigned before it becomes fully spendable.

This introduces the concept of delayed ownership.

Protected transfers

A protected transfer creates a recipient position that exists immediately but remains subject to protocol rules during a waiting period.

During this period:

• the recipient can see the transfer


• ownership is pending


• spendability is restricted


• protocol-defined control actions remain possible

Only after finalization does the asset become ordinary spendable balance.

This is fundamentally different from conventional ERC20 behavior.

Why consider this model?

The goal is not to slow transactions.

The goal is to reduce specific operational risks.

Examples include:

• mistaken transfers


• compromised wallets


• coercion attempts


• inheritance-oriented custody


• delayed release arrangements


• controlled asset distribution

In these situations immediate and irreversible ownership may not always be optimal.

Compatibility challenges

Introducing delayed ownership creates new questions.

For example:

• how should balance reporting work?


• how should wallets display protected balances?


• what should indexers show?


• how should governance systems interpret pending ownership?


• how should third-party integrations handle protected state?

These questions are often more difficult than the custody mechanism itself.

Research direction

IND explores programmable custody on Ethereum through:

• protected transfers


• delayed ownership


• revocable custody windows


• inheritance-aware semantics


• protected and unprotected balance separation

The project is currently deployed on Ethereum mainnet as an experimental protocol.

Additional technical material:

• Main site:
  


• Protected transfers:
  


• GitHub repository:
  
  
  

  Whitepaper:

  
  
  
  Vollständiger Original-Bericht

  Ausführliche Details, Code-Beispiele & Hersteller-Stellungnahme auf dev.to.

  ↗ Original-Artikel auf dev.to lesen