Skip to main content

​
What you will learn

  • How Clavion is organized as a monorepo of specialized packages
  • The role of each package in the transaction pipeline
  • How components communicate across trust domain boundaries

​
System overview

Clavion is a monorepo of 14 TypeScript packages, each belonging to exactly one trust domain. The packages are connected by TypeScript project references and npm workspaces. 
┌────────────────────────────────────────────────┐
│           Domain A (Untrusted)                 │
│  adapter-openclaw  adapter-mcp  plugin-eliza   │
│  adapter-telegram                              │
│       │              │              │          │
│       └──────────────┼──────────────┘          │
│                      │ HTTP (localhost:3100)    │
├──────────────────────┼─────────────────────────┤
│           Domain B (Trusted)                   │
│                      ▼                         │
│              ┌─── core ───┐                    │
│              │  API Server │                   │
│              │  TX Builders│                   │
│              └─────┬───────┘                   │
│         ┌──────────┼──────────┐                │
│      policy    preflight   signer              │
│      audit     registry                        │
├────────────────────────────────────────────────┤
│           Domain C (Limited Trust)             │
│              sandbox                           │
│       (Docker containers, no keys)             │
└────────────────────────────────────────────────┘

​
Package responsibilities

​
Domain A — Untrusted (Agent Adapters)

PackagePurpose
@clavion/adapter-openclawOpenClaw skill wrappers with ISCLClient
@clavion/adapter-mcpMCP server exposing 6 tools for Claude Desktop / Cursor
@clavion/plugin-elizaElizaOS plugin with 5 actions + wallet provider
@clavion/adapter-telegramgrammY-based Telegram bot with inline approval
All Domain A packages share a common pattern: construct a TxIntent, send it to ISCL Core via ISCLClient (HTTP), and return the result.

​
Domain B — Trusted (ISCL Core)

PackagePurpose
@clavion/coreFastify API server, TX builders, approval service, RPC routing
@clavion/signerEncrypted keystore (scrypt + AES-256-GCM), wallet service
@clavion/auditAppend-only SQLite audit trail, rate limiting
@clavion/policyPolicy engine with configurable rules
@clavion/preflightTransaction simulation via eth_call, 7-factor risk scoring
@clavion/registrySkill manifest validation, ECDSA signature verification
@clavion/typesShared TypeScript interfaces and JSON schemas

​
Domain C — Limited Trust (Sandbox)

PackagePurpose
@clavion/sandboxDocker container runner with aggressive isolation

​
Communication model

All cross-domain communication flows through the ISCL Core HTTP API: 
Domain A  ──HTTP──▶  Domain B (ISCL Core API, port 3100)
Domain C  ──HTTP──▶  Domain B (ISCL Core API, port 3100)
  • Domain A and Domain C never communicate directly
  • No shared memory, no direct function calls, no file-based channels
  • The API is bound to 127.0.0.1 — only local processes can connect

​
Technology stack

ComponentTechnologyRationale
LanguageTypeScript (ESM, Node 20+)Type safety, ecosystem
APIFastify + JSON SchemaPerformance, strict validation
EVMviemModern, typed, tree-shakeable
ValidationAJV (strict mode)Fast, standard-compliant
DatabaseSQLite via better-sqlite3Embedded, zero-config, WAL mode
Encryptionscrypt + AES-256-GCMIndustry standard key encryption
HashingJCS + keccak256Deterministic canonicalization
SandboxDockerProcess isolation, resource limits
TestingvitestFast, ESM-native

​
Next steps