Architecture overview

Shinzo has two layers: an on-chain coordination layer and an off-chain data layer. The on-chain layer handles registration, payments, and access control. The off-chain layer handles the actual blockchain data, from fetching it through signing and transforming it to serving it to users.

Neither layer works without the other. The on-chain layer controls who can participate. The off-chain layer does the grunt-work.

System diagram

The schedulerScheduler A coordination service that reads registrations from ShinzoHub and matches indexers to hosts. Like the gateway, it never handles actual data. and gateway are coordination services. They match indexersIndexer 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. to hostsHost 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. and route user queries to the right hostHost 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.. They never touch the actual data.

Component inventory

Component	Layer	Language	Repo	Touches data?
GethGeth 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. (source chainSource 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. node)	Off-chain	Go	go-ethereum	Yes
IndexerIndexer 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. client	Off-chain	Go	shinzo-indexer-client	Yes
HostHost 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. client	Off-chain	Go	shinzo-host-client	Yes
SchedulerScheduler A coordination service that reads registrations from ShinzoHub and matches indexers to hosts. Like the gateway, it never handles actual data.	Off-chain	Go	shinzo-scheduler-service	No
Network gatewayNetwork Gateway A coordination service that routes user GraphQL queries to the right host. It never touches the underlying data.	Off-chain	Go	shinzo-network-gateway	No
ShinzoHubShinzoHub 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.	On-chain	Go (Cosmos SDKCosmos 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.)	shinzohub	No
SourceHubSourceHub 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.	On-chain	Go (Cosmos SDKCosmos 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.)	sourcehub	No
EVM relayerEVM 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.	Off-chain	Go	shinzo-evm-relayer	No
OutpostOutpost 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. contract	On-chain	Solidity	shinzo-outpost	No
ViewView A curated, SDL-defined representation of defraDB documents. Views transform raw indexed data into a structured output shape. creator (viewkitViewkit 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.)	Off-chain	Go	shinzo-view-creator	No
DefraDBdefraDB 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.	Off-chain	Go	defradb	Yes
LensLens 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. (LensVMLensVM 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.)	Off-chain	Go/WASMWASM A portable, sandboxed bytecode format. Lens transforms compile to WASM — typically from Rust or AssemblyScript — and hosts run them via LensVM.	lens	Yes

The two chains

ShinzoHub

ShinzoHubShinzoHub 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. is a Cosmos SDKCosmos 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. chain with an integrated EVMEVM 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., running CometBFTCometBFT 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. consensus. Its native token is SHNZSHNZ 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..

ShinzoHubShinzoHub 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. maintains three EVMEVM 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. precompilePrecompile 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. registries:

Address	Registry	Purpose
0x0210	View RegistryView 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.	Registers viewsView A curated, SDL-defined representation of defraDB documents. Views transform raw indexed data into a structured output shape., deploys SVS-1SVS-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. contracts.
0x0211	Host RegistryHost Registry The ShinzoHub EVM precompile at `0x0211` that tracks registered hosts. View.sol contracts check it before accepting `report()` and `consume()` calls.	Tracks registered hostsHost 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..
0x0212	Indexer RegistryIndexer 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.	Tracks registered indexersIndexer 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..

These precompilesPrecompile 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. are implemented in Go, not Solidity bytecode. They have direct access to Cosmos SDKCosmos 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. keepersKeeper 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., which is how EVMEVM 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. transactions trigger cross-chain ICAICA 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. calls to SourceHubSourceHub 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..

ShinzoHubShinzoHub 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. also runs five custom Cosmos modulesModule 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.: x/admin, x/sourcehub (ICAICA 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. controller), x/host, x/indexer, and x/view. These run alongside the standard Cosmos modulesModule 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. (auth, bank, staking, etc.).

Chain IDs

Environment	Chain ID
Devnet	91273002
Testnet	91273001
Mainnet	91273000

SourceHub

SourceHubSourceHub 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. is a separate Cosmos SDKCosmos 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. chain built by Source Network. It runs the Access Control Policy (ACPACP A set of rules that controls which identities can read, write, query, or update Shinzo data.) moduleModule 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., which implements Google's Zanzibar authorization model.

The ACPACP A set of rules that controls which identities can read, write, query, or update Shinzo data. moduleModule 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. stores authorization tuples:

object#relation@user

For example:

group:host#guest@did:key:z6MkHost7
view:0xABC#subscriber@did:key:z6MkUser1

Permission checks evaluate whether a chain of tuples grants a specific action. Permissions are boolean expressions over relations: admin + creator + subscriber - banned means anyone with the admin, creator, or subscriber relation, unless they are also banned.

SourceHubSourceHub 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. manages two independent policy domains:

1. Protocol participation: which DIDsDID 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. are registered as hostsHost 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. or indexersIndexer 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. (group:host, group:indexer).
2. ViewView A curated, SDL-defined representation of defraDB documents. Views transform raw indexed data into a structured output shape. access: which DIDsDID 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. can read which viewsView A curated, SDL-defined representation of defraDB documents. Views transform raw indexed data into a structured output shape. (view:0xABC#subscriber).

Users never interact with SourceHubSourceHub 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. directly. ShinzoHubShinzoHub 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. sends commands to it via ICAICA 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..

Cross-chain communication with IBC and ICA

ShinzoHubShinzoHub 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. and SourceHubSourceHub 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. communicate over IBCIBC 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. (Inter-Blockchain Communication). IBCIBC 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. has four layers:

• Application layer: ICAICA 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. (Interchain Accounts), IBCIBC 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. Transfer.
• Channel layer: Ordered or unordered packet deliver. ICAICA 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. uses ORDERED channels.
• Connection layer: Links two chains via their light-clients.
• Client layer: Each chain runs a light-client of the other, and verifies state proofs against block headers.

info

The bottom two layers (clients and connections) are set up once and persist. The channel layer is somewhat fragile. ICAICA 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. channels use ORDERED delivery, meaning packets must arrive in sequence. If any packet times out, the channel closes permanently and a new one must be opened.

ICAICA 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. lets ShinzoHubShinzoHub 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. control an account on SourceHubSourceHub 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.. When a precompilePrecompile 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. registration happens on ShinzoHubShinzoHub 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., the keeperKeeper 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. constructs an ICAICA 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. packet wrapping a MsgDirectPolicyCmd and sends it to SourceHubSourceHub 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.. The packet structure:

The HermesHermes 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. relayerRelayer 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. (Rust binary by Informal Systems is the off-chain process that physically moves packets between chains. It reads outbound packets from ShinzoHubShinzoHub 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.'s state, fetches Merkle proofs, and submits them to SourceHubSourceHub 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.. It then reads acknowledgements from SourceHubSourceHub 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. and returns them to ShinzoHubShinzoHub 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.. HermesHermes 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. is stateless and trustless. It cannot fabricate packets because SourceHubSourceHub 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. verifies each packet against a state proof.

The ICAICA 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. relay is asynchronous. When a precompilePrecompile 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. call triggers an ICAICA 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. packet, the EVMEVM 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. transaction completes and returns a receipt before SourceHubSourceHub 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. has processed anything. If the ICAICA 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. packet fails or times out, the EVMEVM 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. transaction still succeeded. The two outcomes are independent.

The x/sourcehub keeperKeeper 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. uses a hardcoded 5-minute timeout on all SendTx calls. If SourceHubSourceHub 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. does not acknowledge within that window, the packet times out and the channel closes.

The bridge to source chains

Two components connect external blockchains (Ethereum, Cosmos chains, etc.) to ShinzoHubShinzoHub 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..

Outpost contracts

OutpostOutpost 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. contracts are deployed on each source chainSource 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.. They handle two things:

• ValidatorValidator 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. assertionsAssertion 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.: a validatorValidator 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. proves their identity using chain-native mechanisms and authorises an operator (delegate) key to act as their indexerIndexer 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.. On Ethereum, the validatorValidator 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.'s withdrawal keyWithdrawal 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. signs an EIP-712EIP-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. message on the outpostOutpost 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. contract that names the validatorValidator 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. (consensus public key) and the operator pubkey. The contract verifies the signature, checks validatorValidator 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. status, and emits an AssertionSigned event.
• Payments: Users call payment() on the outpostOutpost 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.. The contract stores a receipt and emits a PaymentCreated event.

The outpostOutpost 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. design is chain agnostic. Each chain gets its own implementation using whatever verification mechanism is native to that chain. The only requirement is that the output is a signed assertionAssertion 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. that a relayerRelayer 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. can deliver to ShinzoHubShinzoHub 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..

Relayers (EVM relayer)

The EVM relayerEVM 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. is a Go process with two pipelines:

1. The assertionAssertion 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. pipeline subscribes to AssertionSigned events on the outpostOutpost 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.'s IndexerAssertion contract via eth_subscribe, reads the assertionAssertion 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. fields directly from the event, and broadcasts MsgIndexerAssertion to ShinzoHubShinzoHub 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.. No block scanning and no dependency on who built the block.
2. The payment pipeline subscribes to PaymentCreated logLog 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. events from the outpostOutpost 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., extracts user DID and payment amount, and broadcasts MsgRequestStreamAccess to ShinzoHubShinzoHub 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..

The relayerRelayer 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. maintains a persistent block cursor so it can resume where it left off after a restart. It has its own wallet on ShinzoHubShinzoHub 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. and needs SHNZSHNZ 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. for gas.

note

The EVM relayerEVM 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. and the HermesHermes 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. IBCIBC 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. relayerRelayer 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. are completely different systems. The EVM relayerEVM 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. bridges Ethereum to ShinzoHubShinzoHub 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.. The HermesHermes 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. relayerRelayer 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. bridges ShinzoHubShinzoHub 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. to SourceHubSourceHub 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. over IBCIBC 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.. They share the word relayerRelayer 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. and nothing else.

Off-chain data flow

DefraDB

DefraDBdefraDB 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. is the peer-to-peer document database embedded in every indexerIndexer 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. and hostHost 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.. Three separate DefraDBdefraDB 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. instances exist in the system (one per indexerIndexer 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., one per hostHost 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. for primitives, one per hostHost 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. for viewView A curated, SDL-defined representation of defraDB documents. Views transform raw indexed data into a structured output shape. data).

DefraDBdefraDB 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. uses MerkleCRDTsMerkleCRDT 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., a combination of Merkle DAGsMerkle 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. and CRDTsCRDT 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.. Document updates are stored as a Merkle DAGMerkle 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. where each node is a CRDTCRDT 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. operation. CRDTsCRDT 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. give you conflict resolution without coordination. The Merkle DAGMerkle 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. gives you verifiable history. And because nodes can diff DAGs, sync only transfers the missing pieces.

Documents are content-addressed using CIDs (Content IdentifiersContent Identifier 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.). The CID is a hash of the document content, so verification is just re-hashing and comparing. DefraDBdefraDB 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. schemas are defined in GraphQL SDL, and queries use standard GraphQL syntax.

P2P topology

Data replication uses libp2plibp2p A peer-to-peer networking library. defraDB uses it for peer discovery and document replication between indexers and hosts., managed internally by DefraDBdefraDB 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.. The flow for a new document:

1. IndexerIndexer 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. writes document to its local DefraDBdefraDB 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..
2. DefraDBdefraDB 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. computes a content digest.
3. DefraDBdefraDB 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. gossips the digest to connected peers.
4. Peers that want the document request the full content.
5. DefraDBdefraDB 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. sends the full document.

IndexersIndexer 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. are write-only. They publish documents and reject all incoming replication (enforced by a replication filter in the indexerIndexer 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. client). HostsHost 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. accept incoming documents from indexersIndexer 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. and replicate attestation records between each other.

Peers discover each other through bootstrap peers configured in DefraDBdefraDB 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. and through EntityRegistered events from ShinzoHubShinzoHub 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. (when new indexersIndexer 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. or hostsHost 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. join the network).

Signing and attestation

Each indexerIndexer 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. signs every block batch it produces. After writing all documents for a block (Block, Transaction, LogLog 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., AccessListEntryAccessListEntry 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.), the indexerIndexer 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. computes a Merkle root over all document CIDs, signs it with its identity key, and writes a BlockSignature document.

HostsHost 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. verify the signature included in the blockSignature against the CID for that document. They can then create an AttestationRecord (document) for that block to track how many independent indexersIndexer 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. produced the same data. The vote_count field uses a P-counterP-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. CRDTCRDT 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., which tracks the number of indexersIndexer 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. which produced that block.

Snapshots bundle multiple blocks into signed files for faster initial sync. The indexerIndexer 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. periodically creates SnapshotSignature documents whose Merkle root is computed over the per-block BlockSignature roots within the range. So you get a two-level Merkle treeMerkle 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.: document CIDs roll up into per-block roots, which roll up into per-snapshot roots.

Registration flows

Indexer registration

Spans two chains and a relayerRelayer 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.. The indexerIndexer 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. cannot register on ShinzoHubShinzoHub 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. until the validatorValidator 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. has signed an assertionAssertion 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. that ties the indexerIndexer 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.'s operator keyOperator 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. to the validatorValidator 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.'s identity.

Host registration

View registration

Transaction flow through a precompile

The full path of an EVMEVM 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. transaction that hits a registry precompilePrecompile 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. and triggers a cross-chain ICAICA 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. call:

1. User sends an EVMEVM 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. tx to a precompilePrecompile 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. (e.g. 0x0210).
2. A validatorValidator 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. includes the tx in a ShinzoHubShinzoHub 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. block.
3. The EVMEVM 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. calls precompile.Run().
4. The precompilePrecompile 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. Go code runs five sequential operations:
   1. Decode ABIABI 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. arguments.
   2. Run business logic (validate, store).
   3. Call the Cosmos keeperKeeper 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. (e.g. RegisterObject).
   4. The keeperKeeper 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. builds an ICAICA 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. packet and commits it to IBCIBC 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. state.
   5. Emit an EVMEVM 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. logLog 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. and a Cosmos event.
5. HermesHermes 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. picks up the ICAICA 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. packet (async).
6. HermesHermes 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. submits the packet plus state proof to SourceHubSourceHub 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..
7. SourceHubSourceHub 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. verifies the proof and executes the ACPACP A set of rules that controls which identities can read, write, query, or update Shinzo data. command.
8. HermesHermes 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. relays the acknowledgement back to ShinzoHubShinzoHub 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..

The precompilePrecompile 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. emits both a Solidity EVMEVM 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. logLog 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. and a Cosmos SDKCosmos 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. event. The event names differ between layers:

PrecompilePrecompile 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.	EVMEVM 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. logLog 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.	Cosmos event
View RegistryView 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. (0x0210)	ViewCreated(address,address,string)	"ViewRegistered"
Host RegistryHost Registry The ShinzoHub EVM precompile at `0x0211` that tracks registered hosts. View.sol contracts check it before accepting `report()` and `consume()` calls. (0x0211)	Registered(address,string)	"HostRegistered"
Indexer RegistryIndexer 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. (0x0212)	Registered(address,string)	"Registered"