PayTrigo (OpenClawBot, Base/USDC)

Use when an OpenClawBot needs to create or verify PayTrigo payments on Base/USDC without webhooks.

Security Scan

The skill's code implements the advertised PayTrigo flows correctly, but it embeds live-looking platform API keys in multiple scripts and encourages passing private keys on the CLI — practices that are disproportionate and risky for an unknown-source skill.

Purpose & Capability

The code (scripts/*.mjs) implements invoice creation, intent retrieval, tx submission and polling against api.paytrigo.net, which matches the skill description (PayTrigo on Base/USDC). However, instead of requiring the operator to supply a platform API key or declare it as a credential, the scripts ship with hardcoded 'sk_live_...' API keys, which is unusual and insecure for a reusable skill — embedding keys is not necessary for the stated purpose and reduces control for the user.

Instruction Scope

SKILL.md instructs the agent/user to create/read local wallet files, passphrase files, and optionally provide a raw private key via CLI. These actions are within the payment flow's scope, but accepting private keys on the command line (or storing unprotected files) and using an embedded platform key expands the risk surface; the instructions do not require or instruct any unrelated system access.

Install Mechanism

There is no external download/install spec beyond npm install and a single dependency (ethers). No remote archives or unknown URL downloads are used; installation risk is limited to typical npm dependency installation.

Credentials

The package declares no required env vars and SKILL.md claims a platform key is embedded for no-setup usage. The code contains multiple hardcoded platform keys (files: scripts/moltbot-bot-flow.mjs, scripts/moltbot-human-flow.mjs, scripts/paytrigo.mjs). Embedding live-looking API keys in distributed code is disproportionate and risky: keys can be abused, are not user-controlled, and there is no declaration of who owns them. The scripts also encourage passing private keys via CLI (exposes them to process lists) or storing passphrases/files locally — both are legitimate for operation but should be handled more securely and explicitly documented as risky.

Persistence & Privilege

always:false and no install-time persistence or modification of other skills is requested. The skill does not claim or implement system-wide configuration changes beyond writing its own local wallet/recipient files under a .openclawbot directory.

Scan Findings in Context

[HARD_CODED_API_KEY_moltbot-bot-flow] unexpected: scripts/moltbot-bot-flow.mjs contains a hardcoded API_KEY value 'sk_live_EQRe18nZCj...'. Supplying a platform key inside distributed code is not expected as a best practice even though the skill claims to use a platform key.

[HARD_CODED_API_KEY_moltbot-human-flow] unexpected: scripts/moltbot-human-flow.mjs contains a hardcoded API_KEY 'sk_live_EQRe18nZCj...'. Same concern as above.

[HARD_CODED_API_KEY_paytrigo] unexpected: scripts/paytrigo.mjs contains a DEFAULT_API_KEY 'sk_live_M4vDBePQLu8Uenl-...'. Multiple embedded keys across files increase the chance the distributed keys are live and may be abused.

What to consider before installing

This skill mostly does what it says (creates invoices, returns intents, polls status), but exercise caution before installing or running it: - Do not rely on the embedded API keys. Treat the hardcoded 'sk_live_...' values as secrets that could be abused by whoever controls them. Prefer to replace them with your own platform key (provided securely) or modify the code to read a key from a protected environment variable. - Verify the source. The skill has no homepage and an unknown source; confirm you trust the author before using keys embedded in their code. - Avoid passing raw private keys on the command line (use encrypted wallet files and passphrases). Passing a private key via --pk can expose it in process listings; use the encrypted wallet store and supply passphrases via a file with strict permissions. - Review and, if desired, remove or rotate any embedded keys before running in production. Test with minimal amounts and in an isolated environment first. - If you need this functionality but don't want to trust embedded credentials, fork the code, remove the hardcoded keys, and inject your API key via env vars or a secure secrets mechanism. If you want, I can help produce a safe checklist or provide a patched version of the scripts that reads API keys from environment variables and warns if a hardcoded key is present.

This skill provides a minimal, bot-friendly payment flow on PayTrigo using a platform API key and Base/USDC only. It is optimized for OpenClawBots that do not run webhooks and instead poll for status. A platform key is embedded in the helper script for no-setup usage.

Assumptions

• Platform key is used (recipientAddress required).
• Base/USDC is the only enabled chain/token for this key (from Platform Fee Configs).
• Bots can store invoiceId and checkoutToken returned from invoice creation.

No environment variables required

The helper script ships with an embedded key, so OpenClawBots can use it immediately.

Install

Requires Node.js 18+.

npm install

Local wallet memory (recommended)

OpenClawBots can store a recipient address and an encrypted payer wallet locally (no external services needed).

1) Create a local wallet store

node {baseDir}/scripts/moltbot-wallet-setup.mjs create --passphrase-file ./passphrase.txt --set-recipient-from-wallet

This creates .openclawbot/wallet.json, .openclawbot/wallet-address.txt, and .openclawbot/recipient.txt.

If you already have a wallet

You do not need to create a new one.

node {baseDir}/scripts/moltbot-wallet-setup.mjs recipient --address 0xYourWallet
node {baseDir}/scripts/moltbot-wallet-setup.mjs import --pk-file ./payer.pk --passphrase-file ./passphrase.txt --set-recipient-from-wallet

2) Run flows using the stored data

node {baseDir}/scripts/moltbot-human-flow.mjs human --amount 0.001
node {baseDir}/scripts/moltbot-bot-flow.mjs bot --amount 0.001 --passphrase-file ./passphrase.txt

3) Optional: set a separate recipient address

node {baseDir}/scripts/moltbot-wallet-setup.mjs recipient --address 0xYourWallet

Quickstart (CLI scripts)

Use the scenario scripts to test end-to-end flows without additional setup.

Human-in-the-loop (user pays in browser)

node {baseDir}/scripts/moltbot-human-flow.mjs human --amount 0.001 --recipient 0xYourWallet...

Bot pays directly (requires private key)

node {baseDir}/scripts/moltbot-bot-flow.mjs bot --amount 0.001 --recipient 0xYourWallet... --pk 0xPRIVATE_KEY

See README.md in this folder for a short OpenClawBot-focused guide.

Core flow (Human-in-the-loop)

1. Create invoice (platform key, Base/USDC, recipientAddress required)
2. Send payUrl to the user (approval + payment)
3. Poll invoice status until confirmed | expired | invalid | refunded

Core flow (Bot pays directly)

1. Create invoice
2. Get intent (approve/pay calldata)
3. Send on-chain tx (approve if needed, then pay)
4. Submit txHash
5. Poll status

Important: Direct token transfer is invalid. Always use the Router steps.pay from /intent.

---

API Usage (HTTP)

1) Create invoice

Endpoint: POST /v1/invoices

Headers:

• Authorization: Bearer <platform_key> (required if calling HTTP directly)
• Content-Type: application/json
• Idempotency-Key: pay_attempt_<uuid>

Body (Base/USDC fixed, recipientAddress required)

{
  "amount": "49.99",
  "recipientAddress": "0xYourWallet...",
  "ttlSeconds": 900,
  "metadata": { "botId": "openclawbot_123", "purpose": "checkout" }
}

Response includes invoiceId, payUrl, checkoutToken, expiresAt.

2) Get intent (bot-pay)

Endpoint: GET /v1/invoices/{invoiceId}/intent?chain=base&token=usdc

Headers (preferred):

• X-Checkout-Token: <checkoutToken>

Response includes steps.approve, steps.pay, routerAddress, grossAmountAtomic.

3) Submit payment intent (txHash)

Endpoint: POST /v1/invoices/{invoiceId}/payment-intents

Headers:

• X-Checkout-Token: <checkoutToken>
• Content-Type: application/json

Body

{ "txHash": "0x...", "payerAddress": "0x..." }

4) Poll invoice status

Endpoint: GET /v1/invoices/{invoiceId}

Headers:

• X-Checkout-Token: <checkoutToken>

Stop when: status is confirmed | expired | invalid | refunded.

---

Polling policy (safe default)

• submitted right after tx: poll every 3-5s for 2 minutes
• After 2 minutes: poll every 10-15s
• Stop at expiresAt + grace (status will not change after that)
• If you receive 429, backoff and retry later

---

Common mistakes

• Missing recipientAddress with platform key (invalid)
• Direct token transfer instead of Router pay
• Losing checkoutToken (it is only returned on invoice creation)