Back to skill
Skillv1.0.1
ClawScan security
ERC20 Tokenomics Builder · ClawHub's context-aware review of the artifact, metadata, and declared behavior.
Scanner verdict
ReviewMar 18, 2026, 1:17 AM
- Verdict
- Review
- Confidence
- high
- Model
- gpt-5-mini
- Summary
- The skill's tokenomics, vesting, and Uniswap math content matches its description, but the included reference scripts expect private keys and deploy actions while the skill declares no required credentials — a scope and credential mismatch that could lead to accidental secret use or asset movement if followed blindly.
- Guidance
- This skill is primarily a design and documentation toolkit and appears benign for modeling tokenomics, but several included reference scripts perform deployments, token transfers, and rely on private keys (PRIVATE_KEY, TOKEN_ADDRESS, FACTORY_ADDRESS) even though the skill metadata lists no credentials. Before using: (1) don't paste private keys into web UIs or share them with the agent; run any deploy/keeper scripts locally in a controlled environment; (2) prefer multisigs or deploy from hardware wallets, not single private keys in env vars; (3) test everything on a testnet first; (4) review the factory and vesting contracts (ownership, onlyOwner usage, transfer logic) before funding wallets; (5) demand the author declare required credentials explicitly and explain when scripts will perform on-chain actions. The mismatch between declared requirements and referenced env vars is the main reason to treat this skill with caution.
Review Dimensions
- Purpose & Capability
- okName/description match the contents: allocation tables, vesting patterns, Uniswap v2/v3 math, and investor docs. The reference contracts and templates are coherent with a 'token launch readiness' toolkit.
- Instruction Scope
- concernSKILL.md and referenced files include deployment and automation instructions (Hardhat, Foundry scripts, a 'release' keeper) that call contract creation, token transfers, and reference environment variables such as PRIVATE_KEY, FACTORY_ADDRESS, TOKEN_ADDRESS. The top-level skill metadata declares no required env vars or credentials, but the runtime instructions clearly assume access to private keys and on-chain accounts — this is scope creep and a potential operational risk.
- Install Mechanism
- okInstruction-only skill with no install spec and no code execution delivered by the registry. No downloads or install steps — lowest install risk. However the provided scripts (in references) would install or assume developer toolchains (foundry/hardhat) if the user runs them locally.
- Credentials
- concernDeclared requirements list no env vars or secrets, yet referenced scripts read PRIVATE_KEY and other process/env values. For purely modeling and documentation, private keys are unnecessary; their presence is only justified for deployment. The skill should explicitly declare any required credentials and warn about how they are used. Asking for private keys implicitly (in scripts) is disproportionate to a 'design and modeling' description.
- Persistence & Privilege
- okSkill is not always-enabled and does not request persistent platform privileges. It does not modify other skills or system settings per provided metadata.
