Investor Due Diligence

Due Diligence Knowledge Base

The ten questions a sophisticated investor asks, answered with the platform's real architecture, verified data, and honest limitations β€” not marketing.

01

What is it?

A distributed AI compute routing layer that intelligently dispatches inference requests across local device GPUs, a peer mesh of contributed nodes, and cloud providers β€” choosing the cheapest capable route for every request.

MeshInfer.AI is an inference routing platform. When a developer sends an LLM or model inference request through the API, the Coordinator evaluates device capabilities, privacy constraints, latency tolerance, and cost preference β€” then routes the request to the cheapest execution target that can satisfy it:

RouteWhere it runsCostLatency
LocalOn the caller's own device via WebGPU / NNAPI~$0Lowest (no network)
MeshA peer-contributed node with the model loaded in VRAM~$0 (DIU-settled)Low–Medium
CloudA hosted inference provider (OpenAI, Anthropic, etc.)Full retail priceMedium–High

The platform is not a model host β€” it is a routing and settlement layer that sits between the application and whatever compute happens to be available and cheapest. It is part of a broader ecosystem (DOSFI) that includes social inference, credit scoring, streaming, navigation, and trading β€” all built on the same mesh-native routing fabric.

02

Why does anyone need it?

Cloud inference is expensive and getting more so. Most devices already have capable GPUs sitting idle. The gap between what people pay cloud providers and what their own hardware could do is the opportunity.

The economics of LLM inference are structurally inverted. A consumer GPU that cost $500 can run a 1B–3B parameter model locally at near-zero marginal cost, yet developers routinely pay cloud providers $0.15–$15 per million tokens for the same output. The waste compounds:

  • Cloud providers charge for idle capacity the customer already owns.
  • Latency-sensitive applications pay a network round-trip tax they don't need.
  • Privacy-sensitive workloads (PHI, financial data) are forced to cloud for lack of a trusted local path.
  • There is no marketplace where idle consumer GPUs can be productively monetized.
The core insight
Every phone, laptop, and desktop with a modern GPU is a potential inference node. MeshInfer.AI makes that capacity discoverable, routable, and economically settled β€” turning idle silicon into a usable compute fabric.
03

How does it make money?

SaaS subscriptions for the routing platform, margin on cloud fallback traffic, and a settlement fee on DIU (Vital) earned by mesh node contributors.

Revenue streamMechanismStatus
Platform subscriptionsDeveloper ($499/mo), Startup ($1,050/mo), Growth ($2,499/mo), Enterprise ($10,000/mo) β€” tiered by request volume and featuresLive (Stripe)
Cloud fallback marginWhen no mesh node is available, requests fall back to cloud providers; the platform captures the spread between wholesale and retail pricingArchitectural
DIU settlement feeA small percentage of Vital (DIU) earned by node contributors for executing inference is retained as a settlement feeArchitectural
Enterprise contractsCustom routing policies, on-premise coordinators, SLA guarantees, and dedicated node poolsSales-led

The subscription tiers gate access to the routing API, dashboard analytics, and advanced features (A/B testing, canary deployments, custom routing policies). Usage overages are metered and billed through Stripe. The mesh economy (DIU) creates a secondary flywheel: contributors earn for providing capacity, the platform takes a settlement cut, and end-users get cheaper inference.

04

Why can't someone else build it?

The moat is not any single algorithm β€” it is the integration of capability-based routing, a privacy-tiered execution model, post-quantum identity, a working settlement economy, and a live, audited node fleet.

The components are individually replicable. The integration is not. Specifically:

LayerWhat competitors would needWhy it's hard
Routing engineCapability-based dispatch that checks models_available, heartbeat freshness, and privacy tier per-requestRequires a live node registry with honest capability signaling β€” not a static config
Privacy fabricA three-tier model (local_only / mesh_ok / cloud_ok) enforced at the routing layer, not bolted onMost platforms route first and ask about privacy later, if at all
Identity & trustHardware-backed keypairs (TPM/Secure Enclave) + post-quantum signatures (ML-DSA-65, ML-KEM-768) on every dispatchPQC is deployed and runtime-verified; most competitors haven't started
Settlement economyA working DIU ledger with tier-based multipliers, earning categories, and payout flowRequires the full entity model, not a token contract
Node fleetReal GPU-equipped devices with active heartbeats and loaded modelsA chicken-and-egg problem: nodes join when there's traffic; traffic comes when there are nodes
Honest assessment
Each layer is independently buildable by a well-funded team in 6–18 months. The compound moat is the time to integrate all five, get them audited, and bootstrap a live fleet. That integration is what exists today.
05

How is the economy funded?

The DIU (Distributed Intelligence Unit, "Vital") economy is funded by the value it replaces β€” cloud inference spend that is avoided when a request routes to local or mesh execution.

DIU is not a pre-mined token or an ICO instrument. It is an internal accounting unit that represents compute contributed to or consumed from the mesh. The funding loop:

  1. A developer pays a subscription + usage fees in USD (via Stripe).
  2. A request routes to a mesh node instead of cloud, avoiding ~$X of cloud cost.
  3. The node operator earns DIU proportional to the compute provided (tokens, latency, reliability).
  4. The developer pays less than cloud retail; the platform retains a settlement fee; the node operator accumulates DIU.
  5. DIU can be settled to USD via the payout system (PayoutRequest β†’ processPayout).
Terminology
DIU is consistently described as a "Distributed Intelligence Unit," not a cryptocurrency. It is an internal metering and settlement instrument, not a tradeable speculative asset.

Earning categories are structured across five dimensions: participation (telemetry, uptime), inference (executing requests), coverage (regional density), service (routing, coordination), and governance (identity verification, compliance). Each category has tier-based multipliers (Bronze β†’ Diamond) that scale rewards with sustained contribution.

06

How is risk managed?

Five risk vectors are addressed structurally: execution failure (honest fallback), node dishonesty (PoI attestation + reputation), privacy exposure (tiered routing), quantum threat (PQC signatures), and economic manipulation (tier-gated multipliers).

RiskMitigationEnforcement
Inference timeout / node failureTwo-stage deadline with honest cloud fallback β€” if no mesh node completes in time, the request goes to cloud and is logged as a fallback, not relabeled as meshRoutingLog.route_decision + fallback tracking
Node dishonesty (fake results)Proof-of-Inference attestation: deterministic seeds, SHA-256 commitment hashes, re-computation verification, reputation decay on mismatch, quarantine after repeated failurespqcPoIAttestation + Node.reputation
Privacy leakageThree-tier privacy model (local_only / mesh_ok / cloud_ok) enforced at routing time; PHI workloads are local-first by policyMeshPolicy.privacy_rules + per-entity privacy_tier
Quantum computing threatHybrid Ed25519 + ML-DSA-65 signatures on every dispatch; ML-KEM-768 for node identity and TLS key exchangepqcSigning, pqcNodeIdentity, pqcTLS β€” all runtime-verified
Economic gaming (Sybil, wash earning)Hardware-backed identity, tier-gated multipliers, reputation-weighted dispatch, and audit logging on every earning eventDcrProfile + ZoneEarningTier + AuditLog
Known limitations
Sustained large-batch testing (30+ concurrent requests) hits the platform's 120s function timeout. Scaling benchmarks to 10–100 nodes requires provisioning real GPU hardware β€” simulated nodes are prohibited because they would falsify the mesh claim.
07

Who controls governance?

Governance is layered: the platform operator controls the Coordinator and routing policies; mesh policies are configurable per-deployment; the DOSFI identity fabric controls node and user identity; no single party controls the node fleet.

DomainControllerMechanism
Routing logic & CoordinatorPlatform operator (MeshInfer.AI)Code deployment + RoutingPolicy entities
Mesh policies (privacy, fairness, economics)Deployment adminMeshPolicy entities with enforcement_level: advisory β†’ enforced β†’ strict
Node identity & attestationDOSFI Identity FabricHardware-backed keypairs + PQC certificates (24h rotation)
Node fleet compositionIndividual contributorsVoluntary registration + heartbeat liveness; nodes leave when they stop heartbeating
Economic parameters (DIU rates, tiers)Platform operatorZoneEarningTier entities with defined multipliers and base rates
Dispute resolutionAudit trail + reputation systemAuditLog + Node.reputation decay; no on-chain governance theater

There is no DAO, no token voting, and no governance theater. Governance is operational: policies are entities, enforcement is code, and every decision is logged. The Unifying Theory (11 components) provides the architectural constitution that all ecosystem systems inherit.

08

Can it scale?

The routing layer scales horizontally by design. The constraint is not software β€” it is physical GPU hardware. Verified capacity today is 1 concurrent real node; the architecture supports N, but each node requires a real WebGPU-capable device.

The honest answer, backed by audited data:

Verified execution capacity model

audited 2026-07-22
1 node
Real concurrent WebGPU capacity

Maximum simultaneous real on-device inference executions observed. Only node_e7e7eb0e has ever executed real inference (latency_ms > 0).

17 nodes
Historical node registrations

17 nodes registered historically (3 online, 14 offline). 8 appear in task logs, but 7 of those are re-dispatch cancellations (latency_ms: 0) β€” not real inference.

90% mesh / 10% cloud
Single-node test result

10 sequential requests: 9 executed on-device via WebGPU, 1 cloud fallback when the node was occupied. 100% success rate, verified against persisted RoutingLog.

~1 req / 8.7s
Single-node throughput

GPU-bound, not router-bound. Avg latency 8,745ms across 10 requests. Router overhead is negligible; the floor is WebGPU cold-start + generation time.

Dispatch layer verified functional: capability-based routing (only nodes with the requested model in models_available are eligible), heartbeat freshness gating (60s staleness threshold), and honest cloud fallback (triggers when no capable node completes within the 2-stage deadline).

Scaling constraint β€” physical, not software: benchmarks at 10, 50, or 100 concurrent nodes cannot be generated without provisioning real GPU-equipped devices. Each node requires a browser tab with a WebGPU-capable GPU, the model loaded into VRAM, and an active heartbeat. Simulated nodes are prohibited β€” a simulated node does not execute inference; it would relabel cloud fallback as "mesh," falsifying the very claim being measured. Scaling to 10–100 nodes requires provisioning real hardware, not software changes.

The dispatch layer is verified functional: capability-based routing, heartbeat freshness gating, and honest cloud fallback all work. What does not exist yet is a fleet of physical GPU-equipped nodes at scale. Scaling from 1 to 100 nodes is a hardware provisioning problem, not a software problem β€” and the platform is honest about that rather than simulating nodes to inflate the numbers.

09

Why now?

Three forces converged in 2024–2026: WebGPU shipped in all major browsers, small open-weight models (1B–3B) became genuinely useful, and cloud inference costs remained stubbornly high. The routing layer is the missing connective tissue.

EnablerWhat changedWhy it matters now
WebGPU in browsersShipped stable in Chrome, Edge, Safari (2023–2024)Inference can run in a browser tab without native install β€” the mesh can be bootstrapped from existing devices
NNAPI on AndroidMature hardware acceleration APIMobile devices can contribute compute, not just consume it
Small open modelsLlama 3.2 1B/3B, Phi-3, Qwen2.5 β€” genuinely useful for many tasksModels small enough to load in consumer VRAM but capable enough to be worth routing
Cloud cost persistencePer-token pricing has not fallen proportionally to model efficiency gainsThe arbitrage gap between local and cloud is widening, not closing
Post-quantum standardsNIST FIPS 204 (ML-DSA) and FIPS 203 (ML-KEM) finalized (2024)PQC libraries are production-ready; deploying now future-proofs the identity layer
The window
Before WebGPU, local inference required native installs β€” too much friction for a mesh. After cloud prices normalize (if they do), the arbitrage closes. The window is now: browsers can run models, cloud is still expensive, and the routing layer to connect them is what MeshInfer.AI provides.
10

What evidence exists that it works?

Runtime-verified cryptography, audited routing logs, a live node fleet with real heartbeats, a working Stripe billing pipeline, and a transparent testing harness that anyone can run.

Cryptographic verification (runtime, not claimed)

The PQC layer has been verified in the live Deno runtime, not just in unit tests. The self-test actions execute full generate→sign→verify cycles and return FIPS 204 byte-size proofs:

ML-DSA-65 public key1952 bytes (FIPS 204 mandated)
ML-DSA-65 signature3309 bytes (FIPS 204 mandated)
Tampered message rejectionVerified βœ“
ML-KEM-768 encapsulationRuntime-verified βœ“
Library@noble/post-quantum v0.6.1 (audited)

Routing verification

The MeshProofHarness executes real inference requests and cross-verifies client-side results against persisted server-side RoutingLog entries. Last audited run (2026-07-22): 10 sequential requests, 90% mesh / 10% cloud fallback, 100% success rate, ~8.7s average latency (GPU-bound, not router-bound).

Live infrastructure

The platform runs on a live Stripe billing pipeline (4 products, live mode), a real node registry with active heartbeats, and a full entity model covering routing, tasks, telemetry, earnings, ledgers, and audit logs. Nothing is mocked or simulated in the production path.

What you can verify yourself

Bottom line
MeshInfer.AI is a working routing and settlement layer for distributed AI compute. The cryptography is real and runtime-verified. The billing is live. The routing is audited. The constraint on scale is physical hardware, not software β€” and the platform says so rather than simulating results. That honesty is itself part of the diligence answer.