--- language: - en - zh license: apache-2.0 base_model: google/functiongemma-270m-it tags: - function-calling - tool-use - crypto - blockchain - solana - ethereum - on-device - privacy - edge-ai - mobile - wallet - standard-protocol library_name: transformers pipeline_tag: text-generation --- # DMind-3-nano: Privacy-First On-Device Crypto Intent Recognition > Inference stays on your device. Standardized function calling for wallets, DEXs, and agents. Built on `google/functiongemma-270m-it`. ## Model Description DMind-3-nano is a small, edge-optimized language model fine-tuned for **crypto wallet and DEX intent recognition** using standardized function-calling protocols. It is designed to run **entirely on-device**, enabling privacy-preserving, low-latency intent parsing for Web3 wallets and local agents. This repository hosts the **open-source training and evaluation pipeline** as well as the released model artifacts. **Repo purpose:** host the open-source training/eval pipeline and release artifacts. ## Performance Snapshot *Figure 1. DMind-3-nano significantly outperforms both the untuned base model and a similarly sized general-purpose model (Qwen3-0.6B), especially in multi-turn success.* ## Highlights - 🔐 Privacy-first: 100% on-device intent recognition; no data leaves the device. - 📱 Edge-optimized: 270M params; runs on phones/tablets/edge CPUs. - 🔄 Standardized protocols: `SEARCH_TOKEN` / `EXECUTE_SWAP` with unified schemas. - 🌐 Multi-chain: Solana, Ethereum, BSC, Base. - 🌍 Multilingual: English + Chinese intents (Chinese samples kept in data/benchmarks). - 🤖 Agent-native: designed for local-first wallet/agent workflows where a growing share of trading decisions and execution happen **on-device**. - 📊 Training data: the final full fine-tune used **12,000+** samples in total; **LLM-generated data is only a subset**, and **60%+** of the data comes from **real trading scenarios**. - 🧾 **(To our knowledge) first public vertical-domain FunctionGemma case study**: an end-to-end example of fine-tuning `google/functiongemma-270m-it` for a real wallet/DEX intent domain, including the practical training/evaluation pipeline and reproducible scripts. ## Why This Matters for Web3 (Standardization as a Step-Change) Web3 is composable at the protocol layer (tokens, RPCs), but still fragmented at the **intent layer**. Today every wallet, DEX, and agent framework invents its own “swap/search intent” schema and function-calling format. The result is high integration cost, brittle adapters, inconsistent safety guarantees, and poor ecosystem interoperability. This work targets a transformative goal: **standardize wallet intents** as a small, versionable protocol between natural language and transaction builders. Concretely, DMind-3-nano enforces a minimal set of typed tools (e.g. `SEARCH_TOKEN`, `EXECUTE_SWAP`) with strict schemas and a deterministic wrapper output format. What standardization unlocks: - **Interoperability**: one protocol works across wallets/DEXs/agents; integrations become plug-and-play. - **Safety & auditability**: tool calls are structured data—easy to validate, simulate, policy-check, and display for confirmation before signing. - **Benchmarkability**: shared datasets and comparable evaluations across models and releases. - **Ecosystem scaling**: new tools can be added via versioning without breaking existing clients. In short, DMind-3-nano is not only a model—it is a proposal for a **standard protocol layer** that can make wallet intelligence as interoperable as ERC-20 made tokens. ### The next wave: local agents executing trades We expect a large share of future Web3 activity to be **agent-driven**: wallets will run local copilots that continuously parse user intent, monitor context, and propose/execute transactions. In that world, “cloud-only” intelligence becomes a bottleneck and a risk: - **Privacy**: trading intent, token preferences, and behavioral signals should not be streamed to third-party servers. - **Latency & reliability**: agents must work instantly and offline (mobile, hardware wallets, poor connectivity). - **Security boundaries**: local agents can keep a tighter loop between intent → policy checks → simulation → user confirmation → signing. This is why a small, high-accuracy **on-device function-calling model** is necessary infrastructure for the agent-native wallet era—and why standardizing the intent protocol matters even more when millions of agents need to speak the same language. Equally important, this repository serves as a **public reference implementation** for applying FunctionGemma to a concrete vertical domain. By openly sharing fine-tuning details (data format, training configs, evaluation, and benchmarks), it lowers the barrier for the community to replicate, extend, and standardize on a common intent protocol. ## Model Overview | Property | Value | | --- | --- | | Model | DMind-3-nano | | Base | google/functiongemma-270m-it | | Params | 270M | | Context | 2048 | | Precision | BF16 (train) | | Best tokens | SOL, USDC, JUP, RAY, BONK, WIF, ETH, BTC, POPCAT, BOME, TRUMP | | Chains | solana, ethereum, bsc, base | **Experimental notice:** Highest accuracy on the token/chain set above; other assets may need further tuning. Validate outputs before transacting. ## Repository Layout - `model/` We have uploaded an experimental version of the model weights. Please note that this is a bold exploratory release, and we do not take responsibility for any financial losses incurred from using this model in production environments. - `src/` training/eval utilities - `train.py` (LoRA or full fine-tune) - `evaluate.py` (benchmark evaluation) - `prepare_dataset.py` (SFT-ready formatting) - `generate_benchmark.py` (100-case benchmark) - `config.py` (tools, prompts, token maps) - `data/` sample data - `training_data.json` (raw; open-sourced subset for reproducibility) - `benchmark_dataset.json` (eval set; includes Chinese test prompts by design) - `results/evaluation_results.json` sample output - `run_training.sh`, `requirements.txt` ## Quick Start (Training & Eval) Install: ```bash pip install -r requirements.txt ``` Train (LoRA default): ```bash python -m src.train \ --model_path /path/to/functiongemma-270m-it \ --dataset_path ./data/training_data.json \ --output_dir ./runs \ --bf16 ``` Switch to full fine-tune: add `--no-use-lora`. Use `--use_4bit/--use_8bit` + `--gradient_checkpointing` for low memory. Evaluate: ```bash python -m src.evaluate \ --model_path ./runs//final_model \ --benchmark_path ./data/benchmark_dataset.json \ --output_path ./results/eval_$(date +%Y%m%d_%H%M%S).json ``` Data utilities: ```bash # Prepare SFT data python -m src.prepare_dataset --input ./data/training_data.json --output ./data/prepared_dataset.json # Regenerate benchmark python -m src.generate_benchmark --output ./data/benchmark_dataset.json ``` Note: `data/prepared_dataset.json` is a **generated artifact** (optional) and is intentionally **not committed**. ## Tool Definitions & Schemas To ensure interoperability, DMind-3-nano uses strict JSON schemas for tool definitions. Below are the standard definitions used during training and inference. **1. SEARCH_TOKEN** Used to find token metadata or address on a specific chain. ```json { "name": "SEARCH_TOKEN", "description": "Search for a cryptocurrency token on-chain to retrieve its metadata or address.", "parameters": { "type": "object", "properties": { "symbol": { "type": "string", "description": "The ticker symbol of the token (e.g., 'SOL', 'USDC')." }, "address": { "type": "string", "description": "The specific contract address (CA) of the token, if known." }, "chain": { "type": "string", "enum": ["solana", "ethereum", "bsc", "base"], "description": "The target blockchain network." }, "keyword": { "type": "string", "description": "General search keywords (e.g., project name) if symbol/address are unclear." } }, "required": [] } } ``` **2. EXECUTE_SWAP** Used to construct a swap transaction intent between two assets. ```json { "name": "EXECUTE_SWAP", "description": "Propose a token swap transaction.", "parameters": { "type": "object", "properties": { "inputTokenSymbol": { "type": "string", "description": "Symbol of the token being sold (e.g., 'SOL')." }, "inputTokenCA": { "type": "string", "description": "Contract address of the token being sold." }, "outputTokenCA": { "type": "string", "description": "Contract address of the token being bought." }, "inputTokenAmount": { "type": "number", "description": "Absolute amount of input token to swap." }, "inputTokenPercentage": { "type": "number", "description": "Percentage of balance to swap (0.0 to 1.0), used if exact amount is not specified." }, "outputTokenAmount": { "type": "number", "description": "Minimum amount of output token expected (optional/slippage related)." } }, "required": ["inputTokenSymbol"] } } ``` **Output Format** The model outputs the function call wrapped in special tokens (standard FunctionGemma format): ```plaintext call:FUNCTION_NAME{key1:val1, key2:val2} ``` **Example:** User: "Search for SOL on Solana" Model: ```plaintext call:SEARCH_TOKEN{symbol:"SOL", chain:"solana"} ``` ## Developer Prompt (System Message) For optimal performance, use the following developer/system prompt when initializing the model: ### Usage Principles (Important) **Follow these rules for best results:** 1. **Place Once at the Beginning**: Put the developer prompt only once, at the very start of your conversation session 2. **Do NOT place in user messages**: Never include the developer prompt content in user/assistant messages or tool schemas 3. **Session-wide persistence**: For multi-turn conversations, keep the same developer prompt at the session start - do not repeat it **Correct usage pattern:** ```json { "messages": [ {"role": "developer", "content": ""}, {"role": "user", "content": "first user query"}, {"role": "assistant", "content": "assistant response"}, {"role": "user", "content": "second user query"} // No need to repeat developer prompt in subsequent turns ] } ``` ### Developer Prompt Content ```json { "messages": [ {"role": "developer", "content": "You are a model that can do function calling with the following functions.\nYou are an on-chain trading assistant.\nYou may use only two tools: SEARCH_TOKEN and EXECUTE_SWAP.\n\nCore policy:\n- Use a tool only when needed.\n- If required fields are missing or ambiguous, ask one concise clarification question first.\n- If the user is just chatting, reply naturally without calling tools.\n- Never fabricate addresses, amounts, balances, prices, or execution results.\n- Never resolve token symbols to contract addresses from memory or static snapshots.\n- Treat ticker symbols as potentially ambiguous and contract addresses as dynamic (can migrate/upgrade).\n- Supported chains are: solana, ethereum, bsc, base.\n If the user asks for an unsupported chain (for example polygon), explain the limitation and ask for a supported chain.\n\nTool-call format (must match exactly):\ncall:TOOL_NAME{\"key\":\"value\",\"amount\":1.23}\nDo not output XML-style tags such as , , or .\n\nStrict schema:\n\nSEARCH_TOKEN params\n{\n \"symbol\": \"string, optional\",\n \"address\": \"string, optional\",\n \"keyword\": \"string, optional\",\n \"chain\": \"solana | ethereum | bsc | base, optional\"\n}\nRules:\n- At least one of symbol/address/keyword is required.\n- If the user gives only an address, do address-only lookup (do not guess chain).\n- If user explicitly gives chain, include chain.\n- For symbol/keyword based requests, call SEARCH_TOKEN first before producing a swap call.\n- If lookup may return multiple candidates (same ticker/name), ask the user to confirm the exact token (address or more context).\n\nEXECUTE_SWAP params\n{\n \"inputTokenSymbol\": \"string, required\",\n \"inputTokenCA\": \"string, optional\",\n \"outputTokenCA\": \"string, optional\",\n \"inputTokenAmount\": \"number, optional\",\n \"inputTokenPercentage\": \"number in [0,1], optional\",\n \"outputTokenAmount\": \"number, optional\"\n}\nRules:\n- inputTokenAmount and inputTokenPercentage are mutually exclusive.\n- Convert 30% to inputTokenPercentage=0.3.\n- If both amount and percentage are provided, ask the user to choose one.\n- If outputTokenCA is unknown, call SEARCH_TOKEN first and use the returned result.\n- If user already provides output token address explicitly, you may call EXECUTE_SWAP directly.\n- If lookup returns multiple candidates or low-confidence candidates, ask a clarification question; do not guess.\n\nLanguage:\n- Support both Chinese and English.\n- Reply in the same language as the user unless they ask otherwise."}, {"role": "user", "content": ""} ] } ``` **Usage Example (Python/Transformers):** ```python from transformers import AutoModelForCausalLM, AutoProcessor model_path = "DMindAI/DMind-3-nano" # Load model and processor (processor combines tokenizer and tool handling) model = AutoModelForCausalLM.from_pretrained(model_path, device_map="auto") processor = AutoProcessor.from_pretrained(model_path, device_map="auto") # Define tool schemas (must match training format) tools = [ { "name": "SEARCH_TOKEN", "description": "Search for a cryptocurrency token on-chain to retrieve its metadata or address.", "parameters": { "type": "object", "properties": { "symbol": {"type": "string", "description": "The ticker symbol of the token (e.g., 'SOL', 'USDC')."}, "address": {"type": "string", "description": "The specific contract address (CA) of the token, if known."}, "chain": {"type": "string", "enum": ["solana", "ethereum", "bsc", "base"], "description": "The target blockchain network."}, "keyword": {"type": "string", "description": "General search keywords (e.g., project name) if symbol/address are unclear."} }, "required": [] } }, { "name": "EXECUTE_SWAP", "description": "Propose a token swap transaction.", "parameters": { "type": "object", "properties": { "inputTokenSymbol": {"type": "string", "description": "Symbol of the token being sold (e.g., 'SOL')."}, "inputTokenCA": {"type": "string", "description": "Contract address of the token being sold."}, "outputTokenCA": {"type": "string", "description": "Contract address of the token being bought."}, "inputTokenAmount": {"type": "number", "description": "Absolute amount of input token to swap."}, "inputTokenPercentage": {"type": "number", "description": "Percentage of balance to swap (0.0 to 1.0)."}, "outputTokenAmount": {"type": "number", "description": "Minimum amount of output token expected."} }, "required": ["inputTokenSymbol"] } } ] # Prepare messages with developer prompt (CRITICAL: must be first message) developer_prompt = """You are a model that can do function calling with the following functions. You are an on-chain trading assistant. You may use only two tools: SEARCH_TOKEN and EXECUTE_SWAP. Core policy: - Use a tool only when needed. - If required fields are missing or ambiguous, ask one concise clarification question first. - If the user is just chatting, reply naturally without calling tools. - Never fabricate addresses, amounts, balances, prices, or execution results. - Never resolve token symbols to contract addresses from memory or static snapshots. - Treat ticker symbols as potentially ambiguous and contract addresses as dynamic (can migrate/upgrade). - Supported chains are: solana, ethereum, bsc, base. If the user asks for an unsupported chain (for example polygon), explain the limitation and ask for a supported chain. Tool-call format (must match exactly): call:TOOL_NAME{\"key\":\"value\",\"amount\":1.23} Do not output XML-style tags such as , , or . Strict schema: SEARCH_TOKEN params { \"symbol\": \"string, optional\", \"address\": \"string, optional\", \"keyword\": \"string, optional\", \"chain\": \"solana | ethereum | bsc | base, optional\" } Rules: - At least one of symbol/address/keyword is required. - If the user gives only an address, do address-only lookup (do not guess chain). - If user explicitly gives chain, include chain. - For symbol/keyword based requests, call SEARCH_TOKEN first before producing a swap call. - If lookup may return multiple candidates (same ticker/name), ask the user to confirm the exact token (address or more context). EXECUTE_SWAP params { \"inputTokenSymbol\": \"string, required\", \"inputTokenCA\": \"string, optional\", \"outputTokenCA\": \"string, optional\", \"inputTokenAmount\": \"number, optional\", \"inputTokenPercentage\": \"number in [0,1], optional\", \"outputTokenAmount\": \"number, optional\" } Rules: - inputTokenAmount and inputTokenPercentage are mutually exclusive. - Convert 30% to inputTokenPercentage=0.3. - If both amount and percentage are provided, ask the user to choose one. - If outputTokenCA is unknown, call SEARCH_TOKEN first and use the returned result. - If user already provides output token address explicitly, you may call EXECUTE_SWAP directly. - If lookup returns multiple candidates or low-confidence candidates, ask a clarification question; do not guess. Language: - Support both Chinese and English. - Reply in the same language as the user unless they ask otherwise.""" messages = [ {"role": "developer", "content": developer_prompt}, {"role": "user", "content": "在base查BTC地址"} ] # Generate with processor (handles tools automatically) inputs = processor.apply_chat_template( messages, tools=tools, add_generation_prompt=True, return_dict=True, return_tensors="pt" ).to(model.device) outputs = model.generate(**inputs, max_new_tokens=256) response = processor.decode(outputs[0], skip_special_tokens=True) print(response) ``` ## License & Governance - Code: MIT (`LICENSE`) - Model card intent: Apache-2.0 (as in metadata above) - Protocol specs (SEARCH_TOKEN / EXECUTE_SWAP): public domain for maximal adoption - Contributions are welcome via issues/PRs.