Purpose
Run a high-speed token opportunity workflow:
- 1. detect very early pool/token activity,
- triage contract/market risk,
- verify social signal quality,
- execute small, bounded entries when rules pass.
This is an orchestration skill. It coordinates upstream skills and explicit risk policy. It does not guarantee profit.
Required Installed Skills
- -
minara (inspected latest: 1.1.9) - INLINECODE2 (inspected latest:
4.2.7) - INLINECODE4 (inspected latest:
3.0.2)
Install/update:
CODEBLOCK0
Required Configuration and Credentials
Minimum:
Depending on execution route:
- - Minara signer path: Circle Wallet preferred, or chain private-key fallback per Minara docs.
- Torch vault path:
VAULT_CREATOR and linked agent wallet for vault-routed operations.
Preflight checks before any live execution:
- - chain (
solana or base) explicitly selected - funding source identified (vault or signer account)
- max-risk limits loaded
- dry-run path available
Chain-Aware Architecture
Solana path (full stack)
Use:
- - Minara for detection/intent parsing,
- Torch Market for deep token + quote + treasury/lending state,
- optional Torch execution patterns (vault-routed),
- external web search for social confirmation.
Base path (constrained path)
Use:
- - Minara for detection/intent/transaction assembly,
- external web search for social confirmation.
Important boundary:
- - Torch Market and Torch Liquidation Bot are Solana-focused and should not be assumed to provide Base-native token risk primitives.
Inputs the LM Must Collect First
- -
target_chain: solana or INLINECODE13 - INLINECODE14
- INLINECODE15 (example:
1 SOL or base-chain equivalent) - INLINECODE17 (example:
300) - INLINECODE19 :
observe, paper, INLINECODE22 - INLINECODE23 (minimum credible, non-bot mentions)
- INLINECODE24 :
manual-confirm or INLINECODE26
If missing, do not run live execution.
Tool Responsibilities
Minara (minara)
Primary detection/intelligence and swap-intent layer:
- - market chat/intel,
- intent-to-swap transaction generation,
- chain-aware execution pathways,
- strategy support across Solana and EVM (including Base).
Use Minara when rapid parsing and transaction assembly are required.
Torch Market (torchmarket)
Solana-native deep state layer:
- - token discovery (
getTokens) and token details (getToken), - buy/sell quote simulation (
getBuyQuote, getSellQuote), - treasury/lending/position context (
getLendingInfo, getLoanPosition), - vault-routed transaction builders.
Use Torch Market for on-chain structural checks and quote sanity before Solana entries.
Torch Liquidation Bot (torchliquidationbot)
Execution engine specialized for liquidation keepers:
- - continuous scan loop,
- high-speed vault-routed transaction execution patterns,
- strict vault safety boundary.
Important boundary:
- - It is purpose-built for liquidation flow (
buildLiquidateTransaction path), not a generic buy/sell sniper by default. - Reuse only its operational/safety pattern unless a dedicated swap executor is explicitly available.
Canonical Signal Chain
Use this chain for launch-sniping decisions.
Stage 1: Early launch detection
Use Minara intelligence to detect candidate opportunities and parse swap intent context.
Required output:
- - token/mint identifier
- chain
- initial liquidity signal if available
- timestamp of first detection
Stage 2: On-chain risk triage
For Solana candidates, use Torch Market state:
- - token status and reserves,
- quote simulation (buy/sell impact),
- treasury and lending context where relevant,
- holder concentration snapshots (if available through token/holder queries).
Risk interpretation policy:
- - No single field should be treated as a complete rug/honeypot verdict.
- Require multiple independent indicators before green-lighting.
Stage 3: Social signal confirmation
Use external web search tools (not bundled in these three skills) to validate whether real accounts are discussing the token.
Minimum checks:
- - account quality (non-trivial follower/history signals)
- message diversity (not duplicate bot spam)
- temporal alignment with on-chain launch timing
Stage 4: Decision matrix
Compute two gates:
- -
SecurityGate: pass/fail - INLINECODE38 : pass/fail
Execution rule:
- - only if both gates are INLINECODE39
- otherwise INLINECODE40
Stage 5: Execution
If execution allowed:
- - enforce position cap (example: 1 SOL)
- enforce slippage cap
- record tx hash and rationale
- immediately set post-entry monitoring conditions
Scenario Mapping (PEPE2.0 on Solana)
For the scenario in this skill request:
- 1. Minara flags a new Solana token/pool event with initial liquidity context.
- Torch Market fetches token-level state and quote/treasury context.
- Social verification runs in parallel via external web search (X/Twitter signal quality).
- If
SecurityGate=pass and SentimentGate=pass, execute bounded entry (example 1 SOL) with fixed slippage tolerance. - Log full decision trail: signals, checks, final action.
Output Contract
Always return:
- chain, token ID, first-seen timestamp
- indicators checked
- pass/fail with reasons
- source summary
- pass/fail with reasons
-
trade or
no_trade
- size, slippage, route
- exact checks performed
- unresolved uncertainties
Risk Guardrails
- - Never deploy unbounded size; always cap first entry.
- Never trade without slippage limits.
- Never treat hype alone as trade permission.
- Never claim "safe" based on one heuristic.
- Prefer
no_trade on ambiguous or conflicting evidence. - In
auto-with-guardrails mode, require preconfigured hard limits and fail-closed defaults.
Operational Modes
observe
Detection and scoring only. No trade.
paper
Simulated entries/exits with recorded hypothetical PnL.
live
Real execution only after preflight and guardrail checks pass.
Failure Handling
- - Missing key/config/env: halt with explicit missing item list.
- Detection without sufficient risk data: downgrade to
observe. - Sentiment source unavailable: require manual confirmation or
no_trade. - Execution route unavailable on selected chain: return explicit compatibility mismatch.
Known Limits from Inspected Upstream Skills
- - Minara inspected docs describe intent parsing and transaction assembly, but do not expose a dedicated "mempool scanner" endpoint in the inspected
SKILL.md. - Torch Market exposes rich Solana token/treasury/lending state and quotes, but no single built-in "honeypot/rug score" flag.
- Torch Liquidation Bot is liquidation-specialized; using it as a generic swap executor is a repurposing pattern, not its native primary workflow.
- Social signal checks require external web/search skills outside this three-skill stack.
Treat these limits as mandatory disclosures in final operator output.
技能名称: defi-sniper
详细描述:
目的
运行一个高速代币机会工作流:
- 1. 检测极早期的池子/代币活动,
- 对合约/市场风险进行分类,
- 验证社交信号质量,
- 当规则通过时,执行小规模、有边界的入场。
这是一个编排技能。它协调上游技能和明确的风险策略。它不保证盈利。
所需已安装技能
- - minara(已检查最新版本:1.1.9)
- torchmarket(已检查最新版本:4.2.7)
- torchliquidationbot(已检查最新版本:3.0.2)
安装/更新:
bash
npx -y clawhub@latest install minara
npx -y clawhub@latest install torchmarket
npx -y clawhub@latest install torchliquidationbot
npx -y clawhub@latest update --all
所需配置和凭证
最低要求:
- - MINARAAPIKEY
- SOLANARPCURL
根据执行路径:
- - Minara 签名者路径:首选 Circle 钱包,或根据 Minara 文档使用链上私钥回退。
- Torch 金库路径:VAULT_CREATOR 和关联的代理钱包,用于金库路由操作。
任何实时执行前的预检检查:
- - 明确选择链(solana 或 base)
- 确定资金来源(金库或签名者账户)
- 加载最大风险限额
- 提供模拟运行路径
链感知架构
Solana 路径(全栈)
使用:
- - Minara 进行检测/意图解析,
- Torch Market 进行深度代币 + 报价 + 国库/借贷状态查询,
- 可选的 Torch 执行模式(金库路由),
- 外部网络搜索进行社交确认。
Base 路径(受限路径)
使用:
- - Minara 进行检测/意图/交易组装,
- 外部网络搜索进行社交确认。
重要边界:
- - Torch Market 和 Torch Liquidation Bot 专注于 Solana,不应假定它们提供 Base 原生代币风险原语。
语言模型必须首先收集的输入
- - targetchain:solana 或 base
- tokensymbolormint
- maxentrysize(示例:1 SOL 或 Base 链等价物)
- maxslippagebps(示例:300)
- riskmode:observe、paper、live
- sentimentminaccounts(最低可信、非机器人提及数)
- executionpolicy:manual-confirm 或 auto-with-guardrails
如果缺失,则不执行实时执行。
工具职责
Minara(minara)
主要检测/情报和交换意图层:
- - 市场聊天/情报,
- 意图到交换的交易生成,
- 链感知执行路径,
- 支持 Solana 和 EVM(包括 Base)的策略。
当需要快速解析和交易组装时,使用 Minara。
Torch Market(torchmarket)
Solana 原生深度状态层:
- - 代币发现(getTokens)和代币详情(getToken),
- 买入/卖出报价模拟(getBuyQuote、getSellQuote),
- 国库/借贷/头寸上下文(getLendingInfo、getLoanPosition),
- 金库路由交易构建器。
在 Solana 入场前,使用 Torch Market 进行链上结构检查和报价合理性验证。
Torch Liquidation Bot(torchliquidationbot)
专为清算守护者设计的执行引擎:
- - 持续扫描循环,
- 高速金库路由交易执行模式,
- 严格的金库安全边界。
重要边界:
- - 它是为清算流程(buildLiquidateTransaction 路径)专门构建的,默认不是通用的买入/卖出狙击手。
- 除非有明确的专用交换执行器可用,否则仅复用其操作/安全模式。
规范信号链
使用此链进行启动狙击决策。
阶段 1:早期启动检测
使用 Minara 情报检测候选机会并解析交换意图上下文。
所需输出:
- - 代币/铸币标识符
- 链
- 初始流动性信号(如有)
- 首次检测的时间戳
阶段 2:链上风险分类
对于 Solana 候选者,使用 Torch Market 状态:
- - 代币状态和储备,
- 报价模拟(买入/卖出影响),
- 相关的国库和借贷上下文,
- 持有者集中度快照(如果可通过代币/持有者查询获得)。
风险解释策略:
- - 不应将任何单一字段视为完整的拉地毯/蜜罐判定。
- 在开绿灯前,需要多个独立指标。
阶段 3:社交信号确认
使用外部网络搜索工具(不包含在这三个技能中)验证真实账户是否在讨论该代币。
最低检查:
- - 账户质量(非平凡的关注者/历史信号)
- 消息多样性(非重复的机器人垃圾信息)
- 与链上启动时间的时间对齐
阶段 4:决策矩阵
计算两个门:
- - SecurityGate:通过/失败
- SentimentGate:通过/失败
执行规则:
阶段 5:执行
如果允许执行:
- - 强制执行仓位上限(示例:1 SOL)
- 强制执行滑点上限
- 记录交易哈希和理由
- 立即设置入场后监控条件
场景映射(Solana 上的 PEPE2.0)
对于此技能请求中的场景:
- 1. Minara 标记一个新的 Solana 代币/池子事件,并带有初始流动性上下文。
- Torch Market 获取代币级别状态和报价/国库上下文。
- 通过外部网络搜索(X/Twitter 信号质量)并行运行社交验证。
- 如果 SecurityGate=通过 且 SentimentGate=通过,则执行有边界的入场(示例 1 SOL),并带有固定的滑点容忍度。
- 记录完整的决策轨迹:信号、检查、最终行动。
输出合约
始终返回:
- 链、代币 ID、首次看到的时间戳
- 已检查的指标
- 通过/失败及原因
- 来源摘要
- 通过/失败及原因
- 交易 或 不交易
- 规模、滑点、路径
- 执行的确切检查
- 未解决的不确定性
风险护栏
- - 绝不部署无边界规模;始终限制首次入场。
- 绝不在没有滑点限制的情况下交易。
- 绝不将炒作单独视为交易许可。
- 绝不基于单一启发式方法声称“安全”。
- 在模棱两可或冲突的证据下,优先选择 不交易。
- 在 auto-with-guardrails 模式下,需要预先配置的硬限制和故障关闭默认值。
操作模式
observe
仅检测和评分。不交易。
paper
模拟入场/出场,并记录假设的盈亏。
live
仅在预检和护栏检查通过后执行真实交易。
故障处理
- - 缺少密钥/配置/环境:停止并列出明确缺失项。
- 检测到但缺乏足够的风险数据:降级为 observe。
- 情感来源不可用:要求手动确认或 不交易。
- 所选链上执行路径不可用:返回明确的兼容性不匹配。
已检查上游技能的已知限制
- - Minara 已检查文档描述了意图解析和交易组装,但在已检查的 SKILL.md 中未暴露专用的“内存池扫描器”端点。
- Torch Market 暴露了丰富的 Solana 代币/国库/借贷状态和报价,但没有单一内置的“蜜罐/拉地毯评分”标志。
- Torch Liquidation Bot 是清算专用的;将其用作通用交换执行器是一种重新利用模式,而非其原生主要工作流。
- 社交信号检查需要此三个技能堆栈之外的外部网络/搜索技能。
将这些限制视为最终操作员输出中的强制性披露。