Clawpay
WarnAudited by ClawScan on May 10, 2026.
Overview
ClawPay’s instructions match a payment tool, but they ask an agent or user to use a wallet private key and move real USDT through a third-party API with limited safeguards.
Treat this as a real-money payment integration. Only use a separate low-balance wallet, never expose a main private key, pin and inspect dependencies, verify every recipient/amount/invoice address manually, and do not allow autonomous agent execution without explicit per-transfer approval and limits. Assume ClawPay can see payment metadata unless proven otherwise.
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 an agent, script, dependency, or operator mishandles the key, real wallet funds could be lost.
A wallet private key is a full-control financial credential; the artifacts do not define a scoped credential, spending limit, or safer signing boundary.
“Prerequisites: You need a wallet private key with USDT on BSC.” ... “const PRIVATE_KEY = process.env.WALLET_KEY || '0xYOUR_PRIVATE_KEY';” ... “WALLET_KEY=0xYourPrivateKey node send-private.mjs”
Use only a dedicated low-balance wallet, never a main wallet private key, and require explicit user approval and spending limits for every payment.
A wrong recipient, wrong amount, compromised invoice response, or misunderstood workflow could cause irreversible financial loss.
The workflow sends real USDT on-chain to an invoice address returned by the ClawPay API before completing the private transfer, with no built-in confirmation, verification, or rollback guidance.
“const { invoiceAddress } = await invoiceRes.json();” ... “const tx = await usdt.transfer(invoiceAddress, parseUnits(AMOUNT, 18));” ... “await tx.wait();”Manually verify the recipient, amount, network, token, invoice address, service identity, and fees before each transfer; do not let an agent run this autonomously without confirmation.
If the signature is logged, leaked, or replayed, it may let someone interact with ClawPay as that wallet for provider-side actions.
A static signature and payment metadata are sent to the provider, including in a URL query string; the artifact does not show that this authorization is bound to a specific recipient, amount, or expiry.
“const SIGN_MSG = 'b402 Incognito EOA Derivation';” ... “'/invoice?eoa=' + myAddress + '&signature=' + encodeURIComponent(signature)” ... “body: JSON.stringify({ eoa: myAddress, signature, recipient: RECIPIENT, amount: AMOUNT, token: 'USDT' })”Treat the signature as a secret, avoid URL-query authentication, and prefer per-transfer signatures that include recipient, amount, token, chain, nonce, and expiry.
The installed package version may change over time, which matters more for a real-money workflow.
The manual dependency install is expected for the sample JavaScript workflow, but it is unpinned and has no lockfile in the provided artifacts.
“npm install ethers”
Pin dependency versions, use a lockfile, and inspect the copied script before running it.
Users may overestimate the privacy provided and assume the payment is hidden from ClawPay itself.
The privacy claim is framed around recipient/on-chain unlinkability, while the provider API receives sender, recipient, amount, token, and signature data.
“Recipient sees funds from Railgun - can't trace back to you.” ... “body: JSON.stringify({ eoa: myAddress, signature, recipient: RECIPIENT, amount: AMOUNT, token: 'USDT' })”Assume the provider can see the sender-recipient relationship unless its privacy model, logging, and retention practices are independently verified.