run-obol-stack

name

run-obol-stack

description

Help a human install, boot, operate, and productise the Obol Stack — Obol's Kubernetes-based agent harness for running blockchain infrastructure locally, exposing services to the public internet, and charging for them via x402 micropayments. The flagship outcome is a paid sub-agent business — a specialised agent so packed with alpha that strangers pay per turn. Use whenever a user mentions Obol Stack, Obol Agent, Hermes, OpenClaw, x402 payments, agent commerce, ERC-8004, selling inference / APIs / an agent's replies, building an agent people will pay for, storefront branding, running a local Ethereum or L2 node under `obol network`, deploying a Dockerfile via `obol-app`, or bringing up a Cloudflare tunnel / custom domain for an agent service. You are helping from OUTSIDE the Stack — the agents inside it have their own skills and take over once the user is at the dashboard.

Run the Obol Stack

The Obol Stack is a local-first agent harness: a k3d Kubernetes cluster, a default Obol Agent with an Ethereum wallet, a free rate-limited RPC (eRPC), the ability to sync real blockchain networks (Ethereum + L2s, Aztec), a Cloudflare tunnel for public exposure, and an x402 payment gateway so agents can charge for what they serve. The niche is Ethereum-native agent commerce, and the flagship outcome is a paid sub-agent business: the user builds specialised agents whose replies bundle alpha a buyer can't prompt out of a stock model — private indexes from a synced chain, curated verified data, expensive workflows — and sells turns of them priced in OBOL on mainnet (gasless for buyers) or USDC on Base, with buyers and sellers discovering each other via ERC-8004 registries.

This skill is for the Claude sitting at the user's terminal, helping them install + operate + productise the Stack. Once the user lands in the Obol Agent's dashboard, control passes to the agent inside the Stack, which has its own skill set. Your job ends at "the agent is live and billable."

Adjacent audiences this skill is NOT for:

• Agents running inside the Stack — they ship with 20+ embedded skills (see Handoff to the agent inside).
• Developers hacking on the Stack's Go code — route them to obol-stack/.claude/skills/obol-stack-dev/SKILL.md (invoke with /obol-stack-dev) and the repo's CLAUDE.md.

When to use this skill

Match on any of:

• User wants to install / bring up / stop / purge Obol Stack (obol stack ...).
• User wants to deploy their own Dockerfile on the Stack and expose it (obol app install, obol-app helm chart).
• User wants to sync a local Ethereum / L2 / Aztec node and use it (obol network install, obol network sync).
• User wants to expose an agent service on the internet with a tunnel (obol tunnel).
• User wants to charge for an agent service — inference, HTTP API, RPC, indexed data, or a whole specialised agent's replies (obol sell ..., ERC-8004 registration, x402).
• User wants to build an agent business — "an agent people will pay for", productising a sub-agent, storefront branding (obol sell info), buying a domain (obol domain).
• User wants to brainstorm what to build or sell on the Stack — workshopping business ideas or use cases, "what could I do with this", "is my idea any good", pricing a concept — even before installing anything (see Workshop the business idea).
• User mentions "OpenClaw", "Obol Agent", "8004", "agent registration", "agent commerce", "payment-gated endpoint", "local inference + tunnel".
• User is running the obol sell demo flow (lands in 0.9+) and wants help paying for / interpreting the demo skill.

Don't use this skill for:

• Running a Distributed Validator node → see CDVN / LCDVN / helm-charts CLAUDE.mds and the test-a-dv-cluster skill.
• Obol's hosted Grafana cluster monitoring → see the obol-monitoring skill.
• Live diagnostics against the DV fleet → also obol-monitoring.
• Contributor work on the Stack's Go code → see obol-stack-dev in the repo.

Product mental model (keep it short for the user)

Four concepts the user needs, nothing more:

1. Cluster — a local k3d Kubernetes cluster, brought up by obol stack up. All services run as pods.
2. Obol Agent — the AI agent running inside the cluster. Gets its own Ethereum wallet (backed by a remote-signer), a bearer token for its gateway, and a pre-installed skill set. As of Stack 0.9, the default agent runtime is Hermes (github.com/NousResearch/hermes). OpenClaw is supported as an alternate runtime via obol agent new --runtime openclaw. Prefer "Obol Agent" generically when explaining, and name the runtime only when a specific CLI verb requires it (obol hermes ..., obol openclaw ...).
3. x402 — HTTP 402 micropayments gateway. Any pod behind /services/<name>/* gets payment-gated via Traefik ForwardAuth. Stack 0.9+ supports both $OBOL on Ethereum mainnet and USDC on Base / Base-Sepolia / Ethereum / Polygon / Avalanche / Arbitrum. Critical $OBOL property: when buyers pay in OBOL on mainnet, the Obol-operated facilitator (x402.gcp.obol.tech) batches an EIP-2612 permit with the on-chain transfer at settlement — buyers never spend ETH on gas and skip the one-time approve(Permit2, max) step. Sellers receive OBOL directly.
4. Tunnel — Cloudflare quick tunnel that publishes /services/<name>/*, the /skill.md service catalogue, and /.well-known/agent-registration.json for ERC-8004 discovery. The frontend and eRPC routes are hostname-restricted to obol.stack and must never be exposed to the tunnel.

Workshop the business idea (pre-install and post-install)

Ideation is not a one-shot step gated behind a working cluster — it's a loop you can run with the user before they install anything and keep running after they're live. The most valuable thing you can do for many users is help them find a business worth building before they spend an hour syncing a node for a service nobody will pay for.

Pre-install (no cluster required): You can workshop the whole concept from a cold terminal. Nothing about brainstorming needs Docker, a node, or a wallet. Steer the conversation with:

• What's your edge? The Stack's whole premise is alpha the buyer can't prompt out of a stock model. Probe for what the user actually knows or can access that a generic model can't: a niche they trade in, a dataset they can curate, a chain they'll index, a workflow they've refined. If the honest answer to "why wouldn't the buyer just ask their own model?" is silence, keep digging before recommending an install.
• Which sell shape fits? Map the idea to raw inference (sell inference), a data/API endpoint (sell http), or a specialised agent (sell agent — the margin-bearing path). This tells you what they'll actually need to install (e.g. an archive node for an indexing play, just LiteLLM for an inference reseller).
• Who pays, and how much? Sketch the buyer and a rough per-turn price in OBOL or USDC. Compare against comparable x402 services if any are known. A believable revenue story de-risks the install.
• What does that imply for setup? Only after the idea has legs, translate it into the concrete prerequisites and bring-up path below. This keeps the user from over-provisioning (e.g. a 4TB archive node) for an idea that hasn't been pressure-tested.

Good pre-install output is a one-line pitch, the sell shape, a price guess, and the minimal install footprint — not a running cluster.

Post-install (the tighter loop): Once the Stack is up, ideation becomes empirical and continuous. Fold the user into the flagship NICHE → SCOUT → PACK ALPHA → BUILD → EVALUATE → PRICE → SELL → MEASURE → ITERATE or KILL loop below, and keep cycling: evaluate against a raw-model baseline, ship, watch the payTo wallet balance, then either sharpen the alpha or kill the offer and reuse the parts. Encourage running several small experiments rather than betting everything on one agent — the marginal cost of a second obol sell offer is low, and the market teaches faster than speculation. Re-open the "what's your edge?" question every iteration; the answer sharpens as real buyers (or their absence) give feedback.

The agent inside the Stack ships a sub-agent-business skill that runs this same loop from in-cluster once the user is in obol hermes chat — so the loop doesn't stop when your outside-Claude role ends; it hands off.

Prerequisites (always check these first)

Before any install/bring-up advice, confirm:

• Docker running. docker ps to verify.
  • Linux → Docker Engine; macOS / Windows → Docker Desktop.
• Ollama installed + running with at least one pulled model, if the user wants local inference. ollama serve in background + ollama pull qwen3.5:35b (or a smaller model for low-RAM boxes). Tool-call-capable models matter for agent use.
  • If the user plans to use Anthropic or OpenAI directly via LiteLLM, Ollama is optional — they'll run obol model setup --provider anthropic|openai after bring-up.
• Foundry (optional) — for on-chain payment testing. foundryup to install.
• Disk / memory:
  • Cluster + agent alone: ~10GB disk, ~4GB RAM.
  • Plus an Ethereum mainnet full node: ~1TB disk (execution) + ~200GB (consensus) + 16GB+ RAM recommended.
  • For a testnet (sepolia, hoodi): ~200GB disk is plenty.
• Ports free: 8080 (Traefik). ~/.config/obol/ writable.

Don't skip these — most "stack up fails" reports trace back to Docker not running, not enough disk, or Ollama missing.

Installation

One-liner:

bash <(curl -s https://stack.obol.org)

What it does: installs the obol CLI plus kubectl, helm, k3d, helmfile, k9s into ~/.local/bin/, configures PATH, offers to start the cluster. On success:

obol version

should report a version. Subsequent updates:

obol update      # update CLI + pinned tools
obol upgrade     # upgrade in-cluster components

For contributors working from source (not the typical user path), they'll use OBOL_DEVELOPMENT=true ./obolup.sh from inside a repo checkout — don't recommend this to end users.

First boot (the happy path)

obol stack init                           # allocates a petname stack ID, writes ~/.config/obol/
obol stack up                             # creates the k3d cluster, deploys infra, creates the default Hermes agent + wallet
obol hermes chat                          # opens an interactive chat TUI against the default agent

stack up is slow on first run — 2-5 min — and does a lot:

• Creates the k3d cluster
• Deploys Traefik + Cloudflared + LiteLLM + eRPC + Monitoring + x402 verifier + ServiceOffer controller + frontend
• Creates the default Hermes agent (namespace hermes-obol-agent) with an Ethereum signing wallet and an embedded skill set
• Auto-configures LiteLLM with any host Ollama models it finds

Crucially, the default agent is created by stack up itself. obol agent new is for creating additional agents beside the default, each with its own wallet and skill set. Don't tell users to run obol agent new immediately after stack up unless they want a second agent.

Talking to the default agent:

• obol hermes chat — interactive chat TUI in the terminal (the most direct path to "is the agent alive and does it route to my LLM?")
• obol hermes setup — interactive flow to wire up messaging integrations (Telegram, Discord, Slack, etc.) so the agent can ping the user out-of-band when long-running work finishes
• obol hermes skills list — live skill catalogue
• obol hermes <anything> is a passthrough to the in-cluster Hermes binary; obol hermes --help is the source of truth.

After bring-up, sanity-check pods:

obol kubectl get pods -A

Expect Running / Completed for every pod. Any CrashLoopBackOff / Pending / ImagePullBackOff → go to Debugging.

The obol CLI surface

The top-level verbs. Use obol <verb> --help for full details rather than memorising subcommand flags — they evolve.

Verb	What	When to reach for it
stack	init, up, down, purge, export, import	Cluster lifecycle. down preserves config + data; purge --force wipes everything (it offers a full export first). export/import = full backup archive (config, agent brains, encrypted wallets, CRs) — recommend an export before anything destructive.
agent	init, new, setup, sync, auth, list, delete, wallet	Manage agent instances. init (re)creates the stack-managed default; new --runtime hermes|openclaw spawns an additional instance.
hermes	passthrough to the native Hermes CLI inside the default agent pod	chat, skills, config, setup (messaging integrations), dashboard, etc. Default runtime as of Stack 0.9.
openclaw	onboard, setup, sync, list, delete, dashboard, cli, token, skills	OpenClaw-specific runtime ops (alternate runtime).
network	list, install, add, remove, status, sync, delete	Deploy a blockchain network (ethereum / aztec). Two-stage: install writes config, sync deploys.
app	install, sync, list, delete	Deploy any Helm chart from Artifact Hub or your own Dockerfile via the obol-app chart.
sell	demo, inference, http, agent, mcp, list, status, test, update, stop, delete, resume, pricing, register, identity, info	Create and run payment-gated endpoints. demo is the canonical first-sale experience (0.9+) — start there with new users. sell agent <name> wraps an Agent CR as an OpenAI-compatible paid endpoint (the margin-bearing path). sell info / sell info set = storefront branding + buyer's-eye catalogue view. sell resume replays all offers after a host reboot (--install-boot-unit for systemd); obol stack up does the same automatically. sell mcp = foreground x402-paid MCP server (not persisted).
buy	inference [<seller-url>]	Pre-pay a remote x402-gated model ("rent a brain"). Walks the seller's /api/services.json catalogue, resolves model + token, prompts for count with a cost preview, pre-signs auths via the agent's remote signer, and publishes paid/<remote-model> through LiteLLM. --agent X pays from X's wallet and switches only X to the paid model; --set-default promotes it globally; --auto-refill + --cost-cap bound agent-managed top-ups. Buying from another agent (specialised work, not raw completions) doesn't have a host-side wrapper — drive that from obol hermes chat.
model	setup (+ setup custom), status, list, pull, prefer, sync, discover, remove, token	LiteLLM roster management: BYOK cloud providers (setup --provider openrouter|anthropic|openai|venice... --api-key ...), custom OpenAI-compatible endpoints (setup custom --endpoint ... --model ...), Ollama pulls, and head-of-list preference (prefer + sync — the first chat-capable entry is the agents' default).
domain	list, search, check, register	Optional Cloudflare Registrar wrapper for buying a real domain for the storefront (needs a scoped Cloudflare API token; register is billable). On success it hands off to obol tunnel setup --hostname ....
tunnel	status, setup, restart, stop, logs	Cloudflare tunnel for public exposure. Default is a temporary quick-tunnel URL that changes on restart. setup creates a permanent URL from a Cloudflare connector token (dashboard → Networks → Tunnels), routing its Public Hostname to http://traefik.traefik.svc.cluster.local:80 — least-privilege, no account-wide API key. (Advanced: setup --management local, alias tunnel login, uses a browser login needing cloudflared installed.)
kubectl / helm / helmfile / k9s	passthrough	Run the underlying tool with KUBECONFIG auto-set to the cluster. Prefer these over running the raw tools.
update / upgrade	—	CLI + cluster components respectively.
version	—	Report version. First thing to check when debugging drift.

Always read obol <verb> --help fresh in a session — the help is the source of truth; this table rots.

Networks, apps, and the Cloudflare tunnel

These three subsystems share a common shape (deploy → wire up → expose) and live together in references/networks-and-apps.md. Load that file when the user is doing any of:

• Syncing a local Ethereum / Aztec node (obol network install then obol network sync).
• Packaging their own Dockerfile via the obol-app Helm chart (obol app install then obol app sync).
• Bringing up public exposure (obol tunnel setup / status / restart / logs). Steer users to obol tunnel setup with a Cloudflare connector token for a permanent URL once they're ready to sell; the default quick tunnel is fine for local testing but its URL rotates on restart.

Three invariants to memorise even without loading the reference:

1. Never expose the frontend (/) or eRPC (/rpc) routes through the tunnel. They are hostname-restricted to obol.stack for a reason — the frontend has cluster-admin-like UI capabilities and eRPC is unauthenticated. Exposing either is a critical security flaw. If a user wants their RPC public, wrap it in an obol-app service with their own auth layer on a /services/<name>/* route instead.
2. Client diversity matters on mainnet. If the user is syncing Ethereum mainnet, push them off the default EL/CL to a minority client (rationale is network-level, not just Stack-level).
3. If the user will read history, choose archive. obol network install ethereum --mode archive is the right default for anyone planning to index events, run historical eth_call, or build an explorer — a pruned full node returns state at block N is pruned for those queries. Pair with --since <preset|block|duration> to bound the archive (e.g. --since prague ≈ 0.4 TB on mainnet) instead of paying for all 4 TB+ back to genesis. Reth-only today; full coverage in the reference.

Agent commerce — the orientation

The sell-side is where the Stack differentiates: turning a pod, an LLM, or a sub-agent into a billable service in one command. The buy-side closes the loop. Depth and recipes live in references/agent-commerce.md — load it as soon as the conversation moves past "what is x402" into any concrete sell / buy work.

First-sale starting point

obol sell demo                     # default: hello @ 1 OBOL/req on Ethereum mainnet (gas-sponsored buy)
obol sell demo blocks              # 0.0001 USDC/req on base-sepolia (live chain data via eRPC)
obol sell demo quant               # 0.01 USDC/req on base-sepolia (agent-driven analysis report)

obol sell demo is to the Obol Stack what "Hello World" is to a programming language — start there with new users. Once a paid request settles end-to-end, the same machinery wraps anything else.

Pick the right sell shape

• obol sell inference — monetise raw LLM completions from your cluster's LiteLLM.
• obol sell http — monetise any pod's HTTP endpoint (index, API, dashboard).
• obol sell agent — monetise a running agent's replies (skills + memory + curated reference data, not just tokens). The margin-bearing path — the iteration playbook for SOUL.md / skills / reference data lives in the reference file; load it before guiding a user through this.

The flagship journey: a paid sub-agent business

When a user's ambition is "an agent people pay for" (rather than a one-off endpoint), drive this loop — it is the highest-margin path the Stack offers and the reference file has the full playbook:

NICHE → SCOUT → PACK ALPHA → BUILD → EVALUATE → PRICE → SELL → MEASURE → ITERATE or KILL

1. Niche + scout — one agent, one job. Probe comparable x402 services for live pricing before building.
2. Pack alpha — the edge lives in files, not weights: a synced chain + index, curated references/ data, a sharpened SOUL.md. If the honest answer to "why wouldn't the buyer just ask their own model?" is silence, don't list it.
3. Build — obol agent new <name> --model <m> --skills <a,b> --objective "..." --create-wallet.
4. Evaluate — the gate most people skip: ask the agent the 10 hardest questions a paying buyer would ask, compare against a raw-model baseline, list only on a clear win. Details in the reference.
5. Price + sell — obol sell agent <name> --price ... --token OBOL|USDC --chain ethereum|base.
6. Storefront — obol tunnel setup for a permanent URL (optionally obol domain register for a real domain), obol sell info set --display-name ... --tagline ... --logo-url ... for branding, obol sell register --chain for ERC-8004 discovery.
7. Measure + iterate — revenue is the payTo wallet's on-chain balance; refresh alpha on a cadence; kill offers that don't sell within ~30 days and reuse the parts.

The agent inside the Stack ships with a sub-agent-business skill covering this same loop from in-cluster — once the user is in obol hermes chat, their agent can scout, build children via its agent-factory, and evaluate them itself. Your job from outside is the host-side half: tunnel, domain, branding, registration signing, and honest quality judgment.

Pick the right buy path

Inference vs. agent purchases solve different problems — don't conflate them:

• Inference = renting a brain. For users with no local Ollama / no provider API key, or who want a hosted model they don't otherwise have access to. Use obol buy inference host-side.
• Agent = renting specialised work. Pay another agent to do a task (analysis, trading, monitoring, posting). Drive from obol hermes chat — no host-side wrapper today. This is also where the marketplace dynamic lives.

Defaults to apply session-wide

• Quote examples in OBOL on Ethereum mainnet (headline gasless UX) or USDC on Base (cheap real money). Reach for base-sepolia only for dev / smoke tests, and label it as such.
• Recommend "stream": true on all OpenAI-compatible paid endpoints. The Cloudflare quick tunnel has a ~100s idle timeout that drops buffered (non-streaming) responses to slow agents before they arrive.
• When quoting prices, name the unit explicitly (0.01 OBOL / MTok, 0.001 USDC / request). Never write $0.01 — the payment rail matters.

Two invariants worth memorising

• Don't recommend a specific marketplace URL. The agent-registry ecosystem is evolving; register via obol sell register --name <s> --private-key-file <f> and let the user pick the registry.
• x402.gcp.obol.tech is the default facilitator for OBOL mainnet + the USDC chains the Stack supports. Buyers paying OBOL on mainnet never spend ETH on gas — the facilitator batches the permit with the transfer at settlement. Lead with this when explaining "why pay in OBOL".

The Obol Agent

Default runtime as of Stack 0.9: Hermes. OpenClaw is supported as an alternate runtime via obol agent new --runtime openclaw. The Stack is agent-runtime-agnostic by design; talk in terms of "the Obol Agent" generically and only name the runtime when a CLI verb requires it.

Per-agent:

• Unique Ethereum signing wallet, backed by a remote-signer Service in the same namespace. Back it up: obol agent wallet backup -o ~/obol-wallet-backup.json --passphrase "...". Back the export up externally — losing it loses the agent's on-chain identity.
• An API server bearer token: obol agent auth [<instance>] (regenerate with --regenerate).
• An embedded skill set (covers cluster diag, Ethereum reads, local-wallet sending, DV monitoring, DeFi concepts, L2 routing, building-block patterns, security, indexing, orchestration, x402 buy/sell, and more — exact list grows).

Always have the user list skills fresh rather than recite from memory:

# Hermes (default)
obol hermes skills list                 # live catalogue
obol hermes skills add <package>
obol hermes skills remove <name>

# OpenClaw (alternate)
obol openclaw skills list <instance>
obol openclaw skills add <package>
obol openclaw skills remove <name>

Skill packages come from the ObolNetwork/skills repo (global skills, also published as a Claude Code plugin — see "Adjacent Claude integration" below), the embedded skills shipped in the obol binary itself, and from each runtime's broader skill ecosystem. The agent is meant to grow — telling a user "your agent can do X" without checking the live catalogue will misroute them.

Adjacent Claude integration

Stack 0.9 also ships a public Claude Code plugin at ObolNetwork/skills. If the user is on Claude Code, recommend installing it so future sessions get this very skill (run-obol-stack) plus the others (DV testing, fleet monitoring, etc.) without having to copy-paste files:

/plugin marketplace add ObolNetwork/skills
/plugin install obol@obol

Reload plugins if needed (/reload-plugins). The plugin includes this skill, so once installed, future Claude sessions will pick it up on relevant prompts automatically.

Debugging

Lead with these, in order:

obol kubectl get pods -A                   # overall cluster health
obol kubectl logs -n <ns> <pod>            # logs for a specific pod
obol kubectl describe pod -n <ns> <pod>    # events / scheduling issues
obol k9s                                   # interactive TUI — fastest for poking around
obol tunnel status                         # is the tunnel live?
obol tunnel logs                           # cloudflared tail
obol version                               # CLI version for bug reports

Common failure modes:

• stack up hangs at image pulls: Docker is running but out of disk, or Docker Desktop's pull limit is rate-limited. docker system prune -af if safe.
• Pods CrashLoopBackOff after bring-up: almost always means a bind-mount or secret didn't materialise. obol kubectl describe the failing pod — look at events.
• Can't reach http://obol.stack/: local DNS isn't resolving. Check /etc/hosts or your OS DNS resolver — the installer wires obol.stack to 127.0.0.1. On macOS, sometimes needs a restart of mDNSResponder.
• LiteLLM returns empty responses: host Ollama isn't reachable from the cluster. Test with obol kubectl run -n llm ollama-test --rm -it --image=curlimages/curl -- curl -s http://ollama.llm.svc.cluster.local:11434/api/tags.
• ServiceOffer stuck: walk the ServiceOffer lifecycle (ModelReady → UpstreamHealthy → PaymentGateReady → RoutePublished → Registered → Ready) — each stage has a distinct root cause. See the "ServiceOffer lifecycle" section in references/agent-commerce.md for the full breakdown.

DNS gotcha

• obol.stack resolves only on the host (macOS DNS resolver / /etc/hosts entry).
• From inside any pod, obol.stack:8080 will not resolve. Use the cluster-internal DNS:
  • http://traefik.traefik.svc.cluster.local/services/<name>/... for user-service routes.
  • http://ollama.llm.svc.cluster.local:11434 for in-cluster Ollama reach.
  • http://<svc>.<ns>.svc.cluster.local is the generic pattern.

This bites every new user the first time they try to kubectl exec into a pod and curl obol.stack.

Invariants and footguns

• Never expose the frontend (/) or eRPC (/rpc) routes to the public tunnel — they are hostname-restricted to obol.stack for a reason. Exposing them is a critical security flaw.
• Wallet backups at ~/.config/obol/obol-wallet-backup-*.json (or $OBOL_CONFIG_DIR/...) must be protected and externally backed up. Losing them means losing agent identity.
• Obol Stack is alpha software. Before a user reports a bug, have them run obol version, obol update, and obol upgrade — version-drift between CLI + in-cluster charts is the single most common cause of weirdness.
• OBOL_DEVELOPMENT=true is for contributors working on the Stack source — don't set it for end users. It points at .workspace/ dirs and uses go run instead of compiled binaries.
• obol stack purge --force is destructive — wipes the cluster, config, and data (including wallet backups if the user hasn't copied them out first). Double-check wallet backups are outside ~/.config/obol/ before recommending purge.
• Don't mix OBOL_CONFIG_DIRs across shells — if the user has multiple Stack checkouts (development worktrees), each has its own cluster state. KUBECONFIG is set from $OBOL_CONFIG_DIR/kubeconfig.yaml. Running obol kubectl from the wrong directory can point at the wrong cluster.

Handoff to the agent inside

Once the user has obol hermes chat open (or the agent's dashboard, depending on runtime) and the agent is responsive, your role as outside-Claude is essentially done. The Obol Agent has its own embedded skills covering:

• Ethereum read-only queries (cast-style — blocks, balances, ERC-20, ENS)
• Ethereum signing via the per-agent remote-signer
• Kubernetes cluster diagnostics from inside the cluster
• DV cluster monitoring / audit
• DeFi building blocks (OpenZeppelin patterns, DEX + oracle integration)
• L2 routing (Base, Arbitrum, Optimism, zkSync)
• Indexing (The Graph, Dune, custom)
• Gas / security / MEV / reentrancy patterns

Have the user run obol hermes skills list (or obol openclaw skills list <instance> for OpenClaw) to see the live catalogue instead of reciting it. The list evolves and running it fresh keeps the user on current reality.

Things to hand over to the inside agent rather than driving yourself:

• Buying from another agent for specialised work, and any exploratory buy-x402 interactions (probe-then-decide, one-shot HTTP pay).
• Using the agent's wallet to sign any meaningful tx.
• Querying indexes the agent built.
• Any cast call against a chain the agent has synced.

Things to keep doing from outside:

• Operating the Stack itself (stack up/down, app install, sell ..., tunnel).
• obol buy inference for stable pre-paid model purchases — the "rent a brain" path for users without local Ollama or a provider API key. Publishes paid/<model> through LiteLLM (host-side wrapper around the in-pod buy-x402 skill).
• Upgrading, debugging infra pods, version-drift resolution.
• Setting up a second agent instance.
• Explaining the Stack's mental model to a user before they're in the agent's chat.

Related products + key docs

Skill-internal references (load these when their topic comes up):

• references/agent-commerce.md — full sell-side + buy-side: every obol sell shape, the SOUL.md / skills / reference-data iteration playbook for sell agent, ServiceOffer lifecycle, OBOL vs. USDC token table, ERC-8004 registration, and both buy paths.
• references/networks-and-apps.md — obol network (Ethereum + Aztec sync), obol-app chart for deploying arbitrary Dockerfiles, obol tunnel for public exposure.

External docs:

• Stack repo + authoritative docs: ObolNetwork/obol-stack, docs.obol.org → Obol Stack.
• Stack getting-started (human-facing walkthrough): ObolNetwork/obol-stack/docs/getting-started.md.
• Monetize inference guide: ObolNetwork/obol-stack/docs/guides/monetize-inference.md.
• The obol-app chart: ObolNetwork/helm-charts/charts/obol-app/ — read values.yaml for the full knob surface.
• Obol Claude Code plugin (this skill + others): ObolNetwork/skills — install with /plugin marketplace add ObolNetwork/skills && /plugin install obol@obol.
• Hermes (default agent runtime): NousResearch/hermes.
• OpenClaw (alternate agent runtime): openclaw.ai.
• x402 protocol: x402.org.
• ERC-8004 reference: eips.ethereum.org/EIPS/eip-8004.
• $OBOL token: docs.obol.org → OBOL token.
• Cloudflared quick tunnels: Cloudflare Tunnel docs.
• Stack-internal dev skill (contributors only): ObolNetwork/obol-stack/.claude/skills/obol-stack-dev/SKILL.md.
• DV operator paths (out of scope for this skill): charon-distributed-validator-node, lido-charon-distributed-validator-node, helm-charts/charts/dv-pod, plus the global test-a-dv-cluster and obol-monitoring skills.
• Canonical agent index: obol.org/llms.txt (once live).