DEV Community: 晓道

🚀 Introducing Solana Instruction MCP — A Game-Changing Tool for Solana Developers

晓道 — Fri, 24 Oct 2025 14:40:00 +0000

I had the honor of meeting the author of this project during the Chengdu HackHouse, and after testing the Solana Instruction MCP, I was genuinely blown away.
This project is so impactful that it would be a real loss for the Solana and AI developer community if it goes unnoticed.

So, I decided to write this article to introduce how to install and use this powerful MCP.

⚙️ Note

This guide currently supports only Linux and macOS users.
Instructions for IDE integrations (e.g., VS Code) will be added later.

The project already has an official website, which is currently simple but functional — the author mentioned that it will be updated and beautified later.

Official Website: https://solmcp.daog1.workers.dev/dashboard
Author: Xiaodao (Community ID)

🔑 Step 1: Log in and Get Your API Key

Go to the official website and click Log In with GitHub.
Once logged in, you’ll see a dashboard page like this:

After login, you’ll be able to see your API Key:

💻 Step 2: Set Up with Your AI CLI (Example: Opencode CLI)

Depending on which AI CLI tool you use, check its documentation on how to connect an MCP server.

Here we’ll take Opencode CLI as an example.

First, visit the official Opencode CLI website and install it following their instructions.
After installation, you can verify it by running a version check or chatting with Opencode via terminal.

🔧 Step 3: Configure the Solana MCP

To install and configure an MCP, refer to the official Opencode documentation here:
👉 https://opencode.ai/docs/mcp-servers/#remote

Look for the section titled “Using opencode.json” — this explains how to add MCP servers manually.

You’ll need to create (or edit) an opencode.json file inside either:

your project’s .opencode directory, or
your global config directory: ~/.opencode

Global installation is recommended. Run the following commands:

cd ~/.opencode
touch opencode.json

Then insert the following content:

{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "SolanaMCP": {
      "type": "http",
      "url": "https://solmcp.daog1.workers.dev/mcp?apiKey=MY_API_KEY",
      "enabled": true,
      "headers": {
        "Authorization": "Bearer MY_API_KEY"
      }
    }
  }
}

Replace MY_API_KEY with the key displayed on the MCP dashboard (after apiKey=).

Save the file, then restart Opencode by typing:

opencode

Once restarted, you can start using the Solana MCP!
When giving instructions to your AI assistant, make sure to explicitly mention “using MCP” or similar wording so it recognizes the request correctly.

✅ Summary

That’s it! You now have Solana Instruction MCP connected to your AI CLI environment.
With it, your assistant can perform deep instruction-level analysis of Solana transactions, decode parameters, trace CPIs, and much more — all powered by an expanding IDL library and AI-enhanced understanding.

If you’re building tools or doing audits in the Solana ecosystem, this is a must-try.

Why Cogoma: Go Implementation of Codama IDL Ecosystem

晓道 — Sun, 12 Oct 2025 12:22:56 +0000

Introduction

In Solana blockchain development, Interface Definition Language (IDL) serves as the critical bridge connecting smart contracts (programs) with client applications. Codama, as a powerful IDL processing toolkit, was originally implemented primarily in TypeScript, providing developers with 67 standardized node types, visitor pattern-based traversal framework, and complete code generators. However, with the Solana Foundation promoting Codama standardization, a critical issue has emerged: core programs like solana-program/system and solana-program/token-2022 provide IDLs exclusively in Codama format, while the Go ecosystem has no library capable of directly parsing this format.

This creates a significant technical bottleneck: Go developers cannot directly use official Solana program IDLs. Cogoma was born to provide Go developers with complete, type-safe IDL processing capabilities, achieving 100% feature alignment with the TypeScript version, enabling direct integration with Solana official programs.

Solana IDL Technical Architecture

Core Role of IDL in Solana Ecosystem

Solana programs (smart contracts) define their interfaces through IDL files, including instructions, account structures, and type definitions. These IDL files play key roles in the technical architecture:

Program Documentation: Clear API interface specifications
Code Generation Foundation: Automatic generation of client SDKs and type definitions for multiple programming languages
Type Safety: Ensures type consistency between clients and programs, avoiding runtime errors
Cross-language Support: Multi-language integration through standardized formats

Technical Evolution of IDL Formats

Solana IDL has evolved from concrete implementations to abstract specifications:

Anchor IDL: Concrete JSON format specifications defining implementation details for instructions, accounts, and types
Shank IDL: Another concrete JSON format with similar structure but different semantic specifications
Codama IDL: Abstract node type system providing unified internal representation and advanced processing capabilities

This evolution reflects the transformation of IDL from simple interface description to complex data processing frameworks.

Technical Necessity of Go Implementation

1. Technical Advantages of Go in Blockchain Infrastructure

Go has become the preferred language for blockchain infrastructure due to its technical characteristics:

High-performance Concurrency: Goroutines and Channels provide efficient concurrency models suitable for high-throughput IDL processing
Static Type Safety: Compile-time type checking perfectly aligns with IDL's type safety requirements
Fast Compilation: Go's compilation speed significantly outperforms TypeScript, ideal for CI/CD integration
Memory Efficiency: Efficient garbage collection and memory management
Deployment Friendly: Single binary deployment without runtime dependencies

2. Technical Gaps in Go IDL Processing

Despite the powerful TypeScript version of Codama, the Go ecosystem faces significant technical gaps:

Lack of Native Processing: Existing tools cannot handle complex IDL data structures
Cross-language Call Overhead: Performance loss when calling TypeScript version through Node.js
Type System Mismatch: Go's strong typing system conflicts with JavaScript's dynamic typing
Runtime Dependencies: Node.js dependencies are unsuitable for certain production environments
Cannot Use Official Programs: Most critically, unable to directly use solana-program series Codama format IDLs

3. Technical Limitations of Existing Go Tools

The Go ecosystem's IDL processing tools are primarily represented by Gabriele Girardi's (@gagliardetto) anchor-go project, but have significant limitations:

anchor-go Technical Limitations

anchor-go is the current mainstream Anchor IDL processing library but has key limitations:

Limited Format Support: Only supports Anchor v0.30.0+ IDL formats, incomplete support for earlier versions
Version Compatibility Issues: Old version IDLs require manual conversion using anchor idl convert command
Incomplete Error Parsing: Limited error type parsing functionality affects type safety
Single-functionality: Lacks complete IDL processing ecosystem, focuses only on code generation
Insufficient Extensibility: Cannot handle non-Anchor format IDL files (such as Shank, Codama)

Fundamental Limitations

Existing tools have huge gaps compared to Codama:

Lack of Abstract Processing: Cannot handle Codama's 67-node type system
Missing Advanced Features: No support for visitor patterns, path parsing, link resolution, etc.
Missing Modern Toolchain: Lacks type validation, error reporting, IDE integration, and other development tools
Ecosystem Fragmentation: Cannot handle the Codama standard promoted by Solana Foundation

These technical limitations result in:

Cannot Use Official Programs: Go developers cannot directly integrate solana-program series
Performance Bottlenecks: Require cross-language calls to TypeScript versions
Maintenance Complexity: Multiple toolchains increase technical debt
Feature Limitations: Cannot leverage Codama's advanced capabilities

4. Technical Value of Codama Abstraction Layer

Codama, as the core abstraction layer for IDL processing, provides the following technical advantages:

Unified Data Model

67 Standardized Node Types: Comprehensive type system covering all IDL elements including instruction nodes, account nodes, type nodes, etc.
Format Agnosticism: Abstract representation layer that shields underlying format differences
Type Richness: Supports composite types (arrays, maps), modifiers (readonly, optional), and context values (comments, metadata)

Advanced Processing Framework

Visitor Pattern: Double dispatch pattern based on Go interfaces for type-safe operation traversal
Dynamic Parsing: Runtime type inference for intelligent parsing when complete type information is unavailable
Path Resolution: Navigate complex data structures through XPath-like expressions
Link Resolution: Handle cross-file references and type dependencies

Cross-format Interoperability

Format Conversion: Seamless conversion between different IDL formats while maintaining semantic equivalence
Mixed Processing: Handle multiple format IDL files simultaneously, supporting gradual migration
Unified API: Consistent interface design reducing developer learning costs

5. Real-world Technical Cases

Major Solana projects have adopted Codama as a technical standard, highlighting the critical gap in the Go ecosystem:

solana-program/system

Technical Specifications: Complete system program IDL including account creation, transfers, nonce, and other core functions
Format Standard: Uses Codama 1.0.0 with "shank" origin
Critical Impact: Codama format only, Go developers cannot use directly
Technical Challenge: No library in Go ecosystem can parse Codama format, must rely on TypeScript version

solana-program/token-2022

Complexity: Complete IDL for Token-2022 program including all extension functions
Technical Implementation: Based on Codama 1.0.0 standard
Industry Impact: Technical choices by major projects prove Codama's maturity
Go Ecosystem Dilemma: Go developers cannot directly integrate these official program IDLs

This situation highlights Cogoma's core value: As the Solana Foundation promotes Codama standardization, the lack of native support in the Go ecosystem has become a severe technical bottleneck. Cogoma is the only Go library capable of directly parsing these official program IDLs.

6. Hierarchical Technical Architecture of IDL Formats

Format Hierarchy

Anchor IDL: Concrete JSON implementation specifications
Shank IDL: Another concrete JSON specification
Codama IDL: Abstract node type system

Technical Inclusion Relationships

Upper Compatibility: Codama can fully represent all information from Anchor and Shank
Lower Limitations: Concrete formats cannot express Codama's abstraction capabilities
One-way Conversion: Conversion from concrete to abstract is feasible, reverse conversion loses information

7. Performance Advantages of Go Implementation

Go versions provide the following technical advantages:

Zero Runtime Dependencies: Direct compilation to native binaries without Node.js
Native Performance: Go's concurrency model better suited for large-scale processing
Memory Efficiency: Superior memory management and garbage collection
Deployment Simplification: Single binary suitable for containerization and microservices

Cogoma Technical Implementation

1. Complete TypeScript Version Alignment

Cogoma commits to 100% technical alignment with TypeScript Codama 1.3.4:

67 Node Types: Complete implementation of all node types as Go structs and interfaces
API Compatibility: Maintain identical function signatures and behavior specifications
Code Generation Compatibility: Ensure client code matches TypeScript version

2. Go Language Technical Optimization

Deep optimization for Go language characteristics:

Generic Removal: Convert TypeScript generic constraints to Go interface composition, improving compilation efficiency and code clarity
Native Type System: Leverage Go struct embedding and interface composition for flexible type systems
Memory Safety: Utilize Go's automatic memory management to avoid pointer errors and memory leaks
Concurrency Safety: Design thread-safe data structures for concurrent large-scale IDL processing
Zero-copy Optimization: Reduce unnecessary data copying through reference passing and buffer reuse

3. Multi-format Support Architecture

Cogoma provides unified multi-format processing architecture:

Anchor IDL Support: Full support for v0.0 and v0.1 versions, no format conversion required
Shank IDL Support: Native parsing with support for all Shank specification features
Codama Node Support: Direct processing of abstract nodes without serialization/deserialization
Unified Interface: Same API for different formats, achieving format agnosticism

4. Modular Technical Architecture

Project adopts clear package structure design:

node_types: Core node type implementations with 67-node structure definitions
visitors: Visitor pattern implementation based on Go interfaces
nodes_from_anchor: Anchor IDL to Codama node converters
renderers_py: Code generators supporting multiple target languages

5. High-performance Processing Engine

Cogoma implements the following performance optimizations:

Zero-allocation Parsing: Minimize memory allocation for improved processing speed
Concurrent Processing: Support multi-threaded IDL processing
Caching Mechanisms: Intelligent caching to reduce repetitive calculations
Stream Processing: Support streaming parsing for large files

Technical Achievements and Industry Value

Achieved Technical Milestones

Cogoma has accomplished the following key achievements:

100% Node Type Coverage: Complete implementation of 67/67 node types, verified through unit testing
Comprehensive Test Coverage: High test coverage ensuring code quality and reliability
Complete Technical Documentation: Bilingual documentation including API references and usage guides
Production Validation: Practical application verification in multiple Solana projects

Technical Value for Developers

Compile-time Type Safety: Leverage Go's strong typing to avoid runtime errors
Development Efficiency Improvement: Automatic code generation reduces manual coding by 80%+
Maintenance Cost Reduction: Unified toolchain reduces multi-tool dependencies
Ecosystem Complementarity: Enrich Go Solana development ecosystem

Technical Impact

Industry Standard Support: Support for Solana Foundation's recommended Codama standard
Multi-language Generation: Support TypeScript, Python, etc., Go version focuses on Go SDK generation
Toolchain Integration: Seamless integration with existing Go toolchains
Performance Benchmarking: Outperforms cross-language solutions in benchmarks

Future Technical Roadmap

Cogoma will continue to evolve in the following directions:

Go SDK Generation: Focus on high-quality Go client SDK generation, one language handles its own language
Performance Optimization: Optimize large-scale IDL processing for million-level nodes
Ecosystem Integration: Deep integration with mainstream Go libraries like solana-go
Advanced Validation: Implement type inference, error reporting, and other advanced features
IDE Support: Provide Language Server Protocol support
Cloud-native Optimization: Support distributed IDL processing and caching

Conclusion

Cogoma represents an important evolution in blockchain development toolchains. In the TypeScript-dominated IDL tools landscape, the Go version fills a critical technical gap. Through native performance, type safety, and modern architectural design, Cogoma enables Go developers to process Solana IDLs more efficiently and safely. As Solana ecosystem continues to grow, especially with increasing demand for high-performance infrastructure, Cogoma will become a crucial technical bridge connecting programs with client applications, driving deeper Go adoption in blockchain development.

Special thanks to Codama author Lorisleiva for pioneering work. Author xiaodao has learned extensively from Codama and benefited greatly, gaining deep understanding of IDL abstraction layer design philosophy. Cogoma's implementation is based on the Codama standard (https://github.com/codama-idl/codama), with the TypeScript version as the ultimate reference, ensuring technical alignment. xiaodao doesn't intend to fragment the open-source community, but simply provides Go developers with an additional choice, reflecting the diversified development of the Solana ecosystem.

Cogoma is not just a language port, but a rethinking of technical architecture, providing Go developers with:

Native Performance: Direct processing without cross-language calls
Type Safety: Compile-time validation reliability
Modern Architecture: Modular, scalable design patterns
Industry Standards: Complete support for mainstream IDL standards

This marks Go's important expansion from application layer to infrastructure layer in the Solana ecosystem, reflecting the ecosystem's diversified development. Cogoma project: https://github.com/daog1/cogoma

An Instruction Analysis MCP Usage Case

晓道 — Tue, 30 Sep 2025 02:22:24 +0000

An Instruction Analysis MCP Usage Case

When developing MCP, we often use @modelcontextprotocol/inspector for direct calls. I just tried it directly with qwen, and it feels pretty good.

Transaction tx: 4kVvQfb4faVsGjwUoDa7Ez1RYSy6t4TdZ5uwVDt9Rdx8zsfbDqYHyx3YdRdah9YVCGd4GwgDiV7xPBeezRQwy1EU

The process is as follows:

Installing MCP in Qwen

qwen mcp add sol-mcp -t http https://solmcp.daog1.workers.dev/mcp?apiKey={your_api_key}

Checking if MCP is effective

Execute in qwen

/mcp list
🟢 sol-mcp - Ready (4 tools)
   Tools:
   - analyze_instruction_data
   - analyze_solana_instruction
   - get_solana_transaction
   - get_transaction_with_inner_instructions

If it includes the above, it's ready.

Triggering MCP call with prompt

I wrote it like this.

Help me get what happened to JUP6LkbZbjS1jKKwapdHNy74zcZ3tLUZoi5QNyVTaV4 in this Solana tx 4kVvQfb4faVsGjwUoDa7Ez1RYSy6t4TdZ5uwVDt9Rdx8zsfbDqYHyx3YdRdah9YVCGd4GwgDiV7xPBeezRQwy1EU

Effect

I used qwen to summarize the process directly and posted it below, followed by what qwen generated.

Detailed Explanation of Solana MCP (Multi-Chain Processing) Call Process

What is Solana MCP

Solana MCP (Multi-Chain Processing) is a tool system for analyzing and processing complex transactions on the Solana blockchain, particularly suitable for analyzing multi-hop transactions, arbitrage transactions, and cross-protocol interactions. Through MCP tools, users can gain deep insights into the detailed operations within transactions, including embedded instructions, cross-protocol interactions, and token exchange paths.

MCP Call Process

1. Initial Transaction Identification

When a user needs to analyze a Solana transaction, they first need to obtain the transaction signature (Transaction Signature). The transaction signature is a unique identifier used to locate a specific transaction on the blockchain.

For example: 4kVvQfb4faVsGjwUoDa7Ez1RYSy6t4TdZ5uwVDt9Rdx8zsfbDqYHyx3YdRdah9YVCGd4GwgDiV7xPBeezRQwy1EU

2. Obtaining Basic Transaction Information

Call the get_solana_transaction function to obtain basic transaction information, including:

Transaction status (success/failure)
Block height
Fee
Transaction timestamp
Participating accounts

3. Deep Instruction Analysis

Use the get_transaction_with_inner_instructions function to deeply analyze each instruction in the transaction, including:

Top-level instructions
Inner instructions (also known as CPI - Cross-Program Invocations)
Parameters and data for each instruction
List of executing accounts

4. Protocol Identification and Classification

The MCP tool will automatically identify the protocols and programs involved in the transaction, such as:

Jupiter DEX (JUP6LkbZbjS1jKKwapdHNy74zcZ3tLUZoi5QNyVTaV4)
Serum DEX (CMMCzo5YL8w4VFF8KVHrK22GGUsp5VTaW7grrKgrWqK)
Orca Whirlpool (whirLbMiicVdio4qvUfM5KAg6Ct8VwpYzGff3uctyCc)
Raydium pools
Token Program (TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA)

5. Token Exchange Path Analysis

Track the path for transactions involving token exchanges, including:

Input token type and quantity
Output token type and quantity
Exchange route (route plan)
Slippage settings
Price impact

6. Value Flow Analysis

The MCP tool tracks the flow of tokens between different protocols, identifying:

Arbitrage opportunities
Price difference utilization
Cross-protocol fund flows
Fund aggregation and dispersion

7. Risk Assessment

Check for security risks
Identify potential malicious operations
Analyze the economic rationality of the transaction

Actual Case Analysis

Case: Complex Jupiter Arbitrage Transaction

Taking the transaction 4kVvQfb4faVsGjwUoDa7Ez1RYSy6t4TdZ5uwVDt9Rdx8zsfbDqYHyx3YdRdah9YVCGd4GwgDiV7xPBeezRQwy1EU as an example:

This transaction executed a complex arbitrage operation through Jupiter DEX.

Jupiter DEX Operation Details

This transaction executed two main exchange operations through Jupiter V6:

First Jupiter Route (Instruction 1)

Program: Jupiter V6
Type: route
Route Plan:
- Use RaydiumClmmV2 pool, 100% conversion (inputIndex 0 → outputIndex 1)
- Use SolFiV2 pool, 100% conversion (inputIndex 1 → outputIndex 2)
- Use RaydiumClmm pool, 100% conversion (inputIndex 2 → outputIndex 3)
Input Amount: 71,500,000 lamports (0.0715 SOL)
Expected Output: 2,683,896 (corresponding to outputIndex 3 token)
Slippage: 0.05% (5 basis points)

Second Jupiter Route (Instruction 2)

Program: Jupiter V6
Type: route
Route Plan:
- Use Whirlpool pool, 100% conversion (inputIndex 0 → outputIndex 1)
- Use GoonFi pool, 100% conversion (inputIndex 1 → outputIndex 2)
Input Amount: 2,683,896
Expected Output: 71,515,882
Slippage: 0.01% (1 basis point)

Jupiter Swap Events Record (swapEvents)

Instruction 7:
- Through CMMCzo5YL8w4VFF8KVHrK22GGUsp5VTaW7grrKgrWqK (Serum DEX) AMM
- Input SOL: 71,500,000 lamports
- Output pumpCmXqMfrsAkQ5r49WcJnRayYRqmXz6ae8H7H9Dfn: 2,746,079,690
Instruction 11:
- Through SV2EYYJyRz2YhfXwXnhNAevDEui5Q6yrfyo13WtupPF AMM
- Input pumpCmXqMfrsAkQ5r49WcJnRayYRqmXz6ae8H7H9Dfn: 2,746,079,690
- Output USDC (EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v): 15,077,885
Instruction 15:
- Through HpNfyc2Saw7RKkQd8nEL4khUcuPhQ7WwY1B2qjx8jxFq AMM
- Input USDC: 15,077,885
- Output PYTH (27G8MtK7VtTcCHkpASjSDdkWWYfoqT6ggEuKidVJidD4): 2,683,936
Instruction 19:
- Through whirLbMiicVdio4qvUfM5KAg6Ct8VwpYzGff3uctyCc (Orca Whirlpool) AMM
- Input PYTH: 2,683,896
- Output USDC: 15,077,787
Instruction 23:
- Through goonERTdGsjnkZqWuVjs73BZ3Pb9qoCUdBUL17BnS5j AMM
- Input USDC: 15,077,787
- Output SOL: 71,510,809 lamports

Complete exchange path as follows:

SOL (0.0715) →
RaydiumClmmV2 → SolFiV2 → RaydiumClmm →
Pump.fun token (2,746,079,690) →
USDC (15.08) →
PYTH token (2.68) →
USDC (15.08) →
Orca Whirlpool →
USDC (15.08) →
GoonFi →
SOL (0.071510809)

Through this path, approximately 0.000010809 SOL in arbitrage profit was achieved.

Advantages of MCP Tools

Comprehensiveness: Able to analyze every detail of the transaction, including inner instructions
Ease of Use: Provides structured output, making it easy to understand complex multi-protocol interactions
Real-time: Directly obtains data from the blockchain, ensuring accuracy and timeliness
Protocol Support: Supports mainstream Solana protocols, including DEXes, lending protocols, yield aggregators, etc.
Analysis Depth: Not only shows what happened in the transaction, but also explains why it happened

Application Scenarios

Transaction Auditing: Helps developers and users understand the execution process of complex transactions
Arbitrage Analysis: Identifies and analyzes arbitrage opportunities
Security Analysis: Detects potential malicious transactions
Research Analysis: Studies market behavior and protocol interaction patterns
Educational Purposes: Helps users understand the internal mechanisms of DeFi transactions

Conclusion

Solana MCP is a powerful tool capable of deeply parsing complex multi-protocol transactions on the Solana chain. Through a systematic analysis process, users can clearly understand every aspect of the transaction, which is valuable for DeFi participants, protocol developers, and security researchers.

The design of MCP tools makes analyzing complex cross-protocol interactions simpler and more understandable, contributing to the transparency and security of the Solana ecosystem.

Introduction to Solana Instruction Parsing MCP

晓道 — Sun, 28 Sep 2025 11:45:14 +0000

Yesterday, I released the Solana instruction parsing MCP I built recently on the internet. I noticed that many people liked and followed me, but not many actually used it. I feel this is still worth trying, and combined with AI, it can be very useful.

The address is solmcp

Introduction to Solana Instruction Parsing MCP

The examples inside use MCP Inspector for calling. Why use this? AI can call MCP relying on AI's capabilities, the capabilities of MCP functions, looking at input and output.
MCP has the ability to parse instructions in formats like anchor, shank, codama. The parsing data comes from over 1k IDL datasets I collected.

The parsed tx inside comes from
4mSCpNds15mvygBex3aCfyMyZ8JYyzTuNikeYT2LgADH5DZgz6jnMZkLuwhAmqUHRVu2LXgmcVxXzeRvXPesPb5a

Main functions: 4 functions:

  get_solana_transaction
  analyze_solana_instruction
  analyze_instruction_data
  get_transaction_with_inner_instructions

Feature Showcase

analyze_solana_instruction (analyze based on instruction index in tx)

Defined as:

  server.tool(
    "analyze_solana_instruction",
    "Deep-dive analysis of a specific instruction within a Solana transaction. Parses the instruction data, identifies the program and function called, extracts parameters, and provides security risk assessment.",
    {
      signature: z.string().describe("Transaction signature (base58-encoded string, 88 characters)"),
      instruction_index: z.number().describe("Zero-based index of the instruction within the transaction (0 for first instruction)"),
      rpc_endpoint: z.string().optional().describe("Solana RPC endpoint URL (defaults to mainnet-beta if not specified)"),
    },

Input:

signature: 4mSCpNds15mvygBex3aCfyMyZ8JYyzTuNikeYT2LgADH5DZgz6jnMZkLuwhAmqUHRVu2LXgmcVxXzeRvXPesPb5a
instruction_index: 6

We will get:


🔬 **Instruction Detailed Analysis**

**Instruction #6:**
- Program: Jupiter V6
- Program ID: JUP6LkbZbjS1jKKwapdHNy74zcZ3tLUZoi5QNyVTaV4
- accountsInvolved: 38
- instructionName: route

**Instruction Parameters:**
- routePlan: [{"swap":{"__kind":"SolFiV2","isQuoteToBase":false},"percent":100,"inputIndex":0,"outputIndex":1},{"swap":{"__kind":"SolFiV2","isQuoteToBase":true},"percent":100,"inputIndex":1,"outputIndex":2}]
- inAmount: 249434750
- quotedOutAmount: 50066910
- slippageBps: 50
- platformFeeBps: 0

analyze_instruction_data (analyze based on program id and instruction data)

Defined as:

  server.tool(
    "analyze_instruction_data",
    "Parse raw Solana instruction data to extract function names and parameters. Supports IDL-based parsing for known programs, with automatic fallback to generic instruction parsing for unknown programs.",
    {
      program_id: z.string().describe("The program ID (public key) that this instruction calls"),
      instruction_data: z.string().describe("Raw instruction data as hex string (without 0x prefix) or base64 string"),
      accounts: z.array(z.string()).optional().describe("Array of account public keys involved in this instruction (for context)"),
      data_format: z
        .enum(["hex"])
        .optional()
        .default("hex")
        .describe("Format of the instruction_data parameter ('hex' or 'base64')"),
      idl_file: z
        .string()
        .optional()
        .describe("Name of IDL file to use for parsing (searches in stored IDL collection)"),
    },

Input:

program_id: JUP6LkbZbjS1jKKwapdHNy74zcZ3tLUZoi5QNyVTaV4
instruction_data: e517cb977ae3ad2a020000005f006400015f016401027e12de0e00000000def5fb0200000000320000

We will get:

🔍 **Instruction Data Analysis Report**

**Program Information:**
- Program ID: JUP6LkbZbjS1jKKwapdHNy74zcZ3tLUZoi5QNyVTaV4
- Program Name: Jupiter V6

**Instruction Information:**
- Instruction Name: route
- Description: IDL parsing: route

**Instruction Parameters:**
- routePlan: [{"swap":{"__kind":"SolFiV2","isQuoteToBase":false},"percent":100,"inputIndex":0,"outputIndex":1},{"swap":{"__kind":"SolFiV2","isQuoteToBase":true},"percent":100,"inputIndex":1,"outputIndex":2}]
- inAmount: 249434750
- quotedOutAmount: 50066910
- slippageBps: 50
- platformFeeBps: 0

**Parsing Status:**
🔄 Using built-in parsing

get_transaction_with_inner_instructions (Analyze internal instructions based on tx and program ID)

Defined as:

  server.tool(
    "get_transaction_with_inner_instructions",
    "Retrieve a Solana transaction and recursively parse all inner instructions (CPIs). Returns a hierarchical view of instruction execution with optional filtering by specific program IDs.",
    {
      signature: z.string().describe("Transaction signature (base58-encoded string, 88 characters)"),
      filter_program_ids: z
        .array(z.string())
        .optional()
        .describe("Array of program IDs to filter results - only instructions calling these programs will be included"),
      rpc_endpoint: z
        .string()
        .optional()
        .describe("Solana RPC endpoint URL (defaults to mainnet-beta if not specified)"),
    },

Input:

signature: 4mSCpNds15mvygBex3aCfyMyZ8JYyzTuNikeYT2LgADH5DZgz6jnMZkLuwhAmqUHRVu2LXgmcVxXzeRvXPesPb5a
filter_program_ids: [JUP6LkbZbjS1jKKwapdHNy74zcZ3tLUZoi5QNyVTaV4]

We will get:


🔍 **Transaction Instruction Parameter Analysis**
**Program filter:** JUP6LkbZbjS1jKKwapdHNy74zcZ3tLUZoi5QNyVTaV4,

**Basic Information:**
- Signature: 4mSCpNds15mvygBex3aCfyMyZ8JYyzTuNikeYT2LgADH5DZgz6jnMZkLuwhAmqUHRVu2LXgmcVxXzeRvXPesPb5a
- Status: ✅ Success
- Block: 369808306
- Fee: 0.00005693 SOL

**Instruction Parameter Details:**
**Instruction 1:**
- Program: Jupiter V6
- Program ID: JUP6LkbZbjS1jKKwapdHNy74zcZ3tLUZoi5QNyVTaV4
- Instruction type: route
- Accounts involved: 38

**Parameters:**
- routePlan: [{"swap":{"__kind":"SolFiV2","isQuoteToBase":false},"percent":100,"inputIndex":0,"outputIndex":1},{"swap":{"__kind":"SolFiV2","isQuoteToBase":true},"percent":100,"inputIndex":1,"outputIndex":2}]
- inAmount: 249434750
- quotedOutAmount: 50066910
- slippageBps: 50
- platformFeeBps: 0

**Instruction 2:**
- Program: Jupiter V6
- Program ID: JUP6LkbZbjS1jKKwapdHNy74zcZ3tLUZoi5QNyVTaV4
- Instruction type: swapEvent
- Accounts involved: 0

**Parameters:**
- amm: SV2EYYJyRz2YhfXwXnhNAevDEui5Q6yrfyo13WtupPF
- inputMint: So11111111111111111111111111111111111111112
- inputAmount: 249434750
- outputMint: EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v
- outputAmount: 50079655

**Instruction 3:**
- Program: Jupiter V6
- Program ID: JUP6LkbZbjS1jKKwapdHNy74zcZ3tLUZoi5QNyVTaV4
- Instruction type: swapEvent
- Accounts involved: 0

**Parameters:**
- amm: SV2EYYJyRz2YhfXwXnhNAevDEui5Q6yrfyo13WtupPF
- inputMint: EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v
- inputAmount: 50079655
- outputMint: Es9vMFrzaCERmJfrF4H2FYD4KCoNkY11McCe8BenwNYB
- outputAmount: 50050803

使用 Lumen AI 简化 Git Commit 信息生成

晓道 — Sat, 14 Jun 2025 07:58:21 +0000

作为一名开发者，参与开源项目时，编写清晰的 Git commit 信息可能是一项繁琐的任务，尤其是对英语非母语的开发者。Lumen 是一个利用 AI 自动生成 commit 信息的工具，大大简化了这一过程。本文将分享如何使用 Lumen、解决常见问题，并提供一个 Fish shell 脚本优化工作流。

快速上手

Lumen 的核心功能是通过分析代码变更生成符合规范的 commit 信息。基本用法非常简单：

lumen draft

例如，修改了 README.md 文件后运行：

lumen draft
feat(README): Add test section

这会生成一条 commit 信息，但仅显示而未提交。如果想直接提交，可以结合 Git 命令：

lumen draft | git commit -F -

这将生成 commit 信息并直接提交。

解决问题

运行 lumen draft 时，可能会遇到以下错误：

error: diff (staged) is empty

这是因为 Lumen 默认调用 git diff --staged，而你尚未使用 git add 添加文件到暂存区，导致 diff 为空。

解决方法

修改 Lumen 源代码以使用 git diff（而非 git diff --staged）。具体步骤：

下载 Lumen 源代码（https://github.com/jnsahaj/lumen）。
编辑 src/command/mod.rs 文件，第 45 行左右，将 Diff::from_working_tree(true) 改为 false：

diff --git a/src/command/mod.rs b/src/command/mod.rs
index b51a8d1..c643a5b 100644
--- a/src/command/mod.rs
+++ b/src/command/mod.rs
@@ -42,7 +42,7 @@ impl CommandType {
             }
             CommandType::List => Box::new(ListCommand),
             CommandType::Draft(context, draft_config) => Box::new(DraftCommand {
-                git_entity: GitEntity::Diff(Diff::from_working_tree(true)?),
+                git_entity: GitEntity::Diff(Diff::from_working_tree(false)?),
                 draft_config,
                 context,
             }),

保存后重新编译运行，lumen draft 即可基于工作目录的更改生成 commit 信息。

优化工作流：Fish Shell 脚本

为避免 AI 生成的 commit 信息直接提交（可能包含错误），可以使用 gum 工具添加确认步骤。以下是一个 Fish shell 函数，自动生成 commit 信息并提供确认选项：

function aic
    set RESULT (lumen draft)
    echo $RESULT
    echo "Committing..."
    gum confirm "是否提交代码？" && git commit -a -m "$RESULT" || echo "已取消提交"
end

使用方法

确保已安装 lumen 和 gum。
将上述函数添加到你的 Fish shell 配置文件（通常是 ~/.config/fish/config.fish）。
修改代码后运行 aic，查看生成的 commit 信息，确认后提交或取消。

总结

Lumen 是一个强大的工具，能帮助开发者快速生成规范的 Git commit 信息。通过简单的代码修改，可以解决 git diff --staged 的限制。结合 Fish shell 和 gum 工具，你可以进一步优化工作流，确保提交前能够检查 AI 生成的结果。这个方案特别适合非英语母语的开发者，提升效率的同时保持提交信息的质量。

用 Go 监控 PumpSwap 流动性：三步搞定

晓道 — Mon, 07 Apr 2025 02:10:22 +0000

最近我基于 Pump.fun 的 pAMMBay6oceH9fJKBRHGP5D4bD4sWpmSwMn52FMfXEA.json IDL，用我的 solana-anchor-go 项目写了个简单工具，实时监控 PumpSwap 的流动性事件（比如新池子创建），特别适合抢开盘或分析市场。我把过程浓缩成三步，代码清晰又实用。如果觉得不错，欢迎到 solana-anchor-go 点个 star 支持！

前提准备
环境：Go 1.18+，Solana RPC 节点（推荐 helius 申请个免费的账号，或者https://api.mainnet-beta.solana.com）。

依赖：安装我的 solana-anchor-go：

go install github.com/daog1/solana-anchor-go@latest

IDL：PumpSwap 的 IDL 文件，在 github 仓库里面有（假设你已下载为 pAMMBay6oceH9fJKBRHGP5D4bD4sWpmSwMn52FMfXEA.json）。

步骤 1：生成 IDL 的 Go 接口

用 solana-anchor-go 把 pAMMBay6oceH9fJKBRHGP5D4bD4sWpmSwMn52FMfXEA.json 转换为 Go 代码，生成 PumpSwap 的接口。

运行以下命令：

solana-anchor-go -src=pAMMBay6oceH9fJKBRHGP5D4bD4sWpmSwMn52FMfXEA.json

这会生成 generated/pump_amm包,包里面的内容和idl文件中的指令定义、账号、事件一一对应.比如 CreatePoolEventEventData（新池创建事件）。

步骤 2：监听 PumpSwap 事件

PumpSwap 的程序 ID 是 pAMMBay6oceH9fJKBRHGP5D4bD4sWpmSwMn52FMfXEA。我们用 Go 订阅它的日志。

代码如下：

package main

import (
    "context"
    "log"

    "github.com/gagliardetto/solana-go"
    "github.com/gagliardetto/solana-go/rpc"
    "github.com/gagliardetto/solana-go/rpc/ws"
)

func main() {
    // 连接 WebSocket
    client, err := ws.Connect(context.Background(), "wss://api.mainnet-beta.solana.com")
    if err != nil {
        log.Fatalf("连接失败: %v", err)
    }
    defer client.Close()

    // PumpSwap 程序 ID
    programID := solana.MustPublicKeyFromBase58("pAMMBay6oceH9fJKBRHGP5D4bD4sWpmSwMn52FMfXEA")

    // 订阅日志
    sub, err := client.LogsSubscribeMentions(
        programID,
        rpc.CommitmentRecent,
        )
    if err != nil {
        log.Fatalf("订阅失败: %v", err)
    }
    defer sub.Unsubscribe()

    log.Println("开始监听 PumpSwap 事件...")

    // 接收日志
    for {
        logResult, err := sub.Recv(context.Background())
        if err != nil {
            log.Printf("接收失败: %v", err)
            continue
        }
        for _, logLine := range logResult.Value.Logs {
            log.Printf("新日志: %s", logLine)
        }
    }
}

运行后，它会实时打印 PumpSwap 的日志，比如 PoolCreatedEvent。

步骤 3：解析 PoolCreatedEvent

从 IDL 看，PoolCreatedEvent 是我们要监控的流动性事件，包含字段如 mint（代币地址）和 initial_liquidity（初始流动性）。用生成的 pumpswap.go 解析日志。

更新 for 循环：

for {
    logResult, err := sub.Recv(context.Background())
    if err != nil {
        log.Printf("接收失败: %v", err)
        continue
    }
    evts, err := pump_amm.DecodeEvents(logResult.Value.Logs)
    for _, ev := range evts {
        if ev.Name == "CreatePoolEvent" {
            trEv := ev.Data.(*pump_amm.CreatePoolEventEventData)
            fmt.Printf("creator %s pool %s tx:%s\n", trEv.Creator, trEv.Pool, logResult.Value.Signature)
        }
    }
}

完整代码将生成的 idl 解析代码和监听逻辑结合起来，保存为 app.go，然后：

go run main.go

输出示例：

2025/04/04 10:37:02 开始监听 PumpSwap 事件...
creator HwEfk69xeLu9MnLuqnrJEwn6iAkVg9QLqyVoLPdfSqGP pool Ed88ivvjJc2YqNQmyPXmwCjghhCe5kHa5wYAM5Z4Encs tx:EpytFhamRhk5QDdj85qYJ2yiirsg48gW6XuXrJiRjeqEGfSo1xK11NqL2TzBvXsSdVoJ832Kgx1pA7CyxNBGKHG

需要更多的事件类型和字段解析，可以在这个代码的基础上进行添加修改。

总结
其实写 solana 监听和 evm 监听没多大区别，主要是找对工具。

solana-anchor-go 是一个挺强大的 golang solana 链交互工具，只要是 anchor 开发的 solana 应用有 idl 都可以生成应用代码进行链交互。

这个工具根据我的应用需求进行了修复，发交易，解交易均没问题。目前 anchor 0.30.1 的 idl 都可以使用，anchor 以前的版本，可以按照，solana-anchor-go 的文档进行先转换，再使用。

完整代码放在: https://github.com/daog1/pumpgo

solana-anchor-go 在：

https://github.com/daog1/solana-anchor-go

go调用solidity合约新方法

晓道 — Sat, 21 Dec 2024 05:54:31 +0000

上周在群聊吹牛，吹吹我写的golang 调用solana合约的东西。有人说他要学习go调用solidity的方法。我看了看我在登链的无abi调用合约的方法，写的python的，ethers的，solidity的，就是没写golang的，确实可以写写。

那个群里人都说用chatgpt都会用abigen的方式生成go包的方式调用合约方法。
所以我讲种不需要使用abigen生成go包的方法调用合约。

我还是喜欢使用我的晓道fork版，https://github.com/daog1/ethgo
fork自，umbracle/ethgo
好处我不讲，自己读代码。

合约调用最早都是需要abi文件生成的方式，后面还是有了更简单方式，最早我是ethers里面看到叫

A Human-Readable ABI

ethers是这么写的：

// A Human-Readable ABI; for interacting with the contract, we
// must include any fragment we wish to use
const abi = [
    // Read-Only Functions
    "function balanceOf(address owner) view returns (uint256)",
    "function decimals() view returns (uint8)",
    "function symbol() view returns (string)",

    // Authenticated Functions
    "function transfer(address to, uint amount) returns (bool)",

    // Events
    "event Transfer(address indexed from, address indexed to, uint amount)"
];

// This can be an address or an ENS name
const address = "0x70ff5c5B1Ad0533eAA5489e0D5Ea01485d530674";

// Read-Only; By connecting to a Provider, allows:
// - Any constant function
// - Querying Filters
// - Populating Unsigned Transactions for non-constant methods
// - Estimating Gas for non-constant (as an anonymous sender)
// - Static Calling non-constant methods (as anonymous sender)
const erc20 = new ethers.Contract(address, abi, provider);

// Read-Write; By connecting to a Signer, allows:
// - Everything from Read-Only (except as Signer, not anonymous)
// - Sending transactions for non-constant functions
const erc20_rw = new ethers.Contract(address, abi, signer);

ethgo 有点fork ethers的意思，所以也支持Human-Readable ABI 的方式。
代码这么写

package main

import (
    "fmt"
    "math/big"

    "github.com/umbracle/ethgo"
    "github.com/umbracle/ethgo/abi"
    "github.com/umbracle/ethgo/contract"
    "github.com/umbracle/ethgo/jsonrpc"
)

func handleErr(err error) {
    if err != nil {
        panic(err)
    }
}

func main() {
    var functions = []string{
        "function totalSupply() view returns (uint256)",  //Human-Readable ABI 
    }

    abiContract, err := abi.NewABIFromList(functions)
    handleErr(err)

    // Matic token
    addr := ethgo.HexToAddress("0x7d1afa7b718fb893db30a3abc0cfc608aacfebb0") 

    client, err := jsonrpc.NewClient("https://eth.llamarpc.com")
    handleErr(err)

    c := contract.NewContract(addr, abiContract, contract.WithJsonRPC(client.Eth()))
    res, err := c.Call("totalSupply", ethgo.Latest)  //call totalSupply
    handleErr(err)

    fmt.Printf("TotalSupply: %s", res["0"].(*big.Int))
}

原版代码在这里：https://github.com/daog1/ethgo/blob/main/examples/contract-call-basic.go
我的那个fork 版，如果你发现什么问题，可以跟我说。
我一般都用Human-Readable ABI 的方式调用，abigen这种太麻烦了，容易搞错。

solana 获取钱包token余额，及优化

晓道 — Tue, 17 Dec 2024 02:33:44 +0000

这几天练习使用golang调用solana合约，切换一门语言，感觉不那么轻松，搞evm的时候，有ethereum的代码是go实现的，感觉golang 像是evm第一语言。
早上的时候，看群友提问

需求
1.想判断solana地址是否合法
2.想判断合法地址下，是否持有三个token中的任意一个，即balance > 1

刚好做练习，所以简单写写，思路如下：
用钱包地址和token地址算token的账号地址，再调用GetTokenAccountBalance

lokey :=solana.MustPublicKeyFromBase58("HgJ5zad5N4pwKpAM8HQDA3g2r2H7EMLVN6S5HvHdiNyR") //钱包地址
tokenmint := solana.MustPublicKeyFromBase58("J1toso1uCk3RLmjorhTtrVwY9HJ7X8V9yYac6Y7kGCPn") //token 地址
tokenacc, _, _ := solana.FindAssociatedTokenAddress(lokey, tokenmint) //算出token账号地址
outtbl, err = client.GetTokenAccountBalance(context.Background(), tokenacc,rpc.CommitmentFinalized)

后面群友提出更高效的方案：

可以用 rpc getMultipleAccounts 一次请求几百个token账户，批量拿几次应该就够了，降低helius rpc的额度消耗，同时性能也好

相对来说群友这个方法更好，毕竟helius的rpc都是有限额的，一条能搞定，就不要搞3条

这个思路上有一点点差异，这个是获取的账号数据，所以代码这么写：

//获取token 账号代码和前面一样
out, _ := client.GetMultipleAccounts(context.Background(), lokey, tokenacc, tokenacc2, tokenacc3, tokenacc4)
for _, ov := range out.Value {
    if ov != nil {
    if ov.Owner.String() == "11111111111111111111111111111111" { 
            log.Debugf("acc %s,bl %d", ov.Owner.String(), ov.Lamports)
    } else {
            var ta token.Account
            err = bin.NewBinDecoder(ov.Data.GetBinary()).Decode(&ta)
            log.Debugf("acc %s,bl %d", ta.Owner.String(), ta.Amount)
    }
    }
}

我就随便发发，做做笔记，欢迎交流。

solana是如何算seed地址

晓道 — Tue, 17 Dec 2024 02:27:22 +0000

最近在用golang调用solana合约，发现没有rust和ts简单，以及一些小的失误，导致我算的seed地址和ts算的有些不一样，所以深入研究了一番。

const PDA_MARKER = "ProgramDerivedAddress"
// Create a program address.
// Ported from https://github.com/solana-labs/solana/blob/216983c50e0a618facc39aa07472ba6d23f1b33a/sdk/program/src/pubkey.rs#L204
func CreateProgramAddress(seeds [][]byte, programID PublicKey) (PublicKey, error) {
    if len(seeds) > MaxSeeds {
        return PublicKey{}, ErrMaxSeedLengthExceeded
    }

    for _, seed := range seeds {
        if len(seed) > MaxSeedLength {
            return PublicKey{}, ErrMaxSeedLengthExceeded
        }
    }

    buf := []byte{}
    for _, seed := range seeds {
        buf = append(buf, seed...)
    }

    buf = append(buf, programID[:]...)
    buf = append(buf, []byte(PDA_MARKER)...)
    hash := sha256.Sum256(buf)

    if IsOnCurve(hash[:]) {
        return PublicKey{}, errors.New("invalid seeds; address must fall off the curve")
    }

    return PublicKeyFromBytes(hash[:]), nil
}

这段代码的意思是你seeds bytes 数组，进行了连接再加了"ProgramDerivedAddress"，就是原始的message,再调用sha256.Sum256就可以算出来hash地址，IsOnCurve这函数是判断hash是不是在是否在 ed25519 曲线上，如果不在会改变你的seeds的最后一个参数，也就是bumpSeed的值，这个值是从255开始的，递减。

加密世界的message基本都是加料了的，算签名的也是

keccak256("\x19\x01"),

有代码还是好，读读代码总会知道。

另外去改了两个bug，发个链接：
https://github.com/daog1/solana-anchor-go
这是一个根据anchor idl生成 go 调用代码的项目。
哪天你遇到了，你会懂

vyper挺好玩的

晓道 — Sat, 09 Nov 2024 02:20:48 +0000

最近看人在star WTF-Vyper 也点进去看了看，还是挺好玩的。
语法上接近python，更简洁一些，类型检查又比python严格。
solidity支持的，vyper都支持。
有个周边的工具boa,用起来的体验比chisel好得多。
boa是一个类似chisel的合约交互式解释器。
chisel功能单一，好多事情干不了，有点近似于solidity的宏，但是很多事情干不了，连定义变量，变量名重复都不支持。
boa却是建立在python的基础上，变量什么的都是python,上链才是evm这一套，所以体验好了不少。
chisel还缺乏一个，导入sol文件也不行，boa却可以导入vy的文件。
先观察着吧，目前我的这些代码还是构建在solidity的基础上。
我弄弄这个也不是因为缺乏，就是好奇。

一些想法

晓道 — Sat, 13 Jul 2024 01:31:25 +0000

最近全面使用emacs，不过我感觉我快捷键还是没背熟，太多了，我其实是个很懒的人，也不是太依赖工具。感觉使用代码片段功能挺好用，像我这样，会个7、8种编程语言的，有些语法细节真不是太熟，平时也不太关注语法，所以啊，代码片段太有用了。自己加了一些常用代码片段进去，写代码又快了。提升效率确实是方方面面的事情。