> For the complete documentation index, see [llms.txt](https://docs.verio.network/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.verio.network/network/request-lifecycle.md).

# Request Lifecycle & Disputes

How a request moves from submission through audit to settlement.

Applications get a simple interface to verification while the protocol handles the complexity behind it.

## The lifecycle

{% stepper %}
{% step %}

### Request

The application submits a request naming the **artifact, execution profile, verification class, and disclosure mode**. Its fee is held in escrow.
{% endstep %}

{% step %}

### Execute and sign

The provider executes under the canonical execution profile and returns the **output with a signed receipt** to the application.
{% endstep %}

{% step %}

### Anchor batch

At the end of the epoch, the provider anchors its batch on Base: Merkle root, receipt count, fee totals, and a data pointer.
{% endstep %}

{% step %}

### Beacon round

The batch is bound to the first drand round published at least Δ after anchoring, so the provider could not know the randomness when it committed.
{% endstep %}

{% step %}

### Select audits

The Dispute Module derives a seed from the batch root and the beacon, and selects receipts to audit and a verifier for each.
{% endstep %}

{% step %}

### Reveal

The provider reveals each selected receipt and its payload to the assigned verifier within the reveal window.
{% endstep %}

{% step %}

### Replay

The verifier re-executes the same artifact under the same profile and produces a replay receipt.
{% endstep %}

{% step %}

### Compare

The profile's comparison function decides whether the two runs agree.

* **Match:** the audit passes. Holdbacks, verifier fees, and upstream shares settle when the challenge window closes.
* **Mismatch:** two fresh verifiers replay; the majority of three decides. A confirmed **fault** slashes collateral, forfeits holdbacks, and refunds applications.
  {% endstep %}
  {% endstepper %}

Every outcome is recorded as a reputation event.

### By class

| Class  | When replay happens                                                                |
| ------ | ---------------------------------------------------------------------------------- |
| **V1** | Receipts are replayed only when sampled or challenged.                             |
| **V2** | Every receipt is replayed before settlement is final.                              |
| **V3** | Two or more disjoint executors must agree before the output is released at step 2. |

## Audit selection

Once a batch is final, the Dispute Module derives a seed

$$
s = H(r \parallel n \parallel \beta\_R)
$$

from the batch root $$r$$, the receipt count $$n$$, and the beacon randomness $$\beta\_R$$. It selects receipt $$i$$ when

$$
H(s \parallel i) < a\_i \cdot 2^{256}
$$

where the audit probability $$a\_i$$ rises with the receipt's fee and class. A rational provider might cheat only where savings are large, so larger and higher-class receipts are checked more often.

## Disputes

Disputes resolve through bounded rounds:

1. A **match** closes the audit.
2. A **mismatch** escalates to two fresh, disjoint verifiers whose majority decides, in the optimistic spirit of verification games for outsourced computation.
3. A **confirmed fault** slashes the provider, forfeits its open holdbacks, and refunds affected applications.

Verifiers are checked in turn through known-answer tasks.

## Open challenges

Any participant can challenge an eligible receipt by posting a **bond that funds the replay**, so every result stays open to scrutiny until its window closes. Challenges are bonded so they cannot become a denial-of-service vector against honest providers.

{% hint style="danger" %}
A receipt selected for audit that is not revealed counts as a **failed audit**.
{% endhint %}