You can deploy this model and start earning money today!

Views

No views yet

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:

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/<run>/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):

<start_function_call>call:FUNCTION_NAME{key1:val1, key2:val2}<end_function_call>

Example:

User: "Search for SOL on Solana" Model:

<start_function_call>call:SEARCH_TOKEN{symbol:"SOL", chain:"solana"}<end_function_call>

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:

Place Once at the Beginning: Put the developer prompt only once, at the very start of your conversation session
Do NOT place in user messages: Never include the developer prompt content in user/assistant messages or tool schemas
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": "<developer prompt goes here>"},
    {"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):\n<start_function_call>call:TOOL_NAME{\"key\":\"value\",\"amount\":1.23}</end_function_call>\nDo not output XML-style tags such as <function_calls>, <invoke>, or <parameter>.\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": "<user query goes here>"}
  ]
}

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):
<start_function_call>call:TOOL_NAME{\"key\":\"value\",\"amount\":1.23}</end_function_call>
Do not output XML-style tags such as <function_calls>, <invoke>, or <parameter>.

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.