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:
| Type | Enforced by | Examples |
|---|---|---|
| Structural | On-chain program | Only AI signs; 30-day minimum death_timeout; will requires AI activation |
| Behavioral | AI agent logic | Transfer 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.