Running a Shinzo Generator: The Validator Operator FAQ
[2026-07-29]
Every operator has the same first reaction to a new client: new hardware, new keys, new failure modes, another process with opinions about a node that already works. The instinct is correct. Anything that attaches to validator infrastructure is a liability until it proves otherwise.
A Shinzo Generator is a sidecar. It connects to an execution node you already run, reads blocks as they arrive, structures them into queryable documents, signs them with an identity that has nothing to do with consensus, and replicates the result out to Hosts or directly to consumers. It performs no consensus duty. It does not attest, propose, or hold your validator signing key.
What follows is the operational answer to each question a validator team will ask before installing anything.
What is a Shinzo Generator?
The Generator client connects to your chain node over the JSON-RPC and WebSocket interface your execution client already exposes locally, pulls blocks, transactions, logs, and access lists as they land, and normalizes them into a strongly typed document model stored in a local DefraDB instance. It creates a cryptographic commitment over what it produces, signs it, and gossips it out over a peer to peer network to Hosts.
It is not an execution client. It does not serve JSON-RPC to applications, and it does not replace the node it reads from. It consumes the output of infrastructure you already maintain and turns that output into a data product other people can verify.
Over P2P the Generator is write only. It pushes signed documents outward and rejects inbound replication. Data moves in one direction, away from your infrastructure.
Is a Generator another validator?
No. The two roles do not overlap.
Your validator does: participate in consensus, attest to blocks, propose when selected, maintain availability, protect its signing keys.
A Generator does: read chain data, structure it, sign the resulting dataset under its own identity, replicate it to Hosts.
On Ethereum your stack is already an execution client, a consensus client, and a validator client. The Generator sits beside those three. It does not replace one of them, and it does not add a fourth consensus process. It is closer to a monitoring agent in shape than to anything in the signing path.
Does it require more stake?
No. The Generator's data work needs no additional ETH or native token bonded anywhere. It does not create a second validator, it does not change your consensus weight, and it does not alter the stake the source chain already requires of you.
Being an eligible validator on the chain you produce data for is what qualifies you to run a Generator for that chain. Running the Generator itself does not ask you to post more capital.
Does it need validator keys?
Your validator signing key stays inside your existing security boundary and is never handed to the Generator process. The Generator signs its output with a node identity key it generates locally, and signs its network registrations with a separate operator key, also generated locally.
What connects the two worlds is an assertion. Registration runs through an outpost contract on the source chain, which proves that a real validator authorized a specific operator key. On Ethereum, the validator's withdrawal key signs an EIP-712 message on the outpost, providing the consensus public key as an identifier and binding the locally generated operator key to it. That signature is produced once, in your own wallet, and authorizes a data role. It transfers no ability to move stake and no ability to act in consensus. The full mechanism is documented in the outpost reference.
Data signatures are not consensus signatures. A compromised Generator is a compromised data producer, not a compromised validator.
Does it create slashing risk?
Running a Generator does not introduce a new consensus duty or require access to validator signing keys. Operators should still isolate, monitor, and secure it like any other service connected to node infrastructure.
The honest risks are the ordinary ones: a process reading from your node adds RPC load, an exposed API surface is an exposed API surface, and any service on shared infrastructure competes for resources. The Generator client actively calls eth_getBlockByNumber and eth_getTransactionReceipt against the upstream node, so teams running a single node under existing load should size for that or point the Generator at a different one. Its GraphQL and REST endpoints are built for local or private network access and should not be published to the internet.
None of that is a consensus fault condition. All of it is worth treating with the same discipline you apply to every other daemon near a validator.
What additional infrastructure is required?
A Generator is designed as a lightweight sidecar to the infrastructure already required to validate the chain. It does not require another validator stack or a second copy of the chain.
No RPC provider is involved. The Generator reads from the node you run, over the interface that node already exposes on your own network. If you are paying anyone for an endpoint, something has gone wrong with the deployment.
CPU demand is modest. Storage and host stability are the variables that matter, and both depend on the retention policy you choose. Pruning is on by default and keeps the Generator's own footprint bounded. Chain-specific sizing lives in the hardware requirements documentation rather than in a general article because the numbers change with the chain and the release.
Does it have to run on the validator machine?
No. Deployment is your choice:
- Co-located with the node it reads from
- On separate infrastructure inside the same network
- On separate infrastructure connecting to the node remotely
- Isolated entirely from key management and consensus processes
The Generator needs reachable JSON-RPC and WebSocket interfaces on your own node, its own identity, and outbound connectivity. Where it sits relative to your key management and consensus processes is an isolation decision you make, not a constraint imposed by the client.
Deployment separation does not change eligibility. Wherever the process runs, the operator behind it must be an eligible validator on the chain whose data it produces.
What data does it produce?
Chain neutral primitives first: blocks, transactions, receipts, logs or events, and chain specific metadata.
On the current Ethereum testnet that means blocks, transactions, logs, and EIP-2930 access lists, indexed by block hash, transaction hash, block number, and document. Data is available from whatever start height you configure, and backfill depth is an operator decision. Starting further back takes longer to catch up and contributes more history to the network.
Primitives differ by chain. A CosmosSDK chain or an L2 will not decompose into the same shapes as Ethereum, which is why the Generator is implemented per chain rather than as one universal parser.
How is the data verified?
- The Generator structures data read from the node
- It creates a cryptographic commitment over what it produced
- It signs the commitment with its node identity key
- Hosts verify the signature against the registered Generator
- Hosts compare data received from independent Generators and record agreement
- Applications use that agreement as a confidence threshold
Host documentation describes this as an AttestationRecord: a count of how many distinct Generators signed identical data. A signature proves who produced a document and that it has not been altered. Agreement across independent producers is what makes it hard to fake. Verification is a property of the network, not of any one operator's reputation.
What happens after the data leaves the Generator?
Hosts receive signed primitives, verify them, execute Views over them, store the results, and serve queries. A View is a versioned, reusable definition of a dataset: a query over primitives, a GraphQL schema, and Lens transforms that filter, decode, and reshape. Applications reach that output through the Gateway.
Chain node → Generator → Host → View → Gateway → Application
Your responsibility ends at signed, replicated primitives. Everything downstream is a separate role with separate infrastructure.
Can a validator also operate a Host?
Yes, and the roles stay distinct. Generators produce source data from chains they validate. Hosts verify, transform, store, and serve, and do not need to be validators at all. An operator can run both, one, or either.
They have different hardware profiles, different uptime characteristics, and different commercial positions. Running a Host is a data infrastructure business. Running a Generator is an extension of the validation business you already operate. Treat the decisions separately.
How will Generators earn?
Testnet participation is currently focused on validating the software, the network, and the operator experience. Nobody is earning production revenue today, and any claim otherwise should be treated with suspicion.
The production network is designed to compensate operators when applications consume data they helped produce. Payment flows through the network rather than through individual bilateral deals, and revenue is distributed across the roles that did work: production, hosting, transformation. Exact allocation, fee structure, and payout mechanics will be published once the economic model is approved, not sketched in advance.
What testnet does buy you is position. Supported chains, dataset priorities, and operator requirements are being decided now, by the people in the room.
The strongest objection
Validators should focus on consensus. Attaching anything else to node infrastructure is risk for unproven revenue.
This is the right instinct and it deserves a direct answer rather than a rebuttal.
The risk is real but bounded, and it is the same class of risk operators already accept from monitoring agents, MEV infrastructure, and telemetry: a process near the node, isolatable, with no signing authority. The Generator can run on separate hardware, holds no consensus key, and pushes data one way.
Revenue is unproven and testnet is not where it arrives. The reason to run one now is different.
Your infrastructure produces every piece of data anyone reads from this chain. You bought the hardware and you carry the capital risk. An indexer sitting outside the network takes that output, puts it behind a pricing page, and bills the builders in your own ecosystem for access to it. You get nothing, the ecosystem gets nothing, and a company that has never carried a slashing risk in its life books the margin.
The network gets built either way. What is still open is who shapes it. Supported chains, dataset priorities, client behaviour, and what the network asks of operators are being settled right now by the operators running it. Sit this one out and the same companies keep charging rent on data your infrastructure produced, in the ecosystem you secure.
What Shinzo needs from testnet operators
- Run the Generator against a real node
- Maintain uptime and report gaps
- Report installation and upgrade friction
- Test deployment isolation from validator infrastructure
- Review resource usage against your own baselines
- Participate in client upgrades
- Benchmark performance and tell us where it degrades
- Give operational feedback that changes the software
Operator feedback at this stage shapes the client, the requirements, and the economics. Later feedback shapes tickets.
How to join
- Review the Generator documentation and hardware requirements
- Install the Generator client
- Point it at the JSON-RPC and WebSocket interfaces on your own chain node
- Complete assertion and registration, then back up your node identity key
- Confirm your Generator appears in the registry and health checks are green
- Join the operator channel on Discord
Run a Generator on the Shinzo testnet. Start with the operator quickstart.