TrenchClaw
The high quality agentic ai Solana harness ✨ like openclaw 🦞 but specialized for Solana 👽 make trading bots, launch bots, build strategies, trade prediction markets and do research. Made with bun, solana/kit 6, Svelte, Helius, and more. Very gud tek 🤌🏼
Install / Use
/learn @henryoman/TrenchClawREADME
gud tek built by a long-time solami dev
Please give us a star if you're interested in seeing this project get fully built out. It will help me gauge interest. Thank you.
TrenchClaw
TrenchClaw is an openclaw-like agentic ai harness and runtime for the Solana blockchain. It's a personal solana assistant that executes modular on-chain actions, runs automated trading routines, and gives operators full visibility and control from our lightweight svelte gui. This is very dangerous and will be a while before security is perfected.
Built on @solana/kit and Bun from the ground up, with GUI/mobile surfaces planned for 1.0. Zero legacy dependencies (including legacy @solana/web3.js v1). Functional, composable, tree-shakeable. Designed for operators who care about what ships in their binary.
Current test requirement keys: helius api key for helius-backed reads, jupiter ultra key for swap flows, and an OpenRouter or Gateway API key for chat-driven workflows.
Full architecture: ARCHITECTURE.md
Translations
v0.1.0 Release Checklist
- [x] AI chat with OpenRouter and Vercel AI Gateway
- [x] Local instance sign-in, vault, and trading settings
- [x] Managed wallet reads for balances and holdings
- [x] Wallet creation, grouping, and renaming
- [x] Helius RPC-based data fetching
- [x] Dexscreener market and token research
- [x] Jupiter Ultra swaps
- [x] Jupiter Trigger API flows
- [x] Queue jobs, scheduled Ultra swaps, and action sequences
- [x] Direct transfers and token account cleanup
- [x] Runtime memory, queue, and conversation history
- [x] Operator chat now prefers token metadata and tickers over mint-only coin answers
- [x] Desktop GUI for chat, wallets, keys, settings, activity, and runtime status
- [ ] Full runtime settings editor in the GUI
- [ ] Agent-managed scheduler
- [ ] Standard swap paths beyond Jupiter Ultra
- [ ] Telegram chat connector
- [ ] Gatekeeper option for the Helius RPC link
Quick links:
- Quickstart
- Keys and Settings
- Runtime Architecture and Boundaries
- Why TypeScript?
- Why Solana Kit
- TrenchClaw vs ElizaOS and Agent Kit
Interested in sponsoring development? Support us: 7McYcR43aYiDttnY5vDw3SR6DpUxHG8GvLzhUsYFJSyA
Experimental software warning: this is currently unsafe, and unexpected behavior is highly likely if you use it.
Get Started
Use the docs for install and first-run:
Developer Runtime State
Local development should use the same per-instance runtime shape as the shipped product, while keeping mutable state outside the repo.
Default local dev behavior:
bun run devuses~/.trenchclaw-dev-runtimefor runtime state- generated prompt-support files live under
~/.trenchclaw-dev-runtime/instances/<id>/cache/generated/ - that state persists across reconnects and restarts
- that state is personal/local and never part of the repo
Important rules for contributors, reviewers, and agents:
- do not store personal vaults, wallets, logs, databases, or generated runtime state in this repository
.runtime/is the tracked contract only; runtime code must never write there- the external dev runtime keeps local testing close to a real user install without polluting PRs
- tests should use temporary runtime roots, not a shared developer runtime
Common setup:
# initialize the default external dev runtime once
bun run dev:runtime:init
# start local dev against the persistent external runtime
bun run dev
# copy selected instance state into the external dev runtime
bun run dev:instance:clone -- \
--from-root /path/to/source-runtime \
--to-root ~/.trenchclaw-dev-runtime \
--from-instance 00 \
--to-instance 00 \
--parts wallets,db,settings
Useful overrides:
bun run dev -- --runtime-root /path/to/runtime --generated-root /path/to/runtime/instances/00/cache/generatedTRENCHCLAW_RUNTIME_STATE_ROOT=/path/to/runtime
The external dev runtime writes a managed .gitignore so secrets, keypairs, databases, logs, caches, and other personal testing state stay out of git by default.
Dashboard UI
<p align="center"> <img src="./public/v0-ui.png" alt="TrenchClaw main dashboard UI" width="1100" /> </p> <p align="center"> <em>Desktop chat, activity feed, wallet controls, settings, and live runtime console in one operator surface.</em> </p>Runtime Architecture and Boundaries
TrenchClaw is a constrained execution runtime, not a free-form chatbot shell.
The shortest correct model is:
1) Runtime authority
apps/trenchclawis the source of truth.apps/frontends/guiis a client of the runtime.apps/runnerpackages and launches the runtime plus GUI.
2) Tool system
- Runtime tool definitions live under
apps/trenchclaw/src/tools. src/tools/registry.tsdeclares the runtime action tools and workspace tools.src/tools/snapshot.tsbuilds the current tool snapshot from settings, filesystem policy, and release readiness.src/ai/gateway/lanePolicy.tschooses the tool subset for each lane.src/runtime/chat/service.tsregisters only that selected tool subset with the model.
3) Execution boundaries
- Tools are typed and schema-validated before execution.
- Settings-aware policy checks can block or require confirmation before dangerous actions run.
- Filesystem access is constrained by runtime manifests and instance-scoped roots.
- Workspace escape hatches like
workspaceListDirectory,workspaceReadFile, andworkspaceBashstay available only when policy allows them.
4) State model
.runtimeis the repo-tracked contract and template area..runtime-stateis the live mutable state root.- Each active instance owns its own settings, vault, wallets, logs, queue state, and workspace.
5) Why this matters
This design keeps the model on a narrow, explicit tool surface while still allowing enough freedom to inspect the runtime workspace and use a constrained shell when needed. The goal is a local operator runtime with auditable state transitions and deliberate
