Scoring

Scoring is a core component of the consensus system in any Hypertensor subnet. It determines how each node is evaluated based on its performance, behavior, and contributions.

Each subnet is responsible for defining its own scoring algorithm, tailored to its unique goals and architecture. There are no hardcoded or on-chain role restrictions — subnets are free to design and implement any node classification or evaluation strategy they choose.

What Can Nodes Be Scored On?

You can design scoring around virtually any metric relevant to your subnet’s use case. For example:

  • Role-specific behavior

    • Validator accuracy, timeliness, or data quality

    • Worker reliability or output correctness

  • Performance metrics

    • Latency and uptime

    • Speed of consensus data submission or attestation

  • Economic or trust metrics

    • Delegate stake rate

    • Stake balance or reward history

    • Proof-of-Work (PoW) or Proof-of-Useful-Work (PoUW)

  • Reputation or longevity

    • Time active in the network

    • Historical behavior or consistency

💡 The scoring algorithm is executed in the Consensus class — both by the validator and by attesting peers — to ensure consistency and verifiability.

Tools Available for Scoring

Hypertensor gives you powerful primitives for designing decentralized scoring mechanisms:

  • Decentralized Storage Use DHT Record Storage to track task results, reveal hashes, validator scores, and more.

  • P2P RPC Calls Use rpc_* methods to interact with peers, check their state, request data, or verify task completion.

  • Blockchain Integration Access on-chain data such as stake amounts, delegate ratios, role registrations, or governance flags.

  • P2P Proofs Require peers to upload data (e.g., inference outputs, hashes, proofs) to the DHT or directly to other peers for validation.

Design Freedom

There are no enforced on-chain roles in Hypertensor. Every node starts as a general-purpose peer, and the subnet itself defines what each node is responsible for and how they are evaluated.

This flexibility allows you to:

  • Define custom node types (e.g., validators, trainers, relayers)

  • Apply dynamic or evolving scoring models

  • Experiment with staking incentives or decentralized governance

🎯 Your scoring system is not just a metric — it's the mechanism of trust that drives rewards, reputation, and responsibility within the subnet.

PreviousValidatorNextSuggested Design

Last updated