A new experimental project called KeyMesh is exploring whether the Internet Computer can coordinate external computing resources while giving users stronger guarantees around privacy, execution and verification.
The project is being developed in parallel with OhShii Labs and is currently described as an early research effort rather than a finished product. Its first area of focus is AI inference, with the team testing whether users could send encrypted models and inputs to external compute providers without having to place complete trust in the machines running their workloads.
The idea addresses a practical problem in AI computing. Running a local model such as Llama or Mistral can require expensive hardware, while sending sensitive models or data to a centralised API introduces another form of trust. KeyMesh is exploring a middle ground in which a user could encrypt a model and its inputs, send the job to a provider, pay for execution and receive the result while relying on protocol-level mechanisms to establish what happened.
The project’s researchers say the GPU itself is only the starting point. The broader question is how to qualify an external computation and determine whether a provider delivered the execution it claimed to provide.
A machine advertised as having an RTX 5090, RTX 4090 or H100, for example, does not by itself describe how a particular workload was executed. Runtime versions, model builds, CUDA versions, context size, batch configuration, layer placement, Flash Attention settings, power state and other variables can all affect the result or performance.
Early testing on an RTX 2060 highlighted the issue. Running the same Qwen2.5-7B model, the team obtained the same output hash after changing how the model was fitted into memory, while throughput fell from about 49.5 tokens per second to around 21.6 tokens per second. The result remained correct, but the execution conditions were materially different.
KeyMesh is therefore experimenting with the idea of an “execution profile” rather than identifying hardware simply by its advertised GPU model. The proposed profile includes hardware capability, usable VRAM, driver and CUDA versions, inference runtime, model hash and quantisation, context size, batching, attention configuration, layer placement, power and clock state, measured throughput and reproducibility.
The distinction could matter for any marketplace that pays independent providers to perform computing jobs. Two machines with the same advertised GPU may produce very different performance, while repeated executions under the same qualified conditions may provide stronger evidence that a workload was performed consistently.
The initial experiments were deliberately conducted on modest consumer hardware rather than datacentre equipment. On the RTX 2060, researchers found that fixed configurations could produce bitwise-reproducible inference across consecutive runs and after a reboot. However, changing the number of GPU-offloaded layers changed the output hash.
The testing also exposed practical differences that could easily be missed by conventional hardware specifications. The laptop reported 6GB of VRAM, but the usable budget under Windows WDDM was closer to 5.1GB. Cold model loading took roughly six seconds, while battery operation reduced throughput from about 49.5 tokens per second to around 6.8 tokens per second on the same physical machine.
Those findings have implications for how computing services could be priced and benchmarked. A provider claiming to have a particular GPU does not necessarily provide a predictable level of service without knowing the conditions under which that hardware is being used.
The experiments also uncovered problems in the testing methodology itself, including inappropriate benchmark settings, the need to explicitly pin Flash Attention for reproducibility and context-size settings that could exceed the available memory. The team says these findings are useful because they expose assumptions before they become embedded in a production system.
Confidentiality is the other major part of the KeyMesh research. The proposed architecture looks at encrypting model weights before they leave the user’s environment and using ICP’s vetKD/vetKeys mechanism as part of the key-release process. The project describes vetKeys as a way to use threshold cryptography at the IC level, with a derived key delivered in encrypted form to the intended recipient.
However, the experiments have also identified limitations in the security assumptions. An adversarial test found that the team could not support its original claim that a controller could never obtain the model key. Under the current vetKD semantics described in the research, the derived key is tied to the canister identity and derivation context rather than the particular WASM code installed in the canister. A controller able to reinstall the relevant broker at the same canister ID could therefore recreate the derivation path.
The project says this finding means its trust model needs to be narrowed and redesigned. Lease revocation is another unresolved issue before the proposed key-release model could be considered ready for production.
The researchers see ICP as useful because several of the required components already exist at the protocol level. Canisters can coordinate state, payments, job assignments and provider reputation, while canister-to-canister communication, HTTPS outcalls, replicated outcalls, vetKeys and chain-key cryptography provide additional building blocks. The proposed role for ICP is therefore not to run the GPU workload itself, but to provide the coordination, authorisation, cryptographic and economic layer around external computation.
The project also acknowledges that other blockchain networks are pursuing related ideas. NEAR AI, for example, is already working with confidential AI compute using hardware-backed trusted execution environments, including Intel TDX and NVIDIA confidential GPUs. Its approach provides hardware-backed attestation intended to allow users to verify that workloads ran inside the expected environment.
KeyMesh is exploring a different question: whether trusted execution environments could be one verification option rather than a requirement for every provider. Under that model, one provider might offer deterministic execution and redundancy on a consumer GPU, another could provide hardware attestation through a confidential GPU, while future providers might use other verification methods.
The project’s researchers argue that these approaches should not be treated as equivalent. Instead, the protocol could assign different verification profiles based on the evidence available for each execution and potentially use that information when routing, authorising and pricing jobs.
That leaves several separate questions for any external compute network: whether the data remained confidential, whether the expected code and model were executed, whether the computation was correct, whether the advertised execution profile was used and whether the promised performance was delivered. The project argues that no single mechanism is likely to answer all of these questions.
For now, KeyMesh remains firmly in the experimental stage. The team says it has not demonstrated a universal decentralised GPU network, deterministic inference across every NVIDIA architecture, heterogeneous verification or a completed TDX implementation. The security finding around vetKD also means the original trust claim must be revised.
What the experiments have demonstrated so far is narrower. The team has tested vetKD key derivation, reproducible inference on consumer NVIDIA hardware, the effect of execution parameters on output hashes, differences between nominal and usable GPU memory, the impact of power conditions on performance and the effect of runtime defaults on benchmarking. It has also found that cryptographic key derivation costs may need to be included in the economics of running workloads on lower-cost hardware.
The next phase will focus on developing a repeatable hardware qualification process across different NVIDIA generations. Rather than expecting every GPU to produce the same output hash, the project is looking at whether different hardware can be classified into reproducible execution profiles with predictable verification properties.
That remains an open research question. The project’s own description makes clear that KeyMesh could become a standalone project, connect with OhShii or remain a collection of experiments. For now, the focus is on testing whether ICP can provide a coordination and cryptographic layer for external computation that is private, measurable and verifiable, without assuming that every provider offers the same level of trust.
Dear Reader,
Ledger Life is an independent platform dedicated to covering the Internet Computer (ICP) ecosystem and beyond. We focus on real stories, builder updates, project launches, and the quiet innovations that often get missed.
We’re not backed by sponsors. We rely on readers like you.
If you find value in what we publish—whether it’s deep dives into dApps, explainers on decentralised tech, or just keeping track of what’s moving in Web3—please consider making a donation. It helps us cover costs, stay consistent, and remain truly independent.
Your support goes a long way.
🧠 ICP Principal: ins6i-d53ug-zxmgh-qvum3-r3pvl-ufcvu-bdyon-ovzdy-d26k3-lgq2v-3qe
🧾 ICP Address: f8deb966878f8b83204b251d5d799e0345ea72b8e62e8cf9da8d8830e1b3b05f
Every contribution helps keep the lights on, the stories flowing, and the crypto clutter out.
Thank you for reading, sharing, and being part of this experiment in decentralised media.
—Team Ledger Life
Community Discussion