With the amount of new subnets being added it can be hard to get up to date information across all subnets, so data may be slightly out of date from time to time
With the amount of new subnets being added it can be hard to get up to date information across all subnets, so data may be slightly out of date from time to time
Hermes is a specialised Bittensor subnet (netuid 82) built by SubQuery to make blockchain data reliably usable by AI agents through GraphQL. Instead of treating “blockchain data access” as a generic chatbot problem, Hermes structures competition around a concrete capability: answering schema-grounded, project-specific GraphQL questions quickly and correctly across SubQuery projects and The Graph subgraphs.
The system works by continuously selecting “active” projects from a SubQuery-hosted board service, pulling each project’s manifest and schema (primarily from IPFS), generating synthetic numerical challenges from those schemas, and scoring miners against a validator-produced ground truth. Scores combine strict factual consistency checks with a latency weighting function and are smoothed by EMA; final scores are periodically converted into on-chain weights and submitted to Bittensor using the standard weight normalisation pipeline.
Hermes also supports “organic” queries sent by authorised external callers (for example, SubQuery’s AskSubQuery product). These organic requests are routed through a validator-run HTTP API that enforces a signature-based allowlist and then forwards the request to an eligible miner (based on project coverage plus synthetic performance thresholds). This connects real user demand to emissions via the subnet’s dual incentive mechanism (synthetic quality + organic workload/quality sampling).
Technically, the reference implementation is a Python 3.13 codebase using Bittensor (axon/dendrite/subtensor), FastAPI/Uvicorn for the validator’s HTTP entrypoints, and LangChain/LangGraph to build per-project “GraphQL agents” and miner toolchains. By default Hermes is designed as CPU-first (no GPU required in the published minimum compute spec), but it depends on modern LLM access (OpenAI-compatible APIs via OpenRouter or equivalents) and on-chain stake/registration mechanics typical of Bittensor subnets.
Hermes is a specialised Bittensor subnet (netuid 82) built by SubQuery to make blockchain data reliably usable by AI agents through GraphQL. Instead of treating “blockchain data access” as a generic chatbot problem, Hermes structures competition around a concrete capability: answering schema-grounded, project-specific GraphQL questions quickly and correctly across SubQuery projects and The Graph subgraphs.
The system works by continuously selecting “active” projects from a SubQuery-hosted board service, pulling each project’s manifest and schema (primarily from IPFS), generating synthetic numerical challenges from those schemas, and scoring miners against a validator-produced ground truth. Scores combine strict factual consistency checks with a latency weighting function and are smoothed by EMA; final scores are periodically converted into on-chain weights and submitted to Bittensor using the standard weight normalisation pipeline.
Hermes also supports “organic” queries sent by authorised external callers (for example, SubQuery’s AskSubQuery product). These organic requests are routed through a validator-run HTTP API that enforces a signature-based allowlist and then forwards the request to an eligible miner (based on project coverage plus synthetic performance thresholds). This connects real user demand to emissions via the subnet’s dual incentive mechanism (synthetic quality + organic workload/quality sampling).
Technically, the reference implementation is a Python 3.13 codebase using Bittensor (axon/dendrite/subtensor), FastAPI/Uvicorn for the validator’s HTTP entrypoints, and LangChain/LangGraph to build per-project “GraphQL agents” and miner toolchains. By default Hermes is designed as CPU-first (no GPU required in the published minimum compute spec), but it depends on modern LLM access (OpenAI-compatible APIs via OpenRouter or equivalents) and on-chain stake/registration mechanics typical of Bittensor subnets.
Hermes provides a decentralised, incentive-driven infrastructure for GraphQL query processing over indexed blockchain datasets, designed specifically to power AI agents and agentic applications that need fast and accurate on-chain answers. In SubQuery’s own positioning, Hermes is the “bridge between AI and the data layer of Web3” and does this by connecting specialised GraphQL-aware agents directly to blockchain data, then rewarding improvements in speed and accuracy.
At the subnet level, Hermes defines a competitive game for miners and validators:
Validators maintain a rotating set of “active projects” (SubQuery projects and The Graph subgraphs) and repeatedly generate synthetic GraphQL challenges from each project’s schema. Miners are rewarded for returning correct answers quickly; validators are rewarded for running the evaluation loop and maintaining consensus-quality scoring and weight submissions.
A key design choice in Hermes is that challenges are schema-grounded and numeric. The published incentive documentation describes synthetic challenges as numerical questions (counts, sums, averages, percentages) and notes that validators produce ground truth answers through their own agent and then score miner answers with a strict fact-checking prompt on a 0–10 scale (one decimal precision). Synthetic scoring is then multiplied by a quadratic latency weight relative to the validator ground-truth generation time.
Hermes is not only synthetic. It also exposes an “organic” pathway where an authorised caller can submit real chat-style questions (OpenAI-like “chat/completions” payloads) tied to a specific project identifier (cid_hash). The validator’s API verifies request signatures and timestamps and only accepts requests from a configured allowlist of signer addresses, then forwards the request to an appropriate miner and optionally streams the response back in a JSONL format containing both data chunks and final metadata.
Hermes’ practical aim is to reduce the friction and cost of letting AI agents “see” and use blockchain data. SubQuery’s product stack pairs Hermes with AskSubQuery (an MCP-based service that translates natural language to GraphQL and returns results in plain English). In SubQuery’s descriptions, Hermes trains/optimises the underlying agent behaviour via Bittensor incentives while AskSubQuery provides the user-facing interface and acts as an authorised caller that benefits from improvements in Hermes.
Hermes is both a Bittensor subnet and a runnable reference stack (validator + miner software + project/agent tooling) that implements the subnet’s incentive mechanism. The public implementation lives in the SN-Hermes/hermes-subnet repository and is structured around “neurons” (validator/miner), project ingestion and configuration, per-project GraphQL agents, and scoring/weight-setting infrastructure.
Below are the explicit technical attributes requested, using only verifiable details from the official site, code, and SubQuery announcements.
Bittensor network and netuid Hermes runs as netuid 82 on Bittensor mainnet (Finney), as shown by the configuration examples and the validator/miner documentation that explicitly states it applies to “Bittensor Finney.” Testnet support is documented as running on netuid 280.
Mining and validator roles Miners run a Bittensor axon and compete to answer two request types:
Project selection / project management (which projects are “active”).
Hermes provides a decentralised, incentive-driven infrastructure for GraphQL query processing over indexed blockchain datasets, designed specifically to power AI agents and agentic applications that need fast and accurate on-chain answers. In SubQuery’s own positioning, Hermes is the “bridge between AI and the data layer of Web3” and does this by connecting specialised GraphQL-aware agents directly to blockchain data, then rewarding improvements in speed and accuracy.
At the subnet level, Hermes defines a competitive game for miners and validators:
Validators maintain a rotating set of “active projects” (SubQuery projects and The Graph subgraphs) and repeatedly generate synthetic GraphQL challenges from each project’s schema. Miners are rewarded for returning correct answers quickly; validators are rewarded for running the evaluation loop and maintaining consensus-quality scoring and weight submissions.
A key design choice in Hermes is that challenges are schema-grounded and numeric. The published incentive documentation describes synthetic challenges as numerical questions (counts, sums, averages, percentages) and notes that validators produce ground truth answers through their own agent and then score miner answers with a strict fact-checking prompt on a 0–10 scale (one decimal precision). Synthetic scoring is then multiplied by a quadratic latency weight relative to the validator ground-truth generation time.
Hermes is not only synthetic. It also exposes an “organic” pathway where an authorised caller can submit real chat-style questions (OpenAI-like “chat/completions” payloads) tied to a specific project identifier (cid_hash). The validator’s API verifies request signatures and timestamps and only accepts requests from a configured allowlist of signer addresses, then forwards the request to an appropriate miner and optionally streams the response back in a JSONL format containing both data chunks and final metadata.
Hermes’ practical aim is to reduce the friction and cost of letting AI agents “see” and use blockchain data. SubQuery’s product stack pairs Hermes with AskSubQuery (an MCP-based service that translates natural language to GraphQL and returns results in plain English). In SubQuery’s descriptions, Hermes trains/optimises the underlying agent behaviour via Bittensor incentives while AskSubQuery provides the user-facing interface and acts as an authorised caller that benefits from improvements in Hermes.
Hermes is both a Bittensor subnet and a runnable reference stack (validator + miner software + project/agent tooling) that implements the subnet’s incentive mechanism. The public implementation lives in the SN-Hermes/hermes-subnet repository and is structured around “neurons” (validator/miner), project ingestion and configuration, per-project GraphQL agents, and scoring/weight-setting infrastructure.
Below are the explicit technical attributes requested, using only verifiable details from the official site, code, and SubQuery announcements.
Bittensor network and netuid Hermes runs as netuid 82 on Bittensor mainnet (Finney), as shown by the configuration examples and the validator/miner documentation that explicitly states it applies to “Bittensor Finney.” Testnet support is documented as running on netuid 280.
Mining and validator roles Miners run a Bittensor axon and compete to answer two request types:
Project selection / project management (which projects are “active”).
Hermes is described by SubQuery as “SubQuery’s dedicated Bittensor subnet” and SubQuery’s official communications state it is built by the SubQuery team. The authoritative materials that directly connect the team to Hermes are SubQuery’s Hermes announcement posts and SubQuery’s own organisational/team pages.
At the codebase level, the public GitHub repository lists two contributors (GitHub handles cool-firer and ianhe8x). The repository does not publish a complete organisational chart of Hermes-specific engineers; therefore, any additional role mapping beyond what is publicly stated by SubQuery is unspecified.
Ian He – CTO & Co-Founder of SubQuery; quoted on Hermes launch; also a listed GitHub contributor (ianhe8x)
Brittany Seales – Head of Marketing at SubQuery; author of Hermes launch posts
Scott Twiname – Principal Dev of SDK at SubQuery
Marta Adamczyk – Head of Business Development at SubQuery
James Bayly – Advisor listed on SubQuery core team
Luke – (GitHub: cool-firer) Listed GitHub contributor to SN-Hermes/hermes-subnet
Hermes is described by SubQuery as “SubQuery’s dedicated Bittensor subnet” and SubQuery’s official communications state it is built by the SubQuery team. The authoritative materials that directly connect the team to Hermes are SubQuery’s Hermes announcement posts and SubQuery’s own organisational/team pages.
At the codebase level, the public GitHub repository lists two contributors (GitHub handles cool-firer and ianhe8x). The repository does not publish a complete organisational chart of Hermes-specific engineers; therefore, any additional role mapping beyond what is publicly stated by SubQuery is unspecified.
Ian He – CTO & Co-Founder of SubQuery; quoted on Hermes launch; also a listed GitHub contributor (ianhe8x)
Brittany Seales – Head of Marketing at SubQuery; author of Hermes launch posts
Scott Twiname – Principal Dev of SDK at SubQuery
Marta Adamczyk – Head of Business Development at SubQuery
James Bayly – Advisor listed on SubQuery core team
Luke – (GitHub: cool-firer) Listed GitHub contributor to SN-Hermes/hermes-subnet
Hermes was officially announced and launched as SubQuery’s dedicated Bittensor subnet on 15 January 2026. This milestone is marked as Implemented (publicly launched/announced), supported by the SubQuery announcement post dated 15 January 2026. This announcement formally introduced Hermes as the indexing and data-serving layer aligned with Bittensor, establishing its role within the broader SubQuery ecosystem.
On 21 January 2026, Hermes and AskSubQuery were publicly described as a connected stack, with AskSubQuery positioned as an authorised caller benefiting directly from Hermes. This milestone is marked as Implemented (publicly described integration; authorised-caller concept) and is supported by a SubQuery recap post dated 21 January 2026. This clarified the architectural relationship between the two components, defining Hermes as the data-serving subnet layer and AskSubQuery as an application layer authorised to interact with it.
On 29 January 2026, AskSubQuery use cases were expanded through concrete examples of AI agents powered by AskSubQuery and integrated with Hermes. This milestone is marked as Implemented (product content; illustrates intended usage) and is evidenced by a SubQuery post dated 29 January 2026. These examples demonstrated the practical application of the Hermes subnet within AI-driven query and data workflows.
The core subnet operator stack—including miner and validator execution logic, project pulling mechanisms, scoring systems, and statistics dashboards—is marked with an unspecified date but classified as Implemented in public repo. The evidence for this milestone is found in the README documentation, supporting technical docs, and observable code paths within the public GitHub repository. These components collectively define the operational backbone of Hermes as a functioning Bittensor subnet.
The implementation of a signature-gated organic request API for authorised callers is also dated as unspecified and marked as Implemented in public repo. Evidence for this milestone includes validator-side API signature verification logic and allowlist enforcement mechanisms within the repository. This ensures that only approved callers—such as AskSubQuery—can submit organic requests into the subnet.
Finally, the introduction of cloud mining to lower barriers to entry is marked with an unspecified date and classified as Planned (no date given). Evidence for this milestone comes from the statement “Plans to introduce cloud mining” in the original SubQuery announcement. While not yet implemented, this initiative is intended to make participation in Hermes more accessible by reducing hardware and infrastructure requirements for miners.
Hermes was officially announced and launched as SubQuery’s dedicated Bittensor subnet on 15 January 2026. This milestone is marked as Implemented (publicly launched/announced), supported by the SubQuery announcement post dated 15 January 2026. This announcement formally introduced Hermes as the indexing and data-serving layer aligned with Bittensor, establishing its role within the broader SubQuery ecosystem.
On 21 January 2026, Hermes and AskSubQuery were publicly described as a connected stack, with AskSubQuery positioned as an authorised caller benefiting directly from Hermes. This milestone is marked as Implemented (publicly described integration; authorised-caller concept) and is supported by a SubQuery recap post dated 21 January 2026. This clarified the architectural relationship between the two components, defining Hermes as the data-serving subnet layer and AskSubQuery as an application layer authorised to interact with it.
On 29 January 2026, AskSubQuery use cases were expanded through concrete examples of AI agents powered by AskSubQuery and integrated with Hermes. This milestone is marked as Implemented (product content; illustrates intended usage) and is evidenced by a SubQuery post dated 29 January 2026. These examples demonstrated the practical application of the Hermes subnet within AI-driven query and data workflows.
The core subnet operator stack—including miner and validator execution logic, project pulling mechanisms, scoring systems, and statistics dashboards—is marked with an unspecified date but classified as Implemented in public repo. The evidence for this milestone is found in the README documentation, supporting technical docs, and observable code paths within the public GitHub repository. These components collectively define the operational backbone of Hermes as a functioning Bittensor subnet.
The implementation of a signature-gated organic request API for authorised callers is also dated as unspecified and marked as Implemented in public repo. Evidence for this milestone includes validator-side API signature verification logic and allowlist enforcement mechanisms within the repository. This ensures that only approved callers—such as AskSubQuery—can submit organic requests into the subnet.
Finally, the introduction of cloud mining to lower barriers to entry is marked with an unspecified date and classified as Planned (no date given). Evidence for this milestone comes from the statement “Plans to introduce cloud mining” in the original SubQuery announcement. While not yet implemented, this initiative is intended to make participation in Hermes more accessible by reducing hardware and infrastructure requirements for miners.