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.