Skip to main content

AI (Artificial Intelligence)

Neurai's DePIN infrastructure enables direct integration between AI systems and IoT devices through encrypted messaging. This creates autonomous networks where AI services can monitor equipment, make decisions, and coordinate operations without relying on centralized cloud platforms.

AI Integration via MCP and DePIN Messaging​

The MCP (Model Context Protocol) worker in Neurai's DePIN node acts as a bridge between AI services and IoT devices. When enabled, the node polls its message pool for commands, sends them to an AI server, and posts responses back through the same encrypted messaging channel.

How MCP Mode Works​

The MCP worker is an optional background process that runs alongside the DePIN messaging system. Here's the basic flow:

  1. Message Polling: The worker checks the DePIN message pool every few seconds (configurable with -depinmcpinterval)
  2. Command Filtering: It looks for messages that match a specific prefix (default: /ai, set with -depinmcpkey)
  3. AI Processing: Matching messages get sent to an MCP-compatible AI server (Claude, ChatGPT, DeepSeek, or local models)
  4. Response Delivery: The AI's response gets encrypted and posted back to the DePIN network

This architecture means IoT devices can interact with AI services through the same secure, token-gated messaging system they already use for peer-to-peer communication.

Configuration​

Enable MCP mode on your DePIN node:

# Basic DePIN messaging
depinmsg=1
depinmsgtoken=FACTORY_MONITOR
depinmsgport=19002
assetindex=1
pubkeyindex=1

# MCP AI integration
depinmcp=1
depinmcpinterval=5
depinmcpkey=/ai

The node needs to hold the configured token (FACTORY_MONITOR in this example) and will only process messages from other token holders. This creates a private AI network where access is controlled through asset ownership rather than API keys or authentication servers.

Security Model​

DePIN messaging uses ECIES encryption with AES-256-GCM, which means:

  • Each message is encrypted specifically for its recipients using their public keys
  • The DePIN node operator can only decrypt messages addressed to their own node
  • Token ownership is verified through the blockchain before messages are accepted
  • Message signatures prevent tampering and impersonation
  • No central server can read the AI queries or responses

This is different from typical cloud AI services where queries pass through centralized infrastructure. With DePIN, the communication happens directly between nodes, and the blockchain only verifies token ownership.

Practical Example: Factory Equipment Monitoring​

Let's look at a concrete implementation. A manufacturing facility has temperature and vibration sensors on critical equipment. Instead of sending data to a cloud service, the sensors communicate with a local AI through DePIN messaging.

Sensor Device (ESP32):

#include <DepinESP32.h>

DepinESP32 depin;

void setup() {
    // Connect to local DePIN node
    depin.begin("192.168.1.100", 19002, "FACTORY_MONITOR", "your-mnemonic-here");
}

void loop() {
    float temp = readTemperature();
    float vibration = readVibration();

    // Sensor readings exceed normal range
    if (temp > 85.0 || vibration > 0.5) {
        String message = "/ai Equipment alert: Temp=" + String(temp) +
                        "C, Vibration=" + String(vibration) + "g. Recommend action?";

        depin.sendMessage(message, "NXaiNodeAddress...");
    }

    delay(60000); // Check every minute
}

AI Node Response:

The MCP worker receives the sensor data, forwards it to the AI service, and gets back an analysis:

AI Response: Temperature and vibration levels indicate bearing wear.
Recommend: Schedule maintenance within 48 hours. Reduce operating
speed by 20% until inspection.

This response gets encrypted and sent back through DePIN messaging to the sensor device (and potentially to a maintenance coordination system). The entire conversation happens over the encrypted message channel, with no external services involved.

Why This Matters:

  • The factory's operational data never leaves the local network
  • AI analysis happens in near real-time (limited only by network latency, not cloud round-trips)
  • The system keeps working even if internet connectivity is lost (with a local AI model)
  • Access control is enforced through token ownership rather than managing API credentials

The key insight is that AI doesn't need to be centralized. By connecting AI services through DePIN messaging, you can build autonomous systems that make decisions locally while still benefiting from the coordination and verification capabilities of a blockchain.

AI Resource Rental Through Asset-Based Access​

The DePIN messaging system's token-gating mechanism creates a natural marketplace for AI compute resources. Instead of traditional API billing, users acquire tokens to access AI services, and the blockchain handles verification automatically.

How Token-Gated AI Access Works​

When you configure a DePIN node with -depinmsgtoken=AI_COMPUTE, the node only accepts messages from addresses that hold that token. This simple mechanism enables a complete payment system:

  1. Service Provider: Runs a DePIN node with an AI service (GPU, specialized model, etc.)
  2. Token Creation: Creates an asset representing compute credits
  3. User Payment: Users purchase tokens to gain access
  4. Automatic Verification: The blockchain confirms token ownership before processing queries
  5. No Payment Processing: No credit cards, no invoices, no payment processors

Compute-Resource-Based Pricing​

Traditional AI APIs charge per query or per token (in the LLM sense). With Neurai assets, you can implement more flexible pricing models based on actual resource consumption:

GPU Time: Tokens represent hours of GPU access

  • 1 AI_GPU_CREDIT = 1 hour of GPU time
  • User holds 10 tokens = 10 hours of compute available

Inference Count: Tokens as pre-paid inference credits

  • 1 AI_INFERENCE = 100 queries
  • Heavy queries (vision models, large context) = 10 credits
  • Simple queries (classification, small models) = 1 credit

Memory/Bandwidth: Tokens for high-memory or data-intensive tasks

  • 1 AI_VRAM_HOUR = 1 hour access to high-memory GPU
  • Priced higher than compute-only tokens

The key advantage is transparency. Token holdings are visible on the blockchain, so users know exactly what they're paying for and how many credits remain.

Setting Up a Token-Gated AI Service​

Step 1: Create the Access Token

# Create root asset for the AI service
neurai-cli issue "AI_GPU_ACCESS" 1000 "" "" 8 false true

# Cost: 1000 XNA to create
# Supply: 1000 units (divisible to 8 decimals)
# Reissuable: true (can mint more if needed)

Step 2: Configure the DePIN Node

depinmsg=1
depinmsgtoken=AI_GPU_ACCESS
depinmcp=1
depinmcpinterval=3

# Optional: limit message size for cost control
depinmsgsize=4096
depinmsgmaxusers=1

Step 3: Distribute Tokens

# Sell 10 GPU hours to a customer
neurai-cli transfer "AI_GPU_ACCESS" 10 "NXcustomerAddress..."

# They can now send up to 10 hours worth of queries
# (Implementation would track usage and reject after quota)

Privacy in Paid AI Services​

One interesting property of this system: the AI provider can verify payment without knowing which specific user sent which query.

Here's why:

  • Messages are encrypted per-recipient using ECIES
  • The provider's node verifies that the sender owns the required token
  • The provider can read the query content (since it's addressed to them)
  • But they can't link payment history to specific queries without additional correlation

This is different from traditional API services where payment information and query logs are inherently linked in the provider's database.

For stronger privacy, users can:

  • Use different addresses for purchases vs queries
  • Transfer tokens through intermediate addresses
  • Mix tokens with other users before using them

For accountability, providers can:

  • Require token burns for permanent resource consumption
  • Implement rate limiting per address
  • Log query hashes (not content) for dispute resolution

Example: Decentralized GPU Marketplace​

Imagine a network of independent GPU operators offering compute services:

Operator A: Runs 4x NVIDIA A100 GPUs

  • Creates GPU_A_COMPUTE token (1000 units)
  • Prices: 5 XNA per token, 1 token = 1 GPU-hour
  • Configures node with this token requirement

Operator B: Runs specialized vision models on H100 GPUs

  • Creates GPU_B_VISION token (500 units)
  • Prices: 12 XNA per token, 1 token = 30 minutes H100 time
  • Optimized for image/video processing workloads

User Workflow:

  1. User checks token prices and operator reputation (on-chain transaction history)
  2. Purchases appropriate tokens: neurai-cli sendtoaddress "NXoperatorA..." 50 (buys compute credits)
  3. Operator sends tokens: neurai-cli transfer "GPU_A_COMPUTE" 10 "NXuser..."
  4. User configures their application to send queries via DePIN messaging
  5. Usage is automatically throttled based on token holdings

No Intermediaries:

  • No marketplace platform taking fees
  • No payment processor charging percentages
  • No escrow service holding funds
  • Direct peer-to-peer transaction verified by the blockchain

The blockchain provides the trust layer (proving token ownership), while DePIN messaging provides the communication layer (encrypted queries and responses). You get a complete marketplace infrastructure with just these two components.

Implementation Considerations​

Rate Limiting: The MCP worker can track usage per address and reject queries once quota is exhausted. This could be implemented as:

  • Message counter: Track queries per address per time period
  • Token burn verification: Require users to burn tokens for each query
  • Time-based access: Check token holdings at query time, expect balance to decrease over time

Quality of Service: Different token types can provide different service levels:

  • AI_BASIC: Shared GPU access, longer queues
  • AI_PRIORITY: Dedicated resources, faster response
  • AI_EXCLUSIVE: Reserved capacity, guaranteed availability

Refunds and Disputes: Since tokens are regular Neurai assets:

  • Users can resell unused credits to others
  • Providers can buy back tokens as a refund mechanism
  • Smart contracts (if/when implemented) could automate refund logic

This model transforms AI compute from a service (requiring ongoing subscriptions and payment processing) into a commodity (traded like any other blockchain asset).

Distributed AI Networks Through DePIN Messaging​

Multiple AI systems can collaborate through DePIN messaging without centralized coordination. Each AI node specializes in different tasks, and they communicate through encrypted messages to solve complex problems that would be difficult for a single system.

Why Distribute AI Processing​

Centralized AI services have some inherent limitations:

  • Single point of failure: If the service goes down, all dependent systems stop working
  • Data aggregation: All queries and data pass through one provider
  • Latency: Round-trip to distant servers adds delay
  • Cost scaling: Pricing is controlled by a single vendor

Distributed AI networks address these issues by:

  • Specialization: Each node runs models optimized for specific tasks
  • Local processing: Data stays close to where it's generated
  • Fault tolerance: Multiple nodes can handle the same task type
  • Market-driven pricing: Competition between similar service providers

Multi-AI Architecture​

A distributed AI network typically includes several specialized node types:

Vision AI: Runs computer vision models (object detection, defect identification, OCR)

  • Hardware: GPU optimized for image processing
  • Models: YOLO, EfficientDet, or custom trained networks
  • Input: Camera feeds, sensor images
  • Output: Detected objects, classifications, bounding boxes

Time-Series AI: Analyzes sequential data (equipment sensors, production metrics)

  • Hardware: CPU with good memory bandwidth (transformer models) or edge TPUs
  • Models: Prophet, LSTM networks, statistical models
  • Input: Sensor streams, historical data
  • Output: Predictions, anomaly flags, trend analysis

Control AI: Makes operational decisions based on other AIs' outputs

  • Hardware: Lower compute requirements, needs fast message handling
  • Logic: Rules engine or reinforcement learning agent
  • Input: Aggregated data from other AIs
  • Output: Commands to actuators, parameter adjustments

Coordinator: Routes messages and manages workflow

  • Determines which AI should handle which task
  • Aggregates results from multiple specialists
  • Handles retry logic and failure recovery

These nodes communicate exclusively through DePIN messaging. No central server orchestrates them; coordination emerges from message passing.

Message Routing Patterns​

Direct Routing: Simple request-response between two AIs

Vision AI receives image → Processes → Sends result to Control AI

Broadcast: One AI sends data to all network participants

Coordinator broadcasts task → Multiple AIs process → Send results back

Pipeline: Sequential processing through multiple AI stages

Camera → Vision AI → Anomaly AI → Control AI → Equipment

Aggregation: Multiple AIs contribute to a consensus result

3 Vision AIs analyze same image → Coordinator aggregates → Final decision

Each pattern is implemented through DePIN messaging with appropriate token-gating to ensure only authorized AIs participate.

Collaborative Training: Federated Learning​

One powerful application is training models across multiple locations without centralizing data. Here's how it works with DePIN:

  1. Local Training: Each AI node trains on its local dataset
  2. Model Updates: Nodes share weight updates (not raw data) via DePIN messages
  3. Aggregation: A coordinator node averages the updates
  4. Distribution: Improved model gets sent back to all participants
  5. Iteration: Process repeats until convergence

Privacy advantage: Raw sensor data never leaves the local node. Only model parameters (which don't expose individual data points) get shared.

Practical example: Five factories want to improve their defect detection model.

  • Each factory has proprietary production data they can't share
  • Each trains a local vision model on their own defect images
  • They share model weight updates through DePIN messaging
  • The aggregated model performs better than any individual factory's model
  • No factory reveals their specific defects or processes

This is federated learning without requiring a trusted central server to coordinate.

Practical Example: Smart Factory Multi-AI System​

Let's design a complete system for a manufacturing facility with four specialized AI nodes working together.

System Architecture:

Factory Floor
│
├─ Vision AI Node (camera monitoring)
│  ├─ Runs YOLOv8 for defect detection
│  ├─ 12 cameras covering production line
│  └─ Sends alerts when defects detected
│
├─ Predictive Maintenance AI (sensor analysis)
│  ├─ Monitors temperature, vibration, power consumption
│  ├─ LSTM network trained on equipment failure patterns
│  └─ Predicts maintenance needs 24-48 hours ahead
│
├─ Production Optimization AI (process control)
│  ├─ Analyzes throughput, quality metrics, resource usage
│  ├─ Reinforcement learning agent
│  └─ Adjusts machine parameters for optimal output
│
└─ Coordinator AI (workflow management)
   ├─ Receives data from all other AIs
   ├─ Makes high-level decisions
   └─ Sends commands to equipment controllers

Configuration for Vision AI Node:

# Node identifier
depinmsgtoken=FACTORY_AI_VISION

# DePIN messaging
depinmsg=1
depinmsgport=19002
assetindex=1
pubkeyindex=1

# MCP for AI integration
depinmcp=1
depinmcpinterval=2
depinmcpkey=/vision

Configuration for Predictive Maintenance AI:

depinmsgtoken=FACTORY_AI_MAINT
depinmsg=1
depinmcp=1
depinmcpkey=/predict

Configuration for Coordinator:

depinmsgtoken=FACTORY_AI_COORD
depinmsg=1
depinmcp=1
depinmcpkey=/coord

Each node holds all three tokens (VISION, MAINT, COORD), allowing them to send messages to each other. The tokens could be created as sub-assets under a root FACTORY_AI token for organizational clarity.

Message Flow Example:

  1. Defect Detection Event:
Vision AI detects defect → Sends message to Coordinator
Message: "/coord Defect detected on Line 3, Camera 7.
         Type: surface_scratch, Confidence: 94%"
  1. Coordinator Analysis:
Coordinator checks recent maintenance predictions
Queries Maintenance AI: "/predict Status check Line 3?"
Maintenance AI responds: "Line 3 motor bearings at 78% wear estimate"
  1. Decision and Action:
Coordinator determines: Defects likely caused by bearing wear
Sends to Optimization AI: "/optimize Reduce Line 3 speed by 15%"
Sends to Maintenance: "/predict Schedule bearing replacement Line 3"
Sends alert to human operators through factory dashboard

All of this happens through encrypted DePIN messages. No cloud service required. The system continues operating even if internet connectivity is lost, falling back to local decision-making.

Implementation with Real ML Frameworks​

Vision AI using TensorFlow:

import tensorflow as tf
from depinpy import DepinClient  # Hypothetical Python DePIN library

# Load trained model
model = tf.keras.models.load_model('defect_detector.h5')
depin = DepinClient('FACTORY_AI_VISION')

def process_camera_feed():
    while True:
        frame = capture_camera(camera_id=7)

        # Run inference
        prediction = model.predict(preprocess(frame))

        if prediction['defect_score'] > 0.9:
            # Send alert via DePIN
            message = f"/coord Defect detected: {prediction['defect_type']}, " \
                     f"Confidence: {prediction['defect_score']:.2%}"

            depin.send_message(message, recipient="NXcoordAI...")

        time.sleep(1)  # Process at 1 FPS

Predictive Maintenance using Prophet:

from prophet import Prophet
import pandas as pd

class MaintenancePredictor:
    def __init__(self):
        self.depin = DepinClient('FACTORY_AI_MAINT')
        self.sensor_history = pd.DataFrame()

    def update_prediction(self, sensor_data):
        # Add new sensor readings
        self.sensor_history = pd.concat([
            self.sensor_history,
            pd.DataFrame([sensor_data])
        ])

        # Train Prophet model on historical data
        model = Prophet()
        model.fit(self.sensor_history)

        # Forecast next 48 hours
        future = model.make_future_dataframe(periods=48, freq='H')
        forecast = model.predict(future)

        # Check if predicted values exceed failure threshold
        if forecast['yhat'].max() > FAILURE_THRESHOLD:
            hours_until_failure = self.estimate_failure_time(forecast)

            self.depin.send_message(
                f"/coord Predicted failure in {hours_until_failure}h",
                recipient="NXcoordAI..."
            )

Performance Considerations​

Message Size Limits: DePIN messages are limited by default to around 10KB encrypted. This means:

  • Don't send raw images through messages (use IPFS and send the hash)
  • Model updates need to be compressed or sent incrementally
  • Large datasets require different strategies (local training, federated learning)
  • Need to configure more size in config file.

Latency: Message delivery is fast (< 100ms on local networks) but not instant:

  • Vision processing: 50-200ms per frame
  • Message round-trip: 10-100ms
  • AI inference: 10-1000ms depending on model
  • Total latency: 100-1500ms for a complete detect-analyze-respond cycle

This is acceptable for most industrial processes but wouldn't work for high-frequency trading or real-time collision avoidance.

Scaling: Each AI node operates independently:

  • Add more Vision AI nodes to cover more cameras
  • Run multiple Maintenance AI nodes for different equipment types
  • Geographic distribution: Factory in Germany + Factory in Vietnam share learnings
  • No central bottleneck; throughput scales linearly with nodes

Fault Tolerance: If one AI node goes offline:

  • Other nodes continue operating (no single point of failure)
  • Coordinator can route tasks to backup nodes
  • System degrades gracefully (fewer cameras monitored, less frequent predictions)
  • When node returns, it catches up by querying recent messages

Comparison with Centralized AI​

Centralized approach (typical cloud AI service):

  • All data sent to cloud provider
  • Single model serves all customers
  • Vendor controls pricing and features
  • Requires constant internet connectivity
  • Data privacy depends on trusting the provider

Distributed DePIN approach:

  • Data processed locally, only insights shared
  • Each node can run customized models
  • Market-driven pricing through token competition
  • Works offline with local models
  • Cryptographic verification of access, no trust required

The tradeoff is complexity. Running distributed AI requires:

  • Setting up multiple nodes with different models
  • Designing message protocols for coordination
  • Managing token distribution for access control
  • Monitoring system health across nodes

But for applications where data privacy, low latency, or operational independence matter, the distributed approach provides capabilities that centralized services can't match.

Building AI-Powered DePIN Applications​

The three patterns covered above—MCP integration, resource rental, and distributed networks—can be combined in various ways depending on your needs:

Simple IoT + AI: Single MCP node with local AI analyzing sensor data

  • Best for: Small deployments, prototyping, offline operation
  • Example: Smart home with local AI assistant

AI Marketplace: Multiple independent AI providers with token-gated access

  • Best for: Monetizing AI services, accessing specialized models
  • Example: Decentralized GPU rental network

Multi-AI Coordination: Specialized AIs working together through DePIN messaging

  • Best for: Complex industrial systems, federated learning
  • Example: Smart factory, distributed research network

All of these share common infrastructure (DePIN messaging, token-gating, encrypted communication) but differ in how they orchestrate AI capabilities.

The key insight is that blockchain provides more than just a payment layer. By combining asset ownership verification with encrypted messaging, you get a complete coordination infrastructure for autonomous AI systems. No central platform required.