xpr-governance
v0.2.11Interact with XPR Network on-chain governance: view communities, proposals, vote with weighted tokens, and create proposals paying community fees.
⭐ 0· 651·1 current·1 all-time
by@paulgnz
MIT-0
Download zip
LicenseMIT-0 · Free to use, modify, and redistribute. No attribution required.
Security Scan
OpenClaw
Suspicious
high confidencePurpose & Capability
The skill's described purpose (read/view proposals and optionally vote/post proposals) matches the included code: read-only functions call the on-chain RPC and Gov API and write functions sign transactions. However the skill metadata declares no required environment variables or credentials while the code requires XPR_PRIVATE_KEY and XPR_ACCOUNT (and optionally XPR_PERMISSION) to sign transactions — this is an important mismatch between declared requirements and actual capability.
Instruction Scope
SKILL.md documents read-only and write tools and notes that write tools require confirmation, which is appropriate. But SKILL.md does not mention that signing requires storing a private key in env vars or that a dependency (@proton/js) is used. The runtime instructions/code do not read unrelated system files or call hidden endpoints; network calls are to public RPC endpoints and gov.api.xprnetwork.org. The main issue is omission of the signing credential from user-facing instructions/metadata.
Install Mechanism
There is no install spec (instruction-only), which minimizes install-time risk. However the code dynamically imports '@proton/js' and expects Node runtime fetch usage; no dependencies are declared in skill.json. That means the environment must already provide @proton/js (or the operator will need to install it), which is an operational omission and could lead to ad-hoc installs by whoever runs it.
Credentials
The code requires XPR_PRIVATE_KEY and XPR_ACCOUNT for write operations — perfectly proportional to signing transactions — but these required env vars are not declared in skill.json or SKILL.md. Asking for a raw private key is high risk: anyone supplying that env grants the skill full signing authority for that account. The skill does not request unrelated credentials, but the omission of declaration and guidance about safer signing alternatives is worrying.
Persistence & Privilege
The skill does not request always:true or other elevated persistence. It caches a session in memory (cachedSession) but does not modify other skills or system-wide settings. Autonomous invocation is allowed (platform default) but write tools require explicit confirmation per SKILL.md.
What to consider before installing
The code largely does what the description says, but it omits key operational details. Before installing or running this skill: (1) Do not put your full account private key into XPR_PRIVATE_KEY unless you fully trust the skill and author — supplying that env will allow the skill to sign transactions as your account. Prefer using a signing service, a hardware signer, or a key with minimal permissions. (2) Ask the author/maintainer to update skill.json and SKILL.md to explicitly list required env vars (XPR_PRIVATE_KEY, XPR_ACCOUNT, XPR_PERMISSION) and any runtime dependencies (e.g., @proton/js) so you can make an informed decision. (3) If you must test, use only the read-only tools first (they do not require keys) and run them in a sandboxed environment. (4) If enabling write features, consider using an ephemeral or limited-permission key and verify transactions produced before broadcasting. (5) Verify the source/publisher (source is unknown) and prefer skills with declared dependencies and clear provenance; lack of metadata and omitted credential declarations are the main reasons this skill is flagged suspicious.Like a lobster shell, security has layers — review code before you run it.
latestvk97ess0vfymct9xspqeyd35vyn813f0g
License
MIT-0
Free to use, modify, and redistribute. No attribution required.