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

# The Report-Data Binding

> How the report data, the signing address plus your nonce, is recomputed and compared, and why anti-replay is caller-driven.

An attestation is only meaningful if it was produced for **your** request and not replayed from an earlier one. The **report-data binding** is what ties a report to a specific request.

## The Binding

Inside a sealed environment, the hardware stamps a small piece of caller-supplied data into the signed report. That field is the **report data**. It commits the report to two things at once:

```
report_data = signing_address + nonce
```

Because the value includes your nonce, a report produced for one request cannot stand in for another. A different nonce produces different report data, and the signature would not match.

## How It Is Checked

Two separate checks, worth keeping distinct:

1. **The binding is recomputed.** The signing address and the nonce are concatenated in the same form and compared against the report data observed in the evidence. The comparison is **case-insensitive**. A mismatch fails the check.
2. **The observed nonce must equal your nonce.** Separately from recomputing the report data, the nonce in the evidence is checked against the one you sent.

Both must hold. Together they establish that the report was produced for a request carrying your nonce and committed to the expected signing address.

## Send a Fresh Nonce Every Time

**Nothing stores nonces between requests.** There is no memory of nonces already seen, and a nonce is not rejected for having been used before. The freshness comes entirely from you choosing a fresh, unpredictable nonce every time.

* **Send a fresh random nonce** and the checks confirm the report is fresh for this request. This is the supported pattern.
* **Omit the nonce** and an **empty-binding report is permitted**. It is allowed, but you get no replay protection: an empty binding commits to nothing fresh, so an old report could satisfy it.

Replay protection is a property of the protocol you follow, not of the attestation in the abstract. A Nito attestation is replay-resistant when you supply a fresh nonce and verify it was echoed back.

Generate the nonce from a cryptographically secure random source, at least 32 bytes, hex encoded, and never reuse one. The [verify-yourself recipe](/privacy/tee-attestation/verify-yourself-recipe) does this as step one.

## Reports Are Request-Local

Attestation reports are produced for the request that asked for them and are **never persisted**. Each one stands alone: a fresh nonce, a fresh report, a fresh binding check.

## How This Fits the Baseline

The binding and the nonce match are gates 4 and 5 of the [seven-gate baseline](/privacy/tee-attestation/seven-gate-baseline), and gate 7 extends the nonce check into the nested payload for accelerator envelopes. The address side is governed by an additional invariant on [address-only model binding](/privacy/tee-attestation/address-only-model-binding).

## Related Resources

<CardGroup cols={3}>
  <Card title="The Seven-Gate Baseline" icon="door-open" href="/privacy/tee-attestation/seven-gate-baseline">
    Where these checks sit in the sequence.
  </Card>

  <Card title="Address-Only Model Binding" icon="address-card" href="/privacy/tee-attestation/address-only-model-binding">
    How the address binding is validated.
  </Card>

  <Card title="Verify It Yourself" icon="memo-circle-check" href="/privacy/tee-attestation/verify-yourself-recipe">
    Generating and checking a nonce in practice.
  </Card>
</CardGroup>