🦄 Powerloom Uniswap V3 timeseries data

Autonomous Uniswap V3 monitoring on consensus-backed data. Every data point is finalized on-chain by Powerloom's decentralized sequencer-validator network (D...

Security Scan

The skill's code, instructions, and required environment variables are consistent with an on‑chain metering + Uniswap V3 monitoring tool that needs a payer wallet and an API key to call Powerloom's MCP and billing endpoints.

Purpose & Capability

The name/description (Powerloom Uniswap V3 timeseries + on‑chain provenance) match the code and SKILL.md: the package calls Powerloom MCP tools, optionally performs pay-signup/top-up on-chain, and streams snapshots. Requiring node, an EVM RPC, a payer private key, a plan id/token symbol, and a POWERLOOM_API_KEY is coherent for the documented billing and streaming flows.

Instruction Scope

SKILL.md and the scripts are explicit about network calls (bds-mcp.powerloom.io, bds-metering.powerloom.io), EVM RPC access, and optional Telegram/Discord webhooks. Scripts read/write local state files (.powerloom/… or specified state file) and the signup/topup scripts will construct and submit on‑chain transactions. There are no instructions to access unrelated system paths or transmit unrelated secrets, but the agent will be instructed to use a private key and an API key (sensitive).

Install Mechanism

This is instruction + source code (no install spec). Dependencies are standard npm packages (ethers, yaml) from the registry and node is the only required binary. No arbitrary downloads, URL shorteners, or extracted archives are used.

Credentials

The required env vars (EVM_PRIVATE_KEY, EVM_RPC_URL, EVM_CHAIN_ID / PLAN_ID / TOKEN_SYMBOL, POWERLOOM_API_KEY) are sensitive but justified by pay-signup/top-up and authenticated MCP calls. The number and nature of env vars align with the documented payment + authenticated streaming flows. Users should recognize EVM_PRIVATE_KEY grants signing power and POWERLOOM_API_KEY grants access to metering/account actions.

Persistence & Privilege

always is false and the skill does not demand permanent global inclusion. It writes state under local paths (e.g., .powerloom/*.json) which is expected for persistent stream checkpoints. It does not modify other skills or system-wide agent configuration.

Assessment

This skill is internally consistent with its stated purpose, but it requires highly sensitive credentials: an EVM private key (used to sign on‑chain payments) and a POWERLOOM_API_KEY (authenticated access to the metering and MCP endpoints). Only provide a private key if you trust the Powerloom endpoints and the code; prefer using a dedicated wallet with limited funds (not your primary wallet). Verify PLAN_ID and the plan’s recipient address from GET /credits/plans before running pay/topup scripts. Do not commit keys to git; set env vars at runtime or in a protected secrets store. If you only want read/monitoring functionality, avoid running signup-pay or credits-topup (those scripts will perform transfers). Finally, run the scripts locally first (npm install, node >=20) so you can inspect network requests, and consider using a firewall / proxy to audit outbound calls to bds-mcp.powerloom.io and bds-metering.powerloom.io.

Powerloom BDS — Uniswap V3

Install

Contract: bds-agenthub-billing-metering. ClawHub users only need a single origin (default bds-metering.powerloom.io)— bds-agent commands are optional; they are a reference CLI for the same JSON bodies you can send with curl + a wallet or ethers.

Metering HTTP (authoritative)

What	How
List SKUs	GET {BASE}/credits/plans — no auth. Choose a plan row: id, chain_id, token_symbol (and note payment_kind: ERC-20 vs native / CGT).
New key, wallet-only	Pay-signup: POST {BASE}/signup/pay/quote → pay on chain → POST {BASE}/signup/pay/claim with signup_nonce + tx_hash. Returns api_key.
New key, browser	Human device flow on {BASE}/metering (same service).
More credits, existing key	POST {BASE}/credits/topup with Authorization: Bearer sk_live_… and tx / plan (not the pay-signup endpoints).
Check balance	GET {BASE}/credits/balance with Authorization: Bearer …

{BASE} is METERING_BASE_URL, e.g. https://bds-metering.powerloom.io. Set POWERLOOM_API_KEY to the sk_live_... you get after pay-signup, device signup, or copy from the dashboard.

OpenClaw requires.env (mirrors a pay-signup row + wallet + key)

Field	Role
EVM_PRIVATE_KEY	Payer wallet
EVM_RPC_URL	JSON-RPC for that chain
EVM_CHAIN_ID	Must match the plan’s chain_id
PLAN_ID	e.g. launch_10_pl_power_cgt from GET /credits/plans
TOKEN_SYMBOL	e.g. POWER (must match that row)
POWERLOOM_API_KEY	After claim (or set after device signup)

Path A (browser) only usually needs POWERLOOM_API_KEY in practice. If the host enforces the full list, set wallet + plan to the row you will use, or adjust host policy.

Reference client: bds-agent (optional)

docs/USER_GUIDE.md in bds-agent-py has the end-to-end order: Metering service API table → pay-signup → device → top-up. One-liner sequence:

1. bds-agent credits plans — same as GET /credits/plans
2. bds-agent credits setup-evm — writes ~/.config/bds-agent/profiles/<name>.evm.env
3. bds-agent signup-pay --plan-id … --chain-id … --token-symbol … — implements quote / broadcast / claim (including native payment_kind plans)

This repo: Node scripts (no Python, no bds-agent required)

Script	What it does
node scripts/signup-pay.mjs	New key: pay-signup (quote → ERC-20 pay → claim). POWERLOOM_API_KEY not set yet.
node scripts/credits-topup.mjs	More credits: uses existing POWERLOOM_API_KEY, fetches GET /credits/plans, matches PLAN_ID + EVM_CHAIN_ID + TOKEN_SYMBOL, sends ERC-20 or native per payment_kind, then POST /credits/topup. Set EVM_RPC_URL if the public rpc_url in plans is redacted.
node scripts/ensure-credits.mjs	Balance only (GET /credits/balance); no purchase.

npm install once (adds ethers).

Optional env (signup script): METERING_BASE_URL, AGENT_NAME, EMAIL (see metering README).

After you have a key — more credits (top-up)

Spec: POST {BASE}/credits/topup with Authorization: Bearer and JSON { "plan_id", "chain_id", "tx_hash" } after an on-chain payment that matches the plan. In this repo: node scripts/credits-topup.mjs. Reference CLI: USER_GUIDE (EVM credits topup / Tempo per deployment). Check balance: node scripts/ensure-credits.mjs.

Default MCP endpoint: https://bds-mcp.powerloom.io/sse — override with POWERLOOM_MCP_URL if needed.

Generic tool runner: node scripts/powerloom-mcp-client.mjs <tool_name> '{}'

Common tasks → which tool

Task phrase	Tool(s)
Track all swaps for token X (multi-pool)	bds_mpp_stream_allTrades / bds_mpp_snapshot_allTrades + Token-Flow recipe
Whale / USD threshold	bds_mpp_stream_allTrades + filters, or Whale Radar recipe
One pool only	bds_mpp_snapshot_trades_pool_address after bds_mpp_token_token_address_pools or bds_mpp_dailyActivePools
Streaming live	bds_mpp_stream_allTrades with from_epoch checkpoint (see scripts/whale-radar.mjs)
Verify on-chain	verify_data_provenance with cid, epoch_id, project_id from API — never substitute block for epoch

Timeouts: default BDS_MCP_CALL_TIMEOUT_MS=60000. Use 120000 for bds_mpp_stream_allTrades with max_events=50 if you see timeouts under backlog.

Recipes (supported surface)

Pre-built scripts + recipes/*.yaml defaults — prefer these over ad-hoc scripts on weaker models.

Recipe	Script
Whale Radar	node scripts/whale-radar.mjs — default stream = all pools; --mode poll uses poll_fallback_pools only
Token-Flow	node scripts/token-flow.mjs (--token 0x...)
DeFi Analyst	node scripts/defi-analyst.mjs — default multi-pool (bds_mpp_stream_allTrades + all-pools volume); filters.scope: single_pool for one-pool only (--once = one shot)

Model guidance

Recipes produce the same stdout/Telegram output regardless of model. Ad-hoc “compose your own” prompts work best on GPT-4–class or GLM-5+; weaker local models may collapse multi-pool prompts onto one pool — use the Token-Flow recipe instead.

References

See references/ for quickstart, full tool table, verification, credit budget, scope, troubleshooting, and prompt patterns.