PUBLIC GATEWAYPublished / verify live
Genesis-4 JSON-RPC
https://posternlabs.com/g4rpcStart with getcapabilities and getchaininfo. For transactions, query gettxstatus; verify each method against the active release.
BLOCH NETWORK / OPERATIONS PORTAL
Make the network operable.
One entry point for Genesis-4 RPC access, node operations, validator onboarding and integration work. Each surface is marked by its actual stage.
Published access and source components exist today. Managed Ops APIs, delegation setup and cross-chain PQ Shield services need further qualification.
OPS / SERVICE MAPGENESIS-4
01RPC gatewayPUBLISHED
02Validator guidePUBLISHED
03Delegation setupNOT ACTIVE
04Wallet service APIsPLANNED
05PQ Shield integrationREFERENCE
STATUS IS A PRODUCT CONTRACT, NOT A PROMISE OF AVAILABILITY
As of 23 Sep 2026Verify the deployed node and current checkpoint before any value-bearing operation.Inspect the explorer ↗
01 / NETWORK ACCESS
Connect to the chain.
Know the boundary.
The public endpoint is a published gateway. Confirm reachability, method support and chain identity in your own integration.
CHAIN OBSERVATIONPublic
Explorer + records
Inspect blocks, transactions, validators and network data before building operational decisions around them.
Open explorer ↗SELF HOSTEDOperator controlled
Your own node
Run a local RPC behind your access controls. Node RPC is not a key service and should remain on loopback or behind an authenticated proxy.
Read node setup ↗The gateway is operated outside this static site. A listed URL is not an uptime commitment, write entitlement or guarantee of transaction acceptance.
02 / VALIDATOR OPERATIONS
Join with evidence,
then operate with discipline.
A synchronized node and an admitted validator are different states. Onboarding must check the current release, checkpoint, keys and admission conditions.
Trust the right chain
Review release artifacts, genesis identity and the latest valid weak-subjectivity checkpoint before sync.
Separate the keys
Keep validator signing, withdrawal authority and backups in distinct operational controls. No secrets enter this portal.
Check admission
Query getvalidatoradmission on a synchronized node; review stake, fees and queue before any deposit.
Monitor participation
Track peer health, slot progress, finalized checkpoints and the complete exit and withdrawal path.
Operator guide / published
Open validator guide ↗The guide contains version-specific commands and documents unresolved qualification for the full exit and withdrawal cycle. Refresh the checkpoint instructions before use.
03 / STAKING + WALLET INTEGRATION
Useful interfaces.
Clear activation gates.
Protocol code and an operational service are separate milestones. These workflows are described for integrators without implying that they can be used to move value today.
DELEGATION / NOT ACTIVE
Delegated staking setup
The protocol contains delegation accounting, but the deployed transaction admission path still rejects delegation. A self-service setup will follow verified activation and tested entry, exit and withdrawal flows.
- Validator discovery and risk data
- Commission and lockup disclosure
- Activation, deactivation and withdrawal tracking
WALLET API / PLANNED
Wallet creation without custody
A future API can provide network configuration, address validation and unsigned transaction preparation. Key creation and signing must stay on the client device or the integrator's controlled signer.
- Local mnemonic and address derivation
- UTXO, fee and transaction preparation
- Signed broadcast and receipt lookup
SDK / PUBLISHED COMPONENTS
Exchange and app integrations
Use the Genesis-4 integration references and wallet SDK components while confirming the active API contract. A managed, versioned Ops endpoint is still a roadmap item.
- Explicit network and chain binding
- Transaction status and finality data
- Documented error and retry semantics
04 / PQ SHIELD
Post-quantum controls
for other systems.
A non-custodial PQ Shield reference API can build and verify unsigned Bitcoin vault and anchor artifacts from public inputs. Customer-facing hosting, other-chain adapters and security review remain future work.
REFERENCE CAPABILITIES
01
Vault address and witness-script construction
02
Unsigned transaction and sighash preparation
03
Bloch anchor commitment and verification
04
Partner adapters and managed policies Proposed
The reference API never takes a mnemonic or private key and never signs. On a chain that validates only classical signatures, an external PQ approval or anchor does not change that chain's native consensus rules or make its assets unconditionally quantum secure.
05 / DELIVERY SEQUENCE
From access to
qualified operations.
Published entry points are a starting point. Service claims follow repeatable release and security evidence.
Access + guides
RPC gateway, explorer, operator documentation and source components. Verify current runtime behavior.
Operational contracts
Versioned method catalog, health checks, onboarding artifact freshness and transaction status examples.
Delegation + wallet flows
Only after transaction activation, lifecycle testing, wallet security review and clear signer boundaries.
PQ Shield integrations
Chain-specific adapters, threat models, independent review and controlled pilots before managed deployment.
OPERATIONS BEGIN WITH VERIFICATION
Build on a network
you can inspect.
Bloch Ops connects published access to the next set of reliable operator interfaces.