Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.dzap.io/llms.txt

Use this file to discover all available pages before exploring further.

Letting an LLM control a wallet is risky. ZapBot’s design makes the dangerous parts opt-in, observable, and bounded.

​
Threat model

What we defend against:
  1. LLM hallucination — model invents an address, token, or amount.
  2. Prompt injection — third-party content steers the agent.
  3. Replay — leaked signatures reused for new transactions.
  4. Key exfiltration — process compromise leaks the wallet key.
What we don’t defend against:
  • Compromised infrastructure where the LLM provider is malicious.
  • User error (typing the wrong account into metadata).

​
Defenses

​
1. Session-scoped keys

Wallet keys live only in process memory and only when needed. They are:
  • Never written to disk or logs.
  • Never sent to the LLM provider.
  • Wiped on process exit.
In code, signing happens in zapRegistry after explicit user confirmation. The LLM gets the result of the signature (a tx hash), never the key.

​
2. Confirmations on execution

Tools split into two classes:
ClassExamplesConfirmation?
ReadBalanceTool, PriceTool, PoolToolNo
WritePerformZapTool, ZapCallDataGeneratorToolYes — by default
For write tools, ZapBot surfaces a plan and pauses until the user confirms in the shell or via the SDK’s onConfirmation callback.

​
3. Hash-bound intents

When you use gasless intents, the signature commits to:
  • executorFeesHash — fees can’t be inflated.
  • swapDataHash — swap path can’t be substituted.
  • deadline — past expiry, signature is dead.
A compromised relayer can’t profit from a leaked signature.

​
4. Observability

Every tool call is logged with inputs, outputs, and timestamps. Plug result.toolCalls into your observability stack.

​
Best practices for embedding

If you embed ZapBot in a product:
  • Limit per-session value. Your wrapper should reject PerformZapTool calls above a threshold the user explicitly set.
  • Whitelist tokens. For consumer apps, restrict the agent to a set of vetted tokens.
  • Clear separation of read vs write. Run read-only agents in untrusted contexts; gate write paths behind user UI confirmations.
  • Don’t pass production keys to dev agents. Use a dev wallet with capped funds for testing.

​
What to avoid

  • ❌ Passing a long-lived hot wallet key to an unsupervised CLI session.
  • ❌ Letting an agent sign without confirmation in production.
  • ❌ Running an agent over user-generated content (chat threads, emails) without an injection-proofing layer.

​
When something goes wrong

If a transaction settles incorrectly:
  1. Capture result.toolCalls for the failing turn.
  2. Cross-reference the tx hash with getZapTxnStatus / on-chain explorer.
  3. If a refund is owed (cross-chain failure), the refundee address gets it back automatically.
  4. Open an issue in Discord with the trace.