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.
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:
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.
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.
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.
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.
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:
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:
- A developer pays a subscription + usage fees in USD (via Stripe).
- A request routes to a mesh node instead of cloud, avoiding ~$X of cloud cost.
- The node operator earns DIU proportional to the compute provided (tokens, latency, reliability).
- The developer pays less than cloud retail; the platform retains a settlement fee; the node operator accumulates DIU.
- DIU can be settled to USD via the payout system (PayoutRequest β processPayout).
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.
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).
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.
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.
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-22Maximum simultaneous real on-device inference executions observed. Only node_e7e7eb0e has ever executed real inference (latency_ms > 0).
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.
10 sequential requests: 9 executed on-device via WebGPU, 1 cloud fallback when the node was occupied. 100% success rate, verified against persisted RoutingLog.
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.
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.
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 key | 1952 bytes (FIPS 204 mandated) |
| ML-DSA-65 signature | 3309 bytes (FIPS 204 mandated) |
| Tampered message rejection | Verified β |
| ML-KEM-768 encapsulation | Runtime-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
- Mesh Proof Harness β run live routing tests and inspect the logs
- PQC Monitor β inspect cryptographic event logs and signature verification
- Benchmarks β verified capacity data, not projections
- Unifying Theory β the 11-component architectural constitution
- Security Audit Report β enterprise-grade security documentation
