What you will learn
- How Clavion’s architecture provides key isolation through trust domains
- The complete transaction execution pipeline
- How policy rules control what transactions are allowed
- How the approval model balances security with automation
Concept map
Clavion’s security model rests on four foundational concepts:Architecture
System components, package layout, and how they interconnect.
Trust Domains
The three-domain isolation model that keeps keys safe from untrusted code.
Transaction Lifecycle
Every step from intent submission to on-chain confirmation.
Policy Engine
Configurable rules that decide which transactions are allowed, denied, or require approval.
Approval Model
Human-in-the-loop confirmation with CLI, web dashboard, and Telegram support.
Design philosophy
Clavion is intentionally conservative:- Closed action set. Only five transaction types are supported (transfer, transfer_native, approve, swap_exact_in, swap_exact_out). No arbitrary calldata signing.
- Fail-closed defaults. The default policy denies all value-bearing transactions. You must explicitly configure limits.
- Defense in depth. Multiple independent enforcement layers (schema validation, policy engine, preflight simulation, approval flow, audit trail) ensure no single failure compromises the system.
- Intent, not execution. Agents express what they want to do. Clavion decides how (and whether) to do it.