Keyring Network | Docs
  • INTRODUCTION
    • About Us
    • Our Solution
    • Use Cases
  • USER GUIDE
    • 1. Choose a Policy
    • 2. Onboard
      • Keyring Connect
      • Keyring Pro
    • 3. Create a Credential
    • FAQ
      • What is my onboarding status?
      • How to manage multiple entities?
      • What is Keyring's business model?
      • How to create credentials x-chain?
  • INTEGRATION STEPS
    • 1. Create a Policy
      • Connect Policy Builder
    • 2. Integrate to User Flow
    • 3. Permission smart contracts
  • PROTOCOL GUIDE
    • Sandbox
      • Keyring Connect
      • Keyring Pro
    • Data Flow
      • Data Collected
      • Data Storage
    • Smart Contracts
  • RESOURCES
    • Links
    • Get in Touch
    • Brand Assets
    • Data Policies
  • Onboarding Requirements
    • Keyring Pro
      • FalconX
    • Keyring Connect
Powered by GitBook
On this page
  1. PROTOCOL GUIDE

Data Flow

PreviousKeyring ProNextData Collected

Last updated 5 months ago

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.