Key Takeaways

• Darkbloom pools verified idle Macs into an inference network, offering owners additional income and developers an option to lower inference costs.
• Yukon enables researchers and AI agents to run experiments in parallel and reuse verified improvements, while the resulting verifiers and evaluation experience could become a technical moat.
• ECDSA.fail reduced circuit resource costs by 86.1% as of July 26, 2026, while the initial MLX.fast Laguna challenge achieved a 2.6-fold speedup by its August announcement.
• Applying optimizations verified through MLX.fast to similar operating environments in Darkbloom could increase throughput and improve price competitiveness without adding more Macs.

1. Growing inference demand and idle compute

The work assigned to AI agents is becoming more complex. Users now delegate entire workflows: finding information, writing code, reading execution results, and deciding what to do next. A single request can involve repeated model calls and program runs, which increases the demand for inference compute.

Source: a16z

Token usage makes this change clear. In February 2026, agents overtook people as the largest users of models. They now consume nearly five times as many tokens as people. Over the same period, human usage grew 2.8 times, while agent usage grew about 14 times. Only a limited number of organizations have fully adopted agents in their day-to-day work. Given this, demand for inference compute is highly likely to accelerate nonlinearly.

Source: wsj.com

The effects of this inference demand have extended beyond data centers to an unexpected destination: the Mac mini and Mac Studio. Both became highly popular as local AI machines that run models directly. By spring 2026, orders for configurations with large amounts of memory had been suspended or faced substantial shipping delays. An April report by The Wall Street Journal attributed this to a combination of interest in local AI, memory shortages, and the prospect of new models. The supply shortage has continued to this day.

Even a hard-to-find machine leaves its computing capacity unused when its owner is not using it. While some people wait to obtain a machine, that capacity sits idle on someone else's desk. Putting it to use can generate additional income from hardware the owner already has. Darkbloom connects this spare capacity with paying inference demand, allowing owners to earn income with only a small electricity cost.

Of course, there is more to consider than simply renting out a machine. A device being switched on does not mean it is ready for a task. The service needs to check whether the required model is ready, whether sufficient memory is available, and whether the machine is busy with other work. It must also verify that the program handling customer requests is approved. A service that pools idle compute therefore needs a system to track each device's condition, assign requests that match its capabilities, and record completed work.

Through Darkbloom and Yukon, two platforms within EigenCloud, Eigen Labs is putting existing machines to work for inference while improving how much each machine can process. Darkbloom connects developers with spare capacity on Macs that owners have already purchased. Through challenges such as MLX.fast, Yukon brings external researchers and agents together to make open-weight models run faster on that hardware. The two platforms expand usable inference capacity by putting existing machines to work while increasing the amount of work each machine can process.

This approach extends a design principle familiar from EigenLayer: connecting existing resources with new demand. EigenLayer allows staked ETH to provide economic security to additional services in return for rewards. Darkbloom connects existing hardware with inference buyers, while Yukon brings participants' models, tools, and research methods to shared optimization tasks.

2. Darkbloom: turning desktop Macs into inference servers

Introduced by Eigen Labs in April 2026, Darkbloom connects spare Apple Silicon Macs into an inference network that external developers can call. Mac owners make their machines available during idle hours, and developers call the models they need. An intermediary server verifies device conditions and assigns the requests best suited to them.

2.1. From device registration to request processing

How does a Mac owner make idle compute available?

First, the owner installs the provider application, links an account, and selects a model to run. The application checks the GPU, memory, and operating system protections before preparing the model. Owners can specify the days and hours when their computer is available and how much memory to reserve for uses other than inference. Once ready, the Mac connects to an intermediary server called the coordinator. The coordinator tracks the models and execution status of connected devices, checks whether incoming requests are authorized, and assigns tasks. To support broader use, Darkbloom also provides APIs compatible with OpenAI and Anthropic formats. Within the range of supported models and features, users can send inference requests to the resources registered by Mac owners simply by changing the request endpoint in an existing application.

2.2. Protecting data in an unfamiliar environment

However, users may still be uneasy about having their conversations or code processed on a Mac whose owner they do not know. A platform that pools idle Macs is difficult to sustain without assurance that owners cannot secretly inspect user data. Darkbloom addresses this in two stages: device verification and protection of the execution environment.

In the first stage, device verification checks three areas before a machine can receive work:

• Device identity: A signature from a non-exportable key held in the chip's secure area proves that the device is registered.
• App integrity: The check confirms that an approved application is running and has not been tampered with.
• System security: Apple's device management system is used to check whether core macOS protections and secure boot are enabled.

Only Macs that pass all three checks receive serving access. The existing device verification process also rechecks their status every five minutes. Devices that no longer meet the requirements are excluded from request assignments.

Next, an isolated execution environment protects data inside Macs that have passed verification. The model runs directly through MLX within the protected provider application, without a separate server process. With operating system protections in place, access to memory from external processes and debugger attachment are restricted. These controls block the routes a Mac owner could use to inspect data during execution.

Communication and request routing are also encrypted. Requests are transmitted in a form that only the protected application on the designated Mac can decrypt, and responses are handled in the same way. The server that relays requests runs in a confidential virtual machine that restricts the host's access to its memory. It processes request contents in the memory of this protected environment. It does not store conversations and records only operational logs, such as usage. Users' API keys and account balances are never passed to Mac owners.

Further details on the security architecture are available in the Darkbloom GitHub repository.

2.3. Darkbloom's usage and pricing

How much is Darkbloom actually being used? Its published cumulative figures as of September 24 show the following supply and processing volumes:

• Registered Macs: 1,231
• Tokens generated: approximately 287 billion
• Requests: approximately 71.96 million

According to OpenRouter data, Darkbloom served an average of about 15.3 billion tokens per day over the 30 days to mid-October, up roughly 50% from the preceding 30 days. This made it the third-largest of the platform's seven crypto-native inference providers, behind Venice and Phala. Darkbloom serves these requests through its own network of Macs. How competitive is its pricing, then? Let us first consider the perspective of an API buyer.

AI inference services currently reach users through a chain of chip manufacturers, large cloud providers, and API vendors, with a margin added at each stage. By contrast, Darkbloom connects buyers directly with the idle processing capacity of Macs that have already been paid for. Without the need to build new data centers or buy additional GPUs, it can offer structurally lower prices. For GPT-OSS 20B, the direct price is $0.07 per million output tokens, half the $0.14 price of the existing API that Darkbloom uses for comparison.

What does this look like for providers?

Darkbloom's earnings calculator estimates that an M4 Max MacBook Pro with 128 GB of unified memory can earn about $205 per month, or $2,459 per year, assuming that it actively generates output for 60% of the total time. Separately from earnings based on actual inference usage, Darkbloom pays a base reward to devices that pass attestation and remain healthy and online.

Base rewards are settled in five-minute intervals within a fixed monthly budget. A device must stay online for at least 90% of each settlement interval to qualify. For a machine with 128 GB of memory, the reward is approximately $26 per month.

Finally, a Mac running a node can process its owner's inference requests for free. Owners can therefore earn income during idle hours and use the machine as a personal inference server when needed.

Darkbloom's economics therefore come from removing unnecessary margins added at each stage of the existing supply chain and sharing that value between buyers and providers. Buyers get inference at half the price of the existing API, while providers earn additional income from Macs they already own.

Increasing Darkbloom's capacity also requires making models run faster on the Macs already connected, alongside bringing more machines onto the network. If each machine can process more requests, the network can expand its supply without adding hardware. This is where Darkbloom connects with Yukon, discussed in the next section: Yukon opens this software improvement work to external researchers and agents.

3. Yukon: automated research across teams

Yukon is an open research platform where people and AI agents work together. A requester defines a problem and an evaluation environment, and participating teams submit their proposed improvements. Improvements that pass verification are shared with other participants and immediately become the basis for further research. This allows different approaches to be tested in parallel without waiting for a particular team's experiments to finish, so valid results can contribute to 'collective intelligence' without delay.

3.1. Yukon's approach builds on Karpathy's autoresearch

Andrej Karpathy, known as the father of 'vibe coding', developed and released 'autoresearch', a research workflow that formulates hypotheses, modifies code, and uses the results to determine the next experiment. In this workflow, an agent edits the training code itself. Training time and validation data are fixed in advance. Changes are kept if the score improves and reverted if it worsens. These consistent conditions make it possible to clearly compare which implementation performs better.

People only need to write program.md, which sets out the agent's experiment instructions. This document defines the objectives and the scope of permitted changes, and the agent modifies the model architecture and settings in the training code within those limits. With the evaluation criteria established in advance, the agent does not need to ask a person about each experiment. Experiments can continue overnight without people becoming a bottleneck.

Yukon extends this structure to multiple participants.

The researcher prepares the starting code, a baseline as the starting point for comparison, and a verifier to check correctness. Participants submit improvements using their own models and tools, and all submissions go through the same evaluation procedure. The baseline is used to calculate the performance gains that participants submit. The latest code that passes verification is shared with everyone, and other participants can use it in their own research.

Consider a challenge to increase inference speed. The researcher first specifies which model will run on which hardware, how closely its output must match the original, and what will be measured as speed. The researcher then publishes the challenge along with the files participants may edit and the evaluation code they must leave untouched.

Participants take different approaches to the challenge. One team looks for ways to use less memory, while another changes the order of computations or designs a new algorithm. Agents read the literature and code, implement changes, and repeat experiments. People review the results and decide whether to pursue the current direction further or change the underlying structure.

Changes that pass evaluation are published for everyone, along with code diffs, evaluation scores, and execution logs. Later participants can immediately use verified results in their own approaches without implementing everything again from scratch. Multiple teams can therefore test a wider range of strategies in parallel, and sharing results substantially reduces the time spent duplicating research. Where Darkbloom brings together the computing resources that agents need, Yukon also brings participants' domain knowledge, tool choices, and judgment about where problems lie into the research ecosystem.

3.2. Why the evaluation code also needs protection

When participants who do not know one another work toward a common research goal, the execution environment needs to be managed alongside the results. Submitted programs must be run to verify them, but they could secretly read the ground-truth data or change the scoring formula. Yukon therefore defines which code participants may modify and evaluates submissions in a sandbox, a restricted execution environment.

Yukon addresses this by separating participants' code from the scoring code. In an inference speed challenge, for example, the code participants modify runs inside a sandbox, while a separate evaluation program, free of participant code, checks correctness, takes measurements, and calculates scores. Submitted changes are applied to the original code only for files that participants are permitted to edit. Private ground-truth data and credentials are handled where participants cannot access them, and the data used to check correctness is removed from the workspace before performance is measured.

The environment remains strictly controlled during measurement. In the Laguna challenge on MLX.fast, the baseline implementation and submitted code run consecutively on the same hardware, with conditions such as chip temperature aligned to minimize variation caused by the device's state. A large performance gain in a single run may be a measurement error. For this reason, the challenge caps the improvement recognized for a single submission relative to a fixed calibration reference and requires incremental submissions and repeated verification.

When the model changes, the correctness checks and error tolerances must be redesigned. When execution techniques change, the measurement environment must change as well. As evaluation expertise that detects gaming and errors accumulates alongside reproducible records, accepting external code becomes less burdensome. The platform's lasting asset is the quality of its evaluation system, which makes results reliable and reusable, rather than exclusive rights to the winning code. Yukon accumulates verifiers, execution logs, and evaluation experience as it runs challenges. This accumulated knowledge could become a technical moat that competitors would struggle to replicate in a short period.

3.3. Results from Yukon's collaborative research

So how much improvement can people and agents achieve by dividing up work on the same problem? Let us look at ECDSA.fail, the quantum circuit optimization challenge that gave rise to Yukon, and MLX.fast, which increases AI inference speed on Macs.

3.3.1. ECDSA.fail: an 86.1% reduction in quantum circuit resource costs

The first example, ECDSA.fail, is a challenge to optimize quantum computations used to analyze the security of ECDSA.

ECDSA is a digital signature scheme based on elliptic curve cryptography. A user signs a message with a private key that only they hold, and the recipient checks the signature's validity with the public key. This proves that the legitimate key holder signed the message without exposing the private key. The security of this mechanism rests on the mathematical difficulty of deriving a private key from public-key information alone.

Shor's algorithm on a quantum computer can perform the computation needed to obtain this private key. The process repeatedly adds two points on an elliptic curve. ECDSA.fail targets the quantum circuit that performs this point addition, or the arrangement of quantum operations. The research modifies the circuit to perform the same computation with less working space and fewer operations, reducing the cost of the quantum resources needed to obtain the private key.

Eigen Labs first worked with agents to improve the circuit internally, but progress slowed after reaching a certain level. It then published the code, evaluation tools, and leaderboard as an open challenge so that participants with different models and research methods could approach the problem. This format became Yukon at its August launch.

As a result, by July 26, more than 100 participants and agents had contributed over 400 proposed improvements and reduced resource costs by 86.1% compared with the baseline circuit. Following Yukon's collaborative structure, participants took the latest improvements published by other teams, refined them further, and shared their results once they passed verification. When one team found a better approach, other teams could continue their research from that point. Resource costs continued to fall after the July tally. Work that had stalled under internal research began making progress again as participants and agents with different expertise exchanged improvements.

3.3.2. MLX.fast: faster AI inference on the same Mac

The second example, MLX.fast, began with an operational question at Darkbloom. To increase network throughput, the team could recruit more Macs or run models faster on Macs already connected to the network. The latter would allow it to process more requests without adding hardware. The Darkbloom team launched MLX.fast with Poolside and opened inference optimization for the Laguna XS 2.1 model to external participants, extending the work beyond its internal team.

Participants modified the code to make the model run faster while preserving its original answers. The evaluation program checked that the answers had not changed before comparing speed on the same Mac. Here too, improvements that passed verification were shared with other participants as the starting point for their next experiments. Through this process, the initial Laguna challenge achieved a 2.6-fold speedup by its announcement in August 2026, before the work expanded into a follow-up challenge to run the Qwen 3.8 Flash Next model faster.

As of September 24, 60 improvements submitted by 16 participants had passed evaluation and been incorporated into the follow-up Qwen challenge, and the highest speed score was 100.5% above the baseline. Combining the speed of reading inputs and generating answers, this score reached about twice the baseline under conditions where requests were processed one at a time. As with the initial Laguna challenge, external participants' collaborative research thus produced measurable performance gains in the follow-up Qwen challenge.

Notably, Gemma 4 26B A4B, which Darkbloom offers on OpenRouter, is also the subject of an MLX.fast optimization challenge on Yukon. Both Darkbloom's inference software and the challenge use MLX Swift libraries to run models on Apple Silicon.

This suggests that Darkbloom can increase its processing capacity through software improvements without adding hardware. Applying optimizations verified through Yukon to machines operating under similar conditions would allow the same Mac to process more inference requests per unit of time, directly improving Darkbloom's service economics.

4. Expanding compute and research capacity through verification

As AI agents take on more work, they need more computers to run on and more research capacity to improve the software running on those computers. If a company buys all its own equipment and handles every optimization internally, the pace of service growth is ultimately constrained by its capital and staff. Darkbloom and Yukon address this limit with resources outside the company. Darkbloom brings Macs that others have already purchased into the inference supply, while Yukon brings external researchers and agents into software optimization.

The MLX.fast example discussed earlier shows how the two platforms work together. Darkbloom poses an operational challenge: processing more inference requests on the same Mac. Yukon opens that challenge to external researchers and agents, then evaluates their submissions and makes verified improvements available for reuse. Applying those improvements to Darkbloom can increase network capacity without adding a single Mac. Producing more tokens on the same hardware also improves price competitiveness.

Verification connects the two platforms. Darkbloom checks whether an unfamiliar owner's Mac meets the requirements for serving inference requests, while Yukon checks whether externally submitted code actually improves performance. These checks allow both compute supply and software optimization to extend beyond one company's equipment and staff.

Just as EigenLayer allows already-staked ETH to provide security for new services, Eigen Labs is bringing the same principle to the AI market. Developers pay for inference, those payments become income for owners who offer their spare Macs, and external research makes that supply cheaper and faster. The resources are already distributed across many owners. What Eigen Labs adds is the verification that makes those resources trustworthy to use.