T09 · Insecure Skill Coding Practices
- Location
references/vesting-factory.md:91- Finding
Unchecked ERC20 Transfer Result Can Leave Vesting Wallets Unfunded
- Content
View full analysis
- Remediation
View remediation
Security audit
Security checks for vulnerabilities and agentic risk
This skill is a coherent tokenomics guide, but its vesting deployment examples can create contracts and transfer real tokens without enough safety checks.
Review this skill carefully before installing or using it for deployment work. Treat its vesting scripts as illustrative only: test on a testnet first, verify chain ID and addresses, use SafeERC20 or equivalent transfer checks, read token decimals with parseUnits, confirm balances and allowances, validate every beneficiary and schedule, and require explicit confirmation before broadcasting transactions or transferring treasury tokens.
references/vesting-factory.md:91Unchecked ERC20 Transfer Result Can Leave Vesting Wallets Unfunded
references/vesting-factory.md:121Hardcoded 18-Decimal Conversion Can Misallocate Vesting Tokens
Suspicious Unicode normalization or mixed-script content
The Foundry and Hardhat examples perform live contract creation and token transfers in loops with no safety checks, dry-run guidance, or explicit confirmation steps. In a vesting context, mistakes in beneficiary addresses, timestamps, durations, or token amounts are irreversible on-chain and can permanently misallocate treasury assets or lock them into unintended wallets.
The Release Keeper example calls factory.allWallets(0, count), but the factory shown only exposes the public array getter allWallets(uint256) and totalWallets(). An operator copying this automation will either fail at runtime or implement ad hoc workarounds, which can break release automation and leave vested tokens unreleased until manually corrected.