> For the complete documentation index, see [llms.txt](https://docs.robincompute.org/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.robincompute.org/core-concepts/how-it-works.md). # How It Works Every inference job on RobinCompute moves through the same four stages: credit lock, routing, inference, settlement. Different parts of the system own different stages, and most of them leave on-chain state behind. You can audit any of it. *** ## Stage 1: Credit lock No money reserved, no routing. The moment your request arrives, the `job_escrow` contract atomically locks the credit cost of the requested model tier. This buys two guarantees. The worker knows payment is secured before it does any work. And if no worker finishes inside the timeout window, the refund is contract code; nobody has to step in, including you. The escrow lock is a Robinhood Chain transaction. From that point the chain holds the job ID, the credit amount, the model tier, and the escrow entry for your wallet. It never holds the prompt. **On timeout:** If 120 seconds pass with no valid proof from any worker, the `job_escrow` contract returns the credits to your balance. You do nothing. It happens on-chain. *** ## Stage 2: Routing With credits locked, the orchestrator network takes over: a peer-to-peer mesh built on libp2p, with no central server anywhere in the routing path. Workers continuously advertise their state to the mesh: hosted models, free VRAM, GPU type, estimated latency zone, stake weight, and reputation score. A weighted scoring function picks the best candidate: | Factor | Description | | ------------------ | ---------------------------------------------------------------------------- | | Model availability | The worker must host the requested model or a compatible variant | | Stake weight | More staked $RCOMPUTE, higher routing priority | | Reputation score | An on-chain score built from completion history, latency, and proof validity | | Estimated latency | How geographically close the worker sits to your client | The chosen worker receives the job payload: the encrypted prompt, model parameters, and streaming configuration. **Rerouting:** A worker that fails to acknowledge within 8 seconds gets skipped, and the job moves to the next candidate. The escrow never unlocks in between, and the reroute costs you nothing. *** ## Stage 3: Inference On arrival, the worker decrypts the prompt locally with the ephemeral session key carried in the payload envelope. Decryption happens in memory and stays there. Neither the plaintext prompt nor the response ever touches a disk or a log, anywhere. Inference runs on the worker's own GPU backend (llama.cpp on native workers, WebLLM in the browser), and tokens stream back to your client over WebSocket through the orchestrator mesh. The orchestrator forwards the stream blind. It carries encrypted transport frames and neither reads nor buffers the content. When the last token is out, the worker: 1. Hashes the full output token stream with SHA-256 2. Signs that hash with its registered worker key 3. Sends the signed proof to the `settlement` contract *** ## Stage 4: Settlement The `settlement` contract takes the proof and checks three things: * The signing key belongs to an address registered in `worker_registry` * That worker registered the model tier the escrowed job used * The proof arrived inside the allowed window All checks pass, and the contract executes atomically: * Converts the escrowed credits to USDG and releases them * Pays 75% to the worker's wallet, or 85% if the worker holds an active stake * Sends the remainder to the protocol treasury * Emits an on-chain event that Alchemy indexes Seconds after confirmation, the settlement transaction shows up in the RobinCompute Explorer. Pull it up and check it. **Dispute window:** For 60 seconds after the final token, your client can hash the output it received and compare against the proof hash the worker submitted. A mismatch entitles you to open a dispute. The mechanics live in \[On-Chain Settlement]\( ). *** ## Timeline of a typical job ``` 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 ``` The payment machinery itself usually runs start to finish in under a second, because Robinhood Chain's \~100ms blocks confirm each on-chain step almost instantly. Inference time is the variable, a function of model size and output length. *** ## What lives on-chain, and what does not | Data | Location | Reason | | ----------------------------- | -------- | --------------------------------------------------- | | Credit escrow lock | On-chain | Worker payment is guaranteed before work begins | | Job ID, model tier, timestamp | On-chain | A job record anyone can audit | | Credit amount charged | On-chain | Billing anyone can independently check | | Worker address | On-chain | Shows who was paid | | Proof hash | On-chain | What disputes are verified against | | USDG payout transaction | On-chain | Settlement anyone can confirm | | Prompt content | Nowhere | Encrypted in transit and never persisted | | Response content | Nowhere | Exists only in memory while streaming, never stored | | User identity | Nowhere | A wallet address is the only thing ever known | --- # 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.robincompute.org/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.