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

# 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.