What is Aeternum

The Problem With Self-Custody#

Self-custody is the right choice. When you hold your own private keys, no exchange can freeze your account, no company can go bankrupt with your funds, and no one can deny you access to what is yours.

But self-custody carries a risk that almost no one talks about openly: if you become incapacitated or lose access to your keys permanently, your ETH is gone forever. There is no customer support line, no recovery process. The blockchain does not know who you are; it only knows who controls the keys.

Traditional finance solved this long ago through account recovery, beneficiary designations, and estate processes. In the Ethereum ecosystem, partial solutions like social recovery wallets and multisig configurations reduce single-point-of-failure risks. However, these tools share a critical flaw: they assume you are alive and capable of initiating the process. They solve for lost access, not permanent absence. Neither answers the harder question: what happens to your funds when you are no longer here to ask for help?

Until now, a non-custodial, protocol-level dead man's switch that automatically transfers funds to a designated beneficiary — triggered by inactivity alone, with no human able to authorize, delay, or redirect the transfer — has not existed as a deployable public primitive. Aeternum is that primitive.

What Aeternum Does#

Aeternum is a non-custodial smart wallet vault deployed on Ethereum. It gives you two things simultaneously:

A normal wallet experience. You can deposit ETH, send it anywhere, withdraw it at will, and interact with it exactly like a standard Ethereum address. Your funds sit in the contract mapped to your address — no pooling, no lending, no exposure to anyone else's actions.

An automatic backup plan. You designate a backup address — a beneficiary, trusted family member, or heir — or a separate wallet you control as your own safety net — and set an inactivity timer. If you go completely silent for that entire period — no transactions, no pings, nothing — your ETH moves to that backup address on its own. No approval, action, or presence is required from you, your beneficiary, or any single operator for that to happen — the mechanics of exactly how, and why no one party can gatekeep it, are covered in The Core Mechanism below.

If you are active, nothing ever happens. You just have a safer wallet.

The Core Mechanism#

The entire system rests on a single idea: an on-chain inactivity timer. Every time you interact with your vault — deposit, send, withdraw, or even just call the ping() function — the elapsed counter resets, and the full countdown restarts from the configured period.

If your timer reaches zero — meaning you have been completely inactive for your chosen period — the transfer to your backup address becomes available to execute. Someone still has to submit that transaction; in practice, that's almost always the Aeternum Labs keeper bot, which watches for eligible wallets via its own indexed database, then re-confirms each one directly against the contract before acting — rather than polling the chain for its initial scan. But triggerRecovery(), the function that actually executes the transfer, is permissionless: it carries no access restriction at all, so any address can call it — Aeternum Labs' own keeper bot, an independent third-party keeper, your backup address itself, or you. Recovery doesn't depend on any one company's infrastructure staying online.

What matters is that whoever calls it has no say in the outcome. The contract — not the caller — decides whether the transfer is valid, how much moves, and where it goes, based entirely on your current vault configuration, which you can update at any time. The caller can't redirect funds, force an early recovery, or influence anything beyond whether the transaction gets submitted at all.

The diagram above shows the actors and flow of interactions. The dashed arrow represents on-chain events emitted by the vault, picked up by an off-chain indexer and fed into the keeper's own database — this is data flowing outward from the vault, not a live call to it. Before acting on that data, the keeper separately re-checks each candidate directly against the contract to rule out anything the database missed — a read, not shown as its own arrow here, since the diagram focuses on state-changing interactions. The triggerRecovery() call is solid because it's the only actual on-chain transaction between the keeper network and the vault — often batching several wallets into a single transaction for gas efficiency — paid for in ETH gas by whichever address submits it, keeper or otherwise.

Key Properties#

What Aeternum Is Not#

Understanding the boundaries is as important as understanding the capabilities.

Aeternum is not a yield product. Your ETH does not earn interest in v1. It sits in the contract exactly as you deposited it.

Aeternum is not a multisig. Your designated beneficiary cannot access your vault while you are active. Funds only move to that address if recovery triggers.

Aeternum is not a social recovery system. There are no guardians, no votes, and no separate approval window after recovery conditions are met — the inactivity period itself is the only waiting period, and you set its length. Once it elapses, recovery executes as configured.

Aeternum is not custodial. The team that built this contract cannot access your funds. There is no mechanism of any kind for that.

Ready to Get Started?#

The fastest way to see it working is the Quick Start — the full recovery cycle takes under five minutes on Sepolia. If you want to understand the mechanics before committing to any settings, start with The Vault and The Inactivity Timer.