Purpose

Run a high-speed token opportunity workflow:

• detect very early pool/token activity,
• triage contract/market risk,
• verify social signal quality,
• execute small, bounded entries when rules pass.

Required Installed Skills

• minara (inspected latest: 1.1.9)
• torchmarket (inspected latest: 4.2.7)
• torchliquidationbot (inspected latest: 3.0.2)

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

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

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

• 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

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

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.

Torch Liquidation Bot (torchliquidationbot)

Execution engine specialized for liquidation keepers:

• continuous scan loop,
• high-speed vault-routed transaction execution patterns,
• strict vault safety 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).

• 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

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

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

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