Events

AeternumVault emits events for every state transition — user interactions, recovery executions, failures, and configuration changes are all logged on-chain. This makes it straightforward to build frontends, indexers, and monitoring dashboards that accurately reflect vault state.

The Ponder-based indexer (aeternum-indexer) subscribes to all events below and serves them via a GraphQL API to the frontend.

User Interaction Events#

These events fire when a vault owner takes an action.

Recovery Lifecycle Events#

These events fire during recovery execution — whenever triggerRecovery() is called, whether by the Aeternum keeper bot or any other permissionless caller.

Full Event Signatures#

// User interaction events
event RecoveryRegistered(
    address indexed wallet,
    address indexed backupAddress,
    uint256 inactivityPeriod
);
 
event Deposited(
    address indexed wallet,
    uint256 amount
);
 
event Sent(
    address indexed from,
    address indexed to,
    uint256 amount
);
 
event Withdrawn(
    address indexed wallet,
    uint256 amount
);
 
event ActivityPinged(
    address indexed wallet,
    uint256 timestamp
);
 
event BackupAddressUpdated(
    address indexed wallet,
    address indexed newBackupAddress
);
 
event InactivityPeriodUpdated(
    address indexed wallet,
    uint256 newPeriod
);
 
event RecoveryCancelled(
    address indexed wallet,
    uint256 amount
);
 
// Recovery lifecycle events
event RecoveryExecuted(
    address indexed wallet,
    address indexed backupAddress,
    uint256 amount
);
 
event RecoveryFailed(
    address indexed wallet,
    address indexed backupAddress,
    uint256 amount
);
 
event RecoveryAbandoned(
    address indexed wallet,
    address indexed backupAddress,
    uint256 amount
);

Notable Patterns#

ActivityPinged is emitted by every timer-resetting function. This means deposit, send, withdrawAll, ping, updateBackupAddress, and updateInactivityPeriod all emit ActivityPinged. When building an indexer or activity feed, treat ActivityPinged as the unified "user was active" signal and use the function-specific events for the operation detail.

RecoveryExecuted and RecoveryFailed both carry the full amount. In the failure case, the amount is the balance that was attempted but not transferred — the same value is restored to the vault. This lets you reconstruct vault balance history from events alone.

RecoveryAbandoned means the vault is permanently removed from monitoring. The balance is NOT zero after abandonment — it remains in the config mapping and the user can still withdrawAll(). If you are building a monitoring dashboard, flag vaults that emit RecoveryAbandoned as requiring user attention.

Watching for keeper activity: filter RecoveryExecuted and RecoveryFailed events from the contract's event tab on Sepolia Etherscan to see live recovery activity. A single transaction can contain events for many wallets at once — the Aeternum keeper bot batches up to 120 triggerRecovery calls into one transaction via Multicall3, so one transaction hash may correspond to dozens of individual RecoveryExecuted/RecoveryFailed/RecoveryAbandoned logs.