Core concepts

Shinzo runs on four ideas that show up everywhere in the stack: Views, Attestation, DefraDB, and the SHNZ token. The How it works page covers how they fit together end to end.

Views

A View is a developer-defined data product. It describes what raw blockchain data to pull, how to transform it, and what schema to expose the result as. Once deployed, Hosts run it continuously and push results to any application that subscribes.

What a View contains

Every View is a versioned bundle with three parts:

A query that specifies which primitive data to pull from the Indexer layer. Today that means blocks, transactions, logs, and access list entries from Ethereum Mainnet.
A schema, a GraphQL SDL type definition describing the shape of the output. This is what subscribers see and query against.
One or more Lens transforms, WebAssembly modules that do the actual filtering, decoding, and reshaping work.

Why it's designed this way

The split between what data (the query), how to transform it (the Lens), and what shape to expose (the schema) is intentional. It keeps the View portable: any compliant Host can pick it up, run the same deterministic transforms against the same input, and get the same output. Because Lens transforms are WASM and deterministic, any Host or auditor can re-run them to verify the result independently.

You deploy Views through viewkit to ShinzoHub, which validates and registers them. Hosts watch for new View registrations and decide which ones to run.

View categories

Views fall into three categories depending on what data they touch:

Primary: derived directly from Indexer primitives (e.g. decoded ERC-20 transfers from raw logs).
Secondary: derived from other Views (e.g. a portfolio view built on top of multiple token transfer Views).
Tertiary: aggregated or computed across multiple secondary sources.

Most developers today build primary Views. Secondary and tertiary Views become useful once more primary Views exist for them to draw from.

Attestation

Attestation is how Shinzo tracks how much of the network has independently agreed on a piece of data.

The problem it solves

With a centralized indexer, you trust the provider because you have no other option. You can't verify¹ the data you got matches what's actually on chain. In Shinzo, Indexers cryptographically sign every document they produce, so there's a verifiable record of who said what. But a single signature only goes so far. You still need to know whether multiple independent Indexers saw the same thing.

Attestation answers that question.

How it works

When a Host receives a document from an Indexer, it checks the signature and creates (or updates) an attestation record for that document. The record tracks which Indexers signed off and maintains a running vote count.

type Ethereum__Mainnet__AttestationRecord {
    attested_doc: String
    source_doc: String
    CIDs: [String]
    doc_type: String
    vote_count: Int  # CRDT P-counter — only goes up
}

The vote_count field is a CRDT P-counter: it only ever increments, and multiple Hosts merging their counts never produce conflicts. If three Indexers all sign the same block, the attestation record for that block has a vote count of three.

What applications do with it

Apps set their own attestation threshold depending on how much they care about correctness versus speed. A wallet showing recent transfers might accept data with a count of one. A DeFi protocol acting on that data might wait for five. The threshold is a query-time filter, not a system-wide setting, so different queries in the same app can use different thresholds.

Batch signatures

Rather than signing every document individually, Indexers produce a BatchSignature per block: a single document committing to a Merkle root that covers every primitive in that block (transactions, logs, access list entries, and the block itself). A Host can then create a single attestation covering the entire block in one step.

DefraDB

DefraDB is the database embedded in every component of the Shinzo stack. Indexers, Hosts, and application clients each run their own instance. It's what makes the network peer-to-peer rather than client-server.

What it is

DefraDB is an open-source document database built by Source Network. It stores data as content-addressed documents, exposes a GraphQL query interface, handles schema definition, and ships with a libp2p networking layer for replication between nodes. A few properties make it a good fit for Shinzo in particular:

Schema enforcement: primitive documents have defined types that Indexers write into and Hosts read from.
P2P replication: documents gossiped between instances are verified by CID before being accepted.
DID-based access control: read access to any collection can be gated by a DID, which is how subscription access is enforced.
CRDT support: conflict-free merge semantics for types like the P-counter in Attestation Records.

How it connects the network

When an Indexer writes a block to its local DefraDB, DefraDB gossips a digest to subscribed peers over libp2p. Those peers (Hosts) request the full document, verify its CID, and store it locally. No broker is involved.

The same thing happens at the other end. When a Host produces View documents for a subscriber, DefraDB replicates them directly to the subscriber's embedded instance. The app queries its local database. No API call, no round trip.

Why not a conventional database

A conventional database has a server and a client, which means the server is a single point of failure and the client has no way to verify what it receives. DefraDB gives every participant their own node. Data is addressed by content rather than by location, and access control travels with the data.

SHNZ token

SHNZ is the native token of ShinzoHub, the Cosmos SDK chain that coordinates the Shinzo network. It's the economic unit flowing between developers who publish Views, Hosts who serve them, and consumers who subscribe.

Confirmed so far:

Staking: any address can stake SHNZ on a View to signal demand. Stake feeds into the View's price.
Funding: consumers prepay SHNZ into a View's contract, tied to their DID. The balance sits there until a Host serves a query, at which point the current price is debited and credited to the creator's earnings.
Protocol cut: a flat percentage comes off every consumption event. It's enforced in the SVS-1 contract standard and can't be bypassed with a custom pricing contract.

The broader token design (staking incentives, Host earnings, slashing, the final fee rate) is still being worked out.

Technically you can verify that the data you're getting is correct. But you'd have to sign up to multiple APIs, request the same data from each, work it into the same schema, and then compare between them. This is obviously a huge hassle, and incredibly costly. ↩

Views​

What a View contains​

Why it's designed this way​

View categories​

Attestation​

The problem it solves​

How it works​

What applications do with it​

Batch signatures​

DefraDB​

What it is​

How it connects the network​

Why not a conventional database​

SHNZ token​

Footnotes​