01
Pin the release
Record the release artifact, its digest and the node version. Compare the version expected by the activation notice with the binary actually running on your host.
Evidence: artifact digest + running build identityGENESIS-4 / OPERATOR DESK
Prepare the node.
Prove the path.
A validator journey starts with a trusted release, the right chain and observable finality. Check admission against the current RPC response and qualify the complete exit and withdrawal lifecycle independently.
DEPLOYED STATE FIRST
The current public gateway response is shown above when available. Confirm its network domain, admission terms and chain freshness against your own synchronized node. Source defaults do not establish the deployed binary's state.
RPC endpoint ↗01 / PREPARATION
Build an evidence trail
before a bond.
Repeat these read-only and offline checks against the exact deployed release. An active admission flag alone does not establish that the full exit and payout lifecycle is qualified.
02
Verify the chain
Confirm the canonical Genesis-4 manifest and a current weak-subjectivity checkpoint from trusted release material. Compare head, block identity and finalized checkpoint against independent peers.
Evidence: manifest identity + matching finalized root03
Prepare signing custody
Keep the validator signer, funding authority and withdrawal spending authority under separate controls. Preserve sealed backups and slashing-protection records; never place seeds in a web form.
Evidence: custody and recovery procedure04
Qualify connectivity
Observe peers, slot progress, finality and restart behavior on your own node. Keep its RPC on loopback or behind authenticated access and monitor it independently of public gateways.
Evidence: synchronized node + restart observation05
Check live admission
Call getvalidatoradmission on a synchronized node and compare the public gateway. Verify active, activation_epoch, network domain, stake bounds, queue limits and fee quote. Use getvalidatorbykey for a candidate's state; confirm method support on each endpoint.
Read-only verification
Send this JSON-RPC body as a POST to https://posternlabs.com/g4rpc or your own synchronized node. Compare network_domain, epoch, active and activation_epoch; retain the response time and node identity. Never infer exit or withdrawal readiness from active alone.
{"jsonrpc":"2.0","id":1,"method":"getvalidatoradmission","params":[]}No step here asks for a deposit or a private key. A quote from the current head can change before inclusion.
OPERATOR TOOL / READ ONLY
Run a node
preflight.
Collect a timestamped report from your own node before considering any bond. The tool checks chain identity, head lag, finality progress, peers, build identity and admission terms. It cannot certify checkpoint authenticity or the exit-to-payout lifecycle.
Compare what each node actually reports.
Use an independently authenticated network domain as an input. An optional second RPC can reveal a conflicting domain or finalized root at the same epoch. Matching RPC answers are observations, not proof of independent operation.
node preflight.cjs \
--rpc http://127.0.0.1:8545 \
--reference-rpc https://posternlabs.com/g4rpc \
--expect-domain "$BLOCH_NETWORK_DOMAIN" \
--evidence-dir ./preflight-evidence-newNode.js 18+ · zero dependencies · only getchaininfo, getbuildinfo and getvalidatoradmission · no signing or value movement. Sequential per-method diagnostics identify timeouts and RPC errors; any failed method fails the report. The optional evidence bundle records selected public RPC fields and build identity in a new owner-only directory; signed manifest, checkpoint and exit-to-payout verification remain manual. Replace the local URL with your node's real RPC address.
OPERATOR ARTIFACT / V1
Record each gate.
Keep the evidence.
The versioned worksheet starts unqualified. Fill a private copy with authenticated release material, local RPC observations and exact-release lifecycle records. A passing read-only preflight does not change its manual gates.
Manifest and checkpoint
Authenticate the network domain, signed weak-subjectivity checkpoint and signer set through trusted channels.
Installed binary
Match the activation notice and artifact digest to the binary running across the validating fleet.
Funded registration
Recheck the current RPC quote, native funding inputs, offline signing roles and activation queue.
Signer and recovery
Separate signing, funding and withdrawal authority; retain backups and slashing protection.
Exit to payout
Require mainnet exit, production withdrawal delay and a finalized, spendable payout.
Not active
No self-service delegation transaction or deposit path is open.
Do not put private keys, mnemonics, keystore contents or RPC credentials in the worksheet. The JSON is a template, not a live attestation or opening notice.
02 / VALIDATOR ADMISSION
Admission signal.
Independent checks.
Use the current gateway response and complete the remaining operator checks before treating a single admission flag as evidence of a qualified end-to-end service.
Admission signal
Read active, activation epoch, network domain, minimum stake and fee quote from a current RPC response on your own synchronized node.
Fleet identity
Record the running binary and network domain on your own node. Compare finalized roots at the same checkpoint with independent peers.
Network evidence
Review process-level joining, finality, restart and recovery evidence for the deployed release, not just a source-tree rehearsal.
Exit to payout
Confirm authenticated exit, the production withdrawal delay and a spendable payout on mainnet. This qualification is still pending in the available evidence.
Opening notice
Look for a current operator notice that identifies the deployed release and the completed lifecycle. An active RPC flag alone is insufficient.
03 / DELEGATED STAKING
Designed in protocol.
Not open for funds.
Active funded validator admission does not activate delegation. The legacy unfunded Delegate path remains disabled; delegation accounting in source is not a production entry, exit or withdrawal service.
SELF-SERVICE DELEGATIONNOT ACTIVE
What the setup will need
- Qualified validator records and transparent commission terms.
- A funded, replay-safe transaction path with independently tested signing.
- Observable activation, rewards, slashing exposure, exit and withdrawal state.
- Published mainnet activation and recovery procedures.
No delegation amount, APY or opening date is shown until a qualified service can support it.
FOR DELEGATORS
Inspect first
Use explorer records to follow validator identity, participation and finality. Treat displayed protocol fields as observations, not an offer to stake.
Explore validators ↗FOR OPERATORS
Plan the full lifecycle
Prepare monitoring and signer controls now. Verify exit and withdrawal readiness independently of admission status.
Open operator guide ↗04 / SOURCE OF TRUTH
Open the evidence.
Operational decisions should be based on the deployed release and an independently checked node, with source documents used to understand the intended contract.
01 / PUBLIC GUIDEValidator guideVersion-specific operator steps and checkpoint instructions↗02 / RELEASE GATESValidator opening checklistQualification, coordinated activation and opening condition↗03 / PROTOCOLFunded admission specificationFunding, signatures, queue and RPC behavior↗04 / OBSERVATIONBloch ExplorerBlocks, validators, transactions and finality↗
BLOCH OPS / GENESIS-4
Operate from verified state.
Before any bond, verify the deployed release, signer controls, current RPC quote and documented exit-to-payout evidence.