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

# Reputation

I give every worker registered on TheaCompute a reputation score between 0 and 1000. I keep it on-chain, I build it from four performance signals, and I update it each time one of your jobs settles.

Why should you care? Because my router reads it. The higher your score, the more often my routing algorithm chooses you. More jobs for you means more USDG for you.

***

## What goes into your score

| Signal                       | Weight | Description                                                                              |
| ---------------------------- | ------ | ---------------------------------------------------------------------------------------- |
| Job completion rate          | 35%    | How many of the jobs I sent you ended with a valid, settled proof                        |
| Response latency             | 30%    | Your p50 and p95 time-to-first-token, compared with other workers running the same model |
| Proof verification pass rate | 25%    | How many of your proofs passed on-chain verification without a dispute                   |
| Uptime (trailing 30 days)    | 10%    | How often your worker responded when my orchestrator ran health checks                   |

Your overall score is a rolling weighted average, and I weight recent history more heavily than old history. A single bad patch won't haunt you forever.

***

## How I calculate it

Every time a job settles, my `settlement` contract writes that job's performance metrics into your `worker_registry` entry. The registry stores raw counters and works out your score from them with an exponential moving average that has a 30-day half-life. Those counters are public, so your score is arithmetic anyone can redo, not a grade I hand out.

Here's what that means for you:

* When you're new, you start with a clean slate and can build a strong score fast.
* After a rough patch, a few days of normal work visibly pulls your score back up.
* Once you have a long, steady track record, an occasional slow job barely nudges your score.

***

## How my router uses it

When my orchestrator chooses a worker for a job, it weighs four things: reputation, model availability, stake weight, and estimated latency.

Among established workers, reputation usually settles it. If two workers serve the same model with similar latency, I compare their reputation first and only then look at stake weight.

| Score range | Routing priority                                             |
| ----------- | ------------------------------------------------------------ |
| 900 to 1000 | I send you most jobs before anyone else                      |
| 700 to 899  | High priority; you compete well with other veteran workers   |
| 500 to 699  | Normal priority                                              |
| 300 to 499  | Lower than normal; you may see fewer jobs when demand surges |
| 0 to 299    | Low priority; I rarely pick you if someone else is free      |

Every new worker starts out at 500.

***

## How to raise your score

**Completion rate, which I weight at 35%**

Don't disappear in the middle of a job. If you need to take your node offline, run `theacompute-node stop` (or, from the Earn page, click **"Online · take a break"**) so my orchestrator knows ahead of time and stops sending you work. That's how you keep failed completions off your record.

Also avoid serving models that only just squeeze into your VRAM. If you run out of memory during a job, I count it as incomplete, and that pulls this signal down.

**Latency, which I weight at 30%**

I grade latency on a curve: I only compare you with workers serving the same model, never across tiers. You're always measured against your peers.

What helps:

* keep model weights on fast NVMe storage
* don't run other GPU-heavy programs on the machine while your node is up
* make sure tokenization isn't limited by your CPU (a native worker that's GPU-bound is exactly what you want)
* on Apple Silicon Macs, keep the model in unified memory without swapping

**How often your proofs verify, which I weight at 25%**

Most workers keep a perfect 1.0 here forever. The only way it drops is if someone opens a dispute against you and it's confirmed. Running inference honestly is the whole strategy.

**Uptime, which I weight at 10%**

Being dependable matters more than total hours. Lots of short outages hurt you more than a steady node with planned maintenance windows. Stepping away for a while? Shut down cleanly rather than letting your node drop off.

***

## Where you can find your score

**Dashboard:** I show it on your Earn page in the web app.

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

**TheaCompute Explorer:** at `explorer.theacompute.com` I keep a leaderboard of every registered worker ranked by reputation, with each one's stake, number of completed jobs, and 30-day earnings.

**CLI:**

```bash
theacompute-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%
```

***

## How slashing connects to your score

Slashing and reputation are two separate systems set off by the same event. If a dispute against you is upheld, two things happen, each on its own:

1. Your proof verification pass rate drops, and your reputation score drops with it.
2. If you run a native worker (and so have a stake), I burn 5% of your staked $THEA.

There's no shortcut to a high score. You can't buy it, move it to another wallet, reset it, or swap stake in for it. The only thing that builds it is doing good work consistently, and the record of that work sits on the chain for anyone to read.


---

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