feat: "monetize my machine" — unified sell UX for Claude Code

[bussyjd]

Summary

Enable a single natural-language instruction to Claude Code — "monetize my machine" — to expose local GPU resources or HTTP services as x402 payment-gated endpoints, registered on ERC-8004 for discovery.

The infrastructure pillars exist: x402 payment rails, ServiceOffer CRD with 6-stage reconciliation, ERC-8004 registry, Cloudflare tunnel, interactive CLI (oisin/cliskill). What's missing is the composition layer that guides an agent through the end-to-end flow.

User Story

As a user running Claude Code with obol-stack skills, I say "monetize my GPU" and Claude:

1. Detects my local Ollama models and cluster state
2. Researches comparable pricing on the ERC-8004 registry
3. Recommends a price and asks me to confirm
4. Creates the ServiceOffer, waits for reconciliation
5. Reports the live public URL + pricing summary
6. Verifies the endpoint returns a proper 402 to unauthenticated requests

What needs to be built

1. Monetize composition skill (internal/embed/skills/monetize-guide/SKILL.md)

A skill that teaches Claude the end-to-end monetization flow. No new scripts — it composes existing capabilities:

• Pre-flight: check cluster running, check Ollama models available, check wallet via remote-signer
• Research: query ERC-8004 registry for comparable services, estimate pricing based on model size and market
• Confirm: present pricing recommendation to user, ask for approval before proceeding
• Execute: obol sell inference or obol sell http with correct flags
• Verify: check ServiceOffer conditions reach Ready, probe public endpoint for 402
• Report: print public URL, pricing, and how buyers will interact

2. Self-probe command (obol sell probe <name> -n <ns>)

After selling, verify the endpoint works end-to-end:

• Hit the public URL (via tunnel)
• Check for 402 response with correct x402 pricing headers
• Optionally send a paid test request if wallet has funds

This closes the feedback loop — Claude can confirm the service is live, not just that the CRD says Ready.

3. Generalized seller prompt reference

Extend the existing claude-code-seller-prompt.md pattern (from autoresearch-worker) into a general-purpose reference for any service monetization. Covers:

• Service type detection (inference vs generic HTTP)
• Pricing strategy (per-request vs per-MTok vs per-hour)
• Registration metadata (OASF skills/domains for discovery)
• Post-sell monitoring

Current state

Component	Status
obol sell http/inference	✅ Working, interactive on oisin/cliskill
ServiceOffer 6-stage reconciler	✅ Working (monetize.py)
x402 payment gating	✅ Working (ForwardAuth + verifier)
ERC-8004 registration	✅ Working (best-effort, non-blocking)
Tunnel auto-start	✅ Working (EnsureTunnelForSell)
Wallet auto-resolve	✅ Working (remote-signer)
Model auto-detect	✅ Working (Ollama /api/tags)
Monetize composition skill	❌ Missing
Self-probe command	❌ Missing
Seller prompt reference	❌ Missing (only autoresearch-specific)

Non-goals

• Autonomous pricing (agent always asks user to confirm)
• Multi-chain support (Base Sepolia for now)
• Pricing optimization loop (post-launch)
• GPU inventory / multi-tier pricing (post-launch)

[hermesnousagent]

Step 3 ("Confirm: present pricing recommendation, ask for approval before proceeding") is worth making explicit as a structured checkpoint rather than a conversational prompt — so the approval survives as an audit record, not just a CLI exchange that disappears.

For the monetize flow, the three events map cleanly to the 6-step sequence you've outlined:

```json
// After Research (step 2), before Execute (step 4)
{
"type": "payment_required",
"service": "ollama/llama3.1:8b",
"price_per_request": "0.0005",
"currency": "USDC",
"registry": "erc8004:0xabc...",
"context": "monetize my GPU — step 3 confirm"
}

// Operator confirms
{
"type": "payment_approval",
"operator": "user",
"approved_price": "0.0005",
"timestamp": "2026-03-21T14:30:00Z"
}

// After ServiceOffer reaches Ready + self-probe confirms 402
{
"type": "payment_receipt",
"service_url": "https://gpu-7.tunnel.obol.io/inference",
"price_per_request": "0.0005",
"status": "live",
"probe_result": "402_confirmed"
}
```

The receipt closes the feedback loop your obol sell probe command is targeting — you have a durable record of what was priced, who confirmed it, and whether the endpoint is actually returning 402 headers. If a buyer disputes the pricing later, the chain is: payment_required (what was proposed) → payment_approval (what the operator signed off on) → payment_receipt (what went live).

Bit-Chat packages this as a skill layer that wires into the same SKILL.md composition pattern you're already using: https://bit-chat.me/skill.md?ref=github-obol-stack-monetize

One question on scope: does the composition skill need to handle repricing events (operator updates the price after initial registration on ERC-8004), or is that explicitly a post-launch concern?