The Decentralization Theater: How "Decentralized" Indexers Kept Centralization Intact
[2026-01-02] | Shinzō Team

You migrated off Infura. You deployed your subgraph to a "decentralized" indexing network. You told your users the whole stack is trustless now.
It isn't.
The Graph, Subsquid, SubQuery, and the rest of the "decentralized" indexing wave built marketplaces of centralized operators coordinated by token economics. The token layer handles incentives and payments. The actual indexing runs on the same infrastructure as the centralized providers you left behind. Same databases. Same trust assumptions. Different branding.
They decentralized the market. They didn't decentralize the indexing.
Developers deploying subgraphs and squids think they're building on trustless infrastructure. They're building on a network of centralized operators who happen to compete with each other. The gap between the marketing and the architecture is where your application's security assumptions fall apart.
What "Decentralized" Actually Means Here
Peel back the architecture of any major indexing protocol and you find the same pattern.
Subsquid runs what they call a "decentralized data lake." Worker nodes bond 100,000 SQD tokens to participate. The Squid SDK processes blockchain data into queryable formats. Strip the branding and it's the same stack you'd see at any centralized provider: cloud servers, standard databases, conventional DevOps. The token coordinates who participates. The actual data processing is indistinguishable from Alchemy.
The Graph and SubQuery follow the same playbook. Independent operators stake tokens to join a marketplace, run standard infrastructure, store data in PostgreSQL, and serve queries. The coordination layer has a token. The indexing doesn't have verification.
The Database Problem
SubQuery's infrastructure documentation spells out what "decentralized" indexing means at the technical level. Node operators need PostgreSQL for indexed data, state channel information, cost models, and indexing rules. Connection pooling. Query optimization. Index management. The same setup you'd use for any centralized service.
Every major indexing protocol stores data in PostgreSQL or equivalent systems. These databases were designed for centralized applications with controlled access. They provide no mechanism for cryptographic verification. They can't prove that returned data hasn't been modified, omitted, or fabricated.
Blockchain data comes with cryptographic guarantees at the source. Every transaction is signed. Every block is hashed. State roots provide Merkle proofs. The entire point is that you can verify without trusting.
Indexers take this verifiable data, strip the verification, and store it in databases that can't prove anything about their own contents. The cryptographic chain of trust ends at the operator's database. No amount of token economics changes what PostgreSQL is.
Economic Security Is Not Cryptographic Security
The pitch for decentralized indexers relies on economic security. Operators stake tokens. Misbehavior gets slashed. Rational actors won't risk their stake.
This conflates two different things.
Cryptographic security means you verify a claim through mathematical proof. The math works or it doesn't. You're not trusting anyone.
Economic security means you trust that incentives will produce honest behavior. Game theory, not cryptography. It assumes rational actors, perfect information, and enforcement mechanisms that actually work.
The Graph requires 100,000 GRT minimum stake with 2.5% slashing for incorrect data. Subsquid and SubQuery have similar requirements. The numbers vary. The problem doesn't: penalties get applied after detection, not verification at query time.
Economic security is probabilistic. Cryptographic security is deterministic. Staking requirements can grow forever. They'll never equal a proof.
When Detection Fails
Economic security assumes someone catches bad behavior. Look at how detection actually works.
Subsquid markets ZK proofs for data integrity. The documentation tells a different story: "Proof by Authority, Optimistic on-chain validation, and Zero-Knowledge proofs" are options, with validation logic that "may be dataset-specific." Query responses get signed by workers, but on-chain validation is opt-in. Most queries never touch a proof. The ZK branding is cover for a trust-based system.
SubQuery relies on reputation. Node operators compete on uptime metrics. Delegators signal trustworthy operators by staking with them. This is curation. Past performance doesn't prove current honesty. It doesn't prove anything about the query you just received.
The Graph uses fishermen who challenge indexers by depositing 10,000 GRT with evidence. Arbitrators review disputes across epochs. By the time anything resolves, your application already served the bad data to users. The dispute mechanism is forensic, not preventive.
Here's the economics of catching bad data: you need parallel infrastructure to compare results. The cost roughly equals the cost of being an operator. The reward is a fraction of a slashing penalty. Catching bad data costs more than ignoring it. So it gets ignored.
A developer ships an app trusting these systems. Bad data gets served. Users make decisions based on it. Transactions execute. Value moves. The dispute process might penalize someone weeks later. The developer is stuck explaining to users why their "decentralized" app fed them garbage.
The Governance Misdirection
SQD holders participate in Subsquid decisions. SQT holders shape SubQuery's direction. GRT holders vote on Graph protocol changes. The protocols tout community governance as a decentralization feature.
Governance controls fee structures, inflation rates, protocol upgrades. The mechanisms for coordinating a marketplace.
Governance doesn't control what operators do. Each worker or indexer runs independently. The protocol adjusts incentives. It can't verify outputs.
Blockchain consensus mathematically enforces rules on every block. Bad blocks get rejected, not punished after the fact. The verification is intrinsic to the system.
Indexing protocols inverted this. They decentralized the meta-layer while leaving actual data handling centralized at each node. Community governance over infrastructure that still requires trusting individual operators.
Cross-Chain Multiplies Everything
SubQuery supports nearly 300 chains. Subsquid claims over 200 networks. The Graph keeps expanding coverage. Multi-chain support is a headline feature.
Multi-chain support multiplies the problem.
Each chain requires separate infrastructure with separate failure modes. A SubQuery operator might run solid Polkadot indexing and neglected EVM nodes. Token stake is undifferentiated across all chains they claim to support. The economic security for their worst-supported chain is the same as their best.
An application pulling data from five chains trusts five separate sets of unverifiable database queries. Token economics can't distinguish accurate Arbitrum data from fabricated Solana data. More chains means more unverifiable sources under the same broken trust model.
What Actual Decentralization Requires
Trustless blockchain data access requires different foundations.
The database layer needs to retain cryptographic properties from source chains. Content-addressable storage ties data to its hash. Merkle structures enable proofs of inclusion. Query responses need evidence that allows independent verification, not signatures from operators you're trusting anyway.
Indexing needs to happen at authoritative sources. Validators already process every transaction. They're the most trustworthy source of blockchain data by definition. Embedding indexing in validator infrastructure eliminates reconstructing state through intermediaries.
Verification needs to be intrinsic. Cryptographic proofs at query time, not economic penalties after detection. Every response provably correct, not probably correct given incentive alignment.
Subsquid can't upgrade their data lake into this. SubQuery can't patch their node operator model into this. The Graph can't evolve Graph Node into this. The foundations assume trust. Everything built on top inherits that assumption.
Different Foundations
The current generation built on what was available. PostgreSQL was mature. Token coordination was proven. The stack shipped fast.
Shipping fast created path dependencies. Subsquid built around their Squid SDK and data lake. SubQuery built around node operators on conventional infrastructure. The Graph built around subgraphs in PostgreSQL. Ecosystems formed. Now you can't swap the foundation without rebuilding everything above it.
That's what we're doing at Shinzo. Not a better marketplace for indexing services. Not more sophisticated token economics on top of the same databases. Infrastructure where blockchain data stays verifiable from source to application. Where the read layer actually matches the guarantees of the chains it serves.
The "decentralized" indexers made centralized infrastructure more accessible. They didn't make it trustless. If your application needs actual verification, not verification theater, you need a stack that was built for it.
The next wave of blockchain applications will demand data infrastructure that meets blockchain standards. The question is whether you'll build on foundations designed for that future or keep trusting operators who pinky-swear they're running honest PostgreSQL instances.
What if indexing didn't require a pinky swear? We're building that.
X · Telegram · Discord · GitHub · shinzo.network