How I Built an Offline-First CRDT Sync Engine in Nepal for $35K ARR
The Genesis: Building from Emerging Markets
My journey began by building Millimo from the ground up in Nepal — a laboratory for rigorous, capital-efficient product development. That $35K in early revenue and 50+ clients weren't built on venture capital; they were built on sheer necessity and ingenuity.
I grew up in Biratnagar, Nepal, where history is carved into stone and time is measured in generations. Now, as a founder in New York, I see a tech world that is 'Rich' in data but 'Poor' in integrity. Organizations increasingly rely on artificial intelligence for critical business decisions, but when AI generates fabricated data that enters financial reports, the damage cascades.
The ambition was global, and the challenge — Data Fragmentation and LLM Dependence — is global. That's why the move to the US (Millimo Inc.) was not just an administrative step. It was the strategic activation of our structural advantage.
I am not here to compete with the noise. I am here to be the signal. We are transitioning from building a revolutionary product to scaling a revolutionary business model.
The Architecture: Offline-First by Design
Cloud-only tools fail in markets with unreliable connectivity. Rather than treating emerging markets as an afterthought, I designed the entire offline-first architecture around their needs first — building solutions that are better precisely because they work under real-world constraints.
Thus, Millimo ONE was born. A secure, offline-first platform tailored for small and growing businesses. It helps manage inventory, track sales, generate invoices, and keeps data secure, all stored locally, not in the cloud.
The CRDT Merge Engine & GraphQL API
To achieve zero data loss during extended outages, we implemented Conflict-free Replicated Data Types (CRDTs). Every transaction is preserved and reconciled automatically when connectivity restores. To allow enterprise clients to query this distributed, verified data seamlessly, we exposed a strict GraphQL API layer over our sync engine.
The $12B Problem: AI Hallucinations
When AI generates fabricated data that enters financial reports, compliance filings, or operational dashboards — the damage cascades. The average AI-hallucination incident costs enterprises $4.2M in remediation. Without verification, hallucinated data compounds over time.
To solve this, we built MTITAN — the enterprise data integrity foundation. It eliminates AI hallucinations and enforces financial transparency at scale. It uses cryptographic SHA-256 Merkle proofs to verify data authenticity, operating with sub-12ms verification latency.
Following MTITAN, we realized that modern enterprises deploy dozens of AI agents across distributed systems. Without temporal ordering, these agents produce conflicting decisions. KAALASTRA was built to provide temporal AI coordination, assigning globally consistent temporal timestamps to every state change using Hybrid Logical Clocks (HLC).
The $12 Billion Blindspot: Architecting Sub-12ms Cryptographic Verification to Prevent AI Hallucinations
Enterprises are racing to integrate Large Language Models (LLMs) and autonomous agents into their financial, operational, and compliance pipelines. But they have introduced a fatal, $12 billion vulnerability: AI hallucinations.
When an LLM generates a fabricated revenue figure or invents a non-existent inventory SKU, that data enters the enterprise pipeline. If it lands in a quarterly report or a compliance filing, the damage compounds exponentially. The industry-standard approach relies on post-hoc statistical auditing—running batch jobs hours or days later to catch anomalies. By the time the hallucination is caught, the downstream models have already trained on corrupted data.
At Millimo Inc., I architected the MTITAN kernel to solve this. MTITAN is a proprietary data integrity kernel that acts as a proactive, cryptographic verification proxy. By utilizing SHA-256 Merkle proof chains and a multi-pass hallucination detection engine, MTITAN intercepts and blocks fabricated AI data in real-time—achieving deterministic verification in under 12ms.
The Latency Problem with Cryptographic Proofs
To guarantee data provenance, you need cryptographic proofs. The standard approach is a Merkle Tree—a hash tree where every leaf node is a hash of a data block, and every non-leaf node is a hash of its children. To verify a piece of data, you generate a "Merkle proof" (the path from the leaf to the root) and compare it against the known root hash.
The problem? Generating and verifying hashes for thousands of concurrent AI payloads across a massive enterprise database is computationally heavy. If you run a standard SHA-256 hash across an entire table to verify a single LLM output, your latency spikes to hundreds of milliseconds—unacceptable for real-time trading or high-velocity enterprise operations.
The Innovation: Delta-Merkle Proofs
To break the 12ms barrier, I engineered a "Delta-Merkle" verification system for the MTITAN kernel. Instead of re-hashing the entire dataset, MTITAN maintains an in-memory sparse Merkle tree. When an AI agent outputs a payload, MTITAN only computes the hash for the delta (the specific state change) and recalculates the path to the root.
By bypassing the need to re-hash the entire database and relying on an in-memory sparse tree, the cryptographic verification step takes roughly 1.2ms.
The Multi-Pass Hallucination Detection Engine
Cryptography alone doesn't know if an AI is lying; it only knows if data was tampered with after the fact. To proactively catch hallucinations before they are committed to the Merkle tree, I built a multi-pass detection engine that operates in parallel with the cryptographic check:
1. Statistical Anomaly Detection: Checks the AI payload against historical baselines.
2. Semantic Consistency Check: Uses a lightweight, localized embedding model to ensure the payload doesn't contradict the existing database state.
3. Severity Classification: Signals are classified as Info, Warning, or Critical.
Architecting the Truth: How CRDTs and Hybrid Logical Clocks Solve Distributed AI Synchronization
The modern enterprise is deploying dozens of autonomous AI agents across distributed systems. But we have introduced a fatal flaw: without strict temporal ordering, these AI agents produce conflicting decisions—double-spending inventory, generating contradictory financial recommendations, and creating irreconcilable state divergences that cascade into operational failures.
When a network partition occurs (which, in emerging markets and global cross-region setups, is a guarantee, not an exception), nodes diverge. When connectivity restores, traditional databases require heavy, latency-inducing consensus algorithms to reconcile the state.
At Millimo Inc., I architected the KAALASTRA protocol to solve this. By combining Conflict-free Replicated Data Types (CRDTs) with Hybrid Logical Clocks (HLCs), we achieve sub-50ms cross-region synchronization with zero unresolved conflicts.
The Problem with Traditional Consensus (Paxos/Raft)
Traditional distributed databases rely on consensus algorithms like Paxos or Raft. These algorithms require a majority quorum to agree on every state change before it is committed. While this ensures strict consistency, it introduces massive latency. For real-time, high-velocity AI systems, this latency is unacceptable.
The Solution: CRDTs (Conflict-Free Replicated Data Types)
To bypass the quorum bottleneck, I implemented a CRDT-based merge engine. A CRDT is a data structure that can be replicated across multiple nodes, updated independently and concurrently without coordination, and mathematically guaranteed to resolve conflicts deterministically.
We utilize three core CRDT types in KAALASTRA: G-Counters, OR-Sets, and LWW-Registers. Because CRDTs are mathematically commutative and associative, the order in which updates are applied does not matter. As long as every node eventually receives every update, the nodes will converge to the exact same state.
The Core Innovation: Hybrid Logical Clocks (HLC)
If Node A writes to a local SQLite database at 10:00:01.000, and Node B writes at 10:00:01.002, Node B should win. But what if Node A's clock is skewed? Physical clocks (NTP) are fundamentally unreliable for distributed ordering.
To solve this, I implemented a Hybrid Logical Clock (HLC). An HLC combines the best properties of physical time and logical time. The HLC generates a timestamp tuple: (physical_time, logical_counter).
When a node receives a remote update from another node, the receive function ensures the local HLC is pushed forward to remain greater than the remote HLC, preserving causality. This guarantees that every event in the entire distributed system has a globally unique, monotonically increasing timestamp, without ever relying on a centralized clock server.
Read Full Article on Dev.to ↗Let's Build the Future of Data Integrity
If you believe in backing global ambition, capital efficiency, and a founder who has already proven execution outside the spotlight, I am ready to talk about the final close.
Email Aditya Directly View LinkedIn Hub