Subnet 36: Eirel
Eirel is Bittensor Subnet 36. Its on-chain identity describes it as an execution layer for multimodal AI workflows, and lists RendixNetwork/eirel-ai as the subnet’s GitHub repository.
What Eirel Provides
Eirel focuses on running and evaluating AI workflow agents inside a Bittensor subnet. The public repository describes a system where miner submissions are evaluated by validators, scores are aggregated, and the resulting weights are published to the Bittensor network.
The subnet’s first documented workflow family is a multi-turn assistant task. In that setting, miners compete on the quality of agent behavior, while validators evaluate the returned work and contribute scores that feed into Yuma Consensus.
Launch Family Context
Eirel’s public materials describe the launch family as general_chat, a multi-turn conversational
assistant task across instant and thinking modes. The important reader-facing point is that Subnet
36 evaluates agent behavior inside workflow tasks, not only one-shot text completion.
Eirel’s README describes that family as backed by tool
services including web search, URL fetching, sandboxed computation, and retrieval over per-run
document corpora.
That launch shape explains why the article treats Eirel as a workflow execution subnet. A miner is not merely submitting a static answer; it is submitting an agent package that can be evaluated across tasks with conversation history, tool requirements, and task-specific context. The miner guide frames miner work as agent submissions that validators later evaluate through task runs.
Miner and Validator Roles
Miners provide agents for workflow tasks. The important unit of work is the quality of the returned task result.
Validators evaluate those task results and submit scores for aggregation. The repository describes validator-side judging as part of the subnet design, while the on-chain weights remain the mechanism that connects those judgments back to Bittensor.
Evaluation and Transparency
Eirel’s validation design is notable because judging is described as validator-side work. The validator guide says validators receive tasks, evaluate miner-agent responses, score those responses locally, and publish weights from the scores they compute. That keeps the article’s emphasis on independent validator evaluation rather than on a single central scoring oracle.
The same guide describes Eirel scoring as a composite evaluation with gates for groundedness, safety, tool use, efficiency, and other task-quality factors. For readers, this means Subnet 36 is closer to an agent-evaluation market than to a simple chat leaderboard: useful behavior depends on answer quality, appropriate tool use, and avoiding responses that fail task constraints.
The root README also describes a post-run transparency pattern: after a scoring run closes, submission archives from that run become publicly downloadable from the leaderboard. That public artifact trail is relevant because competitors and observers can study what was scored after the run, while active evaluation still depends on validator scores and on-chain weights.
On-Chain Identity
Live SN36 data is available on TaoStats. The live Finney identity for netuid 36 registers the subnet name as Eirel, with the description “The execution layer for multimodal AI workflows.” The registered project website is eirel.ai and the GitHub repository is RendixNetwork/eirel-ai.
Relationship to Yuma Consensus
Subnet 36 uses Yuma Consensus to convert the workflow-evaluation weight vectors that validators submit into the emission shares distributed to miners and validators within the subnet each tempo. The linked documentation describes how validator weight submissions are aggregated into consensus weights for each miner registered on the subnet.
In Eirel’s context, validators receive multimodal workflow tasks, evaluate miner-agent responses against composite scoring criteria including groundedness, tool use, and task quality, and translate those scores into weight vectors for the subnet. The Emission documentation describes how those consensus weights determine each participant’s share of the subnet’s accumulated emission each tempo.
Development Stage Context
The Introduction to Bittensor describes subnet development as moving from localnet to testnet and then mainnet. For Eirel (SN36), that sequence changes how readers should interpret multimodal AI workflow examples and agent evaluation outcomes.
In localnet, Eirel-compatible miners and validators can be developed and tested in an isolated environment. Localnet workflow execution scores and emission outcomes do not represent production subnet performance.
On testnet, Eirel-compatible agents and workflows can be exercised in a shared, non-production network. Testnet evaluations and validator scores are separate from mainnet subnet state.
On mainnet, Eirel (SN36) is the live production subnet where miner agents execute multimodal AI workflows and validators evaluate those results to determine real Bittensor emissions. The Eirel repository describes the mechanism that applies on the production network.
The Bittensor Networks reference separates mainnet, testnet, and localnet. A workflow execution result or emission outcome from one environment should not be read as representing production subnet performance in another environment.
Reader Boundary
Subnet 36 Eirel should not be read as generic Bittensor subnet documentation, a single-turn chat leaderboard, or proof that one text completion defines agent quality. It names one subnet’s multimodal AI workflow execution market on netuid 36 (Understanding Subnets, Glossary: Netuid).
Tool-Backed Task Families Define Miner Work
Eirel’s README describes launch task families backed by tool services such as web search, URL fetching, sandboxed computation, and retrieval over per-run document corpora (Eirel repository).
Miners therefore submit agent packages evaluated inside workflow tasks rather than static answers alone.
Composite Gates Score Agent Behavior
The validator guide describes scoring with gates for groundedness, safety, tool use, efficiency, and other task-quality factors (validator guide).
Validator-side judging combines multiple task constraints instead of one raw response score.
Validator Weights Still Flow Through Yuma Consensus
Subnet 36 uses Yuma Consensus to convert validator weight submissions into emission shares each tempo (Yuma Consensus, Emission).