ChainGPT’s 10M Weekly Users: A Protocol-Level Autopsy

The data shows a single number: 10 million weekly active users on ChainGPT, a decentralized AI-agent protocol launched in late 2025. But numbers hide the ledger. The ledger remembers what the narrative forgets: how many of those users are interacting with on-chain verified inference, and how many are simply querying a centralized fallback server disguised as a smart contract? Reconstructing the protocol from first principles, I traced the user growth to a specific set of optimizations in the ZK-proof aggregation layer — optimizations that trade finality for throughput. Stability is not a feature; it is a discipline. The question is not whether 10M users are real, but whether the protocol’s architecture can sustain them without sacrificing the very guarantees that make it trustless. When I first read the announcement — "ChainGPT reaches 10M weekly active users, fastest-growing dApp in history" — I did not reach for a headline. I reached for the GitHub. I pulled the smart contract for the agent execution registry, the verifier contract for the zero-knowledge proofs, and the off-chain relayer node code. What I found was a system built on three layers: a user-facing frontend that caches results via a centralized API, an optimistic rollup that batches agent interactions every 30 minutes, and a base layer that finalizes the ZK proofs on Ethereum. The 10M number likely counts every query — even those served from cache — as a "user interaction." That is not unusual for consumer apps, but for a protocol that markets itself as "decentralized AI," it raises a mechanical question: how many of these interactions are actually verified on-chain? Let me reconstruct the protocol from first principles. ChainGPT’s core innovation is a "verifiable inference" circuit — a ZK-SNARK that proves an LLM output was generated by a specific model without revealing the input. The circuit is deployed on Ethereum as a verifier contract. For each inference, the agent creates a proof, submits it to a relayer, and the relayer posts the proof to the verifier. But here is the catch: the circuit can only handle ~10 proofs per block on Ethereum mainnet. With 10M weekly users, that is roughly 1.65 million proofs per day, or ~1,145 per minute — far exceeding Ethereum’s block space even with full L1 throughput. The protocol solves this by batching proofs into an optimistic rollup, where batches are committed every 30 minutes and challenged within a 7-day window. The user sees a result instantly from the cache; the proof settles later. Mechanically, the system works. But the security model shifts: the user now trusts the relayer to not equivocate on the cached result before the batch settles. This is a vestige of centralized infrastructure disguised as a Layer 2. In my 2024 work on the Ethereum Pectra upgrade, I encountered a similar trade-off in EIP-7702’s signature validation logic. A reentrancy vector existed when gas pricing conditions changed mid-block. The patched solution required a strict ordering of state writes. ChainGPT’s batching scheme has no such ordering guarantee. If a relayer node is compromised, it can serve a malicious inference result to a user, cache the proof for the correct result, and submit the wrong proof to the rollup. The 7-day challenge window exists, but it assumes that at least one honest challenger is monitoring every batch. With 10M users generating thousands of batches per day, the economic incentive to challenge a single batch is low — the cost of running a challenger node may exceed the expected reward from successful challenges. The protocol’s whitepaper acknowledges this but claims that "the social layer of the community will ensure challenges occur." Social layers do not commute with cryptographic proofs. Protecting the user means designing for the worst case, not the average. Now consider the commercialization angle. 10M weekly active users implies a monthly active user base of roughly 14-16M (using the standard 0.7 weekly-to-monthly ratio for utility apps). The protocol charges a fee per inference: 0.001 ETH per query, split between the relayer (70%), the stakers (20%), and the treasury (10%). At 10M weekly users with an average of 5 queries per session (a conservative estimate for an AI agent), that is 50M queries per week, or 200M per month. Monthly fee revenue: 200M * 0.001 = 200,000 ETH, or roughly $600M at current prices. That is an extraordinary number — larger than the entire DeFi fee market combined for many chains. But here is the hidden detail: the fee is only collected when the proof is submitted on-chain. If the user’s query is served from cache and never finalized (because the relayer batches infrequently or the user does not wait for finality), the fee is never paid. The protocol’s tokenomics whitepaper states that "fees are accrued at proof submission," but the relayer can choose to delay submission indefinitely for low-value queries. In practice, the relayer is centrally operated by the core team — the same team that built the protocol. This is not a trustless fee mechanism; it is a discretionary billing system. During the 2022 Terra collapse, I spent six weeks reverse-engineering the LUNA token’s algorithmic stabilization mechanism. I traced the recursive debt accumulation through smart contract calls and proved that the peg maintenance relied on infinite liquidity assumptions. ChainGPT’s fee model has a similar structural fragility: it assumes that the relayer will always act honestly because it is economically aligned with the protocol’s success. But economic alignment does not prevent a single point of failure. If the relayer goes offline or is compromised, the entire fee pipeline stops. The protocol has no fallback relayer network — no competitive market for relayers. The whitepaper promises "decentralized relayers in Phase 2," but the current codebase shows a single hardcoded address in the contract with no upgrade mechanism. The ledger remembers that promises are not implementations. The contrarian angle is this: the 10M user milestone is not a sign of strength for decentralized AI. It is a sign that users do not care about decentralization — they care about results. ChainGPT’s growth came primarily from its caching layer, which returns answers in under 200ms, far faster than any on-chain verification can achieve. The protocol’s developers knew this. They built the cache to be fast and the proof layer to be slow, knowing that most users would never wait for the proof to finalize. The "verifiable inference" feature is a marketing checkbox, not a user-facing differentiator. This is not unique to ChainGPT. Every "decentralized AI" project I have audited in the past two years — including the ZK-proof pilot I led in 2026 — faces the same trade-off: cryptographic verification is expensive, and users optimise for latency, not trust. The protocols that succeed will be those that separate the user experience from the verification schedule, but only if they also ensure that the verification schedule is enforced automatically, not left to a social layer. A deeper blind spot lies in the proof generation cost. Each inference requires a ZK-SNARK proof, which takes roughly 3 seconds to compute on a high-end GPU. For 50M queries per week, that is 150 million GPU-seconds per week, or nearly 1,700 GPU-days. The protocol claims to use a "distributed prover network" of stakers, but my code review of the prover contract reveals that the work is actually delegated to a single trusted prover node operated by the team. The stakers only verify the proofs after they are submitted. If that prover node is compromised, the attacker can generate proofs for arbitrary model outputs and submit them to the verifier. The stakers would check the proof, but the proof would be mathematically sound — the attacker only needs to control the model execution environment, which is centralized at the prover node. This is a textbook single-point-of-failure with a cryptographic wrapper. Where does this leave us? The 10M weekly user number is real, but the architecture behind it is a fragile hybrid of centralized performance and decentralized promises. I foresee one of two outcomes within the next 12 months: either the protocol ships a truly decentralized relayer and prover network with economic incentives that make honest behavior the dominant strategy, or a security incident — probably a relay equivocation or a prover compromise — will cause a cascade of invalid proofs that erodes user trust. The latter is more likely, because implementing decentralized relayers requires engineering changes that the team has already delayed twice. The ledger remembers what the roadmap forgets. Protecting the user means rejecting the narrative of growth for its own sake and asking the uncomfortable question: is the protocol built to survive a stress test, or is it built to hit a growth target before the stress test arrives?