0G Sandbox
Private, isolated sandboxes for vibe coding — powered by 0G Network.
中文版：README.zh.md
Problem
Vibe coding has two conflicting requirements:
-
Local environments aren't isolated enough. Running untrusted or experimental code locally
risks polluting the development environment, leaking credentials, or causing irreversible
side effects. A fully isolated remote sandbox is needed.
-
Remote servers are controlled by others. Renting a cloud VM solves isolation, but the
host provider can inspect or tamper with the code and data running inside. The sandbox
environment itself cannot be trusted.
Solution
0G Sandbox combines 0G Tapp (TEE-based trusted execution) with
Daytona (sandbox runtime) to satisfy both requirements simultaneously:
- Isolation: each sandbox is a fully containerized Daytona workspace, isolated from the
user's local machine and from other users' sandboxes.
- Confidentiality: the billing proxy and its TEE signing key run inside a hardware TEE
enclave (TDX) managed by 0G Tapp. The host cannot inspect the workload or forge vouchers.
Critically, the provider never sees the user's code — sandbox workloads run inside the
TEE and are opaque to the infrastructure operator.
- Trustless billing: users deposit funds into a Solidity contract on 0G Network. Compute
fees are settled via EIP-712 vouchers signed by the TEE key — no trusted intermediary needed.
Why not just rent a cloud TDX server?
A cloud TDX instance only secures the execution side. In a vibe coding workflow, the attack
surface is larger: your prompts, context, and intermediate outputs all pass through the AI
model, and cloud providers offer no confidentiality guarantee for inference.
0G Sandbox is designed to compose with 0G Compute (TEE-based AI inference),
enabling a fully confidential vibe coding pipeline:
Prompt ──► 0G Compute (AI inference in TEE)
│
▼ generated code
0G Sandbox (execution in TEE)
│
▼ results
settled on 0G Network (trustless billing)
At every step — what you write, what the AI generates, what the code produces — the data
is invisible to any operator, including 0G itself. This end-to-end guarantee is something a
cloud provider, as a single point of trust, fundamentally cannot offer.
Quickstart: OpenClaw in a Private Sandbox
The fastest way to spin up an OpenClaw AI gateway
inside a 0G Private Sandbox is to let Claude do the work for you.
Prerequisites: Claude Code installed.
Option A — Install the plugin (recommended, no cloning needed)
/plugin marketplace add 0gfoundation/0g-sandbox
/plugin install 0g-private-sandbox@0g-sandbox
/reload-plugins
Then invoke the skill anytime:
/0g-private-sandbox
Option B — Clone the repo
git clone https://github.com/0gfoundation/0g-sandbox.git
cd 0g-sandbox
claude
Then just describe what you want in plain language, for example:
"I want to use 0G private sandbox to play with OpenClaw"
Claude will walk you through the rest. When asked for configuration details, the key piece
of information you need is:
| Item | Value |
|---|
| Testnet contract | 0xd7e0CD227e602FedBb93c36B1F5bf415398508a4 |
| RPC | https://evmrpc-testnet.0g.ai |
| Chain ID | 16602 |
Claude will handle onboarding, wallet setup, deposit, sandbox creation, and OpenClaw
configuration automatically.
TEE Key
The TEE key is the single signing key for the entire system — it both signs EIP-712 vouchers
off-chain and sends settlement transactions on-chain. It is fetched automatically from the
tapp-daemon gRPC at startup (or from MOCK_APP_PRIVATE_KEY in dev mode).
The TEE address needs a small amount of 0G for gas to submit settlement transactions.
To find the TEE signer address:
tapp-cli -s http://<server>:50051 get-app-key --app-id 0g-sandbox
# → Ethereum Address: 0x... ← fund this address with 0G for gas
Contract Deployment
See CONTRACTS.md for architecture, deploy/upgrade/verify instructions, and contract addresses.
Running the Server
Copy docker/sandbox/.env.dev to .env, fill in the required values:
cp docker/sandbox/.env.dev .env
# edit .env
go run ./cmd/billing/
Environment Variables
