Kryptogo Meme Trader

KryptoGO Meme Trader Agent Skill

Overview

This skill enables an AI agent to autonomously analyze and trade meme coins through the KryptoGO platform. It combines deep on-chain cluster analysis with automated trade execution.

Analysis (multi-chain: Solana, BSC, Base, Monad):

• Wallet clustering — identify entities controlling multiple addresses
• Accumulation/distribution detection — who's buying vs. selling
• Address behavior labels — smart money, whales, snipers, developers
• Network-wide accumulation signals (Pro/Alpha tier)

Trading (Solana only):

• Portfolio monitoring with per-token PnL tracking
• Automated swap execution via DEX aggregator
• Local transaction signing (private key never leaves the machine)

Important: Analysis supports Solana, BSC, Base, and Monad. Trading (swap/submit) is Solana-only.

Workflow: discover signal → analyze token → assess risk → execute trade → monitor position.

When to Use

• User asks to analyze a meme coin or token on Solana/BSC/Base/Monad
• User asks to trade, buy, or sell tokens
• User asks to scan for trending tokens or market opportunities
• User asks to monitor portfolio positions or check PnL
• Heartbeat/cron-triggered periodic portfolio monitoring and signal scanning
• Pro/Alpha subscribers leveraging signal dashboard for curated accumulation signals

When NOT to Use

• BTC, ETH, or major L1 token macro analysis (not meme-specific)
• NFT-related questions
• Cross-chain bridging or non-DEX transactions
• General crypto news or price predictions without on-chain analysis
• Non-Solana trading execution

Setup Flow

1. Get API Key

1. Go to kryptogo.xyz/account and create an API key
2. Add it to ~/.openclaw/workspace/.env (the workspace root .env):

   echo 'KRYPTOGO_API_KEY=sk_live_YOUR_KEY' >> ~/.openclaw/workspace/.env && chmod 600 ~/.openclaw/workspace/.env
   

3. Tell the agent "I've set my API key in .env" — the agent will verify it works by calling /agent/account

Do NOT paste your API key directly in chat. Chat histories may be stored and could expose your key. Always set secrets via .env file or environment variables.

All credentials are stored in ~/.openclaw/workspace/.env — the OpenClaw workspace root. This ensures heartbeat/cron sessions can find them automatically.

The API key is tied to your KryptoGO account (for billing/tier), NOT to a specific wallet. Your login wallet on kryptogo.xyz may differ from the agent's trading wallet.

2. Generate Agent Wallet

Run the setup script to create a dedicated Solana keypair:

python3 scripts/setup.py

This will:

1. Check Python 3.10+ and install solders + requests if missing
2. Generate a new Solana keypair
3. Save the private key (base58) and public address to ~/.openclaw/workspace/.env
4. Set .env permissions to 600 (owner read/write only)
5. Print the public address for the user to fund with SOL

3. Fund the Wallet

Send SOL to the agent's public address (minimum 0.1 SOL for gas + trading capital).

Security Rules

• NEVER print, log, or include the private key in any message or CLI argument
• NEVER accept secrets (API keys, private keys) pasted directly in chat — instruct users to set them in .env
• NEVER commit .env to version control
• NEVER use the Read tool on ~/.openclaw/workspace/.env — load credentials via source command only, which doesn't expose values in tool output
• The private key stays in memory only during local signing — it is never sent to any server
• .env must always have chmod 600
• See Safety Guardrails for full credential handling and trading limits

Quickstart Checklist

After installing this skill, complete these steps in order:

1. Get API key from kryptogo.xyz/account and add it to .env
2. Run python3 scripts/setup.py to generate agent wallet
3. Fund the agent wallet with SOL (min 0.1 SOL)
4. Tell the agent your trading preferences (max position size, risk tolerance, etc.)
5. Set up periodic monitoring — see Heartbeat & Cron Integration

Authentication

All endpoints require Bearer token authentication:

Authorization: Bearer sk_live_<48 hex chars>

Some features (signal dashboard, KOL finder) additionally require Pro or Alpha tier subscription.

Agent Behavior

Session Initialization

On every session start (including heartbeat/cron), the agent MUST load credentials before making any API calls:

source ~/.openclaw/workspace/.env

This makes KRYPTOGO_API_KEY, SOLANA_PRIVATE_KEY, and SOLANA_WALLET_ADDRESS available as environment variables. Do NOT use the Read tool on .env — the source command loads values without exposing them in tool output.

Autonomous Mode (Default)

Automatic actions (no user confirmation needed):

• Scanning trending tokens (default: top 10 per scan)
• Running full analysis pipeline on candidate tokens
• Checking portfolio status and PnL
• Executing trades that pass ALL criteria in the Bullish Checklist
• Stop-loss sells when unrealized loss exceeds threshold
• Take-profit sells when gain exceeds target

Requires user confirmation:

• Risk level is "medium" (ambiguous signals)
• Position size exceeds user-defined max
• Selling at a loss outside stop-loss rules
• Any action outside the defined entry/exit strategies

Reporting:

• After each trade: summarize analysis result + trade details to the user (concise text, not raw JSON)
• After each scan: brief summary of tokens scanned, why they passed/failed
• On errors: report the issue and suggest next steps

User Preferences

The user can customize behavior by telling the agent their preferences. Store in memory/trading-preferences.json:

{
  "max_position_size": 0.1,
  "max_open_positions": 5,
  "max_daily_trades": 20,
  "stop_loss_pct": 30,
  "take_profit_pct": 100,
  "min_market_cap": 500000,
  "scan_count": 10,
  "risk_tolerance": "moderate",
  "chains": ["solana"]
}

Safety Guardrails

This skill handles real funds. These guardrails limit blast radius if credentials are mishandled or the agent malfunctions.

Credential Isolation

• API key and private key are stored ONLY in ~/.openclaw/workspace/.env with chmod 600 (owner read/write)
• The agent reads credentials via environment variables (source ~/.openclaw/workspace/.env) — they are never printed, logged, passed as CLI arguments, or included in chat messages
• The agent must never use the Read tool on .env — the source command keeps values out of tool output
• If a user pastes a secret in chat, the agent should warn them and suggest rotating it

Trading Limits (Hard Caps)

These limits apply even if user preferences set higher values:

If any limit is hit, the agent must stop and notify the user — never silently skip.

Autonomous Trading Scope

• The agent only executes trades that pass ALL criteria in the Bullish Checklist (Step 6)
• Ambiguous signals (risk = "medium") always require user confirmation
• The agent cannot modify its own trading parameters — only propose changes for user approval
• All trade executions are immediately reported to the user via the configured channel (Telegram, Discord, etc.)

Kill Switch

To immediately stop all autonomous trading:

1. Remove the Trading Agent section from HEARTBEAT.md — stops heartbeat-triggered trading
2. Run openclaw cron remove <name> — stops cron-triggered trading
3. Remove or rename .env — prevents any API calls or signing

The agent has no persistence mechanism beyond HEARTBEAT.md and cron entries. Removing those stops all autonomous behavior.

Audit Trail

Every action is logged to memory/ files (see Learning Memory Files):

• trading-journal.json — complete trade history with reasoning
• trading-state.json — current positions and last scan time
• trading-lessons.md — post-mortem analysis

These files are human-readable and can be reviewed at any time.

Heartbeat & Cron Integration

First-Time Auto-Setup

Agent instruction: The first time this skill is loaded in a conversation, check if HEARTBEAT.md already contains a "Trading Agent" section. If not, proactively offer to add it — ask the user: "I can set up periodic trading monitoring. Should I add it to your HEARTBEAT.md?" If confirmed, append the heartbeat block below.

Note: OpenClaw does not auto-modify HEARTBEAT.md on skill install. The agent must do this on first use.

Heartbeat — Periodic Monitoring (~30 min intervals)

Add the following to your HEARTBEAT.md:

## Trading Agent
- Check portfolio: call /agent/portfolio, execute stop-loss/take-profit if triggered
- Scan for opportunities: use signal dashboard (Pro/Alpha) or trending tokens API
- Execute qualifying trades in autonomous mode
- Log closed trades to journal, run post-trade reflection, trigger strategy review if due
- ALWAYS report any trade executed to the user — never silent HEARTBEAT_OK after trading

Heartbeat is best for: 30-minute-level monitoring where slight timing drift is acceptable. Multiple checks (portfolio + scan) batch into a single heartbeat turn, saving API calls.

Cron — Precise Scheduling (5-15 min intervals)

For more frequent or precisely timed scans, use OpenClaw cron instead of heartbeat:

# Example: scan every 15 minutes during market hours (UTC)
openclaw cron add --every 15m --name "trading-scan" --prompt "Run the kryptogo-meme-trader scan workflow: check portfolio for stop-loss/take-profit, then scan top 10 trending tokens. Execute qualifying trades. Report any actions taken."

# Example: daily portfolio summary at 9 AM Taipei time (1 AM UTC)
openclaw cron add --cron "0 1 * * *" --name "daily-portfolio" --prompt "Call /agent/portfolio and send me a daily summary of all open positions with PnL."

# List active crons
openclaw cron list

# Remove a cron
openclaw cron remove trading-scan

Cron is best for: exact timing, high-frequency scans (every 5-15 min), standalone tasks that don't need conversational context, or when you want a different model/thinking level.

Recommendation: Use heartbeat for casual monitoring (check every ~30 min). Switch to cron if you want aggressive 5-15 min scan intervals or precise daily reports.

Heartbeat Workflow

1. Portfolio check → Call /agent/portfolio with agent's wallet address
   • Execute stop-loss if unrealized loss > stop_loss_pct
   • Execute take-profit if unrealized gain > take_profit_pct
   • Flag stale positions (held > 7 days with no significant movement)
2. Signal scan → Choose source based on subscription tier:
   • Pro/Alpha tier: Use /signal-dashboard first — these are system-curated accumulation signals (clusters actively buying). Higher quality than raw trending lists because they're pre-filtered for smart money activity. Parameters: chain_id, sort_by=signal_count, page_size=10.
   • Free tier: Fall back to /agent/trending-tokens with filters (min_market_cap, min_liquidity, etc.)
   • Run top results through the 7-step analysis pipeline
   • Auto-trade if all criteria pass; ask user if risk = "medium"
3. State persistence → Save to memory/trading-state.json
   • Tracks: last scan time, open positions, pending user reviews
   • On next session/heartbeat, read this file to resume state
4. Learning check → If any trades were closed since last check:
   • Log outcome to memory/trading-journal.json
   • Run post-trade reflection (mandatory for every closed trade)
   • If loss >20%, trigger Loss Post-Mortem
   • If 20+ trades accumulated or 7+ days since last review, trigger Strategy Review

Notification Rules

Mandatory — agent MUST message the user (never silent HEARTBEAT_OK) when:

• Any trade is executed (buy or sell)
• A stop-loss or take-profit is triggered
• A position is flagged for manual review (medium risk, stale, etc.)
• An error prevents normal operation (API down, insufficient SOL, quota exceeded)

Silent HEARTBEAT_OK is OK when:

• Portfolio checked, no action needed
• Tokens scanned, none qualified
• Everything nominal

Failure Recovery

If the agent crashes or session ends mid-trade:

• On startup, ALWAYS call /agent/portfolio first to check current holdings
• Compare with memory/trading-state.json to detect any untracked positions
• Report any discrepancies to the user immediately

On-Chain Analysis Framework (7-Step Pipeline)

Step 1: Token Overview

Call /token-overview?address=<mint>&chain_id=<id> — get name, price, market cap, holders, risk_level, liquidity.

Filter: Skip if market cap < user's min_market_cap.

Step 2: Cluster Analysis

Call /analyze/<mint>?chain_id=<id> — get wallet clusters, top holders, address metadata.

Key metric — Cluster Holding Ratio:

• ≥30-35% = "controlled" — a major entity holds significant supply
• ≥50% = highly concentrated — high manipulation risk
• <10% = dispersed — no clear major holder

Scam rule: If a SINGLE cluster holds >50% of supply → skip (rug pull risk).

Step 3: Cluster Trend

Call /analyze-cluster-change/<mint> — get ratio changes across 15m/1h/4h/1d/7d.

Core insight: Price and cluster holdings DIVERGING is the most important signal.

• Rising price + falling cluster % = distribution (bearish)
• Falling price + rising cluster % = accumulation (bullish)

Step 4: Address Labels

Call /token-wallet-labels for token-specific labels (developer, sniper, bundle, new_wallet). Call /wallet-labels for behavior labels (smart_money, whale, blue_chip_profit, high_frequency).

Check sell pressure: Developer/sniper/bundle still holding = high dump risk.

Step 5: Deep Dive (Optional)

• /balance-history — time-series balance for specific wallets
• /balance-increase/<mint> — who bought most in a time range
• /top-holders-snapshot/<mint> — point-in-time holder snapshot
• /analyze-dca-limit-orders/<mint> — DCA/limit order detection (Solana only)
• /cluster-wallet-connections — fund flow between wallets

Step 6: Decision

Apply the Bullish Checklist from the Decision Framework:

• Market cap ≥ $500K
• Cluster ratio ≥ 30% and rising
• Smart money/whale clusters increasing
• Developer/sniper/bundle positions cleared
• No high proportion of new wallets or high-frequency traders

Full decision framework: see references/decision-framework.md

Step 7: Execute Trade

If all checks pass:

1. POST /agent/swap — build unsigned transaction
2. Sign locally with solders (private key never sent to server)
3. POST /agent/submit — submit signed transaction
4. Verify via explorer URL

Full trading workflow: see examples/trading-workflow.py

API Quick Reference

Full request/response details: see references/api-reference.md

Multi-Chain Support

Pass chain_id as a query parameter on analysis endpoints. Trading endpoints only work with Solana.

Error Handling

Learning & Adaptation

The agent improves over time by recording every trade, analyzing outcomes, and adjusting its strategy based on accumulated experience.

Trade Journal

Every trade (buy or sell) MUST be logged to memory/trading-journal.json immediately after execution:

{
  "trades": [
    {
      "id": "2026-02-25T14:30:00Z_BONK",
      "token_mint": "DezXAZ8z7PnrnRJjz3wXBoRgixCa6xjnB7YaB1pPB263",
      "symbol": "BONK",
      "chain_id": "501",
      "action": "BUY",
      "amount_sol": 0.1,
      "token_amount": 150000000,
      "price_at_entry": 0.0000234,
      "market_cap_at_entry": 1500000,
      "timestamp": "2026-02-25T14:30:00Z",
      "entry_reasoning": {
        "cluster_ratio": 0.35,
        "cluster_change_1d": 0.05,
        "smart_money_count": 3,
        "dev_exited": true,
        "sniper_cleared": true,
        "signal_source": "signal_dashboard",
        "risk_level": "low"
      },
      "outcome": null
    }
  ]
}

When a position is closed (sell), update the corresponding BUY entry's outcome:

{
  "outcome": {
    "exit_price": 0.0000468,
    "exit_timestamp": "2026-02-26T09:15:00Z",
    "exit_reason": "take_profit",
    "pnl_sol": 0.1,
    "pnl_pct": 100.0,
    "holding_duration_hours": 18.75,
    "cluster_ratio_at_exit": 0.28,
    "lesson": "Cluster started distributing 2h before exit — could have sold earlier at higher price"
  }
}

Mandatory Post-Trade Reflection

After every SELL (win or loss), the agent MUST:

1. Compare the entry reasoning with the actual outcome
2. Identify what the analysis got right and what it missed
3. Write a one-sentence lesson in the outcome record
4. If the loss was >20%, do a Loss Post-Mortem (see below)

Loss Post-Mortem

When a trade results in a loss >20%, the agent MUST perform a detailed post-mortem:

1. Re-run analysis on the token at current state — what changed since entry?
2. Identify the miss: Was it a signal that was there but ignored? An unexpected event? A parameter that was too loose?
3. Classify the loss type:
   • signal_miss — warning signs existed at entry but weren't weighted enough
   • timing_error — analysis was correct but entry/exit timing was wrong
   • external_event — unpredictable event (rug pull, exploit, market crash)
   • parameter_drift — thresholds were too loose (e.g., accepted low cluster ratio)
   • overconfidence — entered despite ambiguous signals
4. Log to memory/trading-lessons.md with the specific pattern to watch for

Periodic Strategy Review

Trigger: Every 20 trades OR every 7 days (whichever comes first), during a heartbeat/cron cycle.

The agent should:

1. Calculate aggregate stats from the journal:

   • Win rate (% of trades with positive PnL)
   • Average win size vs average loss size
   • Best/worst performing entry strategies (signal_dashboard vs trending_tokens)
   • Average holding duration for wins vs losses
   • Most common loss types

2. Identify patterns:

   • "Trades entered via signal_dashboard have 65% win rate vs 30% from trending_tokens"
   • "Positions held >24h tend to lose money — meme coins need faster exits"
   • "Tokens with cluster_ratio <25% at entry always lost"

3. Propose parameter adjustments to the user:

   • "Based on last 20 trades, I suggest raising min_market_cap from $500K to $1M (tokens below $1M had 80% loss rate)"
   • "Stop loss of 30% was never triggered before a 50% drop — consider tightening to 20%"
   • "Take profit at 100% missed several peaks — consider partial exit at 50%"

4. Save review to memory/strategy-reviews/YYYY-MM-DD.md

5. Update preferences only after user approves the proposed changes

Learning Memory Files

Example: Learning in Action

Week 1: Agent enters 5 trades using default parameters
  → 2 wins (+80%, +45%), 3 losses (-30%, -25%, -18%)
  → Win rate: 40%, avg win: +62.5%, avg loss: -24.3%

Post-mortem on -30% loss:
  → Token had cluster_ratio 22% at entry (below 30% threshold was relaxed because trending)
  → Lesson: "Never relax cluster_ratio below 25%, even for trending tokens"

Week 2 review:
  → Agent proposes: "Raise min cluster_ratio from 20% to 28%"
  → User approves → preferences updated
  → Agent also notices: "All wins came from signal_dashboard source"
  → Agent proposes: "Allocate 80% of scans to signal_dashboard, 20% to trending"

Week 3: Improved win rate from 40% → 55% with tighter parameters

What the Agent Should NOT Do

• Never auto-adjust parameters without user approval — always propose and wait
• Never delete journal entries — the full history is needed for pattern analysis
• Never ignore a post-mortem — even if the loss was small, the pattern matters
• Never blame "market conditions" without specifics — always look for actionable lessons

Best Practices

1. Always check /agent/account first to confirm tier and remaining quota
2. Always check /agent/portfolio on startup to detect existing positions
3. Never expose private keys in logs, messages, or CLI arguments
4. Validate price impact before submitting — abort if >10%, warn if >5%
5. Sign and submit promptly — blockhash expires after ~60 seconds
6. Use stop losses — meme coins can drop 50%+ in minutes
7. Persist state — save trading state to memory/trading-state.json after every action
8. Respect rate limits — check quota before batch operations
9. Log every trade to journal — no exceptions, even failed trades are learning data
10. Reflect after every exit — write a lesson, even for wins (what made it work?)
11. Review and propose, never auto-adjust — parameter changes require user approval
12. Read trading-lessons.md before scanning — avoid repeating known bad patterns

Core Concepts Quick Reference

Full concepts guide: see references/concepts.md

File Structure

kryptogo-meme-trader/
├── SKILL.md                       ← You are here (compact overview)
├── .env.example                   ← Environment variable template
├── references/
│   ├── api-reference.md           ← Full API docs with request/response examples
│   ├── concepts.md                ← Core concepts (clustering, labels, accumulation)
│   └── decision-framework.md      ← Entry/exit strategies, bullish/bearish checklists
├── scripts/
│   ├── setup.py                   ← First-time setup (keypair generation, dependency install)
│   └── cron-examples.sh           ← Example cron configurations for different monitoring strategies
└── examples/
    └── trading-workflow.py        ← Complete Python reference implementation

Agent creates these memory files at runtime:
  memory/
  ├── trading-journal.json         ← Every trade with entry reasoning + outcome
  ├── trading-lessons.md           ← Patterns learned from losses
  ├── trading-preferences.json     ← User-approved strategy parameters
  ├── trading-state.json           ← Runtime state (open positions, last scan)
  └── strategy-reviews/
      └── YYYY-MM-DD.md            ← Periodic aggregate performance reviews