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 the Shinzo network's coordination chain: 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. ViewsView A curated, SDL-defined representation of defraDB documents. Views transform raw indexed data into a structured output shape., 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., 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 the economic layer (staking, funding, pricing, earnings) all run here.

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. does not store or serve blockchain data. It is a coordination layer only.

Tech stack

Component	Implementation
Application framework	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. v0.53.4
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. 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.	cosmos/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. v0.4.1
Consensus	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.
Native token	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.

Chain IDs

Environment	Chain ID	Status
Devnet	91273002	Running
Testnet	91273001	Target: July 1, 2026
Mainnet	91273000	Future
Local	91273003	Local development

Token details

Property	Value
Base denomination	ushinzoushinzo The base denomination of SHNZ on ShinzoHub. 1 SHNZ = 10^18 ushinzo. Most user-facing tools display SHNZ; on-chain accounting uses ushinzo.
Display denomination	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.
Decimals	18
Bech32Bech32 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. prefix	shinzo
Coin type	60 (Ethereum-compatible)
Key algorithm	eth_secp256k1

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. uses coin type 60, the same as Ethereum. The BIP-44BIP-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. derivation path is m/44'/60'/0'/0/0. A MetaMask private key produces the same underlying address on both chains. The hex address (0x742d...) and bech32Bech32 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. address (shinzo1ws69...) are different encodings of the same public key.

Custom modules

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. has one custom Cosmos 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.:

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.	Path	Purpose
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.	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, sends messages 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 standard 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. 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, mint, distribution, slashing, gov, etc.) and 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./ERC20 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. make up the rest of the 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. set. 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., 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 viewView A curated, SDL-defined representation of defraDB documents. Views transform raw indexed data into a structured output shape. registration are handled by 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. 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., not dedicated 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..

Older docs reference an "Access 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." and a "Registry 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.." These do not exist. The registries are 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. 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., and access control lives 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..

Precompiles

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. uses 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. precompiled contracts to connect Cosmos 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. logic with the Solidity layer. 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. sit at fixed addresses and are written in Go rather than compiled 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..

Address	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.	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.
0x0211	Entity Registry	Registers 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 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. (distinguished by an entity tag)

View Registry (0x0210)

Method	Signature	Description
register	register(bytes)	Register a viewView A curated, SDL-defined representation of defraDB documents. Views transform raw indexed data into a structured output shape. from VWLVWL 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. wire bytes
get	get(bytes32) returns (bytes)	Retrieve registered viewView A curated, SDL-defined representation of defraDB documents. Views transform raw indexed data into a structured output shape. bytes by key

When register(bytes) is called:

1. Decodes VWLVWL 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. wire bytes via viewbundle.DecodeHeader().
2. Extracts the SDL type name via regex.
3. Computes key: keccak256(caller, encodedValue).
4. Modifies SDL to include a unique ID (typename becomes typename_0xkey).
5. Re-encodes via viewbundle.EncodeHeader().
6. Calls sourcehubKeeper.RegisterObject() 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. to register in 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. ACPACP A set of rules that controls which identities can read, write, query, or update Shinzo data..
7. Stores the creator mapping in 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. state.
8. Emits Registered(key, sender, value) 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 Cosmos event.

Key files:

• app/precompiles/viewregistry/methods.go
• app/precompiles/viewregistry/viewregistry.go

Entity Registry (0x0211)

A single 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. handles both 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. and 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. registration. The entity uint8 parameter distinguishes the two: 0 = 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., 1 = 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..

Method	Signature	Description
register	register(bytes, bytes, bytes, bytes, bytes, uint8)	Register a 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. or 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. using dual key proofs

Parameters: peerKeyPubkey, peerKeySignature, nodeIdentityKeyPubkey, nodeIdentityKeySignature, message, entity.

On registration:

1. Verifies the peer keyPeer Key One of two keys submitted during host registration. It identifies the host on the libp2p network. and node identity key signatures.
2. Derives DIDDID 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. and PIDPID 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..
3. Triggers 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. 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. to add the DIDDID 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. to the appropriate group ("host" or "indexer").
4. Emits EntityRegistered(key, owner, did, pid, entity) 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 Cosmos event.

Key files:

• app/precompiles/entityregistry/method.go
• app/precompiles/entityregistry/entityregistry.go

Event names

Each 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 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 names differ:

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.	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.	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
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.	Registered(bytes32,address)	"Registered"
Entity Registry	EntityRegistered(bytes32,address,bytes,bytes,uint8)	"EntityRegistered"

Other events:

Event

Emitted by

AccessRequestSuccess

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. 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. msg_server

Older docs reference DataPurchased, AccessRevoked, and AccessRequestPayment. None of these event names exist in the codebase.

SVS-1 (Shinzo View Standard 1)

A per-viewView A curated, SDL-defined representation of defraDB documents. Views transform raw indexed data into a structured output shape. smart contractSmart Contract Deterministic code deployed on a blockchain. The same inputs always produce the same output, and the output is verifiable by anyone. standard. Each registered viewView A curated, SDL-defined representation of defraDB documents. Views transform raw indexed data into a structured output shape. is expected to have its own 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. instance. The 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. does not deploy these automatically.

The contract exposes four functions:

• stake(): stake 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. on the viewView A curated, SDL-defined representation of defraDB documents. Views transform raw indexed data into a structured output shape..
• fund(did): fund a DIDDID 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.'s access to query the viewView A curated, SDL-defined representation of defraDB documents. Views transform raw indexed data into a structured output shape..
• consume(did): consume funded credits (called by 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. when serving queries).
• report(): report usage.

Price formula:

price = rate x complexity x premium - 5% protocol fee

For custom pricing, viewsView A curated, SDL-defined representation of defraDB documents. Views transform raw indexed data into a structured output shape. can implement the SVPS-1SVPS-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. interface, which exposes a single price() returns (uint256) function.

The sourcehub module (x/sourcehub)

This 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. holds 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. controller logic. It stores 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. connection metadata (controller/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. connection IDs), builds and sends 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. packets 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., and uses a hardcoded 5-minute timeout on all SendTx calls.

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 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. call, 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 a MsgDirectPolicyCmd wrapping a RegisterObjectCmd or SetRelationshipCmd, packs it into a CosmosTx envelope, and sends it over 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.. 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. picks up the packet asynchronously.

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. 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. processes the packet. 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 times out or fails, 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 has still succeeded.

Key file: x/sourcehub/keeper/keeper.go

Payment and access flow

1. User calls 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. contract on the 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., sends ETH. The contract stores the receipt and emits PaymentCreated.
2. 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. subscribes to PaymentCreated, builds MsgRequestStreamAccess, and broadcasts it 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..
3. 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. builds a MsgDirectPolicyCmd with SetRelationshipCmd and sends 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., granting the user's DIDDID 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. read access 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..
4. 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. emits AccessRequestSuccess.

Endpoints

Service	URL (devnet)
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. JSON-RPC	http://rpc.devnet.shinzo.network:8545
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. RPC	http://rpc.devnet.shinzo.network:26657
REST / LCD	http://rpc.devnet.shinzo.network:1317
gRPC	port 9090

What is not implemented yet

These appear in design docs but do not exist in any branch as of the current devnet:

• Balance monitoring (no code monitors user balances for depletion).
• Automatic access revocation (no RevokeAccess message; Expiration field exists in proto but is not enforced).
• DataPurchased event (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. emits PaymentCreated, not DataPurchased).
• GrantAccess 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. message (actual mechanism uses 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. with ACPACP A set of rules that controls which identities can read, write, query, or update Shinzo data. policy commands).
• Direct 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. integration in 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. bridges everything).
• 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. listening 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. events (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. listen 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. 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. RPC, not 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.).