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
Enclave is Bittensor Subnet 92 (SN92), built by LumenLabs. It functions as a decentralised efficiency layer for autonomous AI agents — specifically designed to solve the two decisions that dominate what an agent actually costs to run: what information it keeps in context on each step, and which model answers each call. The result is a Verified Agent Runtime (VAR): a portable, independently recomputable policy that drives the same verified work on a fraction of the token spend, backed by published evidence that the work was completed and the consumption was accurately measured.
The problem Enclave addresses is fundamental to how agents work. Because an agent re-reads its entire accumulated context on every step, a single observation is charged once per step it survives — meaning consumption grows with the product of context length and trajectory depth, not with the actual work performed. Agentic workloads routinely consume five to thirty times the tokens of a conversational exchange. Coding agents have been measured at one-thousand times higher, almost entirely in input the model re-reads rather than output it writes. Falling per-token prices have not resolved this: tokens per task have grown faster than price per token has fallen.
Miners on Enclave compete by submitting candidate Runtimes as containers. Each submission is run against environments where information must be purchased through interaction — nothing is handed over up front. Every model call and every observation crosses a metered relay. Success is verified by a grader that has access to the environment’s private construction state, which the submission never touches. The score is yield: verified solutions divided by weighted token consumption. The Runtime that achieves the highest yield becomes the published policy, and holds that position only until a better submission beats it.
What makes the Verified Agent Runtime distinctive is a combination of three properties. It is portable, governing context assembly and model routing rather than any single model’s internals, so it survives provider changes and does not decay when a new model ships. It is recomputable — every score is a pure function of the round seed, the model price schedule, and the transcript, meaning any third party can regenerate a round and confirm exactly what was claimed. And it is private by separation: the memory-management policy is what the network publishes; the memory itself — code, documents, and conversation history — remains on the user’s own infrastructure and never enters the network. Public knowledge of how to remember; private custody of what is remembered. That is the name.
Enclave’s competition design closes a fundamental attack surface found in conventional benchmarks. A benchmark that presents a corpus can be gamed by a submission that parses known answers rather than invoking a model — under a cost-weighted score, this is not just cheating but the winning strategy, because zero model calls means zero consumption. Enclave removes this by making information available only through charged interactions with the environment. A submission that never calls a model cannot participate. Selective attention wins on arithmetic; forgetting something costs money to fix.
Enclave is Bittensor Subnet 92 (SN92), built by LumenLabs. It functions as a decentralised efficiency layer for autonomous AI agents — specifically designed to solve the two decisions that dominate what an agent actually costs to run: what information it keeps in context on each step, and which model answers each call. The result is a Verified Agent Runtime (VAR): a portable, independently recomputable policy that drives the same verified work on a fraction of the token spend, backed by published evidence that the work was completed and the consumption was accurately measured.
The problem Enclave addresses is fundamental to how agents work. Because an agent re-reads its entire accumulated context on every step, a single observation is charged once per step it survives — meaning consumption grows with the product of context length and trajectory depth, not with the actual work performed. Agentic workloads routinely consume five to thirty times the tokens of a conversational exchange. Coding agents have been measured at one-thousand times higher, almost entirely in input the model re-reads rather than output it writes. Falling per-token prices have not resolved this: tokens per task have grown faster than price per token has fallen.
Miners on Enclave compete by submitting candidate Runtimes as containers. Each submission is run against environments where information must be purchased through interaction — nothing is handed over up front. Every model call and every observation crosses a metered relay. Success is verified by a grader that has access to the environment’s private construction state, which the submission never touches. The score is yield: verified solutions divided by weighted token consumption. The Runtime that achieves the highest yield becomes the published policy, and holds that position only until a better submission beats it.
What makes the Verified Agent Runtime distinctive is a combination of three properties. It is portable, governing context assembly and model routing rather than any single model’s internals, so it survives provider changes and does not decay when a new model ships. It is recomputable — every score is a pure function of the round seed, the model price schedule, and the transcript, meaning any third party can regenerate a round and confirm exactly what was claimed. And it is private by separation: the memory-management policy is what the network publishes; the memory itself — code, documents, and conversation history — remains on the user’s own infrastructure and never enters the network. Public knowledge of how to remember; private custody of what is remembered. That is the name.
Enclave’s competition design closes a fundamental attack surface found in conventional benchmarks. A benchmark that presents a corpus can be gamed by a submission that parses known answers rather than invoking a model — under a cost-weighted score, this is not just cheating but the winning strategy, because zero model calls means zero consumption. Enclave removes this by making information available only through charged interactions with the environment. A submission that never calls a model cannot participate. Selective attention wins on arithmetic; forgetting something costs money to fix.
The product Enclave delivers is the Verified Agent Runtime — a continuously updated, competitively produced policy layer that sits beneath any autonomous agent and governs the four decisions that most directly determine cost: what to carry into each model call, what to retain after each step, what to reacquire on demand rather than carry defensively, and which model from a priced catalogue should answer each step. Because the policy is derived through live competition rather than offline benchmarking, it stays current as models ship and workloads shift — it is a permanent contest rather than a product with a version number.
The target users are teams running autonomous agents at scale — coding agents, research agents, document-processing pipelines — where token consumption is the dominant cost driver. Rather than writing context-management logic themselves, teams can run an Enclave-sourced Runtime beneath their agent and inherit the efficiency gains that survive open competition. The policy holds no user content; it carries only the general knowledge of how to remember, which means it can be adopted without exposing proprietary data to the network.
The technical architecture is built around a set of clean trust boundaries. Miner submissions run as containers in a network namespace with no egress, a read-only root filesystem, all Linux capabilities dropped, and no hardware accelerator. The container’s only channel to the outside world is a unix socket to the metered relay. The relay counts tokens from bytes on the wire and prices them from the round’s pinned model schedule — the container never holds a provider credential and never sees a price. Grading is performed by a module that reads the environment’s private construction state from outside the container, so a submission cannot influence its own success signal.
The scoring module is designed to depend on nothing else in the project — no sockets, no containers, no chain connection. This isolation means any third party can recompute every weight the subnet has ever published from the ledger alone, using the published enclave-score CLI. The ledger is append-only and hash-chained; round headers are written once and refuse rewriting. Aggregates are never stored — a round score is always recomputed on demand from its constituent records, so a scoring fix applies retroactively without a disputed migration.
Incentives align tightly with the product goal. Bittensor emissions flow to the miner submission that achieves the highest yield — verified solutions per dollar of token spend. A Runtime that loses a solution removes a unit from the numerator and adds the failure penalty to the denominator simultaneously, so there is no exchange rate at which degrading quality pays. A submission that abstrains entirely scores zero. The economic structure selects for exactly the behaviour that produces a useful production runtime: solving real tasks efficiently, routing model calls thoughtfully, and managing context precisely.
The product Enclave delivers is the Verified Agent Runtime — a continuously updated, competitively produced policy layer that sits beneath any autonomous agent and governs the four decisions that most directly determine cost: what to carry into each model call, what to retain after each step, what to reacquire on demand rather than carry defensively, and which model from a priced catalogue should answer each step. Because the policy is derived through live competition rather than offline benchmarking, it stays current as models ship and workloads shift — it is a permanent contest rather than a product with a version number.
The target users are teams running autonomous agents at scale — coding agents, research agents, document-processing pipelines — where token consumption is the dominant cost driver. Rather than writing context-management logic themselves, teams can run an Enclave-sourced Runtime beneath their agent and inherit the efficiency gains that survive open competition. The policy holds no user content; it carries only the general knowledge of how to remember, which means it can be adopted without exposing proprietary data to the network.
The technical architecture is built around a set of clean trust boundaries. Miner submissions run as containers in a network namespace with no egress, a read-only root filesystem, all Linux capabilities dropped, and no hardware accelerator. The container’s only channel to the outside world is a unix socket to the metered relay. The relay counts tokens from bytes on the wire and prices them from the round’s pinned model schedule — the container never holds a provider credential and never sees a price. Grading is performed by a module that reads the environment’s private construction state from outside the container, so a submission cannot influence its own success signal.
The scoring module is designed to depend on nothing else in the project — no sockets, no containers, no chain connection. This isolation means any third party can recompute every weight the subnet has ever published from the ledger alone, using the published enclave-score CLI. The ledger is append-only and hash-chained; round headers are written once and refuse rewriting. Aggregates are never stored — a round score is always recomputed on demand from its constituent records, so a scoring fix applies retroactively without a disputed migration.
Incentives align tightly with the product goal. Bittensor emissions flow to the miner submission that achieves the highest yield — verified solutions per dollar of token spend. A Runtime that loses a solution removes a unit from the numerator and adds the failure penalty to the denominator simultaneously, so there is no exchange rate at which degrading quality pays. A submission that abstrains entirely scores zero. The economic structure selects for exactly the behaviour that produces a useful production runtime: solving real tasks efficiently, routing model calls thoughtfully, and managing context precisely.
Enclave (SN92) is built and maintained by LumenLabs, operating as LumenLabs-io on GitHub. The team describes its mission as building open competitions that price the things autonomous agents actually cost — metered intelligence as a public good rather than a vendor product. The enclave-subnet repository is the organisation’s sole public repository, reflecting a focused approach: one subnet, one problem, built correctly rather than broadly.
No individual team members are named in the public repository or organisation profile, which is consistent with the subnet’s design philosophy of letting the work speak for itself. What the codebase reveals is a team with strong foundations in distributed systems, language model infrastructure, and cryptographic protocol design. The design choices — hash-chained append-only ledgers, Decimal arithmetic throughout scoring, deterministic weight allocation by largest-remainder apportionment, structurally impossible container egress rather than policy-blocked egress — reflect production engineering instincts rather than research-prototype habits. The documentation is written to be normative and checkable rather than illustrative.
LumenLabs operates as a lean, technically serious team at an early stage. The subnet is pre-alpha: core components are implemented and covered by smoke tests, one environment family ships, but nothing has been run against Bittensor mainnet yet. The public-facing product at enclave-mu.vercel.app carries the tagline “Agents that know what matters” — a concise description of the VAR’s purpose. The team has not yet established public social media channels for this project.
Enclave (SN92) is built and maintained by LumenLabs, operating as LumenLabs-io on GitHub. The team describes its mission as building open competitions that price the things autonomous agents actually cost — metered intelligence as a public good rather than a vendor product. The enclave-subnet repository is the organisation’s sole public repository, reflecting a focused approach: one subnet, one problem, built correctly rather than broadly.
No individual team members are named in the public repository or organisation profile, which is consistent with the subnet’s design philosophy of letting the work speak for itself. What the codebase reveals is a team with strong foundations in distributed systems, language model infrastructure, and cryptographic protocol design. The design choices — hash-chained append-only ledgers, Decimal arithmetic throughout scoring, deterministic weight allocation by largest-remainder apportionment, structurally impossible container egress rather than policy-blocked egress — reflect production engineering instincts rather than research-prototype habits. The documentation is written to be normative and checkable rather than illustrative.
LumenLabs operates as a lean, technically serious team at an early stage. The subnet is pre-alpha: core components are implemented and covered by smoke tests, one environment family ships, but nothing has been run against Bittensor mainnet yet. The public-facing product at enclave-mu.vercel.app carries the tagline “Agents that know what matters” — a concise description of the VAR’s purpose. The team has not yet established public social media channels for this project.
Enclave is currently in a pre-alpha phase. The core scoring engine, metered relay, environment generation and grading pipeline, episode runner, container sandbox, ledger, chain adapter, validator round loop, and miner SDK are all implemented and covered by smoke tests. One environment family ships. The stated open items before mainnet launch are: CPU time (specified as charged but not yet metered), the reference agent implementation (which will provide a baseline submission for new miners to benchmark against), and originality screening (specified in the design to prevent submissions built against memorised environment outputs, but not yet built).
The broader roadmap is structural rather than feature-driven. Because Enclave is designed as a permanent competition rather than a product, the development path is oriented toward expanding the environment families miners are tested against, refining the scoring parameters, and opening the subnet to mainnet. As agent workloads grow in scale and cost, the value of a competitively produced, recomputable efficiency policy increases — meaning the subnet’s product becomes more useful the more widely agents are deployed.
LumenLabs has signalled that future environment families will extend beyond the initial type, broadening the domain of tasks the competition tests. The whitepaper deltas document tracks deliberate departures from the original specification, providing a transparent record of design evolution. The team’s approach — making all scoring parameters arrive via a signed owner directive rather than operator configuration — means future changes to competition structure can be rolled out without creating disagreements between validators about what a score means.
Enclave is currently in a pre-alpha phase. The core scoring engine, metered relay, environment generation and grading pipeline, episode runner, container sandbox, ledger, chain adapter, validator round loop, and miner SDK are all implemented and covered by smoke tests. One environment family ships. The stated open items before mainnet launch are: CPU time (specified as charged but not yet metered), the reference agent implementation (which will provide a baseline submission for new miners to benchmark against), and originality screening (specified in the design to prevent submissions built against memorised environment outputs, but not yet built).
The broader roadmap is structural rather than feature-driven. Because Enclave is designed as a permanent competition rather than a product, the development path is oriented toward expanding the environment families miners are tested against, refining the scoring parameters, and opening the subnet to mainnet. As agent workloads grow in scale and cost, the value of a competitively produced, recomputable efficiency policy increases — meaning the subnet’s product becomes more useful the more widely agents are deployed.
LumenLabs has signalled that future environment families will extend beyond the initial type, broadening the domain of tasks the competition tests. The whitepaper deltas document tracks deliberate departures from the original specification, providing a transparent record of design evolution. The team’s approach — making all scoring parameters arrive via a signed owner directive rather than operator configuration — means future changes to competition structure can be rolled out without creating disagreements between validators about what a score means.