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.
A User logs in with their non-custodial Master Wallet (for sign-in and onboarding) and is guided through the Keyring onboarding process. Web2 login is coming soon.
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”.
Under a Keyring Pro policy, 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).
Under a Keyring Connect policy, the User won't have to submit any documents. They will be redirected to authorised data sources to extract the verified information automatically.
2️⃣ Verification:
Keyring Pro: The data collected is stored in a secure vault operated by Basis Theory. Relevant data is shared with the appropriate compliance desk to verify the User’s information. In our example, the Policy requires that the vendor ComplyCube verifies the User’s identity and documents. The data is therefore forwarded to ComplyCube at the User's request.
Keyring Connect: Let's assume the Policy accepts Binance as a data source. The user has logged in on Binance and the Keyring browser extension notarises the session. Under an MPC-TLS scheme, they can export and selectively disclose data from the session.
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.
Keyring Pro: 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.
Keyring Connect: The Attestor reads the verified data from the Keyring attestation service acting as the notary in the MPC-TLS scheme.
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.
Last updated
