Trust & verification
Data in Shinzo crosses several trust boundaries on its way from the chain to your app, and each crossing works differently. Most links are backed by signatures you can verify yourself. One rests on the operator being a validator, and one has a known gap. This page walks the path hop by hop and says plainly what each hop guarantees and what it doesn't.
The short version
| Hop | What backs it | What it doesn't cover |
|---|---|---|
| Execution node to Generator | The Generator operator's own validator infrastructure | Wrong or incomplete source data gets signed as-is |
| Validator and Generator identity each-way | On-chain assertion signed by the withdrawal key | Says nothing about data quality |
| Generator to Host | Per-block signature over a Merkle root of CIDs | Chain-correctness, completeness, freshness |
| Cross-Generator agreement | Attestations that Host clients hold and count | Needs thresholds above one to filter a lone bad source |
| Host to App (view data) | Host's signature, deterministic lenses, audit trail | Independent re-verification of the transform itself |
The execution node to the Generator
The Generator client reads blocks from its validator's node over JSON-RPC, and the operator owns the entire infrastructure. It doesn't verify what the node returns: no re-executing transactions, no recomputing the block's Merkle roots, no comparing responses against a second node. It doesn't need to. You don't verify your own infrastructure.
That holds wherever the node runs: your own hardware, a rented VM, or a dedicated node that a managed provider operates for you. In every case it's your node, inside your boundary. Managed nodes compares the setups.
If the node ever serves wrong or incomplete data, that data is what gets signed, and your blocks stop matching what other Generator clients sign for the same heights. Catching that divergence is what attestations are for, as the example below shows.
Who a Generator is
The data link is trusted because the operator is a validator, and the identity link is cryptographic. A Generator client generates its own operator key locally and never touches the validator's consensus or withdrawal keys. During registration, the validator's withdrawal key signs a one-time assertion that ties the operator key to the validator's identity, and that assertion is verified on-chain (through the outpost contract; on the current testnet, through an admin-key approval flow).
So the network can prove which validator stands behind a given Generator. The remaining question is the data itself, and that one isn't answered by trust: the Generator's per-block signature and Merkle root pin down exactly what was signed, and attestations on Host clients catch a source whose data diverges from everyone else's. The next two hops show both mechanisms.
What the Generator's signature proves
Signing every document individually would be slow, so Generator clients sign per block. After writing a block's documents (blocks, transactions, logs, access list entries), the Generator computes a Merkle root over all of their CIDs, signs the root with its operator key, and writes a BlockSignature document. Snapshot signatures do the same across block ranges, giving you a two-level Merkle structure for fast sync.
Because every document is content-addressed, one signed root covers everything in the block. Alter any document and its CID changes, so it no longer matches the signed root. That gives you two guarantees: origin, because you know which Generator produced the data and which validator it belongs to, and integrity, because nobody altered it in transit.
Just as important is what the signature does not prove. It doesn't prove the data matches the chain, since the Generator faithfully signs whatever its node said. It also doesn't prove completeness (nothing was withheld) or freshness (you're seeing the latest state). Attestation, covered next, closes the first gap. The other two are roadmap work, as noted in Verify data.
Hosts and attestations
Attestations live on Host clients, and their main job is telling apart multiple Generator sources. When a Host client receives a block from a Generator, it verifies the signature and recomputes the Merkle root from the document CIDs. Only then does it open (or update) an attestation record for that block, keyed by the block height and the signed root.
Say three Generators, each run by a different validator on its own node, all process block 19,000,000. Two of them sign the same Merkle root, so the Host's attestation record for that root reaches a vote count of two. The third Generator's node served a bad block, so the Generator signs a different root and its attestation record count sits at one. An app that asks for at least two attestations reads the root the first two agree on and never sees the outlier, without needing to know which source was wrong.
The same math smooths over honest disagreement: chains re-org, and requiring more than one attestation keeps your app from acting on a block that just got reorganized out. Attestations covers the record itself and how the counting works, and Attestation as a query filter covers how apps set per-query thresholds.
The lens gap
When a Host runs a View, the lens transform reshapes primitive documents into view documents. Those outputs are new documents with new CIDs, signed by the Host. The Generator clients' signatures do not carry over, so the cryptographic link back to the primitives breaks at the transform.
If your app pays a third-party Host for view data, you cannot independently verify that the output faithfully derives from the signed primitives, because your app never sees the primitives. You are trusting the Host's computation. A few things blunt that risk today:
- Lens transforms are deterministic WASM, so anyone can re-run them over the same primitives and check the output. Independent verifiers can audit Hosts this way.
- Attestation records keep the verified primitive CIDs as an evidence trail, so there is something concrete to audit against.
- The strongest option is to serve yourself. Running your own Host puts no third party in the path at all. See Use your own infrastructure and Privacy.
Policing and economic penalties for manipulative Hosts are part of the protocol design but are not live today. Treat third-party view data as "trusted, auditable later" rather than "verified on receipt."
Where to go next
- Attestations: how vote counts on data work.
- Verify data with signatures and CIDs: the hands-on queries for checking data yourself.
- Attestation as a query filter: setting per-query trust thresholds in your app.
- Generator security: deployment shapes and key separation for operators.
- Managed nodes: what changes when a provider operates your node.