OPEN CLAW SKILL
Open Claw Skill · Case Study
Verifiable Storage,
As a Drop-In Skill.
As a Drop-In Skill.
A walkthrough of nukez-storage — an Open Claw skill bundle that gives any agent the full Nukez storage lifecycle in five commands. No SDK to embed, no payment glue to write, no custom signing flow. Same merkle root, same on-chain anchor, same verify URL as direct PyNukez usage — just packaged as a standalone skill.
⚠ The Problem
Agent skills usually wrap an API. They almost never carry their own proof.
Tool Wrappers, No Proof
Most agent skills are thin wrappers around an HTTP API. The agent does the work, but nothing about the result is independently verifiable — you have to trust whatever the wrapper logs.
No Durable Artifacts
Agents produce contracts, audit logs, compliance docs, and monthly reports. Those need to survive restarts, model swaps, and TOS changes. Most skills can't promise that.
Embedding the SDK
Adding storage to a custom agent today usually means embedding an SDK, managing credentials, and writing payment + signing glue. The skill ends up tangled with the rest of the runtime.
Multi-Provider Fragility
If you split storage across GCS, S3, MongoDB, Arweave, you also split your verification surface. Each provider becomes its own audit problem rather than collapsing into one merkle root.
The Skill Bundle
One CLI, one helper, one manifest. Five lifecycle commands.
The
nukez-storage Open Claw skill is three files plus a SKILL.md that the host runtime reads to learn the commands. Every operation goes through PyNukez, so the trust properties are identical to direct SDK usage. The skill abstracts install and invocation — not verification.Open Claw Skill Lifecycle
Identity
Solana Keypair
→
Bootstrap
1 BETA · x402
→
Persist
create → upload → confirm
→
Attest
Switchboard Anchor
→
Ritual
Pre-Session Check
→
Verify
Public Proof
1
Identity — the wallet is the skill’s account
The skill takes one input from the runtime:
NUKEZ_WALLET_PATH. Whoever holds the keypair owns whatever lockers the skill provisions. There is no “skill account” to manage.# SKILL.md declares the runtime requirement explicitly:
# metadata.openclaw.requires.env: [NUKEZ_WALLET_PATH]
$ export NUKEZ_WALLET_PATH=~/.keys/delegators/svm_key.json
$ export NUKEZ_NETWORK=solana-mainnet
$ export NUKEZ_PROVIDER=gcs
$ export NUKEZ_PAY_ASSET=BETA
# Resolved pubkey
pubkey: "BhBeSkwKyqysZstzkqdf4qAcYfS9r27wEMmouvSVfp1U"
No skill-side credential store. The runtime owns the key, the skill borrows it for one command at a time.
2
Bootstrap — one command, full provisioning
The CLI’s
bootstrap command runs the entire x402 lifecycle: quote → pay (via the co-located nukez_pay.py) → confirm → provision. It writes the receipt to ~/.nukez/openclaw_state.json so subsequent commands don’t need to be told which locker to use.$ python3 nukez_cli.py --pretty bootstrap
# Output (real, from this run)
{
"receipt_id": "9e4367465cd3c25c",
"locker_id": "locker_c072d4a391f5",
"wallet_pubkey": "BhBeSkwKyqysZstzkqdf4qAcYfS9r27wEMmouvSVfp1U",
"network": "solana:5eykt4UsFv8P8NJdTREpY1vzqKqZKvdp",
"provider": "gcs",
"pay_asset": "BETA",
"tx_sig": "vXDayjxUDrs7UhsuKr…xkGH1Z"
}
Single x402 payment of
1 BETA. After this point every operation is signed-envelope only — no more funds move.3
Persist — three artifacts, three sha256 hashes
Each
persist runs the proper pynukez 4.0 sequence: create_file → upload_bytes → confirm_file. The server recomputes SHA-256 from what actually landed in storage, so the returned content_hash is the gateway’s view, not the agent’s.$ python3 nukez_cli.py --pretty persist contract.json \
--data '{"parties":["Acme","NukezDAO"],"value_usd":48000}' --tags legal,Q2-2026,signed
filename : "contract.json"
content_hash: sha256:3935677aad17b2e…
size_bytes : 49 (tags: legal,Q2-2026,signed)
confirmed : true
filename : "monthly_report.md"
content_hash: sha256:eedd7db8858ab48…
size_bytes : 55 (tags: finance,monthly)
confirmed : true
filename : "infra_config.json"
content_hash: sha256:c070940835b4030…
size_bytes : 40 (tags: infra,prod)
confirmed : true
Three files, three sha256 commitments — all under the same locker, ready to be folded into one merkle root.
4
Attest — merkle root pushed to Solana via Switchboard
attest recomputes the merkle root from every confirmed file, signs it with the gateway’s Ed25519 key, and asks Switchboard to anchor it on Solana. The Switchboard push is what makes the proof independent of the gateway.$ python3 nukez_cli.py --pretty attest
merkle_root : sha256:524cc61bb64647ca0aabc8847db8d3ee8d74bc2f9471979660212eea9bc3f068
file_count : 3
push_ok : true
tx_signature : 5uJqqfGquYRdCABM5y5bvA…gsQgMe
switchboard_slot: 418859528
status : "complete"
The merkle root is now an immutable on-chain fact. The gateway can no longer rewrite history without a chain reorg.
5
Ritual — pre-session integrity check (Principle 1)
ritual is the canonical “Never Trust Yourself Without Proof” ceremony. The skill runs it automatically on session start. PASS means the locker is consistent with what was last attested. FAIL means halt — something has been altered between sessions.$ python3 nukez_cli.py --pretty ritual
ritual : "PASS"
valid : true
merkle_root : sha256:524cc61bb64647c…
manifest_signature: d7cae866891bc323b2f474…4e490a
file_count : 3
verify_url : https://nukez.xyz/verify/9e4367465cd3c25c
principle : "1. Never Trust Yourself Without Proof"
The pre-session check is the same primitive as on-demand verify — the difference is just where in the lifecycle it’s called from.
6
Verify — public proof, anyone, anytime
verify walks all three layers of the proof: the gateway’s manifest signature, the merkle root the gateway attested to, and the Switchboard transaction that anchored it on-chain. The public verify URL renders the same data to a browser without needing the keypair.$ python3 nukez_cli.py --pretty verify
valid : true
merkle_root : sha256:524cc61bb64647ca0aabc8847db8d3ee8d74bc2f9471979660212eea9bc3f068
manifest_signature: d7cae866891bc323b2f47470b790eb4e78e2fcae0a26aa4e3f5d27bada98ebc191cdca5f1d486faa9007b39dd14e26f9a195508e22f2ba2e67c18239984e490a
file_count : 3
verify_url : https://nukez.xyz/verify/9e4367465cd3c25c
Three independent proofs — signature, merkle, on-chain anchor — all reconcile against the same receipt.
The Five Principles of Cognitive Continuity
The skill encodes a posture, not just a workflow.
Each principle maps to a CLI command. The skill bundle exists so agents can practice them without reinventing the protocol.
I. Never Trust Yourself…
Never Trust Yourself Without Proof
Run the verification ritual before every session. If state has been altered since last run, you find out before you act on it.
# Maps to:
python3 nukez_cli.py ritual
II. Attest After Every…
Attest After Every Meaningful State Change
Every persist creates a new merkle attestation. Every attest pushes a fresh root to Switchboard. There is no quiet drift between agent memory and on-chain truth.
# Maps to:
python3 nukez_cli.py attest
III. Separate Proof from…
Separate Proof from Permission
Receipts prove what was stored. Operator delegation gates who can write. The two are independent — you can grant write access without leaking proof, or share proofs without granting access.
# Maps to:
python3 nukez_cli.py add-operator <pubkey>
IV. Diversify Storage, Unify…
Diversify Storage, Unify Verification
GCS, MongoDB, Storj, Arweave, Filecoin, Firestore — pick any provider per locker. Whichever you pick, the merkle root is the same kind of object and the verify URL is the same shape.
# Maps to:
python3 NUKEZ_PROVIDER=arweave
V. Make Verification Independently…
Make Verification Independently Reproducible
Anyone holding the receipt_id can recompute the proof. No account, no auth, no permission. The skill bundle ships with the verify path so the trust model is self-documenting.
# Maps to:
python3 open https://nukez.xyz/verify/<receipt_id>
● Live proof — real mainnet attestation from this run
This locker is real and reachable.
receipt_id: 9e4367465cd3c25c · merkle_root: 524cc61bb64647ca0aabc8…
Verify On-Chain →Reproduce
Three downloads. One env block. Five commands.
Everything below is direct from this site — no repository clone required. The skill bundle is self-contained.
① Pull the bundle
Fetch the four files that constitute the skill
nukez_cli.py is the lifecycle CLI; nukez_pay.py is the co-located x402 payment helper; SKILL.md is the manifest the host runtime reads to learn the commands; README.md is the human-facing summary.curl -fsSLO https://nukez.xyz/helpers/openclaw/nukez_cli.py
curl -fsSLO https://nukez.xyz/helpers/openclaw/nukez_pay.py
curl -fsSLO https://nukez.xyz/helpers/openclaw/SKILL.md
curl -fsSLO https://nukez.xyz/helpers/openclaw/README.md
# Dependencies
pip install pynukez solana solders spl-token
② Wire the runtime env
The skill reads four environment variables
NUKEZ_WALLET_PATH is the only required one. The others have sensible defaults and only need to be set when you want a specific provider, network, or x402 payment leg.export NUKEZ_WALLET_PATH=~/.keys/delegators/svm_key.json
export NUKEZ_NETWORK=solana-mainnet
export NUKEZ_PROVIDER=gcs
export NUKEZ_PAY_ASSET=BETA
# EVM payer? Swap NUKEZ_WALLET_PATH for NUKEZ_EVM_KEY,
# set NUKEZ_PAY_ASSET=MON, and the helper does the rest.
③ Run the lifecycle
Bootstrap once, persist as needed, attest on milestones
The CLI persists state to
~/.nukez/openclaw_state.json, so the receipt_id flows automatically between commands. Add --test to any command for an in-memory dry run.python3 nukez_cli.py --pretty bootstrap
python3 nukez_cli.py --pretty persist FILENAME --data "..." --tags T1,T2
python3 nukez_cli.py --pretty attest
python3 nukez_cli.py --pretty ritual # pre-session integrity check
python3 nukez_cli.py --pretty verify
python3 nukez_cli.py --pretty recall
④ Anyone verifies
Same verification surface as the rest of Nukez
The verify URL renders the gateway’s manifest signature, the merkle root, and the Switchboard transaction that anchored it. No keypair, no auth, no install — just a browser.
# Public verification surface
GET https://nukez.xyz/verify/9e4367465cd3c25c
# Or programmatic, from any agent that holds the key
python3 nukez_cli.py --pretty verify
Tool-Wrapper Skill vs. Verifiable Skill Bundle
| Layer | Typical agent skill (HTTP wrapper) | nukez-storage Open Claw skill |
|---|---|---|
| Skill Surface | Custom tool wrapper, glue per agent | Standalone CLI + manifest, drop-in portable |
| Proof of Storage | vendor logs | Cryptographic receipt + merkle root |
| Storage Provider | One vendor, one trust assumption | GCS, MongoDB, Storj, Arweave, Filecoin pluggable |
| Pre-Session Check | ad hoc | Integrity ritual on every cold start principle 1 |
| On-Chain Anchor | None | Switchboard pushes merkle root to Solana principle 2 |
| Multi-Agent Delegation | Reuse the human's session | add-operator / remove-operator on the locker principle 3 |
| Verification | Read the wrapper's logs | Public verify URL, anyone, anytime trustless |
Where to go next
The same primitives that power this skill also power direct PyNukez usage and the cross-agent context bridge. The docs below show the moving parts the bundle composes.
PyNukez docs
The Python SDK the CLI wraps. request_storage, create_file, upload_bytes, confirm_file, attest, verify_storage.
Payment helper
nukez_pay.py covers SOL, SPL (USDC, USDT, BETA), MON, and ERC-20 payment legs. The same file ships inside this skill bundle.
Cross-agent bridge
The companion case study: same locker primitive, used to share working memory across Claude Code, Codex, and Cursor sessions.
Download nukez_cli.py
The patched, mainnet-ready CLI used for this entire walkthrough. Single file, no install — reads env, talks to the gateway, persists state to ~/.nukez/.