What DAEMON emits to Voight
DAEMON maps its native activity to Voight’s event taxonomy. Every action the IDE performs — whether the Claude agent reasoning over a patch, the integrated terminal runningsolana program deploy, or the user approving a Phantom signature — lands as a typed event you can filter and trace.
| Event type | DAEMON activity captured |
|---|---|
reasoning | Claude / Codex chat turns, agent analysis — with model and duration |
action | Agent lifecycle, file patches, terminal commands, filesystem operations |
tool | Tool execution (Shipline steps, MCP tool calls) with outcome + timing |
decision | Approval workflows — policy metadata captured |
tx | Solana transactions — amount, token, status, signature |
error | Runtime failures with source context |
sessionId in metadata so a single DAEMON workspace run groups cleanly in /dashboard/traces.
Architecture
DAEMON uses Voight’s raw HTTP path —POST https://api.voight.xyz/v1/events — directly from the Electron main process. The VOIGHT_KEY lives in DAEMON’s secure storage and is never exposed to renderer code or to the agent runtime. Renderer-side JavaScript and any running agent see only the IPC events DAEMON exposes; the key and the ingestion endpoint stay in main.
This is the cleanest pattern for any Electron / Tauri / sidecar architecture that wants to observe an in-process agent without leaking credentials into the runtime the agent has access to.
Setup inside DAEMON
Users configure the integration in-app — no code changes:- Generate a Voight key at voight.xyz/dashboard/settings. The key is shown once and prefixed
vk_. - Open DAEMON Settings → Integrations → Voight Observability and paste the key.
- Pick a privacy level — defaults to
standard(recommended). - Send a test event — DAEMON ships one synthetic event and verifies it lands in your Voight dashboard before any live agent run.
- Run an agent — every subsequent event streams to Voight in real time.
Privacy — three levels, scrubbed locally
DAEMON implements Voight’s three-level privacy model in the main process, so scrubbing happens before transmission — sensitive content never leaves the machine in clear form.| Level | Behaviour |
|---|---|
| Minimal | Timing + outcomes only. No prompts, no responses, no file paths, no commands. |
| Standard (default) | Full content with local pattern scrubbing applied to prompts, responses, terminal output, and metadata. |
| Full | Raw content as captured. Internal debugging only. |
Retry + status handling
DAEMON respects Voight’s ingestion contract exactly:| Status | DAEMON behaviour |
|---|---|
202 Accepted | Event ingested |
400 | Bad payload — skip retry, surface in DAEMON’s local error log |
401 | Invalid VOIGHT_KEY — DAEMON shows a credentials error |
410 | Agent deleted in Voight — DAEMON stops sending for that agent |
429 | Rate-limited — back off honouring Retry-After |
5xx | Transient — retry with exponential backoff |
Why this combination works
DAEMON gives you the workspace where Solana agents run: Claude / Codex reasoning over real code, Shipline pushing programs to devnet/mainnet, Phantom signing transactions, MCP tools touching Helius / Jupiter / Metaplex / PumpFun. That’s a dense, high-stakes surface — agents proposing on-chain actions with real money attached. Voight gives that surface a memory. Every agent decision, every tool the agent reached for, every approval the human gave or denied, every transaction signature, every error — reviewable in a timeline, grouped by session, filterable by model / outcome / tool, costed automatically. The two products compose without either side needing to know the other’s internals: DAEMON speaks Voight’s HTTP contract from the main process, Voight stores and renders.Links
- DAEMON website · DAEMON GitHub (MIT)
- DAEMON’s Voight integration guide
- Voight HTTP API — the surface DAEMON uses
- Event types reference
- Privacy overview · PII patterns