Overview
An adapter is a Domain A component that bridges an AI agent framework to the ISCL secure signing layer. Adapters construct declarativeTxIntent objects, call ISCL Core over HTTP, and present results back to the agent or user. They never touch private keys, never sign transactions, and never call the blockchain directly.
Every adapter in the Clavion ecosystem follows the same four-step contract:
- Accept user/agent input (natural language, command, tool call).
- Build a
TxIntentdescribing the desired on-chain action. - Send the intent through the ISCL Core API for policy checks, simulation, approval, signing, and broadcast.
- Return the result to the caller.
Architecture Pattern
Every adapter sits between the agent framework and ISCL Core, acting as a translation layer. Component overview:Existing Adapters
All four adapters share the same core pattern:ISCLClient + buildIntent() + executeSecurePipeline(). The only differences are how they receive input and present output.
1
2
ISCLClient
Copy The constructor reads the base URL from three sources in priority order:Common error codes:
src/shared/iscl-client.ts from any existing adapter. The client is framework-agnostic and identical across all adapters. It wraps the ISCL Core REST API with typed methods.Constructor
options.baseUrl(explicit)ISCL_API_URLenvironment variablehttp://127.0.0.1:3000(default)
Key Methods
Error Handling
All methods throwISCLError on non-2xx responses:3
Intent Builder
The intent builder converts framework-specific parameters into a
TxIntent object. Every adapter has one, and they are nearly identical.Building Actions for Each Type
- ERC-20 Transfer
- Native ETH Transfer
- ERC-20 Approval
- Swap (exact input)
4
Handler Functions -- The 2-Step Pipeline
Every fund-affecting operation follows the same two-step pipeline:
txApproveRequest(intent)— Sends the intent to ISCL Core, which runs policy checks, preflight simulation, and prompts the user for approval. This call blocks until the user approves or denies.txSignAndSend({ intent, approvalTokenId })— If approved, sends the intent with the single-use approval token. ISCL Core verifies the token, signs the transaction, and broadcasts it.
Shared Pipeline Function
Extract this intosrc/shared/pipeline.ts so all handlers share the same logic:Complete Handler Example
Read-Only Operations
Balance checks and transaction lookups do not require the approval pipeline:5
Framework Integration
Each framework has its own way of registering tools, commands, or actions. Below are the patterns used by the four existing adapters.
- MCP
- ElizaOS
- Telegram
- OpenClaw
Register tools on an
McpServer instance. Each tool has a name, description, Zod schema, and async handler.Key file:
packages/adapter-mcp/src/server.tsSecurity Checklist
Every adapter must satisfy these five invariants. Violations break the trust model and will be caught by thedomain-b-integrity.test.ts security test suite.
Complete Minimal Example
A self-contained adapter that works with any framework. This example implements a transfer handler in approximately 60 lines:transfer() from whatever command, tool, or action handler your framework provides.
Further Reading
- API Reference — Full endpoint documentation and response schemas
- TxIntent Schema — Detailed schema definitions
- Trust Domains — Domain A/B/C boundaries explained
- Development Setup — Local development environment
- Repository Structure — Package layout and dependencies