Policies and claims
A policy is the compliance rule your dApp gates on. It composes who you accept, where they may not be from, where they verify, and what they must prove, into a single on-chain check. Keyring enforces it and issues a credential to a wallet that passes.
What a policy composes
- Jurisdiction rules. Exclusions by country, such as no UK or Russia, and no FATF high-risk states. A user from an excluded country cannot pass.
- A datasource. The account the user verifies against, such as an exchange. A policy can accept one of several, so a user proves at whichever they hold.
- Claims. The requirements a proof must satisfy. Each claim can carry sub-requirements, such as proof of address and AML/CFT passed. A policy can require a KYC claim for individuals or a KYB claim for businesses.
A user who clears the jurisdiction rules, verifies at an accepted datasource, and satisfies the required claim is issued a credential.
Claims
A claim is a named rule over canonical fields. kyc_verified reads
user.kyc_verified; not_in_fatf reads user.country and excludes a set of
states. Claims are reusable, so the same kyc_verified claim backs every policy
that needs it. Your policy requires one claim, and the proof discloses only the
fields that claim reads. To store the underlying data points a claim
evaluates, or run your own rules on them, see
Data sharing.
Enforcement
The credential lands in the KeyringCore contract, and your contract gates on it with one call. See gating with checkCredential.
Configuring a policy
Policies are provisioned by Keyring for your market. Tell Keyring support the jurisdictions, datasources, and claims you need, and you receive a policy ID to pass to the SDK and your contract.