> ## Documentation Index > Fetch the complete documentation index at: https://docs.voight.xyz/llms.txt > Use this file to discover all available pages before exploring further. # DAEMON > DAEMON — the AI-native Solana IDE — ships Voight as its observability stream for agent runs, tool calls, approval decisions, terminal activity, and Solana transactions. [**DAEMON**](https://www.daemonide.tech) is the AI-native Solana development environment — an Electron-based desktop IDE that consolidates editor, terminal, wallet, deploy pipeline, and AI agents into one workspace. Open source under MIT, available for macOS, Windows, and Linux. DAEMON integrates Voight as its **observability stream** for AI agent runs, tool calls, approval decisions, terminal activity, Solana transactions, errors, and per-session traces. Their integration guide lives at [daemonide.tech/docs/voight-observability](https://www.daemonide.tech/docs/voight-observability). ## What DAEMON emits to Voight DAEMON maps its native activity to Voight's [event taxonomy](/concepts/events). Every action the IDE performs — whether the Claude agent reasoning over a patch, the integrated terminal running `solana 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 | Each event carries a `sessionId` in `metadata` so a single DAEMON workspace run groups cleanly in `/dashboard/traces`. ## Architecture DAEMON uses Voight's [raw HTTP path](/sdk/http-api) — `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: 1. **Generate a Voight key** at [voight.xyz/dashboard/settings](https://voight.xyz/dashboard/settings). The key is shown once and prefixed `vk_`. 2. **Open DAEMON Settings → Integrations → Voight Observability** and paste the key. 3. **Pick a privacy level** — defaults to `standard` (recommended). 4. **Send a test event** — DAEMON ships one synthetic event and verifies it lands in your Voight dashboard before any live agent run. 5. **Run an agent** — every subsequent event streams to Voight in real time. The full DAEMON-side walkthrough lives at [daemonide.tech/docs/voight-observability](https://www.daemonide.tech/docs/voight-observability). ## Privacy — three levels, scrubbed locally DAEMON implements Voight's [three-level privacy model](/privacy/overview) 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. | The scrubber redacts private keys, JWTs, API credentials, email addresses, phone numbers, and payment card numbers — see [PII patterns](/privacy/pii-patterns) for the complete list (12 named patterns + Luhn-validated cards). ## 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 | Failed dispatches never block the agent — Voight ingestion is fire-and-forget by design. ## 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](https://www.daemonide.tech) · [DAEMON GitHub](https://github.com/daemonide) (MIT) * [DAEMON's Voight integration guide](https://www.daemonide.tech/docs/voight-observability) * [Voight HTTP API](/sdk/http-api) — the surface DAEMON uses * [Event types reference](/concepts/events) * [Privacy overview](/privacy/overview) · [PII patterns](/privacy/pii-patterns)