Hiero logo

HIP-1137: Block Node Discoverability via On-Chain Registry

6 min read•April 12, 2026

by Mounil Kankhara

Hiero

With the addition of Block Nodes to the Hiero ledger, network participants require a reliable mechanism to discover and connect to functioning block nodes and other network infrastructure services. HIP-1137, recently approved by the Technical Steering Committee, addresses this critical need by introducing a standardized on-chain registry for discoverable nodes.

This post explains HIP-1137's architecture, its technical implementation, and the impact it brings to the Hiero ecosystem.

Introduction and Background

As the Hiero network continues to grow, so does the diversity of infrastructure supporting it. Beyond consensus nodes that maintain the network state, conduct the Hashgraph consensus algorithm, and execute transactions, the ecosystem includes:

  • Block nodes – nodes that verify and persist block data
  • RPC relays – nodes providing EVM based interfaces on top of the Hiero network
  • Mirror nodes – nodes that ingest and index consensus network data output
  • Other infrastructure nodes supporting various network functions

Previously, there was no standardized, on-chain mechanism for node operators, other than consensus node operators, to advertise their infrastructure or for network participants to discover available services. This created friction for developers looking to connect to the network and for operators seeking to make their services known.

HIP-1137 addresses this gap by introducing an on-chain registry for discoverable nodes.

What is HIP-1137?

HIP-1137 establishes a standardized on-chain registry mechanism for discovering network infrastructure. The proposal introduces:

Registered Nodes as Network Infrastructure: Node operators can create, update, and delete registered node records directly on the Hiero network via new transactions in the Node Service.

Service Endpoints: Each registered node publishes one or more service endpoints with TCP/UDP ports, IP addresses (IPv4/IPv6), or fully-qualified domain names, along with optional TLS requirements.

Multiple Endpoints for each Node: The registry supports endpoints for block nodes, mirror nodes, RPC relays, and general services in a pluggable architecture. Each endpoint may provide additional information specific to the endpoint service, such as provided APIs.

Consensus Node Association: Consensus node operators can associate registered nodes they operate via the associated_registered_nodes list, enabling clients to find additional infrastructure associated with existing consensus nodes.

On-Chain Persistence: All node information is stored persistently in the ledger state, making it authoritative and universally accessible to all network participants.

Motivation and Goals

The Challenge: Block Nodes are critical infrastructure for the Hiero ledger, managing and providing access to block stream data, state snapshots, and content proofs. However, without a standardized discovery mechanism, clients cannot reliably find functioning block nodes. Node operators have no way to advertise their services on the network itself.

The Solution: HIP-1137 provides a trustworthy, dynamic mechanism for discovering nodes by leveraging network state as the source of truth. Node operators register themselves, ensuring they maintain control over their own presence and updates.

Key Benefits:

1. Reliable Service Discovery Clients and SDKs can query the ledger to discover available block nodes, mirror nodes, and RPC relays with current, authoritative information managed by the operators themselves.

2. Operator Control and Identity Each registered node has an associated admin_key controlled by the operator, ensuring only authorized parties can create, update, or delete node registrations. Each node can also associate with a node_account for financial responsibility and identity.

3. Extensible Architecture The registry supports multiple service types (block nodes, mirror nodes, RPC relays, general services) with type-specific metadata. New node types can be added in the future without breaking existing functionality.

4. Multiple Endpoints A single registered node can expose up to 50 different service endpoints, supporting multiple APIs or redundancy across different host addresses or FQDNs.

5. Scalable and Decentralized With the registry embedded in network state, there's no reliance on centralized directories or out-of-band coordination. The system scales naturally as more operators register their infrastructure.

Technical Implementation

HIP-1137 introduces three new transaction types for managing registered nodes on the network:

New Transaction Types:

  1. CreateRegisteredNode – Operators create a new registered node entry with:

    • Admin key (controls subsequent updates/deletions)
    • Description of the node (up to 100 bytes, when encoded UTF-8)
    • Service endpoints (up to 50 endpoints per node)
    • Node account identifier (optional, for financial responsibility)

  2. UpdateRegisteredNode – Node operators can modify:

    • Admin key
    • Description
    • Service endpoints
    • Associated node account

  3. DeleteRegisteredNode – Remove nodes from the registry (can only be deleted if not associated with a consensus node)

Service Endpoint Types:

The proposal supports multiple endpoint types:

  • Block Node Endpoints – Support for Block Node Status, Publish, Subscribe Stream, and State Proof APIs
  • Mirror Node Endpoints – Indexing and query services
  • RPC Relay Endpoints – EVM tool translator services
  • General Service Endpoints – Extensible for future node types

Each endpoint includes:

  • IP address (IPv4/IPv6) or fully qualified domain name
  • Port number
  • TLS requirement flag
  • Endpoint type and capabilities

Association with Consensus Nodes:

Consensus node operators can associate up to 20 registered nodes with their consensus node, indicating that the same entity operates both. This enables operators to publish the relationship on-chain.

Registered Node ID:

Each registered node receives a unique registered_node_id assigned by the network. This ID:

  • Must be unique within a shard and realm
  • Must never be reused, even if the node is deleted
  • Must not match any consensus node ID in the same network

For Developers:

  • Simpler Integration: Connect to Hiero services by querying available nodes rather than using hardcoded endpoints
  • Better Resilience: Implement load balancing and failover logic based on registry data
  • Future-proof: As the ecosystem grows, new infrastructure automatically becomes discoverable

Impact on the Ecosystem

User Stories Enabled by HIP-1137:

For RPC Relay Clients:

  • Discover available RPC relays on-chain and connect to EVM-compatible endpoints without external registries

For Block Node Operators:

  • Register as infrastructure providers and allow other nodes to discover you through block stream data
  • Manage multiple endpoints or geographic redundancy through a single node registration
  • Update service availability and capabilities in real-time

For Mirror Node Operators:

  • Present registered nodes to clients using authoritative on-chain data
  • Maintain their own infrastructure registry integrated with the protocol

For Developers and Application Builders:

  • Query the ledger to find available block nodes, mirror nodes, and other services
  • Implement client-side load balancing and failover logic based on registry data
  • Know that discovered nodes have an on-chain identity tied to a specific operator
  • Use SDK support to easily access the registry (initiatives underway across Java, JavaScript, Python, Go, Rust, Swift, and C++ SDKs)

For Private Hiero Network Operators:

  • Manage all registered nodes relevant to their network directly on-chain
  • Maintain a complete registry of their network's infrastructure

For Network Governance:

  • Identify and track trusted infrastructure providers
  • Remove obsolete or misbehaving nodes when necessary
  • Manage node creation through throttling and fee

HIP-1137 provides foundational infrastructure for several anticipated developments:

1. Payment and Reputation Models Future HIPs may build on this registry to enable:

  • Operators receiving payments for providing services
  • Reputation mechanisms tracking node reliability and performance
  • Automated reputation scoring using proof-of-space-time or proof-of-streaming concepts

2. Service Marketplace The extensible endpoint type system supports a future ecosystem where:

  • Various service types are discoverable and potentially monetized
  • New node types can be registered without protocol changes
  • Operators advertise specialized services and capabilities

3. SDK and Tooling Evolution All major Hiero SDKs are implementing HIP-1137 support to:

  • Automatically discover available nodes on network startup
  • Support intelligent load balancing across multiple discovered nodes
  • Provide fallback mechanisms when nodes become unavailable
  • Enable developers to build resilient applications

4. Network Operator Tools Community tools will leverage the registry for:

  • Network health monitoring and analytics
  • Infrastructure trend analysis
  • Geographic and availability redundancy tracking
  • Operator performance metrics and reporting

5. Mirror Node Enhancement Mirror nodes will extend their APIs (e.g., /api/v1/network/registeredNodes) to provide rich querying capabilities:

  • Filter nodes by type, location, or capabilities
  • Access endpoint details and operator information
  • Query node associations with consensus nodes

How to Learn More

To explore HIP-1137 in detail:

Conclusion

HIP-1137 represents an important step toward a more decentralized and discoverable Hiero network. By enabling on-chain registration and discovery of infrastructure nodes, it empowers operators to advertise their services while making it easier for developers to access the network.

As the Hiero ecosystem continues to mature, mechanisms like this will be essential for supporting a thriving, diverse infrastructure layer. The approval of HIP-1137 is a testament to the community's commitment to building a robust, scalable, and truly decentralized protocol.

Whether you're a developer looking to integrate with Hiero or a node operator considering how to participate in the ecosystem, HIP-1137 opens new possibilities for connection and collaboration.

Recent Hiero Posts