# Data Flow

We designed our architecture to limit sensitive information flows. Here is a high-level description of user data processed and stored by Keyring.

<figure><img src="/files/VzJa2GoaruoC1YtMOFUn" alt=""><figcaption></figcaption></figure>

A User logs in and is guided through the Keyring onboarding process.&#x20;

{% hint style="info" %}
If the user logs in with a wallet, their unique user ID will be derived from their wallet login without an explicit linkage to preserve privacy.
{% endhint %}

1️⃣ **Onboarding:** The User selects the Policy they want to onboard for and submits the required information and documents via the Keyring User Interface. Let’s assume the Policy states: “Verified identity, not US resident”.&#x20;

* **Keyring Pro:** The User must provide their country of residence, proof of identity (e.g. a passport), and proof of address (e.g. a recent utility bill).
* **Keyring Connect:** The User doesn't submit documents directly. Instead, they're redirected to authorised data sources for automatic extraction of verified information.

2️⃣ **Verification:**&#x20;

* **Keyring Pro**: Collected data is stored in a secure vault operated by Basis Theory. The Policy Owner receives relevant data for verification and validation.
* **Keyring Connect:** Let's assume the Policy accepts Binance as a data source. The User logs into Binance, and the Keyring browser extension notarises the session. Using an MPC-TLS scheme, they can export and selectively disclose session data.

3️⃣ **Wallet Selection:** After verification, the User can create on-chain proofs of compliance for one or multiple wallets.

4️⃣ **Attestation Generation:** The User generates an Attestation and sends it to the Keyring-operated Attestor Service, prompting the service to witness their Policy compliance.

* **Keyring Pro:** The Attestor reads the Policy Owner's response via the Admin App or directly through an API (WIP).
* **Keyring Connect**: The Attestor reads verified data obtained from the Keyring attestation service, which acts as the notary in the MPC-TLS scheme.

5️⃣ **Proof Generation**: The User's browser automatically collects various inputs to generate zero-knowledge proofs. These proofs demonstrate a Wallet's Policy compliance while keeping the link to underlying data hidden.

6️⃣ **Credential Generation**: The proofs are combined, allowing the User's browser to create a Credential containing the Wallet Address, Policy ID, and timestamp. This Credential is stored in an on-chain cache.

7️⃣ **Allow Action**: A smart contract restricts access to a given action to wallets with valid Credentials for a given Policy.


---

# Agent Instructions: 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:

```
GET https://docs.keyring.network/docs/protocol-guide/data-flow.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
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.