Glossary

Glossary of terms and definitions for Shinzo Network's decentralized data indexing protocol

A

ABI (Application Binary Interface): Describes how to encode and decode function calls, arguments, and event data for an EVM contract. Lenses such as `decode_log` take ABI JSON as input to read raw log data.
Related terms: EVM, Lens, Log
AccessListEntry: A document type produced by the indexer for EIP-2930 access list entries attached to Ethereum transactions. Most transactions have no access list, so this collection is usually sparse.
Related terms: EIP-2930, Indexer
ACP (Access Control Policy): A set of rules that controls which identities can read, write, query, or update Shinzo data.
Related terms: SourceHub
Assertion: A cryptographic proof, produced on a source chain, that a validator is who they claim to be. It ties the validator's consensus identity to an operator key. Without a valid assertion, a validator cannot register as an indexer on ShinzoHub.
Related terms: Outpost, Operator Key, Withdrawal Key, Consensus Key, Indexer
AttestationRecord: A document a host creates to track how many independent indexers produced the same data for a given block. The `vote_count` field is a P-counter CRDT, so counts converge across hosts without any coordination step.
Related terms: Host, P-counter, BlockSignature, CRDT

B

Bech32: An address encoding format used on Cosmos SDK chains. ShinzoHub uses the `shinzo` prefix (e.g., `shinzo1ws69...`). The same underlying key produces both a hex address and a bech32 address — they are different representations, not different keys.
Related terms: ShinzoHub, Cosmos SDK
BIP-44: A Bitcoin Improvement Proposal that defines a hierarchical deterministic key derivation path. ShinzoHub uses coin type 60 (the same as Ethereum), so the path `m/44'/60'/0'/0/0` produces the same key on both chains.
Related terms: ShinzoHub
Block Data: Raw blockchain data: blocks, transactions, and logs. The indexer fetches this from source chains such as Ethereum and structures it into defraDB documents.
Related terms: Indexer, Indexing, Epoch
BlockSignature: A document the indexer writes after it finishes processing a block. It contains a Merkle root over all document CIDs for that block, signed with the indexer's identity key. Hosts check it to verify the batch came from a known indexer.
Related terms: Indexer, Merkle Tree, AttestationRecord, SnapshotSignature

C

CometBFT: The BFT consensus engine used by Cosmos SDK chains. ShinzoHub runs CometBFT for block production. Hosts connect to ShinzoHub's CometBFT RPC over WebSocket to receive real-time event notifications.
Related terms: Cosmos SDK, ShinzoHub
Consensus Key: The public key a validator uses to sign blocks and participate in chain consensus. During an assertion, this key is bound to an operator key so the indexer can act on the validator's behalf on ShinzoHub.
Related terms: Validator, Assertion, Operator Key
Content Addressable Data: A storage approach where data is identified by a cryptographic hash of its content. Changing anything produces a different hash, so you can verify content without trusting the source.
Related terms: Content Identifier, IPLD, Merkle DAG
Content Identifier (CID): A hash-based identifier derived from content. Used across IPLD and hash-linked data structures to address data by what it is, not where it lives.
Related terms: Content Addressable Data, IPLD
Cosmos SDK: A Go framework for building app-specific blockchains. ShinzoHub (v0.53.4) and SourceHub are both Cosmos SDK chains. ShinzoHub also bundles an EVM module.
Related terms: ShinzoHub, SourceHub, CometBFT, Module
CRDT (Conflict-free Replicated Data Type): A data structure that multiple nodes can update independently and then merge without coordination, always reaching the same result. defraDB uses CRDTs — specifically MerkleCRDTs — to merge document updates from peers.
Related terms: MerkleCRDT, P-counter, defraDB

D

defraDB: A peer-to-peer, document-oriented database embedded in every indexer and host. It handles storage, content addressing, CRDT merging, query serving, and P2P replication via libp2p.
Related terms: GraphQL, View, MerkleCRDT, libp2p
DID (Decentralized Identifier): A self-sovereign identifier (e.g., `did:key:z6Mk...`) derived from a public key. Hosts, indexers, and users are identified by DIDs in SourceHub authorization tuples.
Related terms: DID Key, SourceHub, ACP
DID Key (Digital Identity Key): A cryptographic key pair that represents a user's or device's identity in Shinzo. It is used for signing, encrypting, and authenticating operations.
Related terms: DID, Orbis, Host

E

ECDSA (Elliptic Curve Digital Signature Algorithm): The signature algorithm used by Ethereum and ShinzoHub (secp256k1 curve). Viewkit derives an ECDSA private key from the wallet to sign deploy transactions.
Related terms: EVM, ShinzoHub, Viewkit
EIP-2930: An Ethereum standard that adds optional access lists to transactions, pre-declaring which storage slots a transaction will read or write. The indexer stores these as `AccessListEntry` documents.
Related terms: AccessListEntry
EIP-712: An Ethereum standard for signing structured, typed data in a form users can read before approving. The EVM outpost contract uses EIP-712 for the digest that a validator's withdrawal key signs during an assertion.
Related terms: Outpost, Assertion, Withdrawal Key
Epoch: A fixed number of blocks treated as one unit of time. On Ethereum, an epoch is 32 blocks.
Related terms: Block Data, Indexing
EVM (Ethereum Virtual Machine): The runtime that executes Solidity smart contracts. ShinzoHub embeds an EVM module so its registries are accessible as precompiled contracts at fixed addresses, callable from any EVM tooling.
Related terms: Precompile, ShinzoHub, Smart Contract
EVM Relayer: A Go process that bridges an external EVM chain (e.g. Ethereum) to ShinzoHub. It subscribes to outpost events, extracts assertion or payment data, and broadcasts the relevant Cosmos SDK messages to ShinzoHub. Not the same as the Hermes IBC relayer.
Related terms: Outpost, Relayer, Hermes, ShinzoHub

G

Geth: Go-Ethereum, the Go implementation of an Ethereum node. Each indexer runs alongside a Geth node and connects over WebSocket (port 8546) and JSON-RPC (port 8545) to fetch block data.
Related terms: Indexer, Validator

H

Hermes: An IBC relayer written in Rust by Informal Systems. It moves IBC packets between ShinzoHub and SourceHub by fetching Merkle proofs from one chain and submitting them to the other. It is stateless and cannot fabricate packets; SourceHub verifies each one against a state proof.
Related terms: IBC, ICA, Relayer, ShinzoHub, SourceHub
Host: A Shinzo node that receives indexed data from indexers over P2P, verifies it, runs lens transforms to produce view documents, and serves those documents over GraphQL.
Related terms: DID Key, Orbis, ShinzoHub
Host Registry: The ShinzoHub EVM precompile at `0x0211` that tracks registered hosts. View.sol contracts check it before accepting `report()` and `consume()` calls.
Related terms: Host, Precompile, ShinzoHub

I

IBC (Inter-Blockchain Communication): A protocol for passing authenticated messages between independent blockchains. It works in layers: light clients verify state proofs, connections link two chains, channels carry ordered or unordered packets, and applications (like ICA) run on top. ShinzoHub and SourceHub communicate over IBC.
ICA (Interchain Accounts): An IBC application that lets one chain control an account on another. ShinzoHub uses ICA to send policy commands to its account on SourceHub. ICA channels are ordered, meaning a single timed-out packet permanently closes the channel and a new one must be opened.
Related terms: IBC, Hermes, ShinzoHub, SourceHub
Indexer: A node that reads blockchain data from a source chain, parses it into structured documents, and writes them to defraDB. Indexers are write-only: they push data out over P2P and reject all incoming replication.
Related terms: Indexing, defraDB, Block Data, Primitive Prefix, Validator
Indexer Registry: The ShinzoHub EVM precompile at `0x0212` that tracks registered indexers. An indexer cannot register here directly — it must first complete an assertion via an outpost contract. The registry verifies the stored assertion before accepting registration.
Related terms: Indexer, Precompile, Assertion, Outpost
Indexing: The process of parsing blockchain data and storing it as structured, schema-compliant documents in defraDB.
Related terms: Indexer, defraDB, Block Data
IPLD (Interplanetary Linked Data): A data model for decentralized systems (used by IPFS, among others). It structures data as Merkle DAGs so every object is content-addressed and verifiable.
Related terms: Merkle DAG, Content Identifier, Content Addressable Data

K

Keeper: In Cosmos SDK, a Go object that owns a module's state and provides the only sanctioned way to read or write it. Precompile code on ShinzoHub calls keepers directly — for example, to send an ICA packet — without going through Solidity bytecode.
Related terms: Cosmos SDK, Module, Precompile

L

Lens: A WASM module that transforms primitive documents (e.g., raw `Log` records) into view documents (e.g., `USDCTransfer`). Lenses must be deterministic: the same input always produces the same output. Hosts run them via LensVM.
Related terms: LensVM, View, WASM, Viewkit
LensVM: The WASM execution environment inside a host that runs lens transforms. It supports Wasmtime, Wasmer, and Wazero runtimes, and can run lenses in both directions if the WASM module exposes an `inverse()` function.
Related terms: Lens, WASM, Wasmtime, Wasmer, Wazero
libp2p: A peer-to-peer networking library. defraDB uses it for peer discovery and document replication between indexers and hosts.
Related terms: defraDB, P2P
Log: A document type the indexer produces for event logs emitted during transaction execution. `topics` holds the indexed parameters and `data` holds the non-indexed ones, both as raw hex. ABI decoding happens later, in a lens.
Related terms: Indexer, Lens, ABI

M

Materialized directive: A GraphQL SDL annotation used in view definitions. `@materialized(if: true)` tells defraDB to pre-compute and store view data at write time, so queries are fast but storage use is higher. `@materialized(if: false)` computes results on query.
Related terms: View, Schema Definition Language, defraDB
Merkle DAG: A directed acyclic graph where each node is identified by a hash of its content and links to parents by their hashes. Unlike a Merkle tree, nodes can have multiple parents. defraDB uses Merkle DAGs to store document history.
Related terms: Merkle Tree, IPLD, Content Addressable Data
Merkle Tree: A tree where each internal node is the hash of its children. Changing any leaf changes every hash up to the root, so you can verify any piece of the dataset by checking a small proof.
Related terms: Merkle DAG
MerkleCRDT: defraDB's core storage primitive. Each document update is a CRDT operation stored as a node in a Merkle DAG. The CRDT part handles conflict-free merging; the Merkle DAG part gives verifiable history and lets peers sync only what they are missing.
Related terms: CRDT, Merkle DAG, defraDB
MEV-boost: A service on Ethereum that lets validators hand off block construction to external builders. Because those builders control the block's `extraData` field, Shinzo's assertion design does not rely on it — validator identity is read directly from the outpost event instead.
Related terms: Validator, Outpost, Assertion
Module: A Cosmos SDK building block that owns a slice of chain state, handles messages, and emits events. ShinzoHub adds five custom modules (`x/admin`, `x/sourcehub`, `x/host`, `x/indexer`, `x/view`) on top of the standard Cosmos set.
Related terms: Cosmos SDK, ShinzoHub, Keeper

N

Network Gateway: A coordination service that routes user GraphQL queries to the right host. It never touches the underlying data.
Related terms: Scheduler, Host
Node Key: A node identity key submitted alongside the peer key during host registration. ShinzoHub verifies both signatures and derives the host's DID and PID from them.
Related terms: Host, Peer Key, DID, PID

O

Operator Key: Also called the delegate key. Generated locally by an indexer operator and bound to a validator's identity through an assertion. The indexer uses it to sign ShinzoHub registrations and protocol actions.
Related terms: Indexer, Validator, Assertion, Withdrawal Key
Orbis: Shinzo's key management component. It generates, stores, and provides access to the cryptographic keys used for identity, encryption, and signing.
Related terms: DID Key, Host
Outpost: A smart contract deployed on a source chain. Validators call it to prove their identity before registering as indexers; users call it to pay for view access in the source chain's native currency. Each chain type has its own outpost implementation.
Related terms: Smart Contract, ShinzoHub, Assertion, Relayer

P

P-counter (Positive Counter): A CRDT that only increments. Each node tracks its own count separately; merging just takes the max per node and sums them. `AttestationRecord.vote_count` uses a P-counter so all hosts converge on the same indexer count without coordinating.
Related terms: CRDT, AttestationRecord
Peer Key: One of two keys submitted during host registration. It identifies the host on the libp2p network.
Related terms: Host, Node Key, libp2p
PID (Peer ID): A libp2p peer identifier derived from a host's keys at registration time. Other peers use the PID to address the host on the P2P network.
Related terms: Host, libp2p, Peer Key
Precompile: A contract at a fixed EVM address implemented in native Go rather than Solidity bytecode. ShinzoHub's three registries (View `0x0210`, Host `0x0211`, Indexer `0x0212`) are precompiles so they can call Cosmos SDK keepers directly and trigger ICA packets.
Related terms: EVM, Keeper, View Registry, Host Registry, Indexer Registry
Primitive Prefix: A prefix added to document collection names to namespace them by chain and network (e.g., `Ethereum__Mainnet__Block`). Keeps documents from different chains separate in the same defraDB instance.
Related terms: Indexer

R

Re-org: Short for chain reorganization: the canonical block at a given height changes. When this happens, different indexers may briefly hold different versions of the same block. Hosts store each version as a separate document; applications pick the one with more attestation votes.
Related terms: Indexer, AttestationRecord
Relayer: A process that moves data between chains. Shinzo uses two that share nothing but the name: the EVM relayer bridges Ethereum to ShinzoHub, and Hermes bridges ShinzoHub to SourceHub over IBC.
Related terms: EVM Relayer, Hermes, Outpost

S

Scheduler: A coordination service that reads registrations from ShinzoHub and matches indexers to hosts. Like the gateway, it never handles actual data.
Related terms: Network Gateway, Indexer, Host
Schema Definition Language (SDL): The GraphQL-based schema language used to define document types, fields, constraints, and relationships in defraDB. Views and collections are both defined in SDL.
Related terms: View, defraDB
ShinzoHub: Shinzo's coordination chain: a Cosmos SDK chain (v0.53.4) with an integrated EVM, running CometBFT consensus. It holds the view, host, and indexer registries and the economic layer (staking, pricing, payments). It does not store or serve indexed blockchain data.
Related terms: Host, Outpost, SourceHub, Cosmos SDK, EVM, CometBFT
SHNZ: ShinzoHub's native token. The display denomination; on-chain the base unit is `ushinzo` (1 SHNZ = 10^18 ushinzo). Used for staking, transaction fees, view funding, and relayer gas.
Related terms: ShinzoHub, ushinzo
Smart Contract: Deterministic code deployed on a blockchain. The same inputs always produce the same output, and the output is verifiable by anyone.
Related terms: Outpost
SnapshotSignature: A document that seals a contiguous range of blocks into a single signed file for faster initial sync. Its Merkle root covers the per-block `BlockSignature` roots within the range, forming a two-level tree: document CIDs roll up to block roots, which roll up to the snapshot root.
Related terms: BlockSignature, Indexer, Merkle Tree
Source chain: Any external blockchain that Shinzo indexes — Ethereum, an L2, a Cosmos chain, etc. A source chain hosts an outpost contract and is read by indexers.
Related terms: Outpost, Indexer, Relayer
SourceHub: A separate Cosmos SDK chain built by Source Network that handles authorization for Shinzo. It runs the ACP module (based on Google's Zanzibar model) and stores authorization tuples in the form `object#relation@user`. Users never call SourceHub directly — ShinzoHub sends commands to it via ICA.
Related terms: ACP, Host, ShinzoHub, ICA
Stream ID: A unique identifier assigned to a curated data feed when it is registered.
Related terms: View
SVPS-1 (Shinzo View Pricing Standard 1): An optional pricing contract interface a view can use instead of the default SVS-1 formula. It exposes a single `price() returns (uint256)` function.
Related terms: SVS-1, View
SVS-1 (Shinzo View Standard 1): A per-view smart contract deployed automatically by the View Registry at registration time. It exposes `stake()`, `fund(did)`, `consume(did)`, and `report()`. The default price formula is `rate × complexity × premium` minus a 5% protocol fee.
Related terms: View, View Registry, SVPS-1

U

ushinzo: The base denomination of SHNZ on ShinzoHub. 1 SHNZ = 10^18 ushinzo. Most user-facing tools display SHNZ; on-chain accounting uses ushinzo.
Related terms: SHNZ, ShinzoHub

V

Validator: An entity that participates in a chain's consensus. On Ethereum, a validator's withdrawal key signs an EIP-712 message on the outpost to authorize an operator key as its indexer.
Related terms: Indexer, Assertion, Withdrawal Key, Operator Key, Consensus Key
View: A curated, SDL-defined representation of defraDB documents. Views transform raw indexed data into a structured output shape.
Related terms: defraDB, Schema Definition Language
View Registry: The ShinzoHub EVM precompile at `0x0210`. When `register(bytes)` is called, it decodes the VWL bundle, registers the view in SourceHub via ICA, and deploys an SVS-1 contract for the new view.
Related terms: View, Precompile, VWL, SVS-1, ShinzoHub
ViewBundle: The packaged form of a view: GraphQL query, SDL, lens metadata, and WASM lens binaries. Viewkit produces a ViewBundle and submits it to the View Registry. The wire format is VWL.
Related terms: VWL, Viewkit, View Registry
Viewkit: A CLI tool for creating, testing, and deploying views. It defines the SDL, attaches lenses, runs local validation using the Wasmer runtime, packages everything into a ViewBundle, and submits a deploy transaction to the View Registry.
Related terms: View, ViewBundle, VWL, View Registry, Wasmer
VWL (View Wire Language): The binary format for view bundles. It is a single byte stream: a `"VWL"` magic header and version byte, then the GraphQL query, SDL, lens metadata, and a lens blob (optionally zstd-compressed) containing the WASM binaries.
Related terms: ViewBundle, Viewkit, View Registry

W

WASM (WebAssembly): A portable, sandboxed bytecode format. Lens transforms compile to WASM — typically from Rust or AssemblyScript — and hosts run them via LensVM.
Related terms: Lens, LensVM, Wasmtime, Wasmer, Wazero
Wasmer: A WASM runtime written in Rust. Viewkit uses it to validate lenses locally before deployment.
Related terms: WASM, LensVM, Viewkit
Wasmtime: A WASM runtime written in Rust. The primary runtime used to execute lenses in production hosts.
Related terms: WASM, LensVM
Wazero: A pure-Go WASM runtime with no CGo dependency. An alternative lens runtime in LensVM, useful when avoiding CGo is a requirement.
Related terms: WASM, LensVM
Withdrawal Key: On Ethereum, the key that controls a validator's stake withdrawals. The outpost requires the withdrawal key to sign the EIP-712 assertion digest — it is the chain's strongest proof that a given party controls the validator.
Related terms: Validator, Assertion, Outpost, EIP-712