0G ClawBack
WarnAudited by ClawScan on May 16, 2026.
Overview
This skill matches its backup purpose, but it ships a wallet private key and can persist broad agent/workspace state and recovery keys to memory and 0G Storage, so it needs careful review before use.
Install only after removing the bundled .env file, supplying your own scoped wallet credentials, and confirming exactly which files will be backed up. Treat 0G uploads as long-lived/publicly addressable, and store encryption keys outside agent memory in a proper secret manager.
Publisher note
This version runs Openclaw to create a backup, which is then stored in a decentralized environment.
Findings (3)
Artifact-based informational review of SKILL.md, metadata, install specs, static scan signals, and capability signals. ClawScan does not execute the skill or run runtime probes.
Uploads may run using an exposed or unintended wallet key, and users may not realize the skill depends on sensitive wallet credentials.
The skill package includes a real-looking wallet private key, and the upload scripts use `process.env.PRIVATE_KEY` to create an ethers wallet signer.
PRIVATE_KEY="0x4083026c...1c80d246a"
Remove the bundled .env/private key, declare required environment variables and credential needs in metadata, and require users to provide their own scoped testnet/mainnet wallet intentionally.
Private project files, memory logs, configuration notes, or generated tools could be packaged and uploaded more broadly than the user expects.
The instructions create lifecycle-triggered backups of the active workspace and upload them to 0G Storage without clearly bounding paths, exclusions, or requiring explicit per-upload confirmation.
Run the ClawBack pipeline when... After modifying `MEMORY.md`... Skill evolution... `openclaw backup create` ... `npm run upload:secret -- <PARSED_FILE_PATH>`
Require explicit user approval for each backup/upload, show the exact files included, exclude secrets by default, and document retention/reversibility limits for 0G Storage.
Recovery keys could be exposed through future agent context, memory sharing, backups, or accidental publication, making encrypted uploaded state recoverable by others who obtain the key.
The skill directs the agent to store the decryption key in persistent memory or a tracking database, even while acknowledging that the key is sensitive.
Immediately record both values in the active tracking database or `MEMORY.md`... `Encryption Key Hex:`... Treat the hex key as a private security credential.
Do not store encryption keys in general MEMORY.md; use a dedicated secret manager or user-controlled vault and keep only non-sensitive root hashes in agent memory.