> For the complete documentation index, see [llms.txt](https://docs.theacompute.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.theacompute.com/core-concepts/how-it-works.md). # How It Works I take every inference job through the same four stages, in the same order: unit lock, routing, inference, settlement. Different parts of me handle different stages, and most of them leave on-chain state behind. That means you can audit any of it yourself. *** ## Stage 1: I lock your units If nothing is reserved, I don't route anything. As soon as your request reaches me, my `job_escrow` contract atomically locks the unit cost of the model tier you asked for. (My contracts call units "credits", so that's the word you'll see on-chain.) That gets both of us two guarantees. The worker knows its payment is secured before it starts working. And if no worker finishes inside the timeout window, your refund is contract code, so nobody has to step in, not even you. I record that escrow lock as a transaction on Robinhood Chain. From then on, the chain holds the job ID, the unit amount, the model tier, and the escrow entry for your wallet. Your prompt never goes there. **If time runs out:** When 120 seconds go by without a valid proof from any worker, my `job_escrow` contract puts the units back in your balance. You don't lift a finger. It all happens on-chain. *** ## Stage 2: I find you a worker Once your units are locked, my orchestrator network picks things up. It's a peer-to-peer mesh built on libp2p, and there's no central server anywhere along the routing path. My workers keep telling the mesh about themselves the whole time: which models they host, how much VRAM is free, their GPU type, their estimated latency zone, their stake weight, and their reputation score. I run a weighted scoring function over all of that to pick the best one: | Factor | What I look at | | ------------------ | ---------------------------------------------------------------------------------- | | Model availability | The worker has to host the model you asked for, or a compatible variant | | Stake weight | The more $THEA a worker has staked, the higher I rank it for routing | | Reputation score | An on-chain score I build from its completion history, latency, and proof validity | | Estimated latency | How close the worker sits to your client, geographically | The worker I pick gets the job payload: your encrypted prompt, the model parameters, and the streaming configuration. **When I reroute:** If a worker doesn't acknowledge within 8 seconds, I skip it and hand the job to the next candidate. Your escrow stays locked the whole time, and the reroute doesn't cost you anything. *** ## Stage 3: Your worker runs the model When the payload lands, the worker decrypts your prompt locally using the ephemeral session key that travels in the payload envelope. That decryption happens in memory and never leaves it. Neither your plaintext prompt nor the response ever hits a disk or a log, anywhere. The worker runs inference on its own GPU backend (llama.cpp on native workers, WebLLM in the browser), and I stream the tokens back to your client over WebSocket through my orchestrator mesh. My orchestrators pass that stream along blind. They carry encrypted transport frames and never read or buffer what's inside. Once the final token is out, the worker: 1. Runs SHA-256 over the full output token stream 2. Signs the resulting hash with its registered worker key 3. Submits that signed proof to my `settlement` contract *** ## Stage 4: I settle up My `settlement` contract takes the proof and checks three things: * The signing key belongs to an address that's registered in `worker_registry` * That worker registered for the model tier your escrowed job used * The proof showed up inside the allowed window If everything checks out, the contract does all of this atomically: * Turns the escrowed units into USDG and releases them * Pays 75% to a browser worker's wallet, or 85% to a native worker, since native workers are required to stake * Sends whatever is left to the protocol treasury * Emits an on-chain event for Alchemy to index A few seconds after confirmation, you'll find the settlement transaction in the TheaCompute Explorer at `explorer.theacompute.com`. Your own jobs also live on your Jobs page (`theacompute.com/app/jobs`), each with its receipt and a Blockscout link. Go look one up and check my work. **Your dispute window:** For 60 seconds after the final token, your client can hash the output it got and compare it with the proof hash the worker submitted. If they don't match, you're entitled to open a dispute. I walk through how that works in \[On-Chain Settlement]\( ). *** ## A typical job, start to finish ``` T+0ms User submits request T+~100ms Credits locked on-chain (escrow tx) T+~250ms Job routed to worker T+~450ms Worker acknowledges and begins inference T+Ns Tokens stream to client (N = inference duration) T+N+50ms Worker submits proof on-chain T+N+250ms Settlement tx confirmed, USDG in worker wallet T+N+60s Dispute window closes ``` My payment machinery usually wraps up in under a second end to end, since Robinhood Chain's \~100ms blocks confirm each on-chain step almost right away. The part that varies is inference time, which depends on the model's size and how long the output is. *** ## What I put on-chain, and what I never do | Data | Location | Why | | ----------------------------- | ------------ | --------------------------------------------------------------------------------------- | | Unit escrow lock | On-chain | So the worker's payment is guaranteed before any work starts | | Job ID, model tier, timestamp | On-chain | So anyone can audit the job record | | Units charged | On-chain | So anyone can check your bill independently | | Worker address | On-chain | So you can see who got paid | | Proof hash | On-chain | So disputes have something to be checked against | | USDG payout transaction | On-chain | So anyone can confirm the settlement | | Prompt content | Nowhere | I encrypt it in transit and never keep it | | Response content | Nowhere | It only lives in memory while streaming, and I never store it | | User identity | Not on-chain | My network only ever sees a wallet address, and nothing about who you are goes on-chain | --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.theacompute.com/core-concepts/how-it-works.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.