v4 liveLatest build.

Architecture

Built like an app.
Not a fork.

Product shape mirrors implementation shape: native responsibilities stay native, renderer code talks through typed contracts, and core editing keeps working offline.

main process

Database and filesystem work stay in the main process. Renderer code talks through typed handlers instead of direct access.

typed IPC

Handlers return predictable contracts for agents, wallet, git, terminals, and the rest of the app surface.

offline first

Core editing stays local through Monaco and custom protocols. The app does not depend on browser-native assumptions.

runtime

  • Electron 33
  • React + TypeScript
  • Vite
  • Monaco

native layer

  • node-pty
  • better-sqlite3
  • typed IPC
  • custom protocols

workspace

  • Zustand state
  • simple-git
  • plugin registry
  • electron-builder
daemon · project tree
▸ tree daemon/
electron/ · main · windows · lifecycle
  ipc/ · one handler per domain
  services/ · business logic
src/ · renderer panels + UI
  panels/ · working UI surfaces
  store/ · domain state · zustand
  components/ · shared primitives

Inside Daemon

The same shell, now showing more of DAEMON's Solana runtime, wallet path, launch flow, and MCP surface.

Daemon
STREAMFLOW + DAEMON
Staking, launch tooling, and Solana execution are moving into one branded access path.
Solana workspace
Choose the path that gets the project live faster.
Keep DAEMON open to everyone, then use Streamflow staking to unlock supporter access, earlier opportunities, and stronger priority without turning the IDE into a token gate.
Project
live
Solana workspace detected
DAEMON maps the repo to wallet, runtime, launch, and deploy surfaces so a new project starts with an execution path instead of a blank editor.
Current route
Operator workspace
Staking
live
Streamflow access path
Token utility now has a native home on the site: verify the wallet, open the Streamflow pool, and hand access back into DAEMON.
Supporter benefit
Pro, priority, and early access
Launch
partial
Protocol adapters
Pump.fun, Raydium, Meteora, and broader launch tooling are being collapsed into one execution surface instead of scattered setup steps.
Direction
One workspace from idea to go-live
Why stake
Early access
Major updates, launches, and ecosystem opportunities reach stakers before public rollout.
Priority access
When scarce spots, betas, or partner activations open, stakers go first.
Staker status
Supporters carry visible early-backer status across future DAEMON community and ecosystem surfaces.
Operator fit
The landing page can explain why DAEMON matters to Solana builders before asking them to commit capital.
What ships next
Finalize the production Streamflow pool and publish the branded staking route.
Wire desktop Pro to consume staking-based entitlement from the same access model.
Roll out supporter tiers that feel like access, not just a token dashboard.
Keep the staking story tied to actual Solana workflows in the app.
user
Set up the Solana launch workflow so wallet, validator, and launch adapters all use the same runtime path
assistant
I’ll route this through the Solana workspace surface: validator readiness, Helius transport, wallet assignment, and the native launch adapters for Pump.fun, Raydium, and Meteora. Opening Solana Toolbox...
user
Make sure the wallet flow shows the signing path before launch
assistant
I’ll keep the preview step visible so quotes, launch actions, and transaction confirmation all share one Solana UX instead of separate tools.
Ask Claude...
Daemonmain3
ClaudeHeliusJupiterMCP 4validator :8899