Phase 3 — Multichain

The Problem Phase 3 Solves#

After Phase 2, a user holding ETH on Ethereum mainnet is fully protected — their hybrid wallet monitors inactivity and recovers assets automatically. But most active crypto users do not confine their holdings to a single chain. They hold ETH on Arbitrum for DeFi, bridge to Base for lower fees, keep BNB on BNB Chain, hold stablecoins on Polygon, and so on.

Each of those positions sits outside Aeternum's protection after Phase 2. If the user becomes incapacitated, the Ethereum mainnet recovery fires and moves their mainnet ETH to the backup address. Their Arbitrum, Base, BNB positions sit unprotected — subject to the same original problem that Aeternum was built to solve.

Phase 3 closes that gap by expanding the Aeternum hybrid wallet and AeternumRecoveryManager to every major EVM-compatible network.

---

Independent Per-Chain Deployments#

Phase 3 uses no cross-chain messaging and no bridge infrastructure of any kind. Every supported network gets its own fully independent deployment:

• Its own AeternumRecoveryManager contract.
• Its own registry of registered wallets, monitored the same way as every other Aeternum deployment — an off-chain indexed database drives discovery, and every candidate is re-validated on-chain immediately before recovery executes. There is no on-chain scan position of any kind to track, on this chain or any other. See Keeper Network for the full mechanics of that pipeline.
• Its own keeper coverage, from three independent operators. The Aeternum Labs bot and Gelato — both already active as of Phase 2 — extend their scan-validate-execute pipelines to include each new chain. Chainlink CRE joins at this phase as a multi-chain orchestrator: a single off-chain service running one independent workflow per chain, each watching that chain's own registry and submitting triggerRecovery transactions to that chain's own contract. What CRE centralizes is the operation of those workflows — running them all from one piece of infrastructure — not their execution. No workflow's transaction ever depends on data, state, or a message from another chain. On each chain, CRE calls that chain's recovery entry point exactly like the Aeternum Labs bot and Gelato do on that same chain: permissionlessly, with the result re-validated entirely from that chain's own on-chain state.
• No designated caller, no access gate of any kind. Recovery execution on every chain is permissionless, exactly as it is on Ethereum mainnet — any address may call it once a wallet is due, and the contract's own on-chain validation is what makes that safe.

This design is intentional. A trigger-on-one-chain, transfer-on-another model would introduce bridge dependency risk, oracle latency, and message-passing attack surfaces — exactly the category of failure this protocol is built to protect people from, not add to. By running independently per chain, each deployment inherits the same trust properties as the Phase 2 AeternumRecoveryManager: nothing happening on any other chain can interfere with recovery execution here, and a failure on one chain has zero effect on any other.

Assets on each chain recover independently to the designated backup address on that same chain.

---

Supported Networks#

All networks listed are EVM-compatible chains with mature RPC and indexing infrastructure — the baseline requirement for deploying both the AeternumRecoveryManager contract and the keeper network's off-chain scanning pipeline on a given chain. Future chains are added as that infrastructure matures elsewhere.

---

Per-Chain Registration#

Users protecting assets across multiple chains register separately on each chain. The registration flow is identical to Phase 2 on each network — connect wallet, designate backup address, set inactivity period.

The backup address is configured per deployment. A user can choose a different backup address for each chain, or use the same address everywhere. Common patterns:

• Same backup everywhere — simplest setup, the primary beneficiary's address receives everything across all chains on recovery
• Chain-specific backups — different estate trustees per chain, or a chain-specific multisig for each network's assets
• Hardware wallet as universal backup — a single Ledger address designated everywhere, receiving all multi-chain assets

The inactivity period is also per-chain. A user might want a shorter timer on their active DeFi chains (Base, Arbitrum) and a longer timer on cold-storage chains (Ethereum mainnet). This flexibility is fully supported.

---

Activity Synchronisation#

In Phase 2, opening the Aeternum app resets the timer on the connected chain. In Phase 3, the app submits a separate, gas-sponsored activity ping to each chain's AeternumRecoveryManager independently. No cross-chain message passing occurs — each ping is a fully independent on-chain interaction on its respective network, sequenced by the app layer rather than any bridging infrastructure.

This means a user who opens their Aeternum app on any device automatically extends their inactivity deadline across every protected chain — without needing to manually interact on each network individually.

For users who prefer a more hands-on approach, the manual ping() function remains available on each chain's contract independently.

---

What Carries Forward From Phase 2#

Every Phase 2 capability extends to each Phase 3 deployment unchanged:

• Hybrid wallet architecture — the EIP-7702 account model, with ETH and ERC-20 assets remaining in the user's self-custodial address on each chain
• Multi-asset recovery — ETH and all registered ERC-20 balances on each chain transfer to the designated backup address on that same chain when recovery triggers
• Passive activity detection — opening the app triggers a background ping on every chain where the user has a registered vault, with no manual interaction required
• Per-token failure isolation — individual ERC-20 transfer failures are retried independently without blocking recovery of other assets on the same chain
• The keeper network's scan-validate-execute model — each chain's deployment is monitored by its own instance of the same off-chain discovery, on-chain validation, and batched permissionless execution pipeline described in Keeper Network. There is no on-chain scan position on any chain, Phase 3 included.
• MAX_RECOVERY_ATTEMPTS abandonment handling — each chain's deployment enforces the same three-attempt ceiling on ETH recovery, with per-token failure tracking for ERC-20s, independently of every other chain's deployment.
• Permissionless execution — no access gate — exactly as on Ethereum mainnet, no chain's deployment gates recovery execution behind a designated caller. Any address, on any chain, may call recovery for a due wallet; the contract's own validation is what makes that safe, not who is asking.

Phase 3 is not about re-engineering the wheel, but rather taking a mature asset-protection engine and expanding its footprint globally across networks.