Phase 4 — Financial Primitive

The Premise#

Every feature in Phases 1–3 is about protecting what you already have. Phase 4 asks a different question: what if self-custody and on-chain capital efficiency weren't a trade-off — what if your own smart account could permissionlessly execute yield strategies and automate payments without delegating custody to anyone?

Phase 4 transforms the Aeternum hybrid wallet from a recovery tool into a fully programmable financial primitive. The inheritance guarantee from Phase 1 remains the bedrock — it is never weakened, never traded off. Everything in Phase 4 is purely additive and entirely opt-in. No core wallet behavior changes, and assets always remain entirely within the user's own custody. Activating a yield strategy does not transfer control to any third party — it instructs the user's own smart account to execute pre-authorized on-chain logic autonomously.

---

Self-Custodial Yield Automation#

Users who want their capital productive can initialize yield strategies directly from their Aeternum wallet. There is no intermediary routing funds — the user's own wallet executes the on-chain logic to deposit into established, independently audited DeFi protocols. The user holds the resulting yield-bearing positions natively in their own account.

Three strategy tiers are planned:

Conservative#

The account programmatically mints a liquid-staking receipt token, earning native Ethereum staking rewards — Lido's stETH is the clearest example available today. Liquid staking tokens like this typically rebase or accrue automatically, so the user's balance grows without any additional transactions.

• Risk profile: low — backed close to 1:1 by ETH staked with the protocol's node operators
• Liquidity: high for established liquid-staking tokens, which trade at near-parity with ETH on major DEXes
• Expected yield: tracks Ethereum validator rewards, historically in the ~4–5% APY range

Balanced#

The account deposits assets directly into an established on-chain lending market, accumulating variable lending yield in an interest-bearing receipt token — Aave V3 is the clearest example available today. Yield fluctuates with market borrow demand.

• Risk profile: moderate — smart contract risk plus utilisation rate variability
• Liquidity: high when pool utilisation is below 100%
• Expected yield: typically 2–8% APY depending on market conditions

Optimised#

The account dynamically allocates capital across multiple verified protocols based on live yield spreads. The rebalancing itself is fully authorized by the user in advance — no signature or judgment call from any off-chain party is required at execution time. A keeper simply calls a pre-authorized rebalancing function on the user's own account, on schedule or when spread conditions are met — the same permissionless trigger-not-authority pattern used everywhere else in the protocol: the caller has no say over what the logic does, only whether it runs.

• Risk profile: moderate — additional complexity from multi-protocol exposure
• Liquidity: depends on allocation mix
• Expected yield: targets best available on-chain rate at any given time

---

Predictable — Fixed-Rate Stablecoin Vaults#

The three tiers above are all variable-rate — the yield a user actually earns moves with market conditions. A beneficiary who isn't crypto-native will find "this earns a fixed rate" far easier to understand than "this holds a receipt token whose yield floats with utilization." A fourth, fixed-rate option is planned to close that gap.

The Aeternum wallet will let users deposit into an externally-operated, independently audited fixed-rate vault built to the ERC-4626 standard — emerging products like Aave's Stable Vaults are the clearest reference point today, though the actual protocol integrated will depend on audit completion and market conditions at implementation time, per the note above. The resulting vault shares sit natively in the user's own smart account, exactly like the other three tiers: Aeternum sets no rate, captures no yield spread, and bears no risk if the vault's return falls short of anything promised to the user. This is a routing and discovery layer, not a new trust relationship — fully consistent with the "no intermediary" principle stated at the top of this page.

---

Programmable Position Unwinding#

Because yield-bearing positions are held natively by the user's own address, they fall completely under Aeternum's recovery architecture. When recovery triggers on a wallet holding a yield-bearing position, the contract does not simply attempt to transfer that token — it first unwinds the position into base ETH, then transfers the proceeds.

This is necessary because yield-bearing and rebasing tokens have unique transfer mechanics that do not map cleanly to a simple "send to backup address" flow. The two examples below use today's reference protocols to illustrate the pattern the recovery manager follows — the same unwind-then-transfer approach applies to whichever protocols are actually integrated at launch.

Example: Unwinding a Liquid Staking Position (stETH)#

The AeternumRecoveryManager either routes through the Curve stETH/ETH pool for immediate settlement or initiates a Lido native withdrawal — the execution path is determined at recovery time based on liquidity conditions and speed requirements.

Example: Unwinding a Lending Position (aWETH)#

The AeternumRecoveryManager invokes Aave Pool's withdraw() function directly from the user's account context to redeem the underlying WETH plus all accrued interest. It then unwraps the WETH to native ETH and completes the recovery transfer.

If an Aave pool hits 100% utilisation and temporarily restricts withdrawals, the system falls back to the MAX_RECOVERY_ATTEMPTS retry loop — gracefully retrying on the keeper network's subsequent cycles rather than failing permanently.

---

The Automated Disbursement Layer#

This is where Aeternum's recovery infrastructure becomes a general-purpose programmable execution layer — disbursement and inheritance triggering through the same underlying primitives.

Consider a user who holds 50 ETH in their Aeternum wallet. They choose to:

• Keep 30 ETH in recovery-only mode, earning no yield
• Route 20 ETH to a lending market for yield
• Configure a disbursement rule: send 0.1 ETH to their children's wallets on the first of every month
• Set a recovery trigger: if inactive for 365 days, send everything to their designated beneficiary

The keeper network executes all of it. The monthly disbursements run on the same permissionless scan-validate-execute pipeline that drives recovery monitoring — the same keepers (the Aeternum Labs bot, Gelato, and Chainlink CRE) simply call the pre-authorized disbursement logic on schedule, exactly the way they call recovery for a wallet that's become due. The inheritance trigger and the disbursement triggers share the same underlying primitive: a monitored wallet with programmable execution rules, and callers who can only ask the contract to check its own conditions — never decide the outcome themselves.

---

Enterprise APIs#

Phase 4 exposes Aeternum's infrastructure as a programmatic API surface for institutions and developers building on top of it.

Use cases being designed:

Treasury automation. A company treasurer configures recurring payroll disbursements from a yield-bearing treasury account. The Aeternum recovery layer provides a fallback if the treasury becomes unmanaged — assets route to a designated succession address automatically.

DAO grant distribution. A DAO configures automated grant payments with built-in inheritance fallback. If the DAO's governance becomes inactive, assets can route to a community-controlled multisig.

Custody tools. Builders can integrate the recovery engine and disbursement infrastructure without developing their own off-chain indexing pipeline, on-chain validation logic, or keeper infrastructure from scratch.

Compliance and estate planning. Institutional users can configure auditable recovery flows that satisfy legal requirements for digital asset succession.

The API surface will be documented in full as Phase 4 contracts are designed and audited. The recovery guarantee — that the user's assets go where they configured, automatically — remains the foundation everything else is built on.

---

What Carries Forward From Phase 3#

Phase 4 builds on the complete Phase 3 stack. Every multichain capability carries forward unchanged:

• Independent per-chain deployments — each supported network continues to run its own AeternumRecoveryManager, monitored independently by the same off-chain discovery / on-chain validation keeper pipeline described in Keeper Network. No chain gates recovery or disbursement execution behind a designated caller — every keeper on every chain is permissionless, exactly as on Ethereum mainnet. Phase 4 introduces no cross-chain dependencies between these deployments, consistent with the multi-chain orchestration model established in Phase 3.
• Multi-asset recovery with yield position unwinding — ETH and all registered ERC-20 balances remain recoverable on every chain. Phase 4 extends this by adding programmatic unwinding of yield-bearing positions — illustrated earlier using stETH and aWETH as worked examples of the pattern — at recovery time, so beneficiaries receive settled assets rather than positions they may not know how to manage.
• Activity synchronisation across chains — opening the Aeternum app continues to reset the inactivity timer across all registered vaults via the independent per-chain background signature flow established in Phase 3.
• Per-chain beneficiary configuration — backup addresses and inactivity periods remain independently configurable per chain.

Scaling for Phase 4 Volume#

What Phase 4's volume does stress is throughput on the execution side: more due wallets, plus — new at this phase — disbursement calls competing for the same submission pipeline. The scaling path for that is the one Keeper Network already describes as the planned direction: horizontal signers. A single keeper submits batches sequentially from one private key today; running multiple independent signing keys lets multiple batches be in flight at once, with throughput scaling roughly linearly per signer added, and no change required to the contract itself. Phase 4's combined recovery-and-disbursement load, across every supported chain, is a plausible point where that stops being a documented direction and becomes an operational necessity.

None of this requires a contract change. Every keeper — the Aeternum Labs bot, Gelato, Chainlink CRE, and any additional signer or operator brought on to handle Phase 4 volume — remains just another permissionless caller of the protocol's entry points, with no more leverage over the outcome than any keeper has ever had.