Frequently Asked Questions

Common questions about custody guarantees, fees, keeper reliability, upgradeability, and permissionless execution.

Custody and Control

Can the protocol take my ETH?

No. There is no mechanism of any kind that allows anyone — including the people who built this — to access your vault balance.

Your ETH can only move in two ways: on your direct instruction — through withdrawAll() (which returns your full balance to your connected wallet) or send() (which transfers any amount to any address you choose) — or to your pre-configured backup address via automated recovery after your inactivity period expires. No other path exists. The contract has no owner function, no admin key, no pause mechanism, and no upgrade path. The deployed bytecode is the permanent, immutable rule set.

Can Aeternum Labs access my funds?

No. The team that built AeternumVault has no privileged role in the deployed contract. There is no onlyOwner modifier on any fund-handling function, and no address known to Aeternum Labs has any special capability over your vault.

There is no entity with elevated permissions of any kind — not Aeternum Labs, not a designated caller, not anyone. Recovery execution (triggerRecovery()) is permissionless: literally any address can call it, but the caller supplies only a wallet address and has zero influence over the outcome. Every condition — whether recovery executes, how much moves, and where it goes — is re-validated from your own on-chain configuration at the moment of the call. The caller is a trigger, not an authority. See Key Actors for the full explanation of why no access gate is needed.

Is the contract upgradeable?

No. Each deployed version of AeternumVault is immutable and cannot be modified after deployment. There are no proxy contracts, no transparent upgrade patterns, and no governance mechanisms that could alter how an existing vault contract behaves once users deposit into it.

This is intentional. The rules you agree to when registering remain fixed for the lifetime of that deployment. Aeternum Labs will develop new versions, but they are deployed as entirely new contracts. You choose whether to remain on your current version or migrate.

Is it non-custodial if my ETH is inside the contract?

Yes, in the most meaningful sense of the term. The contract holds ETH in escrow mapped to your address — not in a shared pool, not as a loan to a protocol, not as collateral in a market. Your balance is yours, and it can only move on your instruction or after your inactivity period expires and recovery triggers.

A bank also "holds" your money, but the bank can lend it, freeze it, or lose it. The AeternumVault contract cannot do any of those things. It is more accurate to think of it as a public lockbox than a bank account.

Costs and Fees

How much does Aeternum cost?

AeternumVault v1 is completely free. There are no subscription fees, no tiers, and no protocol-level charges.

The only costs are:

Standard Ethereum gas fees for transactions you initiate (register, deposit, send, etc.)
Nothing for monitoring — the Aeternum Labs keeper bot that watches your vault and submits recovery transactions pays the ETH gas itself as an operating cost, not passed on to individual users

This is a deliberate policy. Foundational wallet safety should be accessible to everyone without friction. The core v1 protocol is, and will always remain, completely free to use.

Why is it free if someone has to pay gas to execute recovery?

Aeternum Labs runs the keeper bot that watches vaults and submits triggerRecovery transactions, and absorbs the ETH gas cost as an operating expense rather than billing it to users. Because triggerRecovery() is permissionless, this isn't a service you're structurally dependent on paying for either — anyone, including you or your backup address, could call it directly at no cost beyond gas.

Future value-added services (In-app financial services, Yield routing revenue share, Enterprise and developer APIs, institutional tools) will generate revenue to sustain this model without monetizing the core recovery mechanism.

Timer and Recovery

What happens if I forget to ping and my timer expires?

Your ETH is sent to your backup address automatically. You will need to coordinate with your designated beneficiary to move the ETH back, then call register() to restart protection.

What if I interact with other dApps but not Aeternum specifically?

Only on-chain interactions with the AeternumVault contract reset your timer. Swapping on Uniswap, voting in a DAO, minting an NFT — none of these interact with the AeternumVault contract, so none of them reset your inactivity timer.

If you are active in DeFi but not touching your Aeternum vault directly, you still need to call ping() before your inactivity period elapses. In Phase 2 and later versions, the Aeternum app will handle this automatically in the background when opened.

Can I interact with my vault after the timer expires but before recovery fires?

Yes. There is always a window between when your vault becomes eligible for recovery and when a keeper actually submits triggerRecovery() on-chain — typically seconds, occasionally longer if the keeper's cycle has a lot to process. The Aeternum Labs keeper bot cycles roughly every 12 seconds, so this window is usually short — but it exists.

If you ping or deposit in that window, your timer resets and recovery is no longer eligible. triggerRecovery() re-validates every condition from scratch at the moment it executes, regardless of what any off-chain keeper believed was true when it decided to submit the call. If your vault is no longer eligible, the call silently returns and no ETH moves. See Automatic Recovery for the full mechanics.

What if I want a shorter inactivity period on mainnet?

The minimum on mainnet is 180 days. This floor is enforced immutably in the contract — it cannot be lowered.

On Sepolia testnet, the minimum is 5 minutes, which allows the full recovery cycle to be tested in a single session. See the Testnet Walkthrough for a step-by-step guide.

Your Beneficiary

What if my beneficiary loses access to their address?

As long as your own primary wallet is still accessible, you can update the backup address at any time by calling updateBackupAddress(). Your inactivity timer resets as a side effect.

If your designated beneficiary has changed — a new primary heir or an update to your estate plan — the same function handles it. There is no limit to how many times you can update your beneficiary address.

The backup address only matters if recovery actually triggers — and recovery only triggers after your full inactivity period elapses with no interactions. As long as you remain active and in control of your primary wallet, you control who receives your assets and when.

What if my beneficiary's address fails to receive ETH?

If the backup address cannot accept ETH — for example, a multisig or smart contract that is misconfigured to reject plain ETH transfers — the recovery attempt fails. The contract:

Restores your vault balance
Increments the failed attempt counter
Re-adds your vault to monitoring for retry
Emits a RecoveryFailed event

The keeper network will retry up to three times. After three consecutive failures, the vault is permanently abandoned — your balance remains accessible via withdrawAll(), but automatic monitoring stops and that backup address is permanently blocked from future use. See Automatic Recovery for the full failure-handling lifecycle.

This is why testing your beneficiary's address before registering matters. Send a small test transaction and confirm receipt. If your backup is a multisig, confirm it is configured to accept plain ETH before relying on it for recovery.

Can I designate different beneficiaries across chains?

Yes. In Phase 3, each chain deployment is independently configured. You can designate a different backup address — and therefore a different beneficiary — on each chain. Common approaches: the same beneficiary across all chains for simplicity, or chain-specific multisigs held by estate trustees for different asset classes.

Can multiple people designate the same beneficiary?

Yes. The same backup address can be designated as the beneficiary for multiple different primary wallets. The restriction is one vault per primary address — there is no limit on how many primary wallets can point to the same backup.

The only restriction is that a backup address permanently blocked due to three consecutive failed recovery attempts cannot be used in any new registration, regardless of which primary wallet is attempting it.

Technical

Can I have multiple vaults?

Each Ethereum address can register one vault. If you want to protect multiple wallets, each wallet registers its own vault independently with potentially different backup addresses and inactivity periods.

Why can anyone call triggerRecovery() — isn't that a security risk?

It isn't, and the reason is worth understanding because it used to work differently. Earlier versions of this contract gated recovery execution behind a one-time-set forwarder address — only Chainlink Automation's registered forwarder was permitted to call the execution function. That model has been removed entirely.

triggerRecovery(wallet) now carries no caller restriction at all — any address can call it. This is safe because the function gives the caller no leverage to begin with: the caller supplies only a wallet address, and every subsequent decision — whether recovery executes, how much moves, and where it goes — is made exclusively from storage the vault owner wrote. The caller cannot redirect funds, force an early recovery, or influence the outcome in any way.

Removing the single designated caller doesn't weaken this safety property — it removes a dependency on any one party, such as a single automation provider, remaining available to submit the transaction. See Key Actors for the full explanation.

What if the keeper bot goes down?

If the Aeternum Labs keeper bot were ever unavailable, your ETH would simply remain in your vault, unrecovered, until service resumed — or until someone else calls triggerRecovery() on your behalf, since the function has no access restriction. Gelato Network is planned as an independent backup keeper (Phase 2). Chainlink CRE joins in Phase 3 as a multi-chain orchestrator — additional, independently-operated callers of the same permissionless function.

The worst-case outcome of any keeper outage is a delay in recovery, not loss of funds. See Keeper Network for the full architecture.

Does AeternumVault accept ETH sent directly to the contract address?

No. The contract's receive() function reverts unconditionally:

receive() external payable {
    revert AeternumVault__DirectTransferNotAllowed();
}

If you accidentally send ETH directly to the contract address without using deposit() or register(), the transaction fails and your ETH is returned. This prevents funds from becoming permanently stranded with no vault association.

What is the contract address on Sepolia?

The AeternumVault contract on Ethereum Sepolia is deployed at:

0x9Eb95e4b47aECCB131f20AE7af33A29832499067

You can explore it on Sepolia Etherscan, including all transactions, events, and the verified source code.

Mainnet deployment will be announced publicly after the external security audit is complete.

What is the difference between withdrawAll() and cancelRecovery()?

Both functions return ETH to your wallet. The difference is what happens to your vault afterwards:

withdrawAll() — returns your entire balance but keeps your vault active. You remain registered and monitored. You can deposit again at any time. Your timer resets.
cancelRecovery() — returns your entire balance AND deregisters your vault. You are removed from monitoring entirely. To re-activate recovery protection, you must call register() again.

Use withdrawAll() when you want all your ETH back temporarily but plan to continue using the vault. Use cancelRecovery() when you want a clean exit.

Can I deploy AeternumVault to mainnet myself?

Not without a commercial license from Aeternum Labs.

AeternumVault is published under the Business Source License 1.1 (BUSL-1.1). The BUSL permits non-production use — local development, testing, academic research, and deployment on public testnets like Sepolia — without restriction. Production deployment on any mainnet blockchain is not permitted under the base license.

The Change Date: The license converts automatically to GNU GPL v3.0 or later on the earlier of (a) four years from the date of the first official Aeternum mainnet deployment, or (b) January 1, 2031. After the Change Date, anyone may deploy, fork, and build on AeternumVault freely under the terms of GPL-3.0.

If you want to deploy AeternumVault in a production environment before the Change Date, contact Aeternum Labs to discuss a commercial license.