Solana Payments
PassAudited by VirusTotal on May 12, 2026.
Overview
Type: OpenClaw Skill Name: solana-payments Version: 1.0.0 The skill bundle is benign. It provides instructions and code examples for creating Solana USDC subscription payment URLs using the `@tributary-so/payments` SDK. All network interactions are directed to the `tributary.so` domain, which is consistent with the stated purpose. There is no evidence of data exfiltration, malicious execution, persistence mechanisms, or prompt injection attempts against the agent to perform actions outside the skill's stated scope. The `!IMPORTANT!` instruction regarding the gateway public key is a security-relevant instruction to ensure the payment system functions correctly, not a malicious directive.
Findings (0)
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 amount, recipient, frequency, or auto-renew setting could produce a payment link that asks customers to approve the wrong recurring payment.
The documented checkout session can create recurring subscription-payment URLs, including an example with auto-renew enabled and an unlimited-renewal default.
autoRenew: true ... mr: Maximum renewals (default: "null" = unlimited)
Before sharing or using a checkout URL, explicitly confirm the recipient public key, amount, billing frequency, auto-renew setting, maximum renewals, success URL, and cancel URL.
Users who follow the setup may add a third-party package to their project; package provenance and version changes affect security.
The instruction-only skill directs users to install an external npm SDK, while the registry provides no install spec or pinned package version.
npm install @tributary-so/sdk
Install the SDK only from the trusted npm source, pin an expected version, and review the package documentation or lockfile before production use.
Customer IDs, plan names, or other metadata placed in tracking IDs or memos may become visible in public blockchain transaction history.
The documentation encourages per-user tracking identifiers and notes that memo data is stored on-chain, which can make identifiers persistent and publicly visible after payment.
Tracking IDs should be unique per user/subscription combination ... memo: "Monthly premium subscription - user_123" ... This memo is stored in the transaction MEMO field on-chain
Avoid putting personal data, internal account IDs, or sensitive business details in tracking IDs or memos; use opaque, non-identifying references where possible.