AI Architecture

DZap AI uses one runtime (DZapSDK) behind four interfaces: SDK, CLI, HTTP, and MCP. The model decides what to call; runtime code decides what is allowed to execute.

Core runtime behavior

Startup requires DZAP_STARTUP_PASSWORD
Every ask call requires metadata.accountInfo[]
Metadata is sanitized before prompt injection (private_key is excluded)
Session memory is in-process and keyed by generated sessionId

Model and tool calling

LLM adapter: @ai-sdk/openai with generateText(...)
Default model: gpt-4o-mini (DZAP_OPENAI_MODEL override)
Tool choice: automatic
Step cap: stepCountIs(25)
Retries: DZAP_MODEL_MAX_RETRIES (default 2)
Timeout: DZAP_MODEL_TIMEOUT_MS (default 4500000)

Tool exposure pipeline

ToolFactory -> EXPOSED_TOOL_NAMES -> SDKToolsRegistry -> DZapSDK -> CLI / HTTP / MCP

All exposed tools are wrapped by SDKTool, which:

validates input with zod when schema is present
executes tool code
normalizes JSON-string payloads into structured objects
returns duration + typed result/error details

Session logging

Each session captures:

metadata snapshot
conversation timeline
structured tool logs
summary counters

You can retrieve this through getSessionHistory(sessionId) or GET /sessions/:sessionId/history.

Scheduler and persistence

Storage: SQLite via better-sqlite3
Default DB: schedules.db (DB_PATH override)
Statuses: pending, running, done, error
Scheduler loop: runs periodically (60s default from server startup)

The on-chain trigger evaluator currently exists, but the final execution hook is still a stub.

End-to-end flow

User input
  -> ask()
  -> tool planning + calls
  -> optional interactive confirmation (zap/chain change)
  -> final response + step trace
  -> session log persistence

Safety & Execution

Interactive gates and execution controls.

SDK-AI

API methods and direct tool execution examples.

​Core runtime behavior

​Model and tool calling

​Tool exposure pipeline

​Session logging

​Scheduler and persistence

​End-to-end flow

​Related pages