> For the complete documentation index, see [llms.txt](https://docs.usedecentral.org/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.usedecentral.org/core-concepts/on-chain-settlement.md).

# On-Chain Settlement

Every inference job on Decentral generates at least two Solana transactions: one to lock the escrow when the job is submitted, and one to release payment when the job is verified complete. Both are publicly visible on any Solana explorer.

This page covers the settlement mechanics in detail: the on-chain programs involved, the escrow lifecycle, payout distribution, and the dispute process.

***

## Why Solana

Solana's economics make per-job micropayment viable in a way that no other chain currently does.

| Property         | Value              | Why it matters for Decentral                                                                                  |
| ---------------- | ------------------ | ------------------------------------------------------------------------------------------------------------- |
| Finality         | \~400ms            | Settlement confirms before the full inference stream even reaches the client                                  |
| Cost per tx      | \~$0.00025         | Settling an $0.08 inference job costs less than 0.3% overhead                                                 |
| Throughput       | \~65,000 TPS       | Each job generates at least 2 on-chain transactions. At scale this must be a rounding error, not a bottleneck |
| Native USDC      | SPL token          | No bridging; USDC lives natively on Solana                                                                    |
| Anchor framework | Type-safe programs | Audited, safe smart contract development with PDA account model                                               |

Settling the same $0.08 inference job on Ethereum L1 would cost between $2 and $10 in gas, making per-job settlement economically impossible at this price point.

***

## On-chain programs

All programs are written in Rust using the Anchor framework. Source code is open and all programs are audited before Mainnet deployment.

### `job_escrow`

Handles the credit lock at job submission and the refund path if no valid proof is submitted.

**When a job is submitted:**

* Validates that the user's credit balance covers the requested model tier
* Atomically creates an escrow PDA with the credit amount, job ID, model tier, and expiry timestamp
* Marks the escrow as `Pending`

**When a valid proof is received:** Transitions the escrow to `Settled` and signals the `settlement` program to release funds.

**On timeout:** If the escrow PDA is still `Pending` at the expiry timestamp (120 seconds after job submission), any party can call the `refund` instruction. The program releases the locked credits back to the user's balance and closes the PDA.

### `worker_registry`

Tracks every registered worker on the network.

For each worker, the registry stores:

* Solana public key
* Staked $DECENTRAL amount and lock tier
* Declared model support list
* On-chain reputation score (0 to 1000)
* Cumulative completed jobs and earnings
* Last seen timestamp

Workers must be registered to receive job routing. Registration requires a minimum stake for Tier 2 workers.

### `settlement`

Called by workers when submitting proof of completion.

**Verification steps:**

1. Look up the job ID in `job_escrow`. Confirm status is `Pending` and has not expired.
2. Look up the submitting keypair in `worker_registry`. Confirm the worker is registered and declared the model tier used.
3. Verify the proof signature: the SHA-256 hash of the output stream must be signed by the worker's registered keypair.
4. If all checks pass, calculate the payout split based on the worker's current stake tier.
5. Release the escrow: transfer USDC to the worker's wallet and the remainder to the protocol treasury PDA.
6. Update the worker's reputation score and completed job count in `worker_registry`.
7. Emit a `JobSettled` event for the Helius indexer.

### `staking`

Handles $DECENTRAL staking for workers and passive stakers.

Lock options: 30 days, 90 days, and 180 days. Longer locks earn a higher reward rate multiplier (up to 1.5x at 180 days).

Workers with an active stake in `staking` are recognized by the `settlement` program and receive the 85% payout rate instead of the base 75%.

Slashing is triggered by `settlement` when a valid dispute is confirmed. The slashed amount (5% of stake) is burned, not redistributed.

### `governance`

Manages on-chain voting for model curation, protocol fee parameters, and program upgrades. Active post-beta. $DECENTRAL holders vote proportionally to their staked balance.

***

## Payout distribution

When a job settles, the escrowed USDC is split as follows:

| Recipient         | Unstaked worker | Staked worker |
| ----------------- | --------------- | ------------- |
| Worker wallet     | 75%             | 85%           |
| Protocol treasury | 25%             | 15%           |

Workers qualify for the 85% rate if they have a minimum of 1,000 $DECENTRAL staked in the `staking` program at the time the settlement transaction executes.

The protocol treasury accumulates USDC. Weekly, the treasury program:

* Uses 50% of accumulated fees to buy back $DECENTRAL on Jupiter and Raydium and burn the purchased tokens
* Distributes 50% to $DECENTRAL stakers pro-rata by staked balance

Every buyback and burn is a public Solana transaction. The Decentral Explorer displays the full history.

***

## Dispute process

If you believe a worker submitted a proof that does not match the response you received, you can open a dispute within 60 seconds of receiving the final output token.

**Opening a dispute:**

Call the `dispute` instruction on the `settlement` program with:

* The job ID
* Your locally computed SHA-256 hash of the received output stream

The program compares your hash to the proof hash the worker submitted. If they differ, the job is flagged as `Disputed` and held in escrow pending arbitration.

**Beta arbitration:** The Decentral multisig reviews disputes and issues a ruling. If the worker is found to have submitted a fraudulent proof, 5% of their staked $DECENTRAL is slashed (burned), and the user's credits are refunded.

**Post-beta arbitration:** A DAO committee elected by $DECENTRAL holders will handle disputes. The long-term direction is ZK proof-of-inference, which would make this fully trustless by making the proof self-verifying without a dispute window.

***

## Reading settlement data

Every settled job is a verifiable Solana transaction. You can inspect it using:

**Solana Explorer** at `explorer.solana.com`: search by transaction signature or the job's escrow PDA address.

**Helius API**: query the `worker_registry` PDA for a given worker address to get their full on-chain earnings history, job count, and reputation score.

**Decentral Explorer**: the network-level view at `usedecentral.org/explorer` shows live job completions, worker leaderboards, treasury balance, and buyback history with links to every underlying transaction.

**API response headers**: every API call includes `x-decentral-job-id` and `x-decentral-tx-signature` headers so you can immediately verify the settlement transaction for any request you make.


---

# 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.usedecentral.org/core-concepts/on-chain-settlement.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.
