Imported from sickn33/agentic-awesome-skills (
skills/meme-coin-audit/SKILL.md). Install upstream withnpx skills add sickn33/agentic-awesome-skills --skill meme-coin-audit. Copyright stays with the author (MIT).
⚠️ AUTHORIZED USE ONLY This skill is for educational purposes or authorized security assessments only. You must have explicit, written permission from the system owner before using this tool. Misuse of this tool is illegal and strictly prohibited.
Mandatory confirmation gate Before running any command that probes, exploits, changes, persists on, extracts data from, or attempts credential access against a target:
- Ask the user to state the exact target URL, IP, account, or resource.
- Ask the user to confirm written authorization and the permitted scope.
- Show the exact command(s) and explain their expected effect.
- Wait for explicit confirmation in the current conversation.
Without that confirmation, remain read-only and provide defensive guidance only. Prefer a sandbox, disposable VM, or controlled lab.
MEME COIN & TOKEN SECURITY AUDIT
Fast-kill rug pull detection and deep token security analysis for EVM and Solana meme coins.
PRE-DIVE KILL SIGNALS
Check these BEFORE reading a single line of code. Record these as triage signals requiring evidence, not proof of fraud or a reason to claim an audit was completed.
High-priority review signals
- Contract not verified on Etherscan/Solscan → source-level review is blocked; verify bytecode/program identity and report the limitation
- Deployer wallet has history of rug pulls (check Etherscan deployer page)
- Token age < 1 hour AND no known team → Too early, wait for more data
- Mint authority retained (Solana) AND no cap → uncapped issuance capability; intent and exploitability require further evidence
- Freeze authority retained (Solana) on meme coin → freeze capability; not proof of a honeypot
- Transfer hook present (Token-2022) with mutable hook program → Honeypot vector
- Permanent delegate extension (Token-2022) → privileged transfer/burn capability whose actual authority and constraints must be examined
Soft Kills (Proceed with Extreme Caution)
- Top holder > 20% of supply (excluding DEX pools)
- LP not burned or locked in verified contract
- Contract is upgradeable / proxy with retained admin
- Less than $5K liquidity in the pool
- No social presence / anonymous deployer with no history
THE ONE RULE
"Check ALL authorities and owner functions. The retained authority IS the rug vector."
Retained privileges can create risk, but ordinary market sales, compromised keys and unprivileged vulnerabilities can also cause loss. A privilege is not automatically a bug: document authority, constraints, intended policy and concrete impact.
BUG CLASSES (8 TOKEN-SPECIFIC)
1. HIDDEN MINT / UNLIMITED SUPPLY
Common rug pattern. Deployer mints tokens post-launch, dumps on LP.
Quick grep (EVM):
grep -rn "function mint\|_mint(\|_balances\[.*\] +=" src/ --include="*.sol" | grep -v "test\|lib\|node_modules"
Quick grep (Solana):
grep -rn "MintTo\|mint_to\|mint_authority" src/ --include="*.rs" | grep -v "test\|target"
Potential mitigating evidence (not proof of safety): MAX_SUPPLY enforced in every mint path, or mint function removed entirely.
2. HONEYPOT / TRANSFER RESTRICTION
Common scam pattern. Buy works, sell blocked.
Quick grep:
grep -rn "blacklist\|isBlacklisted\|_bots\|maxTxAmount\|approve.*override\|tradingEnabled" src/ --include="*.sol"
Solana equivalent:
grep -rn "freeze_authority\|transfer_hook\|TransferHook\|permanent_delegate" src/ --include="*.rs"
Potential mitigating evidence (not proof of safety): No blacklist mapping, no transfer hooks, no freeze authority.
3. FEE MANIPULATION
Common rug pattern. Sell fee set to 99% after initial buys.
Quick grep:
grep -rn "setFee\|setSellFee\|_taxFee\|_sellFee" src/ --include="*.sol"
grep -rn "function set.*Fee" -A5 src/ --include="*.sol" | grep -v "require\|MAX\|<="
Potential mitigating evidence (not proof of safety): Fee setter has require(fee <= MAX_FEE) with MAX_FEE <= 10%.
4. LIQUIDITY POOL DRAIN
LP removal, migration, or manipulation to crash price.
Quick grep:
grep -rn "migrateLP\|emergencyWithdraw\|\.sync()\|setPair\|setRouter" src/ --include="*.sol"
Potential mitigating evidence (not proof of safety): LP tokens burned to dead address, no migration function, no pair setter.
5. BONDING CURVE MANIPULATION
Exploits in pump.fun-style bonding curves.
Quick grep:
grep -rn "virtualReserve\|setCurve\|graduate\|bonding_curve" src/ --include="*.sol" --include="*.rs"
Potential mitigating evidence (not proof of safety): Curve parameters immutable, graduation permissionless.
6. AUTHORITY RETENTION (SOLANA)
Retained mint/freeze/update authorities on Solana tokens.
Quick grep:
grep -rn "mint_authority\|freeze_authority\|update_authority\|close_authority" src/ --include="*.rs"
grep -rn "set_authority.*None" src/ --include="*.rs" # Good sign: revocation
Potential mitigating evidence (not proof of safety): All authorities = None, verified on-chain.
7. FAKE RENOUNCE / HIDDEN OWNERSHIP
Ownership appears renounced but backdoor control retained.
Quick grep:
grep -rn "renounceOwnership.*override\|_shadowAdmin\|_backupOwner\|selfdestruct" src/ --include="*.sol"
Potential mitigating evidence (not proof of safety): renounceOwnership NOT overridden, no second admin role, no selfdestruct.
8. SANDWICH AMPLIFICATION BY DESIGN
Contract makes holders maximally sandwichable.
Quick grep:
grep -rn "swapExactTokensForETH" -A5 src/ --include="*.sol" | grep "0,"
grep -rn "swapThreshold\|_rebase\|mandatoryPool" src/ --include="*.sol"
Potential mitigating evidence (not proof of safety): Auto-swap has proper slippage, no rebase mechanics.
FAST RED-FLAG SWEEP
Run the 8 bug-class greps above across the source tree for fast red-flag detection. These incomplete source patterns may help locate:
- Direct mint/balance manipulation
- Blacklist and transfer restriction patterns
- Unbounded fee setters
- LP migration and emergency withdraw functions
- Fake renounce overrides
- Zero slippage auto-swaps
- All Solana authority patterns
- Token-2022 dangerous extensions
Source grep does NOT check (verify these out-of-band):
- On-chain state (use Etherscan/Solscan for authority verification)
- Holder distribution (use DEXTools/Birdeye)
- LP lock status (use Unicrypt/PinkLock/Solscan)
- Deployer wallet history (manual check)
FOUNDRY POC TEMPLATE (TOKEN EXPLOITS)
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;
import "forge-std/Test.sol";
import "../src/Token.sol";
contract TokenExploitTest is Test {
Token token;
address owner = makeAddr("owner");
address victim = makeAddr("victim");
address attacker = makeAddr("attacker");
// Uniswap V2 router (mainnet fork)
address constant ROUTER = 0x7a250d5630B4cF539739dF2C5dAcb4c659F2488D;
address constant WETH = 0xC02aaA39b223FE8D0A0e5C4F27eAD9083C756Cc2;
function setUp() public {
vm.createSelectFork("mainnet");
// Deploy token as owner
vm.startPrank(owner);
token = new Token();
// Add liquidity...
vm.stopPrank();
}
function test_hiddenMint_rug() public {
// Step 1: Victim buys tokens
vm.startPrank(victim);
// ... buy tokens on Uniswap
vm.stopPrank();
// Step 2: Owner mints and dumps
vm.startPrank(owner);
uint256 supplyBefore = token.totalSupply();
token.mint(owner, 1_000_000_000e18);
assertGt(token.totalSupply(), supplyBefore, "Supply should increase");
// ... sell minted tokens
vm.stopPrank();
// Step 3: Victim's tokens are now worthless
// Assert token price crashed
}
function test_honeypot_blacklist() public {
// Step 1: Victim buys
vm.startPrank(victim);
// ... buy tokens
vm.stopPrank();
// Step 2: Owner blacklists victim
vm.startPrank(owner);
token.blacklist(victim);
vm.stopPrank();
// Step 3: Victim cannot sell
vm.startPrank(victim);
vm.expectRevert("Blacklisted");
token.transfer(address(1), 100e18);
vm.stopPrank();
}
function test_fee_manipulation_rug() public {
// Step 1: Verify initial fee is low
assertEq(token.sellFee(), 3); // 3%
// Step 2: Owner sets fee to 99%
vm.prank(owner);
token.setFees(3, 99); // Buy 3%, Sell 99%
// Step 3: Victim sells — loses 99% to fees
vm.startPrank(victim);
uint256 balanceBefore = address(victim).balance;
// ... sell tokens
// Assert: received almost nothing
vm.stopPrank();
}
}
SOLANA QUICK CHECKS (NO SOURCE CODE NEEDED)
When you don't have source code, check on-chain:
1. MINT AUTHORITY → decode the mint with the installed SPL Token CLI or a trusted token-aware RPC parser
- Should be null
- If Some(pubkey) → retained mint capability; inspect supply controls
2. FREEZE AUTHORITY → same as above, check freeze_authority
- Should be null
- If Some(pubkey) → retained freeze capability; assess constraints
3. LP STATUS → Check Raydium/Orca pool
- Verify token supply burn transactions and pool-specific ownership; an address transfer alone is not proof of burning LP.
- LP locked? (in verified locker with no backdoor)
- LP held by deployer? → CRITICAL: instant rug
4. TOP HOLDERS → Birdeye/Solscan holders tab
- Top 10 < 30% of supply (excluding pools)
- Creator wallets (check first transactions)
5. PROGRAM UPGRADEABILITY
- Is the program upgradeable? → can change any logic
- Upgrade authority should be None for immutable programs
6. TOKEN-2022 EXTENSIONS
- Any transfer hook? → potential honeypot
- Permanent delegate? → CRITICAL
Related Skills & Chains
web3-audit— When the target is a DeFi protocol (not just a token). Workflow primitive: this skill's 8 token-specific bug classes are a subset ofweb3-audit's scope; if the target has lending / vault / oracle logic beyond the token contract itself, also loadweb3-auditfor the broader 10 DeFi bug classes.triage-validation— When deciding if a rug-pull finding qualifies as a bug bounty submission. Workflow primitive: many "rug vector" observations are pre-rug warnings, not exploitable bugs in a deployed protocol; run 7Q gate to distinguish "the deployer COULD rug" (informational) from "the contract IS exploitable now" (reportable).report-writing— When writing up a confirmed token security finding for Immunefi / private bounty. Workflow primitive: Foundry PoC template here feeds intoreport-writing's Immunefi body template.offensive-osint— When the token has off-chain infrastructure (project website, Telegram, deployer doxxing). Workflow primitive: on-chain audit is this skill's domain; deployer wallet history, social presence, and project legitimacy checks route tooffensive-osint.bb-methodology— When confirming engagement mode. Workflow primitive: PART 0 separates "pre-investment due diligence" (this skill's primary use) from "Immunefi bug bounty submission" (different reporting + severity standards); the answer routes which post-audit handoff is correct.
Operator Notes (Claude-BugHunter)
Engagement-derived + 2026-specific additions to the vendored foundation. Upstream engagement/test claims are not independently verified by this catalog review. The upstream content covers the WHAT; this layer covers the WHEN-IT-WORKS-vs-WHEN-IT-DOESN'T.
Solana-specific signals — 2025-2026 reality
Token-2022 transfer hooks are the new rug-pull vector. Hook authority can be set to a single key; that key can pause / blacklist / fee-on-transfer arbitrary addresses post-launch. Always check hook authority + permanent-delegate authority for Token-2022 mints:
# get mint extensions for a Token-2022 mint
spl-token display <MINT_ADDRESS> --program-id TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb
# look for: TransferHook { authority: ... }, PermanentDelegate { delegate: ... }
A non-null TransferHook authority can change hook configuration; inspect the referenced program, its upgrade authority and actual transfer behavior. If PermanentDelegate is non-null → that delegate can move any holder's tokens at any time (effectively a built-in confiscation). These are privileged capabilities requiring context, not a determination of malicious intent.
For any bonding-curve launch, identify the exact program/version, graduation state and current authorities from on-chain evidence. Do not generalize a mutable parameter or authority layout across protocols.
Honeypot detection — beyond the obvious
transfer() succeeds in dry-run but fails on certain addresses (sender allowlist / blocklist). Test with: simulated buy → simulated transfer to a different address → simulated sell. If buy and transfer succeed but sell fails, investigate the revert, liquidity, account setup and route; a failed simulation alone is not proof of intentional trapping.
Quick triage matrix:
| Test | Honeypot Signal |
|---|---|
| Buy from random wallet | Succeeds (must — or no one would touch it) |
| Transfer to second random wallet | Often fails on honeypot |
| Sell from original wallet | Fails or applies > 50% tax |
| Sell from team-controlled wallet | Succeeds (the giveaway) |
Cross-source verification: solana-rugcheck, rugcheck.xyz, dexscreener risk signals, honeypot.is (EVM). Never trust a single source — rug-checkers can be fooled by deferred-malice patterns (clean for first 7 days, hook activates later).
LP lock claims — verify, don't trust
LP-lock badges on DexScreener mean nothing without on-chain verification. Check the actual lock contract (Unicrypt, TeamFinance, Bonkbot, PinkLock) for:
- Unlock date — the on-chain timestamp, not the badge text
- Lock owner — is it the deployer's wallet? Are there multiple lockers fragmenting the LP?
- Extension / shortening permission — some lock contracts allow the owner to SHORTEN the lock; that's an exit hatch dressed as a lock
- Lock contract bytecode — verify it's the canonical locker, not a fork with backdoors
Some "locked" LPs are 1-day locks renewed weekly — visually the same as a year lock to the buyer, but the deployer can let it lapse on any Tuesday. Always read the lock contract source on the chain explorer.
Pre-investment due diligence in under 5 minutes
The 6-question fast filter:
- Mint authority null?
- Freeze authority null?
- Update authority null (for metadata immutability)?
- LP locked in a verified contract for > 6 months?
- Top 10 holders concentration < 30% (excluding pools/burn addresses)?
- Bonding curve completed (for pump.fun) AND post-completion mint authority null?
Do not turn this checklist into investment sizing advice or a safety score. Record block/slot, chain, mint/program addresses, authorities and verified sources. Liquidity depth, holder clustering and admin controls require contextual analysis. Private submission routes, bundles and split orders do not guarantee protection from MEV or price impact; no percentage loss estimate is established here.
When to Use
- You have explicit, written authorization to assess the target in scope, and the task matches this skill's vulnerability class or technique within a bug-bounty or penetration-test engagement.
- You need the recon, exploitation, or validation workflow described below — executed strictly inside the approved scope.
Limitations
- Authorized scope only: the confirmation gate above is mandatory before any probing, exploitation, or credential-access command.
- Docs-only import: upstream helper scripts, commands, engine, and research assets are not bundled; reinstall tooling from the source repo when needed.
- Validate every finding (see
triage-validation) before reporting; report viareport-writing. Prefer a sandbox, disposable VM, or controlled lab.
Example
# Read-only first step; confirm scope before anything active.
cat scope.txt # target list from the authorized engagement brief
Adapted from elementalsouls/Claude-BugHunter (MIT); frontmatter, When to Use/Limitations, and safety boundaries added for upstream compliance. Docs-only import: executable helpers, commands, engine, and research assets not bundled.
Evidence limits
Source search is not exhaustive. Verify deployed code matches the reviewed revision, proxy implementation/admin state and actual Token/Token-2022 program. Mint metadata update authority is distinct from mint/freeze authority. LP positions can be concentrated-liquidity NFTs rather than fungible LP tokens. The Foundry template is incomplete pseudocode: Token.sol, liquidity, balances and protocol methods must be supplied and tested on a pinned local fork; it is not a working exploit or a demonstrated price impact. Never broadcast transactions during an audit without the exact authorized command gate above. Findings require reproducible evidence and disclosure through the permitted channel.
