Data Flow

We designed our architecture to limit sensitive information flows and access to what is strictly necessary and therefore reduce vulnerability. Here is a high-level description of user data processed and stored by Keyring.

Simplified view of end-to-end data flows

A User logs in with their non-custodial Master Wallet (for sign-in and onboarding) and is guided through the Keyring onboarding process.

Note that we mention an "AuthKey" in the chart above, it is a unique identifier derived from the Master Wallet, keeping the link between the AuthKey used for identity-related data management and the connected wallet obfuscated.

1️⃣ Onboarding: The User chooses the Policy they want to onboard for, and submits the required information and documents on the Keyring User Interface. Let’s assume the Policy represents: “Verified identity, not US resident”, the User will be required to fill in their country of residency and send a proof of identity (e.g. a passport) and proof of address (e.g. a recent utility bill).

2️⃣ Verification: This data is automatically stored in a secure vault operated by Basis Theory. Relevant data is shared with the appropriate Compliance Partner(s) to verify the User’s information. In our example, the Policy requires that the KYC/AML vendor ComplyCube verifies the User’s identity and documents. The data is therefore forwarded to ComplyCube at the User's request.

3️⃣ Wallet Selection: Once the verification is complete, the User will be able to create on-chain proofs of compliance for one or multiple wallets (Trading Wallets).

4️⃣ Attestation Generation: The User then generates an Attestation they send to the Attestor Service operated by Keyring, prompting the service to witness their compliance with the Policy. The Attestor reads the verified data from the Compliance Partner’s API to confirm the claim. In our example, the Attestor checks that ComplyCube has properly identified the User and that their country of residency is not the US.

5️⃣ Proof Generation: The User’s browser automatically collects various inputs from the process to generate zero-knowledge proofs demonstrating a Wallet’s compliance with a Policy while keeping the link to the underlying data hidden.

6️⃣ Credential Generation: The proofs are combined and allow the User’s browser to create a Credential which contains the Wallet Address, the Policy ID, and a timestamp. The Credential is stored in an on-chain cache.

7️⃣ Wallet Checks: If the Policy requires it, an Attestor Service will run the Trading Wallet through checks conducted by a KYW vendor.

8️⃣ Allow Action: A smart contract restricts access to a given action to Users who can prove they meet the Policy’s requirements. The contract will verify on-chain that the User has valid Credentials and Wallet Checks to allow this action.