Openclaw Service

OpenClaw as a Service — how Molt.id runs isolated AI agents for every .molt domain.

Molt.id Multiclaw Service

Molt.id Multiclaw Service is OpenClaw as a Service — a multi-tenant platform that gives each .molt domain owner their own isolated AI agent (OpenClaw instance) running inside a Cloudflare container. Users authenticate via Solana NFT ownership, and the platform handles all infrastructure: container lifecycle, LLM routing, channel integrations, and data persistence.

---

Architecture Overview

                    ┌──────────────────────────┐
                    │   Cloudflare Workers      │
                    │   (HTTP Router)           │
                    └──────┬───────────────────┘
                           │
            ┌──────────────┼──────────────┐
            │              │              │
            ▼              ▼              ▼
    ┌──────────────┐ ┌──────────┐ ┌──────────────┐
    │ User A       │ │ User B   │ │ User C       │
    │ Container    │ │Container │ │ Container    │
    │              │ │          │ │              │
    │ OpenClaw     │ │ OpenClaw │ │ OpenClaw     │
    │ ClawRouter   │ │ ClawRtr  │ │ ClawRouter   │
    └──────────────┘ └──────────┘ └──────────────┘
            │              │              │
            └──────────────┼──────────────┘
                           │
                    ┌──────▼───────────────────┐
                    │   Cloudflare R2 Storage   │
                    │   (Snapshots, User Data)  │
                    └──────────────────────────┘

Components

Component	Purpose
Worker	Cloudflare Worker that routes requests, manages containers, and handles auth
Container	Isolated Docker container with OpenClaw + ClawRouter pre-installed. One per user
R2 Storage	Persistent storage for snapshots, user data, and configuration

---

NFT Domain Authentication

Users authenticate by proving ownership of a .molt domain NFT (Metaplex Core asset). The NFT contains on-chain attributes that map to a Molt.id Multiclaw Service user identity.

Authentication Flow

1. User visits login page
   ↓
2. Server generates a signing challenge with a random nonce
   (Nonce stored with 5-minute TTL for anti-replay)
   ↓
3. User signs the challenge message with their Solana wallet
   (Ed25519 signature via Phantom, Solflare, etc.)
   ↓
4. Server verification:
   a) Validate nonce (anti-replay)
   b) Verify Ed25519 signature
   c) Fetch NFT on-chain data from Solana RPC
   d) Confirm signing wallet is the NFT owner
   e) Parse Metaplex Core attributes for agent_id + agent_name
   ↓
5. Auto-create user if first login
   ↓
6. Return JWT token + access link to your agent instance

NFT Attributes (On-Chain)

The NFT stores these attributes in the Metaplex Core Attributes plugin:

Attribute	Required	Purpose
agent_id	Yes	Unique container identifier. Becomes the userId in Molt.id Multiclaw Service
agent_name	No	Display name for the agent. Falls back to {agent_id} Agent

The NFT's Name field is used as the domain name (e.g., alice.molt).

Token Lifecycle

• JWT tokens are valid for 7 days

• Signed with HMAC-SHA256

• Stored as an HttpOnly cookie scoped to your agent's path

---

Cloudflare Containers

Each user gets an isolated Cloudflare Sandbox container running OpenClaw.

Container Image

Base: Cloudflare Sandbox
  + Node.js 22
  + pnpm
  + OpenClaw (globally installed)
  + ClawRouter (x402 LLM proxy)

Services Running Inside Each Container

Service	Purpose
OpenClaw	Main AI assistant — HTTP/WebSocket API + Control UI
Telegram Server	Receives Telegram webhook messages
ClawRouter	Local OpenAI-compatible proxy for x402 micropayment LLM routing

Idle Timeout & Sleep

• Containers automatically stop after 10 minutes of no external requests

• Only incoming requests reset the idle timer — internal activity does not

• When sleeping, the container's processes are killed and the slot is freed

• On the next request, the container cold-starts and restores from its R2 snapshot

This is how we keep costs near zero — you only pay when your agent is active.

Container Startup (Cold Start)

When a user's container is accessed after sleeping:

1. Cloudflare provisions a fresh container instance

2. R2 snapshot is downloaded and restored (chat history, workspace, device identity)

3. Fresh config is written with current channel tokens, LLM keys, and auth

4. ClawRouter starts (if wallet key is available)

5. OpenClaw gateway starts

6. A loading page is shown to the user while startup completes

---

R2 Storage & Snapshots

R2 is used for all persistent storage — user data, snapshots, and global configuration. No ingress fees.

What's Stored

Data	Contents
User records	Name, channel tokens, LLM keys, quota, settings
Container snapshots	Compressed tarball of the container's persistent filesystem
Snapshot metadata	Timestamp, size, version

What Persists Across Restarts

Included in snapshots:

• Device identity (critical for channel pairing)

• Approved sender lists (pairing allowlists)

• All chat transcripts and session history

• Agent state files

• User workspace, memory, and custom files

Excluded (always written fresh on startup):

• OpenClaw config

• API credentials

• Wallet keys

• Lock files, SQLite temp files, and logs

Backup Triggers

Trigger	Frequency
Auto on request	Every 2 min (throttled)
Telegram webhook	Every 2 min (throttled)
Scheduled cron	Every 5 min
Manual	On demand
Before restart/kill	Automatic

Snapshot Limits

• 50 MB maximum per snapshot — larger snapshots are skipped

Restore Process

On cold start:

1. Snapshot tarball is downloaded from R2

2. Extracted into the fresh container

3. Config files are written after restore (always fresh, never from snapshot)