> For the complete documentation index, see [llms.txt](https://suiverify.gitbook.io/suiverify/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://suiverify.gitbook.io/suiverify/audit-and-compliance/e2e-user-flow.md).

# E2E User Flow

The verification process is a multi-step flow that involves interaction between the frontend, a secure backend, and the on-chain contracts.

#### Phase 1: Frontend DID Selection

1. The user selects the type of verification they want to perform (e.g., "18+ Age Verification") from the dApp's UI.
2. The frontend calls the `get_did_type_info` function to fetch details about the selected DID, such as its name, description, and required documents.

#### Phase 2: Start Verification On-Chain

3. The user clicks "Start Verification," which triggers a transaction calling the `start_verification` function. This creates a new `UserDID` object on-chain with the status set to `PENDING`.

#### Phase 3: Document Submission & Off-Chain Verification

4. The user is prompted to submit the required documents (e.g., Aadhar QR code, face capture) to a secure backend.
5. A Python backend processes these documents to verify their authenticity.
6. Upon completion, the backend updates its internal database and pushes a result message to a Kafka queue.
   * Kafka Message Example:

     JSON

     ```
     {
       "user_address": "0x123...",
       "did_type": 1,
       "verification_result": true,
       "user_did_id": "0xabc..."
     }
     ```

#### Phase 4: Rust Backend Updates Contract

7. A Rust service consumes the message from the Kafka queue and calls the `update_verification_status` function on the `Simple DID Registry` contract, updating the `UserDID` object's status to `VERIFIED` or `REJECTED`.

#### Phase 5: SSE Update to Frontend

8. The backend sends a Server-Sent Event (SSE) to the user's frontend to notify them that the verification is complete.
9. The UI updates to show a new "Upload Documents" button.

#### Phase 6: Encrypted Document Upload & NFT Claim

10. The user uploads their sensitive documents. These are encrypted on the client side using Seal and uploaded to decentralized storage (Walrus).
11. The frontend calls the `register_user_document` function on the `Government Whitelist` contract to log the `encryptionId` and `blobId`.
12. Finally, the user signs a transaction to call the `claim_did_nft` function. This mints their Soul-Bound NFT, which serves as their official on-chain credential, and marks the `UserDID` object as claimed.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://suiverify.gitbook.io/suiverify/audit-and-compliance/e2e-user-flow.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.