> For the complete documentation index, see [llms.txt](https://docs.robinmesh.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.robinmesh.com/core-concepts/how-it-works.md).

# How It Works

Every inference job on RobinMesh passes through the same four stages: credit lock, routing, inference, and settlement. Different parts of the system own different stages, and several of them leave on-chain state behind that anyone can audit.

***

## Stage 1: Credit lock

Nothing routes until money is reserved. The moment a request comes in, the `job_escrow` contract atomically locks the credit cost of the requested model tier.

Two things follow from this design. The worker knows payment is guaranteed before doing any work. And if no worker finishes the job inside the timeout window, the refund happens automatically in contract code, with nobody needing to step in.

Locking the escrow produces a Robinhood Chain transaction. At that point the chain records the job ID, the credit amount, the model tier, and the escrow entry for the requesting wallet. What the chain never records is the prompt itself.

**On timeout:** Should 120 seconds pass without a valid proof from any worker, the `job_escrow` contract returns the credits to the user's balance. The user does nothing; it happens on-chain.

***

## Stage 2: Routing

Once credits are locked, the orchestrator network takes over. It is a peer-to-peer mesh built on libp2p, and no central server sits anywhere in the routing path.

Workers keep the mesh informed about themselves at all times: hosted models, free VRAM, GPU type, estimated latency zone, stake weight, and reputation score.

A weighted scoring function then picks the best candidate:

| Factor             | Description                                                                  |
| ------------------ | ---------------------------------------------------------------------------- |
| Model availability | The worker has to be hosting the requested model or a compatible variant     |
| Stake weight       | More staked $RMESH means higher priority in routing                          |
| Reputation score   | An on-chain score built from completion history, latency, and proof validity |
| Estimated latency  | How geographically close the worker is to the requesting client              |

The chosen worker then receives the job payload: the encrypted prompt, model parameters, and streaming configuration.

**Rerouting:** A worker that fails to acknowledge within 8 seconds is skipped, and the job moves to the next candidate. The escrow never unlocks during this, and the user pays nothing extra for the reroute.

***

## Stage 3: Inference

On arrival, the worker decrypts the prompt locally with the ephemeral session key carried in the payload envelope. Decryption is confined to memory. 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), with tokens streaming back to the client over WebSocket through the orchestrator mesh.

The orchestrator forwards the stream blind. It handles only 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

On receiving the proof, the `settlement` contract 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

With all checks passed, 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 what remains to the protocol treasury
* Emits an on-chain event that Alchemy indexes

Seconds after confirmation, the settlement transaction is visible in the RobinMesh Explorer.

**Dispute window:** For 60 seconds after the final token arrives, the client can compare its own hash of the output against the proof hash the worker submitted. A mismatch entitles the client 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 mechanics themselves usually take under a second from request to settled payout, since Robinhood Chain's \~100ms blocks confirm each on-chain step almost instantly. How long inference itself takes is 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 that can be independently checked           |
| 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.robinmesh.com/core-concepts/how-it-works.md?ask=<question>&goal=<endgoal>
```

`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.