Migration

OpenClaw gave you automation.
0trace gives you accountability.

Your scripts don't change. Your security posture does. Full feature parity plus a capability enforcement model OpenClaw was never designed for.

✓ Feature parity ✓ No vendor lock-in ✓ Git-native skill format

Why migrate

What changes. What stays. What you never worry about again.

A side-by-side look at what OpenClaw gives you and what 0trace adds on top.

OpenClaw0trace
Skill format Visual node graph Plain Markdown + YAML
Capability model Trust all / ambient authority Declare-first, deny by default
Audit trail Log aggregation (optional) SHA-256 hash-chained, built-in
Skill signing None Ed25519, verified before execution
Self-hosted Yes (Node.js + PostgreSQL) Yes (single Zig binary + SQLite)
Runtime deps Node.js, npm, external DB Zero — single binary
Version control Export/import JSON Git-native (plain text files)
Memory footprint ~512 MB typical 64 MB default cap

Why migrate before something goes wrong?

An OpenClaw skill runs with whatever authority is present in its environment.

That works fine — until it doesn't. A skill tampered with between commit and execution. An agent writing to a path you didn't intend. An auditor asking you to prove what your agents did on a specific date.

0trace's execution model makes these scenarios structurally impossible or immediately verifiable. You don't have to wait for an incident to justify the migration.

✗
Skill tampered between commit and execution

No signature check → runs anyway

✗
Agent writes to an unintended path

No capability enforcement → no alert

✗
Auditor asks what Agent 7 did on March 3rd

No hash chain → no provable answer

✓
With 0trace: all three are solved structurally

Before you ever need to explain them

Concept mapping

Everything has an equivalent

The concepts translate directly — the format is just more secure.

OpenClaw0traceNotes
Flow / Workflow Skill (.md file) 0trace skills are version-controlled plain text
Node / Step Step in skill frontmatter Declarative, not visual drag-and-drop
Trigger Scheduler / API call / CLI zt run skill.md or HTTP POST /api/run
Credential / Secret secrets.read:SECRET_NAME Referenced by name, never embedded
Team / Workspace Org Managed via dashboard or API
Execution History Run + Audit Log SHA-256 chained, tamper-evident
Plugin Capability declaration Explicit resource access replaces opaque plugins
Node editor Code editor (any) Skills are text files — edit anywhere

Step by step

Seven steps. Run 0trace alongside OpenClaw — no cutover required.

1

Audit your OpenClaw flows

Export all flows from OpenClaw. List every credential, every external service, every file path your flows touch. This becomes your capability list in 0trace.

2

Install 0trace

# Docker
docker pull 0trace/runtime:latest
docker run -p 8080:8080 0trace/runtime zt serve

# Or download the binary
curl -L https://github.com/0trace-ai/zt/releases/latest/download/zt-linux-amd64 -o zt
chmod +x zt && ./zt --version
3

Convert your flows to skills

Each OpenClaw flow becomes a .md file. Before and after:

Before (OpenClaw)

backup.flow.json
// OpenClaw flow (simplified JSON)
{
  "name": "Backup Database",
  "trigger": { "type": "cron", "schedule": "0 2 * * *" },
  "nodes": [
    { "type": "credential", "id": "db-cred" },
    { "type": "execute", "cmd": "pg_dump", "credential": "db-cred" },
    { "type": "write", "dest": "/var/backups" }
  ]
}

After (0trace)

backup-database.md
# Backup Database
capabilities:
  - fs.write:/var/backups
  - secrets.read:DB_PASSWORD
  - process.exec:pg_dump
steps:
  - run: pg_dump -U admin {{secrets.DB_PASSWORD}} mydb > /var/backups/dump.sql
4

Declare capabilities

For each external resource your skill needs, add a capability declaration. Start restrictive — run the skill and see what gets blocked, then add only what's needed.

5

Sign your skills

Generate a keypair and sign your skill bundles before running in production.

zt sign backup-database.md --key=~/.zt/signing-key.pem
6

Run and verify

Execute the skill. Check the audit log. Verify the hash chain.

zt run backup-database.md
zt audit --skill=backup-database --verify
7

Migrate your team

Create an org, invite team members, migrate your credential store. When all skills are validated, decommission OpenClaw.

Parity

Everything OpenClaw does. Plus a security model it was never designed for.

Your workflows stay. Your scripts stay. Your accountability posture gets an upgrade.

✓ Scheduled execution (cron-style triggers)
✓ HTTP API trigger (POST /api/run)
✓ Secret / credential management
✓ Multi-step workflows
✓ Execution history and logs
✓ Team / org management
✓ Web dashboard
✓ Self-hosted deployment
✓ Docker support
✓ Ed25519 skill signing (new)
✓ Hash-chained audit log (new)
◦ Visual node editor (not planned — text-first)
◦ Managed cloud hosting (coming soon)

FAQ

Common questions

Do my existing OpenClaw flows work as-is?

Not directly — OpenClaw uses a node graph format; 0trace uses Markdown skills. But the migration is straightforward: each node/step maps to a step declaration, and each credential maps to a capability. The guide above covers the full conversion.

Do I need to rewrite my scripts?

No. Your shell scripts, Python scripts, and API calls stay the same. Only the wrapper format changes from OpenClaw's JSON graph to a 0trace Markdown skill.

Can I run 0trace and OpenClaw in parallel during migration?

0trace is a completely separate binary with no dependencies on OpenClaw. Run both simultaneously, migrate flows one at a time, then decommission OpenClaw when done.

What about my OpenClaw plugins?

0trace's capability model replaces plugins. Instead of installing a plugin to access Stripe, you declare network.fetch:api.stripe.com. The difference: 0trace's model is explicit and auditable by default.

Is there a migration tool?

Not yet. We're building a CLI converter (zt migrate --from=openclaw flow.json). Follow the GitHub repo for updates.

Start with one skill. Migrate the rest when you're ready.

The runtime runs alongside OpenClaw — no cutover required.