T09 · Insecure Skill Coding Practices
- Location
lib/scam_check.js:65- Finding
Incorrect Token-Age Calculation Can Produce Unsafe Trading Guidance
- Content
View full analysis
0 && sigs[0].blockTime) { const ageHours = (Date.now() / 1000 - sigs[0].blockTime) / 3600; if (ageHours < CONFIG.MIN_TOKEN_AGE_HOURS) { issues.push(`Token is <${CONFIG.MIN_TOKEN_AGE_HOURS}h old - high risk`); } } } ``` ### Technical Analysis `getSignaturesForAddress()` returns signatures in reverse chronological order, with the newest signature first. Requesting only one signature therefore retrieves the mint account's latest recorded activity, not its creation transaction. Consequently, `ageHours` measures the elapsed time since the most recent activity involving the address. It does not establish the token's age as advertised. The validation also fails open when: - The RPC returns no signatures. - The returned signature has no `blockTime`. - The available history is insufficient to identify the creation transaction. In those cases, no issue is added. If the ticker and local blacklist checks also pass, the function can return `safe: true` even though token age was never established. ### Attack Path 1. An attacker creates or promotes a risky token whose symbol is absent from the static ticker list and whose mint is absent from the initially empty mint blacklist. 2. The user submits that mint to `checkTokenSafety()`. 3. The RPC returns no usable signature timestamp, or returns data that does not represent account creation. 4. The age check adds no issue when the age cannot be determined. 5. The remaining local checks pass. 6. The function returns `safe: true`, potentially causing the user or an automated agent to treat an unverified token as safe. The same implementation can also falsely f ...[truncated 638 chars]- Remediation
View remediation
