SilkyWay
WarnAudited by ClawScan on May 10, 2026.
Overview
SilkyWay matches its stated Solana payments purpose, but it can sign and submit real-money transactions and stores wallet private keys locally, so it needs careful review before use.
Use devnet first, install only from a verified package/version, keep little or no real USDC in the generated wallet until you trust the setup, require manual approval for every payment, verify recipients and amounts, protect ~/.config/silkyway/config.json, and avoid using custom API endpoints unless you understand the signing risk.
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.
A mistaken or overly autonomous invocation could move real funds, and users must trust the API response to match the intended recipient, amount, token, and program.
The pay command takes a transaction returned by the SilkyWay API, signs it with the local private key, and submits it. The provided implementation does not show a local confirmation or transaction-instruction verification step before signing.
const { transaction: txBase64, transferPda } = buildRes.data.data;
const tx = Transaction.from(Buffer.from(txBase64, 'base64'));
const keypair = Keypair.fromSecretKey(bs58.decode(wallet.privateKey));
tx.sign(keypair);
...
signedTx: tx.serialize().toString('base64')Require explicit per-transaction user confirmation and locally verify decoded transaction instructions against the requested recipient, amount, mint, source wallet/account, and allowed program IDs before signing.
If the API URL is accidentally or maliciously redirected, the CLI could request transaction data from an unexpected server before signing.
The transaction-building API endpoint can be changed by config or the SILK_API_URL environment variable, but the registry metadata declares no environment variables. Combined with local signing of server-built transactions, this makes endpoint provenance important.
export function getApiUrl(config: SilkConfig): string {
return config.apiUrl || process.env.SILK_API_URL || CLUSTER_API_URLS[getCluster(config)];
}Declare this override, warn clearly when a non-official API URL is used, and consider disabling endpoint overrides for signing flows unless an explicit developer mode is enabled.
Any local user, process, backup, or malware able to read the config file could copy the wallet key and potentially spend funds from that wallet.
Wallet private keys are part of the saved JSON configuration, and the provided code does not show encryption, OS keychain use, or restrictive file-mode handling.
export interface WalletEntry {
label: string;
address: string;
privateKey: string;
}
...
fs.writeFileSync(CONFIG_FILE, JSON.stringify(config, null, 2), 'utf-8');Store keys in an OS keychain, encrypted keystore, hardware wallet, or at minimum create the config with restrictive 0600 permissions and clear warnings to keep funded balances limited.
The code a user installs from npm may not be exactly represented by the reviewed artifacts, making it harder to verify a tool that can sign financial transactions.
The executable installed by npm is dist/cli.js, but the provided file manifest contains TypeScript source and no dist/cli.js. For a payments CLI, the exact runnable code should be included or otherwise verifiably tied to the reviewed source.
"bin": {
"silk": "dist/cli.js"
},
"files": [
"dist"
]Include the built dist files in the review artifacts, align package-lock/package versions, publish immutable checksums, and pin the installed package version.
Anything typed into support chat is shared with the provider and can be linked to the persistent agent ID.
The support chat sends the user's message plus a persistent agentId to the SilkyWay API. This is purpose-aligned, but it is an external communication channel users should understand.
const res = await client.post('/chat', { agentId, message });Do not send private keys, seed phrases, or unnecessary payment details in chat; the provider should document retention and privacy handling.
