Infer134
Private AI inference
About
The problem it solves AI agents and companies increasingly need to buy small units of inference from external workers, but today this usually means opaque API billing, no clear per-job payment state, and poor auditability. Putting everything onchain is not a good answer either, because prompts, outputs, and model details can be private or commercially sensitive. Infer134 solves this by creating a local-first pay-per-inference workflow with private offchain execution and transparent settlement metadata. A buyer can choose a worker-published GPU/model offer, submit a prompt, receive an offchain result, verify a signed execution receipt, and release payment. The prompt and output stay offchain, while hashes, worker identity, receipt hash, and payment state provide a clear audit trail. People can use Infer134 to: - let AI agents purchase inference jobs from independent compute workers; - make AI agents and companies increasingly need to buy small units of compute, such as LLM inference, from external workers. Today this usually means using opaque API billing, trusting a centralized provider, or exposing too much private data when trying to add blockchain payments. Infer134 makes this workflow safer and clearer by separating the private work from the public settlement trail. A buyer can submit an inference request, choose a worker-published GPU/model offer, keep the prompt and output offchain, receive a signed execution receipt, and release payment based on explicit job state. The system stores only minimal settlement metadata such as hashes, worker identity, receipt hash, and payment state. People can use Infer134 to: - let AI agents pay for inference work per request; - let independent GPU workers publish local compute capacity; - give buyers a readable receipt for what was executed; - avoid putting prompts, outputs, or model data onchain; - make payment state transparent without turning private inference into public data; - demonstrate how x402-style pay-per-request flows could work for AI services. The current MVP is local-first and intentionally narrow. It does not claim trustless proof-of-compute. Instead, it focuses on a practical buyer journey: discover a worker, create a job, run inference offchain, verify the signed receipt, and release payment.
How it's made
Challenges we ran into One of the main challenges was keeping the demo honest while still making it understandable for the judges. It would have been easy to show a fake GPU marketplace with static offers, but that would not reflect the behavior of the real system. Instead, we connected the buyer UI, provider UI, backend catalog, and local provider-node runtime so that offers only appear when the worker is actually online and the selected model/runtime is ready. This created a few tricky edge cases: * The backend could contain previously published offers while the provider node was offline. * A worker could publish a vLLM model while the local runtime was only running in mock mode. * The buyer page needed to hide stale offers without making the app look broken. * The demo needed to clearly explain what is verified and what is still trusted. We addressed this by adding runtime-readiness checks and filtering the buyer marketplace to show only live, compatible GPU/model bundles. If the provider node is unavailable or the runtime does not match, the UI now explains that stale offers are hidden instead of pretending they are usable. Another challenge was defining the trust boundary. Infer134 does not prove that a model output is semantically correct. In the MVP, we verify hashes, payment state, and signed execution receipts. Making that distinction explicit helped keep the project focused and avoided overclaiming “trustless AI” or “proof of compute” before those pieces exist.