Seed nodes and discovery
Stable seed endpoints help a young network find initial peers without becoming permanent traffic relays by accident. Peer diversity, inbound capacity and address propagation are monitored against documented limits.
Web3 & Blockchain
Node infrastructure that the client can inspect and take over
We operate seed, validation and RPC nodes with explicit access boundaries, chain-health monitoring and reproducible recovery across regions.
Capabilities
What this service delivers
Authenticated RPC endpoints
RPC methods are separated by caller and risk, with private networking, authentication and request quotas around exposed interfaces. Administrative wallet and node-control methods are not placed on a public application endpoint.
Sync, snapshot and resync
Bootstrap snapshots are created from identified software versions and verified heights with integrity manifests. Runbooks cover snapshot restoration, trusted validation boundaries and full resynchronisation when a snapshot is unsuitable.
Storage and pruning
Capacity models include chain growth, state databases, indexes, logs and temporary space required during upgrades. Pruning is enabled only where historical serving, recovery and application dependencies permit it.
Chain and peer monitoring
Metrics track block height, tip age, peer count, resource pressure and RPC latency across independent nodes. Hash disagreement at comparable heights raises a fork alert rather than being averaged into a healthy status.
Controlled upgrades and restart
Binaries, configuration and data migrations are staged on a non-critical node before rolling replacement. Restart order preserves peer and RPC capacity, with rollback criteria fixed before the change begins.
Technology stack
Tools used for the work
LinuxTerraformAnsibleDockerPrometheusGrafanaOpenTelemetryWireGuardBitcoin Core
Process
How the engagement runs
01
Classify node roles
We map seed, validation, archive, pruned and application RPC responsibilities separately. Each role receives explicit network exposure, storage, retention and recovery requirements.
02
Build reproducible infrastructure
Hosts, networks, firewall policy and node configuration are represented as reviewable code. Secrets and RPC credentials are issued per environment and caller rather than copied between machines.
03
Synchronise and verify
Nodes sync from known software and genesis parameters, with checkpoints used only where the protocol and client approve them. Heights, hashes and sampled state are compared before an endpoint is declared ready.
04
Exercise operations
Snapshot restore, full resync, failed upgrade, disk pressure and regional loss are rehearsed. Monitoring is tuned to distinguish normal slow blocks from stalled or divergent consensus.
05
Transfer operating knowledge
The client receives infrastructure definitions, access inventory, restore procedures and dependency records. Joint drills confirm that nominated operators can replace a host and revoke Genisys access.
01
Young networks need discovery without dependency
Seed nodes give new peers reachable starting addresses, but they should not become the only route into the network. We distribute seeds across providers and regions, observe peer diversity and document bootstrap alternatives in node releases. DNS or fixed seeds remain an availability dependency until independent operators emerge.
Hosting more machines under one organisation does not make a chain decentralised. If Genisys runs most reachable nodes, the network retains concentrated administrative, provider and upgrade risk regardless of geographic labels.
02
RPC exposure follows method risk
Public chain reads, transaction submission and administrative controls have different consequences and should not share unrestricted credentials. Private networks, mutual authentication, method allowlists, quotas and response-size limits reduce the chance that an application query becomes node control or resource exhaustion.
RPC availability is bounded by node health and chain state. Load balancers remove unhealthy instances but must not conceal fork disagreement; callers need an explicit degraded response when backends report incompatible tips.
- Per-caller RPC credentials
- Method and request limits
- Independent tip comparison
- Audited administrative access
03
Recovery requires more than a backup file
Chain data can often be downloaded again, while configuration, keys, peer policy and application indexes may not be replaceable in the same way. Backups are classified by role, encrypted and restored on a schedule. Snapshot manifests identify network, height, block hash, client version and integrity digest.
A snapshot shortens transfer but does not remove validation assumptions. We retain a full-resync procedure and enough free storage for database rewrites, migration copies and rollback. Pruning decisions record which historical queries will no longer work.
04
Operations should be transferable
Infrastructure definitions, node configuration, alerts and restart procedures stay in repositories accessible to the client. Credentials are separable, provider ownership is explicit and dependencies are recorded so another operator can reproduce the estate without undocumented Genisys accounts.
We can manage nodes and incident response, but we do not require permanent operational control. The client should be able to take the infrastructure over, revoke our access and appoint independent operators without rebuilding the network design.
FAQ
Common questions
What is included in managed blockchain node hosting?
It includes provisioned hosts, node configuration, monitored sync and peers, controlled RPC, upgrades, backups and recovery procedures for agreed roles. Application support and protocol changes are scoped separately.
How do you secure a blockchain RPC endpoint?
We separate methods by risk and apply private networking, authentication, quotas and request bounds. Wallet, peer-control and shutdown methods remain isolated from ordinary application callers.
Can hosted nodes make a blockchain decentralised?
No. Nodes controlled by Genisys or one client remain a concentrated administrative domain even when spread across regions and providers.
How are blockchain node snapshots verified?
Each snapshot is tied to a network, block height, block hash, client version and integrity digest. Restoration includes tip and sampled-state comparison, while a full resync remains available when trust assumptions are unacceptable.
What happens when blockchain node storage fills up?
Alerts should trigger before the filesystem reaches a dangerous threshold. Capacity can be expanded or eligible nodes pruned, but pruning is not used where archive queries or recovery obligations require full history.
Can the client take over the hosted nodes?
Yes, provided provider access and ownership are arranged accordingly. We deliver infrastructure code, configuration, credential inventories and runbooks, then verify takeover through a joint recovery exercise.
Related services
Connected engineering capabilities
Plan a blockchain node hosting engagement.
Share the problem, current system and constraints. We will respond with the questions needed to define a credible next step.