Receipts Guard
WarnAudited by ClawScan on May 10, 2026.
Overview
Receipts Guard’s purpose is coherent, but it can use wallet/private identity authority and make on-chain changes while the registry declares no credentials, and its security approval claim covers an older feature set.
Review this skill carefully before installing. Use a dedicated low-value wallet, require manual approval for transactions/payments/rulings, protect the local receipts directory, and verify the full current source and server authentication before any cloud deployment.
Findings (5)
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.
If the agent has this private key, it can sign blockchain transactions for this workflow, spend gas, and alter public identity or reputation state.
A blockchain wallet private key is high-impact account authority. The supplied registry metadata says there are no required env vars or primary credential, so this authority is under-disclosed in the install contract.
Registers identity on-chain to ERC-8004 Identity Registry: - Requires `RECEIPTS_WALLET_PRIVATE_KEY` environment variable - Stores transaction hash in DID document - Mainnet: credibility anchor
Use only a dedicated low-balance wallet, expose the private key only when needed, and require human approval for all transaction-signing or payment actions. The skill metadata should explicitly declare this credential.
A mistaken or overly autonomous invocation could register or modify identity/reputation records and incur transaction costs.
The code includes Ethereum tooling and ERC-8004 registry write interfaces. That is expected for this skill, but these tools can create durable public-chain effects.
const { ethers } = require('ethers'); ... 'function register(string agentURI) external returns (uint256)' ... 'function setMetadata(uint256 agentId, string metadataKey, bytes metadataValue) external' ... 'function giveFeedback(uint256 agentId, int128 value, ...)'Treat chain-related commands as transaction-signing operations. Review chain, contract address, gas cost, and payload before allowing the agent to run them.
Local compromise or unsafe backups of the .openclaw receipts directory could expose identity keys or arbitration evidence.
The skill persistently stores identity material and private keys on disk. The audit describes file permissions, but not encryption at rest.
~/.openclaw/receipts/identity/ ├── did.json [644] Public DID document ├── private/ [700] Restricted directory │ ├── key-current.json [600] Active private key │ └── key-archive/ [700]
Protect and back up `~/.openclaw/receipts` carefully, avoid shared machines, and consider adding encryption or passphrase protection for private keys.
Users may trust the current wallet, server, and payment features more than the provided audit evidence supports.
The bundled audit is for v0.6.0, while the evaluated skill is v0.7.1 and adds HTTP server, x402, cloud deployment, and ERC-8004 features. The production-approval wording may overstate coverage of the current high-impact functionality.
Security Audit Report: receipts-guard v0.6.0 ... Overall Assessment: **PASS** ✅ ... **Recommendation:** Approved for production use.
Do not rely on the v0.6.0 audit for v0.7.1. Request or perform a current review of the HTTP, x402, ERC-8004, and wallet-handling code before production use.
If deployed, the service may continue storing identity/evidence data and responding to API requests beyond a single local task.
The deployment config supports a persistent cloud service that can restart on requests. This is disclosed and purpose-aligned, but it changes the skill from a local CLI into a reachable service.
[mounts] source = "receipts_data" destination = "/data" ... auto_stop_machines = true auto_start_machines = true min_machines_running = 0
Deploy server mode only if needed, verify authentication and CORS settings, and ensure persistent data and secrets are stored in the intended protected location.