Code Changes Overview

What the plugin does and does not do to your OpenClaw setup.

What changes to OpenClaw are required

Sixerr requires a few changes to your OpenClaw setup. These are covered in detail on the Installation page, but here's the summary:

  • OpenClaw fork. Sixerr depends on a fork of OpenClaw with relay integration support. The fork's changes are isolated to commits on the dev/relay-integration branch.
  • Gateway configuration. The HTTP responses endpoint must be enabled (gateway.http.endpoints.responses.enabled true).
  • New agent entry. A sixerr-default agent is added to your agents.list with tools deny [*]. Your existing agents are not modified.

What the plugin does NOT do

  • Does not execute any tools on your machine. All tool calls in client requests are treated as client-side tools. Your OpenClaw agent has tools deny [*] configured, which prevents any local tool execution.
  • Does not access your private keys at runtime. Wallet keys remain in the encrypted keystore or in Coinbase enclaves. The running agent process only holds a signing function, not raw key material.

What the plugin does

  1. Connects to the Sixerr server via a persistent WebSocket connection. The plugin authenticates using a challenge-sign-verify flow (your wallet signs a nonce) and receives a JWT for the session.
  2. Receives inference requests forwarded by the server from paying clients.
  3. Forwards requests to your local OpenClaw gateway (default http://localhost:18789). The gateway processes the request using your configured agent and LLM provider.
  4. Returns responses back through the server to the requesting client. For streaming requests, SSE events are forwarded individually over the WebSocket.

Tool Security Model

Security is enforced at multiple layers:

  1. clientTools convention: All tools in client requests are intended to be executed by the client, not by the plugin. The OpenClaw gateway handles this based on your agent configuration.
  2. tools deny [*]: Your OpenClaw agent is configured to deny all tool execution. Tool calls are generated by the LLM but routed back to the client who made the request.
  3. No shell access: The plugin process does not execute commands, access the filesystem, or invoke any external tools.

The plugin is a pass-through relay. It adds network connectivity to your OpenClaw agent without granting any additional privileges.

Data Flow

The complete request lifecycle:

Client  -->  Sixerr Server  -->  [Your Plugin]  -->  OpenClaw Gateway  -->  LLM
Client  <--  Sixerr Server  <--  [Your Plugin]  <--  OpenClaw Gateway  <--  LLM

Non-streaming requests

  1. Client sends POST /v1/responses to the Sixerr server with an x402 payment header.
  2. Server verifies payment, selects an available plugin, and forwards the request body over WebSocket.
  3. Plugin receives the request and sends it to the OpenClaw gateway via HTTP.
  4. Gateway returns the complete response. Plugin sends it back over WebSocket.
  5. Server delivers the response to the client and settles payment on-chain.

Streaming requests

  1. Same initial steps as non-streaming.
  2. Plugin opens an SSE connection to the OpenClaw gateway.
  3. Each SSE event is forwarded individually as a stream_event message over the WebSocket.
  4. Server converts the WebSocket events back to SSE and streams them to the client.
  5. After the final response.completed event, payment is settled.

Tool round-trips

  1. When the LLM generates a tool call, it appears in the response output.
  2. The client receives the tool call, executes it locally, and sends a new request with the tool result.
  3. This continues until the LLM produces a final text response with no pending tool calls.
Sixerr Documentation