DZap AI separates planning from execution so the model can reason freely without directly controlling chain writes.
Core rule
The model can suggest actions; runtime controls whether those actions execute.
Execution classes
| Class | Examples | Confirmation |
|---|
| Read | prices, balances, pools, docs retrieval | none |
| Plan/Build | route generation, calldata build | none (but reviewed in response) |
| Interactive execute | PerformZapTool, ChangeChainTool | explicit user confirmation |
Built-in controls
- Startup password gate (
DZAP_STARTUP_PASSWORD)
- Required wallet metadata per ask call
- Prompt-level metadata sanitization (no
private_key in model prompt)
- Step cap (
25) and model timeout/retry controls
- Session logging for all tool activity
Interactive flow controls
- Route must already be generated and cached for the session.
- Runtime requests explicit confirmation (SDK/CLI driven).
- Approvals and transaction execution happen only after confirmation.
- Tool waits for user confirmation.
- Timeout is 120 seconds.
- Resolution is completed through
POST /zap/chain/:sessionId.
Safe execution pipeline
intent -> tool planning -> route/build -> user confirmation -> execute -> session log
Logging and traceability
Session history includes metadata, conversation timeline, tool logs, and summary counters.
See ZapBot Safety for runtime-level safety guidance. Last modified on May 26, 2026
