| name | gate-info-riskcheck |
| version | 2026.3.25-1 |
| updated | 2026-03-25 |
| description | Token and address risk assessment. Use this skill ONLY when the user's query is exclusively about token/contract/address security with no other analysis dimensions. Trigger phrases: is this token safe, check contract risk, is this address safe, honeypot, rug. If the query ALSO mentions fundamentals, technicals, news, sentiment, or any other analysis dimension, use gate-info-research instead — it handles multi-dimension queries in a single unified report. Address risk mode (is this address safe) is exclusive to this skill and must NOT be routed to gate-info-research. |
gate-info-riskcheck
General Rules
⚠️ STOP — You MUST read and strictly follow the shared runtime rules before proceeding.
Do NOT select or call any tool until all rules are read. These rules have the highest priority.
→ Read gate-runtime-rules.md
→ Also read info-news-runtime-rules.md for gate-info / gate-news-specific rules (tool degradation, report standards, security, routing degradation, and per-skill version checks when scripts/ is present).
- Only call MCP tools explicitly listed in this skill. Tools not documented here must NOT be called, even if they
exist in the MCP server.
Security guardian Skill. The user inputs a token name or contract address, the system calls the contract security detection Tool to retrieve 30+ risk detection results, tax analysis, holder concentration, and name risk data. The LLM aggregates the results into a structured risk assessment report. Address compliance checking will be added in a future phase.
Trigger Scenarios: User mentions a token/contract address + keywords like safe, risk, check, audit, honeypot, rug, contract security, scam.
Per-skill updates: This directory includes scripts/update-skill.sh and scripts/update-skill.ps1. Policy: info-news-runtime-rules.md §1. The Trigger update steps below apply in addition to gate-runtime-rules.md; when scripts are present, use this flow for version checks before execution.
Trigger update (with Execution)
Default (PD / blocking): On each trigger, run check first without GATE_SKILL_UPDATE_MODE=auto. The script only compares local vs remote; if Result=update_available, it does not overwrite files. STOP — ask the user whether to update before any apply, run, or skill Execution. In sandboxes (e.g. Cursor), use full / all permissions when later running apply. This matches blocking update confirmation in the independent-script TEST_REPORT: blocking is enforced by these SKILL instructions plus check-only behavior (not by silent auto-apply).
Strict check (Agent / IDE — recommended on check): Use GATE_SKILL_CHECK_STRICT=1. When Result=update_available, check exits 3 and prints GATE_SKILL_CHECK_EXIT=3 — it stops only that shell step. Hard rule: after you ask the user, end this assistant turn; do not call apply, run, or MCP in the same message. run applies without a prior user step — do not use run in chat for the blocking flow; use check → user confirms → apply.
Step 1 — Check
Install root: check / apply read $DEST/SKILL.md. Typical $SKILL_ROOT: $HOME/.cursor/skills/<name>/, $HOME/.codex/skills/<name>/, $HOME/.openclaw/skills/<name>/, $HOME/.agents/skills/<name>/, $HOME/.gemini/antigravity/skills/<name>/. Single-arg: the script resolves DEST in that order when SKILL.md exists; otherwise DEST is scripts/../. Workspace-only trees need two-arg check / apply with explicit DEST.
Bash (blocking — no auto; example Cursor):
GATE_SKILL_CHECK_STRICT=1 bash "$HOME/.cursor/skills/gate-info-riskcheck/scripts/update-skill.sh" check "gate-info-riskcheck"
PowerShell:
$env:GATE_SKILL_CHECK_STRICT = '1'
powershell -ExecutionPolicy Bypass -File "$env:USERPROFILE\.cursor\skills\gate-info-riskcheck\scripts\update-skill.ps1" check "gate-info-riskcheck"
Result semantics: skipped = no action. update_available = remote newer; with blocking flow, do not apply until the user agrees. check_failed = could not compare — proceed with current version per info-news-runtime-rules.md.
Agent parse (stdout): GATE_SKILL_UPDATE_AGENT_ACTION=…. BLOCK_UNTIL_USER_CONFIRMS_UPDATE → Step 2 before Execution. CONTINUE_SKILL_EXECUTION → no block from the check script.
Step 2 — Confirm or Reject (blocking)
If update_available:
-
STOP — do NOT proceed to Execution yet.
-
Inform the user (e.g. newer version available; summarize if helpful).
-
Wait for the user’s reply — blocking step.
Hard rule (Cursor / Agent): When check reports update_available, or BLOCK_UNTIL_USER_CONFIRMS_UPDATE, or strict exit 3, end this turn after asking. Only in the user’s next message run apply (if they agree) or revoke-pending (if they decline). Do not chain apply in the same turn as check for this flow.
- User agrees → run
apply with GATE_SKILL_CONFIRM_TOKEN from strict check stdout when required, then Execution.
- User declines →
revoke-pending, then Execution on the current install.
Two-step gate (strict check): apply / run (without GATE_SKILL_UPDATE_MODE=auto) fail until GATE_SKILL_CONFIRM_TOKEN matches .gate-skill-apply-token. User decline → revoke-pending.
GATE_SKILL_CONFIRM_TOKEN="<paste from check stdout>" bash "$HOME/.cursor/skills/gate-info-riskcheck/scripts/update-skill.sh" apply "gate-info-riskcheck"
bash "$HOME/.cursor/skills/gate-info-riskcheck/scripts/update-skill.sh" revoke-pending "gate-info-riskcheck"
$env:GATE_SKILL_CONFIRM_TOKEN = '<paste from check stdout>'
powershell -ExecutionPolicy Bypass -File "$env:USERPROFILE\.cursor\skills\gate-info-riskcheck\scripts\update-skill.ps1" apply "gate-info-riskcheck"
powershell -ExecutionPolicy Bypass -File "$env:USERPROFILE\.cursor\skills\gate-info-riskcheck\scripts\update-skill.ps1" revoke-pending "gate-info-riskcheck"
If Step 1 was not strict (no pending token): apply without GATE_SKILL_CONFIRM_TOKEN is allowed.
If skipped or check_failed: no update step; proceed to Execution.
Optional — GATE_SKILL_UPDATE_MODE=auto
For CI / unattended automation only: setting GATE_SKILL_UPDATE_MODE=auto on check makes the script apply immediately when the remote is newer — no user confirmation and incompatible with blocking update confirmation tests. Do not use auto on check when reproducing the blocking PD flow.
Parameters
- name: Frontmatter
name above; must match skills/<name>/ on gate-skills.
- Invoke: Use
$SKILL_ROOT/scripts/update-skill.sh (or .ps1) where $SKILL_ROOT/SKILL.md is this skill — e.g. ~/.cursor/skills/<name>, ~/.codex/skills/<name>, ~/.openclaw/skills/<name>, ~/.agents/skills/<name>, ~/.gemini/antigravity/skills/<name>; do not treat ~/.cursor (or any host root without skills/<name>/SKILL.md) as the install. With one arg, the script resolves $SKILL_ROOT in that order before falling back to the script’s directory; workspace installs need explicit DEST.
Do not dump raw script logs into the user-facing reply except when debugging. On check exit 3 (strict), do not run Execution until Step 2 is resolved. On check_failed or apply failure, still run Execution when appropriate per runtime rules.
MCP Dependencies
Required MCP Servers
| MCP Server | Status |
|---|
| Gate-Info | ✅ Required |
MCP Tools Used
Query Operations (Read-only)
- info_coin_get_coin_info
- info_compliance_check_address_risk
- info_compliance_check_token_security
- info_onchain_get_address_info
Authentication
Installation Check
- Required: Gate-Info
- Install: Run installer skill for your IDE
- Cursor:
gate-mcp-cursor-installer
- Codex:
gate-mcp-codex-installer
- Claude:
gate-mcp-claude-installer
- OpenClaw:
gate-mcp-openclaw-installer
Routing Rules
| User Intent | Keywords/Pattern | Action |
|---|
| Token contract security check | "is this token safe" "any risk with PEPE contract" "check 0x... contract" | Execute this Skill (Token Security mode) |
| Address risk check | "is this address safe" "is this a blacklisted address" | Execute this Skill (Address Risk mode — currently degraded) |
| Single coin analysis | "analyze SOL for me" | Route to gate-info-coinanalysis |
| Address tracking | "track this address" "fund flow" | Route to gate-info-addresstracker |
| Token on-chain analysis | "on-chain chip distribution" | Route to gate-info-tokenonchain |
| Project due diligence | "is this project legit" "team background" | Route to gate-info-coinanalysis (fundamentals focus) |
Execution Workflow
Step 0: Multi-Dimension Intent Check
Before executing this Skill, check if the user's query involves multiple analysis dimensions:
- If the query is about address safety (e.g., "is this address safe", "check 0x..."), proceed with this Skill (Mode B) — address risk is exclusive to this Skill and NOT covered by
gate-info-research.
- If the query is only about token/contract security with no other dimension, proceed with this Skill (Mode A).
- If the query also mentions fundamentals, technicals, news, sentiment, comparison, or any other analysis dimension beyond security, route to
gate-info-research — it handles multi-dimension queries with unified tool deduplication and coherent report aggregation.
Mode A: Token Security Check (Core Mode — Ready)
Step 1: Intent Recognition & Parameter Extraction
Extract from user input:
token: Token symbol (e.g., PEPE, SHIB) — mutually exclusive with address
address: Contract address (e.g., 0x...) — mutually exclusive with token
chain: Chain name (eth / bsc / solana / base / arb, etc.) — required
Parameter Completion Strategy:
- If user provides only token without chain: ask "Please specify the chain (e.g., eth, bsc, solana)"
- If user provides a contract address without chain: attempt to infer from address format (0x prefix likely EVM chain, but still confirm specific chain)
- If user asks about major coins (BTC, ETH): inform them "Major coins typically have no contract security risks. If you need to check, please specify the wrapped token or a Meme token on a specific chain"
Step 2: Call 2 MCP Tools in Parallel
| Step | MCP Tool | Parameters | Retrieved Data | Parallel |
|---|
| 1a | info_compliance_check_token_security | token={token} or address={address}, chain={chain}, scope="full", lang="en" | Risk level, 30+ risk items, tax analysis, holder concentration, name risk, honeypot detection, open-source status | Yes |
| 1b | info_coin_get_coin_info | query={token or symbol} | Token basic info (project name, sector, listed exchanges — supplementary context) | Yes |
Both Tools are called in parallel with no dependencies.
Step 3: LLM Aggregation — Generate Risk Report
Pass the security detection data and fundamentals to the LLM to generate the assessment report using the template below.
Mode B: Address Risk Check (Degraded Mode)
info_compliance_check_address_risk is not yet available (P3 phase). Currently only info_onchain_get_address_info can provide basic address information.
| Step | MCP Tool | Parameters | Retrieved Data | Status |
|---|
| 1 | info_onchain_get_address_info | address={address}, chain={chain} | Basic address info, balance, transaction count | ✅ Available |
| 2 | info_compliance_check_address_risk | — | Address compliance risk labels | ❌ Not ready |
Degradation Handling: Inform the user "Address compliance risk detection is under development. Currently only basic address information is available. For token contract security checks, please provide the token name or contract address."
Report Template (Token Security Mode)
## {token} Contract Security Report
### 1. Risk Overview
| Metric | Result |
|--------|--------|
| Chain | {chain} |
| Contract Address | {address} |
| Overall Risk Level | {risk_level_text} ({highest_risk_level}) |
| High-Risk Items | {high_risk_num} |
| Medium-Risk Items | {middle_risk_num} |
| Low-Risk Items | {low_risk_num} |
| Honeypot Detected | {is_honeypot ? "⛔ Yes" : "✅ No"} |
| Open Source | {is_open_source ? "✅ Yes" : "⚠️ No"} |
### 2. High-Risk Item Details
{If high-risk items exist, list each:}
| Risk Item | Description | Value |
|-----------|------------|-------|
| {risk_name_1} | {risk_desc_1} | {risk_value_1} |
| {risk_name_2} | {risk_desc_2} | {risk_value_2} |
| ... | ... | ... |
{If no high-risk items: "✅ No high-risk items detected"}
### 3. Tax Analysis
| Metric | Value | Status |
|--------|-------|--------|
| Buy Tax | {buy_tax}% | {Normal/Elevated/Extreme} |
| Sell Tax | {sell_tax}% | {Normal/Elevated/Extreme} |
| Transfer Tax | {transfer_tax}% | {Normal/Elevated/Extreme} |
{If multiple DEX pools have different tax rates, list the major pool breakdowns}
### 4. Holder Concentration
| Metric | Value | Status |
|--------|-------|--------|
| Holder Count | {holder_count} | {Many/Normal/Low} |
| Top 10 Holder % | {top10_percent}% | {Normal/High/Extremely Concentrated} |
| Top 100 Holder % | {top100_percent}% | — |
| Developer Holdings | {dev_holding_percent}% | {Normal/High} |
| Insider Holdings | {insider_percent}% | {Normal/High} |
| Largest Single Holder | {max_holder_percent}% | {Normal/High} |
### 5. Name Risk
| Metric | Result |
|--------|--------|
| Domain Token | {is_domain_token ? "⚠️ Yes" : "✅ No"} |
| Contains Sensitive Words | {is_sensitive ? "⚠️ Yes" : "✅ No"} |
| Sensitive Words | {sensitive_words} |
### 6. Project Basic Info (Supplementary)
| Metric | Value |
|--------|-------|
| Project Name | {project_name} |
| Sector | {category} |
| Listed on Major Exchanges | {exchange_list} |
{LLM generates a 3-5 sentence comprehensive risk assessment:}
Overall contract safety level
Most critical risk items (if any)
Whether holder concentration is healthy
Whether tax rates are reasonable
Whether further manual audit is recommended
{Auto-generated explicit warnings based on detection results:}
Honeypot detection (if applicable)
High tax warning (if applicable)
Excessive holder concentration (if applicable)
Contract not open-source (if applicable)
Decision Logic
| Condition | Assessment |
|---|
is_honeypot == true | Highest-level warning: "⛔ Detected as honeypot contract — extremely likely unable to sell. Do NOT purchase." |
is_open_source == false | Flag "Contract is not open-source — code logic cannot be audited, elevated risk" |
buy_tax > 5% or sell_tax > 5% | Flag "Abnormally high tax rate — extreme trading costs" |
buy_tax > 10% or sell_tax > 10% | Flag "⛔ Extreme tax rate — suspected malicious contract" |
top10_percent > 50% | Flag "Highly concentrated holdings — insider/whale dump risk" |
top10_percent > 80% | Flag "⛔ Extremely concentrated holdings — dump risk is critical" |
dev_holding_percent > 10% | Flag "Developer holdings are elevated — watch for sell-off risk" |
holder_count < 100 | Flag "Extremely few holders — insufficient liquidity and decentralization" |
high_risk_num > 0 | List each high-risk item with explanation |
high_risk_num == 0 && middle_risk_num <= 2 | Flag "Contract security check passed — no significant risks detected" |
is_domain_token == true | Flag "This is a domain token — unrelated to the project of the same name. Verify carefully." |
is_sensitive == true | Flag "Token name contains sensitive words — possible impersonation/fraud risk" |
| Any Tool returns empty/error | Skip that section; note "Data unavailable" in the report |
Risk Level Mapping
highest_risk_level Value | Risk Level | Label | Description |
|---|
| 0 | Safe | ✅ Safe | No risk items detected |
| 1 | Low Risk | Low Risk | Only low-risk items present |
| 2 | Medium Risk | Medium Risk | Medium-risk items present — monitor |
| 3 | High Risk | High Risk | High-risk items present — exercise extreme caution |
| is_honeypot=true | Critical Risk | ⛔ Critical Risk | Honeypot contract — strongly advise staying away |
Error Handling
| Error Type | Handling |
|---|
| Missing chain parameter | Prompt user: "Please specify the chain (e.g., eth, bsc, solana, base, arb)" |
| Neither token nor address provided | Prompt user: "Please provide a token symbol or contract address" |
| Contract address does not exist / unrecognizable | Prompt user to verify the address and confirm the chain |
| Token is a major coin (BTC/ETH, etc.) | Inform: "Major coins typically have no contract security risks. For contract token checks, specify the wrapped token or Meme token on a specific chain" |
| check_token_security timeout/error | Return error message; suggest trying again later |
| Address risk query (currently unavailable) | Inform: "Address compliance detection is under development." Guide user to gate-info-addresstracker for basic address info |
| User inputs a regular address thinking it's a contract | Attempt detection; if empty result, inform "This may not be a contract address. For address information, use the Address Tracker feature" |
Cross-Skill Routing
| User Follow-up Intent | Route To |
|---|
| "Analyze this coin for me" | gate-info-coinanalysis |
| "What about on-chain chip distribution?" | gate-info-tokenonchain |
| "Any recent news?" | gate-news-briefing |
| "Track this address" | gate-info-addresstracker |
| "Compare this with XX" | gate-info-coincompare |
| "How is this coin's price action?" | gate-info-trendanalysis |
Available Tools & Degradation Notes
| PRD-Defined Tool | Actually Available Tool | Status | Degradation Strategy |
|---|
info_compliance_check_token_security | info_compliance_check_token_security | ✅ Ready | — |
info_coin_get_coin_info | info_coin_get_coin_info | ✅ Ready | — |
info_onchain_get_address_info | info_onchain_get_address_info | ✅ Ready | Address mode can retrieve basic info |
info_compliance_check_address_risk | — | ❌ Not ready (P3) | Address compliance risk detection unavailable — inform user and guide to address tracker |
Safety Rules
- Mandatory honeypot warning: When
is_honeypot=true is detected, display the "⛔ Critical Risk" warning in the most prominent position — never downplay
- No investment advice: Risk assessment is based on on-chain data and must include a "not investment advice" disclaimer
- No absolute safety guarantees: Even if all checks pass, state that "automated detection cannot cover all risks"
- Data transparency: Label detection data source and timestamp
- Flag missing data: When any dimension has no data, explicitly inform the user — never fabricate safety conclusions
- Address privacy: Do not proactively expose address holder identities — only display publicly available on-chain data