Monolith — Crypto Wallet
ReviewAudited by ClawScan on May 10, 2026.
Overview
This appears to be a purpose-aligned crypto wallet skill, but it can move real funds and relies on an external privileged daemon, so it deserves careful review before installation.
Only install if you trust and can verify the Monolith daemon package, because that component enforces wallet security and signs transactions. Start with very low caps, a minimal allowlist, explicitly specify chain IDs, and only enter approval codes after checking the native macOS approval summary.
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 daemon package is compromised or not the expected release, it could affect wallet policy enforcement or transaction signing even if the skill code looks reasonable.
The security-critical signer and policy enforcer is an external privileged package rather than the reviewed JS skill files, and the artifact does not provide checksums or code-signing verification details.
Install local macOS components ... `MonolithDaemon-v0.1.5.pkg` (admin/root install) ... The signing daemon ... enforces all policy.
Install only from a trusted, verified release; check the daemon package signature/checksum and review the daemon source before funding the wallet.
A user or agent omitting the chainId could submit a transaction on Base instead of the intended wallet/home chain.
The command comment says an omitted chain uses the daemon home chain, but the code hard-defaults to chain 8453. For a send operation, that mismatch could lead to an unintended chain selection if the daemon accepts the hint.
chainId: 1 or 8453 (optional, uses daemon's home chain) ... const chainId = chainIdStr ? parseInt(chainIdStr, 10) : 8453;
Require an explicit chainId for sends, or query and display the daemon home chain before building the transaction intent.
An agent can move funds without a per-transaction prompt when the action fits configured caps and allowlists.
Automatic in-policy transactions are clearly disclosed and central to the wallet-for-agents design, but they are still high-impact financial actions.
Transactions within policy limits execute automatically (autopilot). ... ETH and USDC transfers within limits to allowlisted addresses
Keep spending caps low, keep the allowlist narrow, and review audit logs regularly.
Approving policy or allowlist changes can expand what future agent actions may do automatically.
The skill can request changes to wallet spending controls and recipient allowlists. This is purpose-aligned and described as Touch ID protected, but it changes future transaction authority.
`policy update '<json>'` | Update spending policy (Touch ID required) ... `allowlist <add|remove> <address> [label]` ... (Touch ID required)
Approve these changes only when the native confirmation exactly matches your intent.
If the runtime environment is tampered with, wallet requests could be sent to an unexpected local service.
The daemon endpoint can be redirected by an environment variable that is not declared in the metadata. In this wallet flow, intents and approval codes are sent to the selected local socket.
export const SOCKET_PATH = process.env.MONOLITH_SOCKET || `${process.env.HOME}/.monolith/daemon.sock`;Do not set MONOLITH_SOCKET unless you intentionally use a test daemon; consider pinning/authenticating the daemon endpoint.