Keep the network alive. Earn by doing useful work.
ZooBC needs reliable infrastructure: nodes that validate the chain, gateways that route public traffic, archival services that preserve history, and operators who understand continuity and security.
Why this symbol?
The elephant represents memory, continuity, and dependable strength. These are the qualities infrastructure operators bring to a network that must remain available and preserve its history.
Operate a service whose failure is visible before it becomes contagious.
ZooBC infrastructure is not one interchangeable server. A full node validates and accepts transactions, an archival service preserves deep readable history, a gateway routes public traffic to allowed healthy services, and a relay has its own network role. Operators must know which service is responsible before diagnosing it.
Respect service boundaries
Gateway GET requests may use archival history, while POST requests must reach a full node with a mempool. An archival service is read-only. Sending writes to the wrong service can look like a chain failure when it is only a routing error.
Verify what you install
Hash every node, gateway, Wallet, or utility release before execution. Compare the exact fingerprint with release evidence and reject revoked, missing, or unexplained files. Operational urgency is not a reason to skip provenance.
Measure health in layers
Machine CPU, memory, disk, and uptime answer a different question from gateway reachability, allowlist health, chain height, peer connectivity, and registry status. A green machine can still serve stale chain data.
Protect the control plane
Gateway administration uses a per-box admin key with no default value. Allowlist writes and release synchronization belong behind that boundary. Public chain reads must not quietly inherit administrative authority.
Diagnose the failed layer, not the nearest symptom.
The same blank screen can come from a browser, gateway, archival service, full node, allowlist, or chain-state problem. Check them in order.
| Symptom | Likely boundary | Operator check |
|---|---|---|
| GET history fails | Gateway route or archival service | Check gateway status, archival reachability, and whether the 404 has a response body before treating it as a route fallback. |
| Transaction will not broadcast | Full-node route or mempool | Confirm the POST reached a full node. Archival services are read-only and cannot accept a transaction. |
| Specific-node hostname is refused | Gateway allowlist | Confirm the node IP and port are admitted. The restriction prevents the gateway from becoming an open proxy. |
| Dashboard is green but height is stale | Chain-facing service | Compare blockchain status and latest block with another healthy endpoint; machine uptime alone does not prove chain freshness. |
| Release appears but cannot be trusted | Release registry or authority | Hash the exact file, inspect release status, and confirm the current release authority independently. |
| Disk pressure rises | Host capacity or archival growth | Inspect system stats, retention role, logs, and growth before availability is affected; do not wait for a service crash. |
Use a runbook that leaves evidence.
An operator should be able to explain which binary is running, where it came from, what role it serves, which network it follows, and how its health was measured.
- 01
Define the service
Record whether the host is a full node, archival service, gateway, relay, or combination explicitly supported by the deployment. Record domain, API port, network, and the owner responsible for intervention.
- 02
Verify and install
Acquire the current package, calculate SHA-256, compare release evidence, review the configuration, and protect generated credentials. Keep the fingerprint and version in the deployment record.
- 03
Prove both machine and chain health
Check system resources and gateway status, then query blockchain status and the latest block. Compare height and freshness with an independent endpoint before declaring the service ready.
- 04
Exercise the actual role
For gateways, test public reads, specific-node routing, and authorized allowlist behavior. For full nodes, test transaction submission safely on testnet. For archival services, test deep history reads.
Do not expose a new service as healthy when the binary is unverified, the network is ambiguous, the chain height is stale, administrative credentials are default or shared, or the service role has not been exercised end to end.
Keep operations tied to live controls and maintained references.
Status pages show the present; manuals explain behavior; the Explorer provides independent network context; the security and rewards pages explain why the service matters.
Gateway mode, reachability, allowlisted nodes, chain-facing status, and machine statistics.
↗RUNBOOKDeveloper operationsGateway routing, node targeting, allowlists, relays, release tools, downloads, and operational endpoints.
↗CONTROL PLANEAdmin referenceAuthenticated allowlist and release synchronization endpoints for gateway administration.
↗NETWORK VIEWExplorer networkRegistered nodes, gateways, relays, archival services, and current network activity.
↗CONSENSUSChain securityBuilder selection, registry behavior, participation score, and attack-cost mechanics.
↗REWARDSCoinbase modelEmission curve, reward distribution assumptions, fees, and expected node outcomes.
↗Reliability is a record, not a feeling.
Operate so another qualified person can understand the service and recover it without guessing.
- Record versions, hashes, configuration ownership, and network identity.
- Monitor machine resources and chain freshness separately.
- Use distinct, protected administrative credentials per box.
- Test read and write paths against the correct service role.
- Describe outages as unavailable or stale until measurements return.
- Send transaction POSTs to an archival service.
- Treat host uptime as proof the node is synchronized.
- Expose administrative routes or keys in public documentation.
- Add arbitrary targets to the gateway allowlist.
- Install a release whose fingerprint or authority cannot be confirmed.
Does this sound like you?
For node operators, gateway operators, infrastructure engineers, and technically capable network stewards.
You are comfortable running services, reading logs, and maintaining systems.
You want participation to come from useful network work rather than mining hardware or passive wealth.
You care about uptime, security, verification, and long-term continuity.
You want to help test infrastructure before mainnet genesis.
Enter through a real door.
Each route below leads to an existing ZooBC page, tool, or current community destination.
Download and run
Get the published node software and use the verification tools before installation.
↗GATEWAYUnderstand the gateway
See how public traffic reaches healthy nodes and review the live gateway status.
↗OPERATIONSRead the operator guide
Review node, gateway, API, allowlist, release, and operational information.
↗Follow the evidence.
Use the source that matches the question instead of relying on a single marketing page.
From interest to participation.
- 01Verify and install the current software
- 02Connect to testnet and monitor behavior
- 03Coordinate production requirements before mainnet
Keep the network alive. Earn by doing useful work.
ZooBC needs reliable infrastructure: nodes that validate the chain, gateways that route public traffic, archival services that preserve history, and operators who understand continuity and security.