> ## Documentation Index
> Fetch the complete documentation index at: https://docs.giwa.tokscale.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Verified Usage and the Evidence Ladder

> Learn what separates self-reported usage from attested usage, and what it takes for a receipt to climb each rung.

Every Tokscale usage number carries one of five verification tiers. One vocabulary (self-reported, consistency-checked, source-verified, gateway-verified, attested) drives the landing page, product badges, and the receipt inventory; each surface states its own evidence criterion and its own availability.

Self-reported usage is forgeable. Verified usage is an asset.

## The five tiers

| Tier                | What it means                                                             |
| ------------------- | ------------------------------------------------------------------------- |
| Self-reported       | Usage submitted by a local client                                         |
| Consistency-checked | Self-reported usage that passes pattern, time-series, and rate validation |
| Source-verified     | Usage cross-checked against provider billing                              |
| Gateway-verified    | Usage observed directly by the Tokscale Gateway                           |
| Attested            | Gateway-verified usage anchored on GIWA and bound to a Dojang identity    |

### Self-reported

Usage read off a developer's own machine by the open-source Tokscale CLI, which covers 41 client integrations and is live today. Running `tokscale submit` publishes it to a public profile.

This is real data at real volume, and it is what solves cold start. It is also forgeable by construction: the CLI can only report what the client on that machine tells it. So it is labeled self-reported everywhere it appears, including in the open-source product itself. For the full client list, see [Supported Clients](/usage-tracker/supported-clients).

### Consistency-checked

Self-reported usage that survives validation on submission. The open-source project calls this **Level 1 validation**: totals must reconcile, no negative values, no future dates, required fields present, and duplicate submissions rejected.

That catches accidents and careless tampering. It does not catch a determined forger, because every input still originates on the machine being measured. Stronger than raw self-report, still client-originated.

### Source-verified

Usage cross-checked against provider billing records. Labeled as a target: no page, badge, or receipt in the current system claims it.

### Gateway-verified

Usage observed directly by the Tokscale Gateway as it proxies the request, bound to a project and a price, and written into the immutable request ledger (UPDATE-blocking triggers; rows cannot be rewritten in place while retained). This is the tier the gateway produces on every metered request, and the substrate receipts are signed from. See [The Gateway and Its Workers](/gateway/service).

### Attested

Gateway-verified usage anchored on GIWA via EAS and bound to a Dojang identity. Today the anchoring lands only on the local EAS fixture (hermetic localnet); no Usage Root exists on public GIWA Sepolia yet. Publishing the first one is the next milestone, tracked on [Live Evidence](/overview/live-evidence). The attestation mechanics are specified in [Receipt Attestation (EAS)](/gateway/receipt-attestation) and the identity rail in [Dojang](/builder-passport/dojang).

## Why the ladder is the product

Tokscale's existing data sits at the bottom two tiers. The gateway moves it to gateway-verified. Anchoring moves it to attested. Each step up makes the same activity harder to forge, easier to price, and usable by third parties (launchpads, grant programs, bounty boards) without trusting Tokscale's say-so.

For how the shipped CLI and the gateway divide this ladder between them, see [The Open-Source Base](/usage-tracker/open-source-base).

## How a receipt climbs

```mermaid theme={null}
flowchart TD
    R["receipt<br/>EIP-712 signed"]
    RR["receiptRoot<br/>merkle root"]
    L["leaf<br/>wallet-bound"]
    UR["Usage Root<br/>EAS attestation"]

    R --> RR --> L --> UR
```

Leaves are unsalted and minimal: each one commits a receipt digest to one wallet and one subject epoch, so a receipt cannot move between passports. The class of evidence behind the root is committed on-chain as the `uint8(1)` discriminator inside the salted `summaryCommitment`, so a verifier checks the class cryptographically instead of trusting a label.

The end-to-end ladder runs on a local localnet under one harness target:

```sh theme={null}
BUILDX_BUILDER=desktop-linux bun run local:e2e
```

Pass marker: `GIWA_LOCAL_E2E_OK`, with browser artifacts `verified=receipt,passport,transactions`.

## Next steps

* Verify a receipt against its root yourself in [Verifying a Receipt](/builder-passport/verify-a-receipt).
* For the receipt format the ladder is built on, see [UsageReceiptV1](/gateway/usage-receipt-v1).
* For how the top tier anchors on-chain, see [Receipt Attestation](/gateway/receipt-attestation).
* For what each tier's live status is today, see [Live Evidence](/overview/live-evidence).