Defi Sniper

Orchestrates early token launch detection, on-chain risk analysis, social signal verification, and guarded swap execution on Solana and Base chains.

Security Scan

The skill's stated purpose (orchestrating token launch detection and guarded swaps) matches the tools it references, but the runtime instructions expect access to additional sensitive credentials and external installs that are not declared, creating incoherence and an elevated risk if you enable live execution.

Purpose & Capability

Name/description align with the requested binaries (node, npx) and declared env vars (MINARA_API_KEY, SOLANA_RPC_URL) because the skill is a meta-orchestrator of Minara/Torch stacks. Declared requirement of 'skills.entries.minara.enabled' is plausible for a meta-skill that delegates to Minara. Minor mismatch: the SKILL.md repeatedly references other secrets/configs (Circle Wallet signer, chain private-key fallback, VAULT_CREATOR, linked agent wallet) that are functionally required for live execution but are not listed in requires.env.

Instruction Scope

SKILL.md is instruction-only and tells the agent to install and orchestrate minara, torchmarket, and torchliquidationbot via npx. It explicitly instructs using signers/vaults and possible private-key fallbacks for live transactions and calls for external web searches for social verification. Those directions mean the agent will need to access private keys or vault credentials and interact with external web tools; those sensitive accesses are not consistently declared or gated in the skill file. The doc does include preflight checks and a 'do not run live' admonition if inputs are missing, but that relies on agent/installer discipline rather than enforced declarations.

Install Mechanism

The skill is instruction-only (no install spec), so it will not itself write code to disk, but it instructs running 'npx -y clawhub@latest install ...' to fetch upstream skills. Using npx to pull packages is expected for this workflow but still means third-party code will be installed and executed on the host at runtime — a moderate-risk action that the SKILL.md delegates to the agent/user.

Credentials

Only MINARA_API_KEY and SOLANA_RPC_URL are declared as required env vars, which are reasonable. However, live execution requires signing capability (Circle Wallet, private key) and possibly vault credentials (VAULT_CREATOR and a linked agent wallet), which are referenced but not declared. This mismatch hides additional sensitive secrets the agent will need to access, increasing the chance of accidental exposure or misconfiguration.

Persistence & Privilege

The skill does not request always:true and allows autonomous invocation (platform default). That combination is not itself a red flag, but because the skill orchestrates live on-chain transactions and may request signing credentials at runtime, enabling autonomous invocation increases the blast radius. The skill also requires another skill to be enabled via 'skills.entries.minara.enabled' but does not claim to alter other skills' configurations.

What to consider before installing

This skill is coherent with its stated goal but has notable gaps that increase risk. Before installing or enabling live execution: 1) Do not provide private keys directly — prefer a vault or hardware signer with constrained permissions and verify any vault env var names (e.g., VAULT_CREATOR) that the orchestration may require. 2) Treat MINARA_API_KEY as sensitive and scope its permissions; confirm what Minara can do with that key. 3) Run initial testing in 'observe' or 'paper' mode and use dry-runs only; never allow 'live' or 'auto-with-guardrails' until you’ve validated behavior. 4) Audit the upstream packages (minara, torchmarket, torchliquidationbot) that the SKILL.md instructs you to install via npx — npx will fetch and run third-party code. 5) If you must run live trades, restrict the agent’s network and host environment, and require manual-confirmation execution_policy so the agent cannot autonomously sign transactions. 6) Ask the skill author to declare all required env vars and config paths (signer/vault variables) explicitly in the skill manifest and to document exact external endpoints used for social checks; absence of those declarations is the main coherence/privilege concern.

Purpose

Run a high-speed token opportunity workflow:

1. detect very early pool/token activity,
2. triage contract/market risk,
3. verify social signal quality,
4. 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)
• torchmarket (inspected latest: 4.2.7)
• torchliquidationbot (inspected latest: 3.0.2)

Install/update:

npx -y clawhub@latest install minara
npx -y clawhub@latest install torchmarket
npx -y clawhub@latest install torchliquidationbot
npx -y clawhub@latest update --all

Required Configuration and Credentials

Minimum:

• MINARA_API_KEY
• SOLANA_RPC_URL

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 base
• token_symbol_or_mint
• max_entry_size (example: 1 SOL or base-chain equivalent)
• max_slippage_bps (example: 300)
• risk_mode: observe, paper, live
• sentiment_min_accounts (minimum credible, non-bot mentions)
• execution_policy: manual-confirm or auto-with-guardrails

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
• SentimentGate: pass/fail

Execution rule:

• only if both gates are pass
• otherwise no_trade

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.
2. Torch Market fetches token-level state and quote/treasury context.
3. Social verification runs in parallel via external web search (X/Twitter signal quality).
4. If SecurityGate=pass and SentimentGate=pass, execute bounded entry (example 1 SOL) with fixed slippage tolerance.
5. Log full decision trail: signals, checks, final action.

Output Contract

Always return:

• Detection

  • chain, token ID, first-seen timestamp

• OnChainRisk

  • indicators checked
  • pass/fail with reasons

• SocialSignal

  • source summary
  • pass/fail with reasons

• ExecutionDecision

  • trade or no_trade
  • size, slippage, route

• AuditTrail

  • 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.