> 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/providers/reputation.md).

# Reputation

Each worker registered on RobinMesh carries a reputation score, stored on-chain, ranging from 0 to 1000. Four performance signals feed into it, and it refreshes every time one of your jobs settles.

The score matters because the router reads it. A higher number means the routing algorithm picks you more often, and more jobs means more USDG.

***

## What feeds the score

| Signal                       | Weight | Description                                                                                 |
| ---------------------------- | ------ | ------------------------------------------------------------------------------------------- |
| Job completion rate          | 35%    | Of the jobs routed to you, how many ended in a valid settled proof                          |
| Response latency             | 30%    | Your p50 and p95 time-to-first-token, measured against other workers serving the same model |
| Proof verification pass rate | 25%    | Share of your submitted proofs that cleared on-chain verification with no dispute           |
| Uptime (trailing 30 days)    | 10%    | How much of the time your worker answered the orchestrator's health checks                  |

The overall score is a rolling weighted average that favors recent history over old history. One rough stretch does not follow you forever.

***

## The math behind it

Whenever a job settles, the `settlement` contract pushes that job's performance metrics into your `worker_registry` entry. The registry keeps raw counters and derives the score from them using an exponential moving average with a 30-day half-life.

Some consequences of that design:

* New workers start clean and can build a strong score quickly.
* After a bad stretch, a few days of normal performance is enough for visible recovery.
* Veterans with a long consistent record can absorb the occasional slow job without their score moving much.

***

## How the router uses it

When the orchestrator picks a worker for a job, reputation is one of four inputs; the others are model availability, stake weight, and estimated latency.

Among established workers, reputation ends up being the deciding factor most of the time. Given two workers on the same model with comparable latency, the router compares reputation first and falls back to stake weight second.

| Score range | Routing priority                                           |
| ----------- | ---------------------------------------------------------- |
| 900 to 1000 | Top of the queue for most jobs                             |
| 700 to 899  | High priority, holds its own against other veteran workers |
| 500 to 699  | Standard priority                                          |
| 300 to 499  | Below standard; job flow may thin out when demand spikes   |
| 0 to 299    | Low priority, seldom chosen when others are available      |

Every new worker begins at 500.

***

## Raising your score

**Completion rate (35% weight)**

Never vanish mid-job. When you need to take a node down, run `robinmesh-node stop` so the orchestrator hears about it first and stops routing jobs your way; that is what prevents failed completions on your record.

Also resist the temptation to serve models that barely fit your VRAM. An OOM during a job counts as an incomplete job, and those drag this signal down.

**Latency (30% weight)**

You are graded on a curve: latency comparisons only happen between workers serving the same model, never across tiers. Your competition is always your peers.

Ways to move the needle:

* put model weights on fast NVMe storage
* keep other GPU-heavy processes off the machine while the node runs
* make sure tokenization is not CPU-bound (a native worker bottlenecked on the GPU is exactly where you want to be)
* on Apple Silicon Macs, keep the model resident in unified memory with no swapping

**Proof verification pass rate (25% weight)**

Most workers hold a perfect 1.0 here indefinitely. The only thing that lowers it is a dispute opened against you and confirmed, so honest inference is the entire strategy.

**Uptime (10% weight)**

Consistency beats raw hours. Frequent short outages score worse than an otherwise steady node that takes planned maintenance windows. Going away for a while? Shut down cleanly instead of letting the node drop off.

***

## Where to see your score

**Dashboard:** the Earn tab in the web app displays it.

**On-chain:** your `worker_registry` entry contains both the score and the raw counters behind it. Look it up by your registered worker address over Robinhood Chain JSON-RPC (`https://rpc.mainnet.chain.robinhood.com`) or on Blockscout.

**RobinMesh Explorer:** `robinmesh.com/explorer` hosts a leaderboard of every registered worker sorted by reputation, showing each one's stake, completed job count, and 30-day earnings.

**CLI:**

```bash
robinmesh-node status
# ...
# Reputation score: 847 / 1000
# Completion rate (30d): 99.1%
# Median first-token latency (30d): 1.3s
# Proof pass rate (all time): 100%
# Uptime (30d): 98.4%
```

***

## Where slashing fits in

Slashing and reputation are separate mechanisms that happen to share a trigger. When a dispute against you is upheld, two things occur independently:

1. Your proof verification pass rate falls, pulling your reputation score down with it.
2. If you hold a stake, 5% of your staked $RMESH is burned.

There is no shortcut into a high score. It cannot be bought, moved between wallets, or substituted with stake; the only input is sustained good performance.


---

# 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/providers/reputation.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.