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.

A User logs in and is guided through the Keyring onboarding process.

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.

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

• 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:

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