Phase 2 — Hybrid Wallet

The Core Shift#

Phase 1 requires users to deposit ETH into an escrow-style vault contract. The assets move from your wallet into the AeternumVault contract's custody before recovery protection begins. This works well, but it introduces friction: a separate deposit step, a separate contract balance to track, and a mental model of "my vault" as a distinct place from "my wallet".

Phase 2 eliminates this entirely. Your assets never leave your own address.

Instead of depositing into a contract, users either create a new Aeternum wallet from scratch or import an existing Externally Owned Account (MetaMask, Coinbase Wallet, hardware wallet — anything). In either case, the address looks and behaves like a completely standard Ethereum wallet. The recovery infrastructure operates on the account without requiring any asset migration.

This is made possible by EIP-7702, an Ethereum standard that allows a regular EOA to delegate execution logic to a smart contract without changing the underlying address or requiring a separate proxy deployment. The user maintains one address and one seed phrase, while the AeternumRecoveryManager contract gains the ability to execute recovery logic on their behalf when inactivity conditions are met.

From the outside, the Phase 2 wallet is indistinguishable from MetaMask. DeFi protocols, exchanges, and wallets all see a standard Ethereum address. Under the hood, the EOA has been upgraded into a programmable hybrid account.

The keeper network shown above also expands at this phase: Gelato comes online as a second, independently-operated keeper alongside the Aeternum Labs bot — see How Recovery Works in Phase 2 below for what that means in practice.

---

Multi-Asset Recovery#

Phase 1 supports native ETH only. Phase 2 expands to ETH and any ERC-20 token from launch.

Each token balance is tracked independently per user in the AeternumRecoveryManager. When recovery triggers, the contract transfers all registered token balances alongside the ETH balance to the backup address in a single execution — the beneficiary receives everything the wallet held, not just the ETH.

Key design properties:

• Partial failure isolation. If a single token transfer fails during batch recovery (e.g. a frozen stablecoin), that token's failure is recorded and retried on a subsequent recovery attempt — the same per-wallet retry mechanism used in Phase 1, just extended to track failures per-token rather than only per-wallet. The remaining assets transfer normally — one broken token cannot block recovery of everything else.
• Revocable allowances. Token allowances granted to the AeternumRecoveryManager are revocable at any time. Revoking before recovery triggers causes that token to be skipped silently while all other assets recover normally.
• No custody transfer. At no point do your tokens move to the AeternumRecoveryManager contract. The manager holds an allowance, not the assets.

---

Activity Detection — No Ping Required#

Phase 1 requires users to manually call ping() to signal liveness when they are not otherwise transacting. If you go on a long trip and do not move any crypto for six months, you need to remember to ping before your timer expires.

Phase 2 removes this requirement entirely. Simply opening the Aeternum app resets your inactivity timer.

When you open the app, it automatically sends a gasless, signed interaction to the AeternumRecoveryManager to update your lastActivity timestamp. You do not need to approve transactions or pay gas fees — the protocol handles this seamlessly via Paymaster sponsorship.

This has two important consequences:

Accidental recovery becomes much harder to trigger. If your inactivity period is 365 days, you just need to open your wallet app once a year — the same natural behavior expected of anyone who occasionally checks their crypto balance. Recovery is reserved for true absence, not scheduling oversight.

The liveness signal becomes semantically stronger. Phase 1's recovery guarantee is complete and unchanged — if the inactivity period elapses and your vault holds ETH, recovery executes without exception. What Phase 2 refines is the precision of the signal that drives the timer. A manual ping() call proves key control; opening the app proves genuine wallet engagement. The underlying trigger conditions, contract logic, and execution guarantees carry forward identically. The timer simply becomes a more meaningful proxy for the real question: is this person still actively using their wallet?

The manual ping() function remains available on-chain for users who want to prove liveness from a separate interface or a scripted environment. It is no longer the primary mechanism — it is a power-user option.

---

How Recovery Works in Phase 2#

The AeternumRecoveryManager is monitored the same way Phase 1 vaults are: an off-chain indexer tracks activity events for every registered wallet, a keeper bot's database-driven scan identifies wallets that are due for recovery, and each candidate is re-validated directly on-chain before anything executes. See Keeper Network for the full mechanics of that pipeline as it operates in Phase 1 — the same model carries forward here.

What's new at this phase is who's running the pipeline. Phase 1 runs on the Aeternum Labs bot alone. Phase 2 is where Gelato joins as a second, independently-operated keeper — both running the same scan-validate-execute cycle against the same contract, with no coordination required between them. See the Keeper Network phase breakdown for the full rollout plan across all phases.

When a wallet's inactivity period expires, either keeper — or any other permissionless caller, since the entry point carries no access restriction — can invoke recovery on the manager for that wallet. The manager re-validates every precondition independently at execution time, exactly as _executeRecovery() does in Phase 1, and only then moves funds: ETH and all registered ERC-20 token balances transfer from the Aeternum wallet to the user's designated backup address in a single execution — the same recovery guarantee as Phase 1, just from a self-custodial address rather than a vault escrow, across multiple asset types rather than one, and now backed by two independent keepers rather than a single point of monitoring failure.

If Gelato and the Aeternum Labs bot ever raced to recover the same wallet, that resolves exactly as described in Keeper Network's Race Safety section — the first call to land executes normally, and the second silently returns without reverting or double-transferring funds. Nothing about having two keepers instead of one changes that guarantee.

Ownership rotation — where control of the smart account itself transfers to the backup rather than assets moving — is reserved as a future opt-in feature once Aeternum wallets are common enough as backup addresses to make it meaningful. Asset transfer remains the default recovery execution path in Phase 2.

---

What Carries Forward From Phase 1#

The following architecture elements are preserved in Phase 2:

• The keeper network's scan-validate-execute model — extended, not replaced. Off-chain discovery via an indexed database, on-chain re-validation of every candidate before submission, and batched on-chain execution all carry forward from Phase 1 unchanged in principle. Recovery execution remains permissionless: any address can call it once a wallet is due, and the contract's own precondition checks — not the identity of the caller — are what make that safe. What's added at this phase is a second keeper (Gelato), not a change to the model itself; scaling either keeper's individual throughput is expected to follow the same path outlined for Phase 1 — multiple independent signing keys per keeper, so more batches can be in flight at once, rather than any change to the recovery contract itself. See Keeper Network for the full detail on how this works today, its phase-by-phase rollout plan, and its own scaling notes for what's planned versus what's already shipped.
• MAX_RECOVERY_ATTEMPTS abandonment handling — with per-asset nuance. The three-attempt ceiling on per-wallet abandonment carries forward for ETH recovery. In Phase 2's multi-asset model, individual ERC-20 token transfer failures are tracked separately per token across retry cycles — a single failing token does not count against the wallet-level abandonment counter. Abandonment applies when the ETH recovery path itself has failed three consecutive times.
• The stale-data safety pattern in _executeRecovery — every candidate wallet is re-validated on-chain immediately before any asset moves, regardless of what a keeper's off-chain database or its on-chain validation pass believed to be true when it decided to submit the call.
• Permissionless execution — no access gate. Just as triggerRecovery() in Phase 1 carries no caller restriction, Phase 2's recovery entry point is equally permissionless. Any address may call it once conditions are met; the safety property comes entirely from what the contract re-validates before acting, not from who is allowed to ask it to act.
• The event schema (with additions for multi-asset transfer and per-token failure events).

These preserved mechanics form a battle-tested safety foundation. Phase 2 layers on top of this foundation by expanding the protocol's surface area — transitioning from a localized escrow contract to a comprehensive, multi-token recovery manager capable of securely retrieving assets straight from the user's self-custodial wallet.