Skill
ReviewAudited by ClawScan on May 18, 2026.
Overview
This wallet skill is mostly disclosed, but it asks for an agent signing credential and its docs conflict on whether Guardian co-signing is always required before spending.
Before installing, verify Sigil's co-signing thresholds and make sure low-value transactions cannot bypass the controls you expect. Use a dedicated agent signer only, never an owner wallet key, configure strict whitelists and spending limits, run dry evaluations before execution, and review the provider's data-handling terms.
Findings (4)
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.
A user may provide a signing credential believing every transaction needs Guardian co-signing, while the API reference describes a tier where the agent can sign alone.
This conflicts with the main safety claim in SKILL.md that every transaction requires both the agent's signature and the Guardian's co-signature. In a wallet-spending context, that inconsistency could cause users to overestimate the required approval boundary.
Co-Signing Tiers: LOW (below `guardianThreshold`): Agent signs alone; MEDIUM (above `guardianThreshold`): Agent + Guardian co-sign
Clarify the exact threshold behavior before use, configure strict policies and thresholds, and do not assume Guardian co-signing is mandatory for every transaction unless verified.
If the signer or API key is mishandled, the agent could submit transactions allowed by the wallet policy.
The skill requires an API key and an agent signing credential that can submit wallet transactions. This is purpose-aligned, but it is sensitive delegated financial authority.
`SIGIL_AGENT_SIGNER` | Purpose-generated agent signing credential for UserOp signatures ... `tx:submit` | ✅ | Submit transactions (Guardian-validated)
Use only a dedicated agent signer, never an owner wallet key, keep minimal gas on the signer, set strict whitelists and spending limits, and rotate credentials regularly.
Incorrect or overly broad transaction construction could move funds or interact with contracts on supported chains.
The documented API can submit signed UserOps on-chain. That is central to the stated wallet purpose, but it is an irreversible, high-impact action path.
POST https://api.sigil.codes/v1/execute ... Execute (Evaluate + Co-sign + Submit On-Chain) ... `userOp`: { `sender`, `nonce`, `callData`, `signature` }Prefer dry-run evaluation first, require clear user intent for transfers, and configure wallet policies so only approved targets, functions, and value limits are allowed.
Wallet activity and transaction intent may be visible to Sigil and its simulation or AI-risk infrastructure.
Transaction details and history are processed by external service components for simulation and AI risk scoring. This is disclosed and purpose-aligned, but users should understand the data flow.
Layer 2: Simulation ... Dry-runs the transaction via Tenderly ... Layer 3: LLM Risk Scoring ... AI analyzes the transaction in context of recent history.
Review Sigil's privacy and retention terms, avoid submitting unnecessary sensitive transaction data, and use accounts/policies appropriate for the trust you place in the provider.