Proof States
Proof requests and credentials move through a series of states as a verification interaction progresses. Understanding these states helps you manage proof requests and interpret history logs.
Proof request states
| State | Description |
|---|---|
CREATED | Proof request has been created but not yet shared with a holder. |
PENDING | Proof request has been shared and is awaiting a response from the holder. For HTTP flows, calling the share endpoint again while in this state refreshes the QR code. Proof requests using the ISO mDL offline flow start directly in PENDING since the holder initiates the connection. |
REQUESTED | Holder has connected to the request (ISO, BLE, and MQTT flows only) but has not yet submitted a presentation. |
ACCEPTED | Holder submitted a valid presentation and verification succeeded. |
ERROR | The holder submitted a presentation that could not be verified (for example, a revoked credential or invalid signature), or an error occurred during the presentation process such as a timeout. |
INTERACTION_EXPIRED | The share URL has expired and can no longer be used by the holder. Call the share endpoint again to generate a new URL and return the proof request to PENDING. The verifier.interactionExpiresIn parameter in your verification protocol configuration controls how long share URLs remain valid; if not set, they remain valid indefinitely. |
RETRACTED | The proof request was deleted while in REQUESTED state. The history of the interaction is retained. |
DELETED | The proof request has been hard-deleted and no history is retained. Possible from CREATED, PENDING, and INTERACTION_EXPIRED states only. |
REJECTED | MQTT only. The holder explicitly rejected the presentation request. In all other verification flows no distinction is made between rejection and non-response — the proof request remains in its current state (PENDING for HTTP, REQUESTED for BLE). |
Credential states
When a proof is verified, any credentials presented as part of that proof
enter the system in one state: ACCEPTED.
Verification is a point-in-time event: the holder's presentation is either verified or it is not. The system does not monitor or update credential status over time after verification, since the interaction is complete.
Credentials presented during verification may include claims your application treats as time-sensitive, such as an expiration date. The system stores these as regular claims — interpreting and acting on them is the responsibility of your application logic.