How it works

A Connect verification runs through four stages; each hands a cryptographic artifact to the next, and the user’s raw account data never leaves the browser.

The arrow labels are the artifacts handed between stages; amber marks the local proving stage.

Launch. The dApp calls KeyringConnect.launchExtension(config) with its policy ID and the user’s wallet. The extension opens as a side panel, or the browser is redirected to the installation page.

Prove. The extension guides the user to sign in to a provider and runs a TLSNotary proving session locally (WebAssembly, in an offscreen document). The notary co-signs commitments to the session without seeing its plaintext; only the fields the policy needs are disclosed.

Verify and issue. Keyring verifies the proof and evaluates the disclosed fields against the policy’s rules. On a pass, an attestation is issued through a blinded signature, so issuance cannot be linked to the credential that later appears on chain.

Check. The credential lands in the KeyringCore contract, and gating becomes a single view call:


require(keyringCore.checkCredential(policyId, msg.sender), "not compliant");

checkCredential returns true while the credential is unexpired and the address is not blacklisted for the policy.

The cryptography behind stages two and three is in Learn; the state machine the SDK observes during the flow is in tracking state.