If you've read The Blockchain Illusion, you already know the uncomfortable truth: most of your "onchain" life is really you trusting somebody else's server. Alchemy, Infura, The Graph. These middlemen process blockchain data and serve it through APIs that applications trust without verification.

The result is a fundamental contradiction. Smart contracts eliminate trust in financial transactions, but applications trust API providers to accurately represent what's in those contracts. Private keys give users sovereign control of assets, but users need permission and payment to see what those assets are doing. "Trustless" has become marketing rather than technical reality.

Fixing this requires going back to first principles. What properties make blockchains trustless? How do we apply those same properties to the data layer?

What Trustless Data Access Actually Requires

Shinzo starts from first principles. Apply the same properties that make blockchains work to the layer that reads from blockchains.

Cryptographic verifiability. You can verify a blockchain transaction with cryptographic proofs. You should be able to verify indexed blockchain data the same way. Mathematical proof that data matches blockchain state, not trust.

Permissionless access. Anyone can submit transactions to a blockchain without applying for an API key. Anyone should be able to query blockchain data the same way. No authentication, no corporate approval, no tiered access based on how much you pay a middleman. The data lives on a permissionless system. Accessing it shouldn't require permission from a gatekeeper.

Censorship resistance. Blockchains resist transaction censorship through distributed validation. Data access should resist censorship through distributed serving. No single entity can filter what you see.

Sovereignty. You control your private keys and can submit transactions directly to the blockchain. You should be able to verify data directly from blockchain infrastructure without intermediaries.

These properties enable decentralization as an emergent outcome. When data access is cryptographically verifiable, permissionless, censorship-resistant, and sovereign, it naturally becomes decentralized because no central authority can satisfy these requirements.

This is the critical insight most projects miss. Decentralization isn't a goal. It's a consequence of getting the foundational properties right. Chase decentralization directly and you get distributed trust. Build for verifiability, permissionlessness, censorship resistance, and sovereignty, and decentralization follows.

The Validator Architecture

Here's the insight: validators should provide indexing as native infrastructure.

Validators already run full nodes. They already process every transaction. They already maintain complete blockchain state. The computational overhead to index data on top of what they're already doing is minimal.

When validators produce blocks, they also index the data. Applications query the network for blockchain data. The infrastructure securing the blockchain is the same infrastructure producing verifiable indexed data.

Applications don't select specific validators. The network routes queries to validators serving relevant data. Multiple validators can serve the same query. Natural redundancy. Cryptographic proofs verify correctness, eliminating trust.

If one validator is unavailable, applications query others seamlessly. If a validator serves incorrect data, cryptographic proofs reveal it. The system is resilient to individual failures or misbehavior by design, not by reputation or staking mechanisms.

The Technical Foundation

Three components work together to make this possible.

Lightweight indexer clients run alongside validator nodes, processing blockchain events with direct access to local state. No RPC overhead, no network latency to external services. The indexer hooks into the same execution context the validator uses for block production. When a block is finalized, the indexed representation is generated deterministically and signed. Multiple validators indexing the same chain produce identical content-addressed outputs that can be verified against each other.

The storage layer uses DefraDB, a peer-to-peer database built on Conflict-Free Replicated Data Types (CRDTs) and Merkle DAGs. Every piece of data is content-addressed and self-verifying. The key innovation is using recursive SNARKs for state verification. Traditional Merkle CRDT verification is O(n) where n is the length of the event history. Recursive proofs compress this to O(1). Months of indexing history verified with a single proof that fits in a few hundred bytes.

Data transformation happens through LensVM, a WebAssembly-based engine for bi-directional schema transformations. Think of it as database migrations that maintain cryptographic provenance. Developers write lens functions that reshape indexed data to match their application's schema while preserving verifiable links to source data. These lenses are themselves content-addressed and composable. A lens graph emerges organically as transformations build on each other, creating a shared library of reusable data views across the network.

These components combine into a pipeline with cryptographic proofs at every layer and no trust assumptions anywhere.

How This Actually Works

Query blockchain data and verify it cryptographically. Access it without permission. Route around censorship through distributed infrastructure.

You verify data correctness cryptographically, like you verify transactions. You access data without permission, like you submit transactions. You query blockchain state through distributed infrastructure that resists censorship, like transaction processing resists censorship.

Every piece of indexed data includes a cryptographic proof of its correctness. You can verify the data mathematically, not based on reputation or economic incentives. Multiple validators indexing the same data can be cross-verified automatically. If data is wrong, the proof fails. There's no "close enough" or "probably accurate."

The access model is truly permissionless. No API keys, no rate limits, no service agreements. Applications connect directly to a peer-to-peer network of data hosts. Anyone can run a host, anyone can query, anyone can verify. Access is determined by cryptography and network protocols, not by corporate policies.

Verifiability is complete. There's a chain of proof from raw blockchain state to indexed data to query results. Historical data is as verifiable as current data. Custom transformations maintain cryptographic links to source data. You can verify not just individual transactions, but aggregations, balances, and derived data.

Because the data is verifiable and permissionlessly accessible, you can host it yourself. Applications can run their own nodes for maximum control. Users can choose where their data lives: their device, developer infrastructure, or distributed network. Decentralization stops being an architectural requirement and becomes a natural consequence of cryptographic properties.

What This Enables

Remove the trust requirements from blockchain data access and the design space opens up.

Multi-chain queries without multi-chain headaches. Query Ethereum, Solana, and Bitcoin through the same interface. No juggling three different indexer APIs, no maintaining separate integrations, no trusting three different providers. One query layer, cryptographically verified responses regardless of source chain.

Custom indexing without infrastructure. Write a lens function, deploy it, and you have a new queryable data view. No standing up servers, no managing databases, no syncing nodes. Your transformation runs across the network and produces verifiable outputs.

Verifiable data pipelines. Feed indexed data directly into your backend knowing it's cryptographically proven. Build trading bots, analytics dashboards, or risk systems where every input carries a proof. No more "trust but verify" where the verify part never actually happens.

AI with provable inputs. Onchain AI agents need to prove they acted on accurate data. Feed models blockchain state with cryptographic proofs attached. When your agent executes a trade or triggers a contract, the inputs are verifiable, not just "whatever Alchemy returned at the time."

Local-first architectures that actually work. Store data on user devices, sync through the network, verify correctness on either end. Build apps that work offline and sync when connected without sacrificing data integrity.

Ditch the API keys. No rate limits, no tiered pricing, no authentication tokens. Connect to the network and query. Access is protocol-level, not permission-level.

The Path Forward

This transition won't happen overnight. Validators need to adopt new tooling. Developers need to embrace new patterns. The ecosystem needs to move away from dependencies on familiar centralized services.

But the current model is fundamentally broken. We can't keep calling applications "trustless" when they require trusting infrastructure providers. We can't claim "verifiability" when most of the data stack is unverifiable. We can't promise "permissionless access" when access is gated by API keys and service agreements.

As blockchain technology moves from speculation to real-world utility, these contradictions become increasingly untenable. A regulatory event, a service outage, or a simple change in business terms will eventually make painfully clear what we already know: you can't build a trustless future on infrastructure that requires trust.

Shinzo provides the alternative. Not just a different indexer, but a fundamentally different approach where trust gets replaced by verification, where permission gets replaced by cryptographic access, where centralization becomes unnecessary because the technical properties don't require it.

The technical architecture is done. Implementation is underway. We're building with validators, developers, and protocols who recognize that blockchain infrastructure needs the same cryptographic guarantees as the blockchains themselves.

The validators securing the blockchain produce the indexed data. No separate infrastructure, no separate trust assumptions. Reading blockchain data gets the same guarantees as writing to it.

No intermediaries requiring trust. No gatekeepers controlling access. No compromises on the principles that made this technology worth building.

Join Us

We're opening up our community to developers, validators, and anyone who cares about building infrastructure with real cryptographic guarantees. Tired of choosing between convenience and verifiability? Felt the limitations of trust-based systems in your supposedly trustless applications? Think blockchain data should carry the same proofs as blockchains themselves? We want to hear from you.

The comprehensive technical architecture paper is coming soon. It details the cryptographic foundations, proof systems, distributed architecture, and formal analysis that make Shinzo possible.

You can keep paying for data you can't verify. Or you can help build infrastructure that doesn't require trust in the first place.

Shinzo: The verifiable blockchain data layer. Built by developers who refused to compromise.
X · Telegram · Discord · GitHub ·  shinzo.network