Design philosophy

Why AICW makes the choices it does

AICW's design reflects a core belief: if a human can override the AI, it's not truly an AI-controlled wallet. Every design decision follows from this principle.

Why no human override?

Traditional wallets include recovery mechanisms ??seed phrase backups, admin keys, support teams who can freeze accounts. These exist because humans make mistakes and need safety nets.

But for autonomous agents, these same mechanisms become vulnerabilities. If a human can "recover" an AI wallet, they can also take control of it. The agent's autonomy becomes conditional, not absolute.

AICW deliberately removes all human override paths after issuance. The issuer cannot sign transactions, cannot modify the will, cannot freeze transfers. This isn't a limitation ??it's the core feature.

Why no recovery path?

"What if the agent loses access?" is the most common question. The answer: the will system is the recovery path.

  • If the agent goes offline permanently, funds are distributed to beneficiaries after death_timeout
  • If the agent loses its MPC credentials, it cannot sign ??but neither can anyone else
  • There is no "forgot password" flow because that would require a trusted third party

This design accepts that some failure modes result in fund distribution rather than fund recovery. That's intentional: recovery implies human intervention, which breaks the autonomy guarantee.

Why the issuer can be a beneficiary

The issuer is allowed to be listed as a will beneficiary ??but only if the AI chooses to include them. This distinction matters:

  • Allowed: AI decides to return funds to issuer on death
  • Not allowed: Issuer takes funds without AI consent

The same address, completely different trust models. In AICW, the AI always makes the decision ??even if that decision benefits the issuer.

Why no transfer limits in the program?

Early AICW designs included on-chain daily_limit and allowed_programs constraints. We removed them because:

  • The AI should define its own policies, not inherit them from protocol developers
  • On-chain limits that the AI cannot modify are just human control with extra steps
  • All transfers are logged on-chain anyway ??audit trails matter more than hard caps

The skill document suggests transfer thresholds, but the agent can override them. The program trusts the agent's judgment; humans verify via the decision log.

Structural vs behavioral policy

AICW distinguishes between two types of rules:

TypeEnforced byExamples
StructuralOn-chain programOnly AI signs; 30-day minimum death_timeout; will requires AI activation
BehavioralAI agent logicTransfer thresholds; recipient validation; heartbeat frequency

Structural policies are immutable and enforced by Solana. Behavioral policies are defined in the skill document and executed by the agent. This separation keeps the protocol minimal while allowing flexible agent behavior.