# Attestation flow

> This page walks the end-to-end timeline of a deposit moving through [ASP attestation](/protocol/asp/what-is-an-asp), from transaction confirmation to the note becoming spendable.

This page walks the end-to-end timeline of a deposit moving through [ASP attestation](/protocol/asp/what-is-an-asp), from transaction confirmation to the note becoming spendable.

## Step-by-step

1.  **T+0 (user)**: The [`Entrypoint`](/protocol/contracts/entrypoint)`.deposit()` transaction confirms. [`PoolVault`](/protocol/contracts/pool-vault)`.commitments(commitment)` returns a timestamp, which means the note is in the [state tree](/concepts/state-tree). Locally, the note's status is `PENDING`.
2.  **T+seconds (ASP)**: The ASP indexer picks up the `LabelRegistered` event the Entrypoint triggered, decrypts the encrypted opening with the ASP's own key, recomputes the deposit's label, and adds it to the ASP's pending review queue.
3.  **T+up to 7 days (ASP)**: Compliance policy is applied. Review is often completed within an hour but can take up to 7 days. An approved label is added to the next root, while a rejected label remains excluded.
4.  **T+minutes (ASP)**: The ASP service generates a new Merkle root that includes the approved labels, and a holder of `POSTMAN_ROLE` calls [`ASPRegistry`](/protocol/contracts/asp-registry)`.updateASPRoot(root, ipfsCID)`.
5.  **T+next sync (user)**: The client calls `session.discoverNotes()`. The SDK checks the snapshot or the chain for label attestation and records the `PENDING` to `ACTIVE` transition locally.

## Typical latencies (Sepolia)

-   From indexing to review: seconds.
-   Review and approval: often within an hour, up to 7 days.
-   From review to root generation: seconds to minutes, depending on batch policy.
-   Root publication: one on-chain transaction, roughly 15 seconds to confirm.
-   Local sync: as fast as the client polls.

The total time from deposit confirmation to the note becoming spendable is often within an hour, though it can take up to 7 days.

## What goes wrong

-   **ASP downtime**: deposits sit `PENDING` longer than usual. Operator monitoring catches this, and users can either wait or [ragequit](/operations/ragequit).
-   **Policy rejection**: the deposit moves to `REJECTED`, and ragequit is the recovery path.
-   **Postman role compromise**: a bad actor pushes a root that approves labels it shouldn't. Detection requires off-chain monitoring, and there is no on-chain governance mechanism for rolling back a bad root.