CredentialRegistryIdentityValidatorPolicy

The CredentialRegistryIdentityValidatorPolicy validates that accounts involved in a transaction hold the required credentials from ACE's Cross-Chain Identity infrastructure. It checks each account against configured credential sources (IdentityRegistry + CredentialRegistry pairs) and credential requirements (which credential types must be present and how many validations are needed).

This is the primary policy for enforcing identity-based compliance such as KYC, accreditation, or sanctions screening.

Configuration

Both properties below can be set when the policy is first deployed and updated afterward by the policy owner. Credential sources contain on-chain addresses and must be configured per network. Credential requirements define rules that apply across chains.

Credential sources

A credential source defines where to look up identity and credential data for a given credential type. Each source is a tuple of:

  • Credential type ID — A bytes32 identifier for the credential type this source applies to (e.g., KYC, accreditation).
  • Identity registry address — The IdentityRegistry contract that maps wallet addresses to Cross-Chain Identifiers (CCIDs).
  • Credential registry address — The CredentialRegistry contract that stores credentials linked to CCIDs.
  • Data validator address (optional) — A contract that performs additional validation on the credential data. Set to address(0) for attestation-only checks. See Credential data and privacy for a full explanation of attestation-only vs. Credential Data Validator checks.

Multiple sources can be registered for the same credential type. The policy checks all configured sources and counts validations across them. Source uniqueness is determined by the (identityRegistry, credentialRegistry) pair — two sources with the same registry pair but different dataValidator addresses are considered duplicates.

Limits: Up to 8 sources per credential type.

Credential requirements

A credential requirement defines what credentials an account must hold. Each requirement specifies:

  • Requirement ID — A unique bytes32 identifier for this requirement.
  • Credential type IDs — An array of bytes32 credential types to check (e.g., KYC, accreditation).
  • Minimum validations — How many of the listed credential types must validate successfully. Must be at least 1.
  • Invert flag — When true, the check passes if the credential does not exist. This is useful for "must not be sanctioned" checks, where you want the transaction to succeed only if the account does not hold a sanctions credential.

An account passes a requirement if it accumulates at least minValidations successful validations across the listed credential types and configured sources.

Limits: Up to 8 requirements total, up to 32 credential types per requirement.

Runtime behavior

The policy expects a variable number of parameters from the extractor, each an address to validate. Every address is checked against all configured requirements.

For each address, the validation process:

  1. Iterates through all credential requirements.
  2. For each requirement, checks the listed credential types against each configured source.
  3. For each source, looks up the account's CCID in the IdentityRegistry, then checks whether the CredentialRegistry holds the credential for that CCID.
  4. If a DataValidator is configured, it additionally validates the credential data.
  5. Counts successful validations. If the count meets minValidations, the requirement passes.
  • run() — Reverts if any address fails any requirement. Returns Continue if all addresses pass all requirements.
  • postRun() — No state changes.

API reference

Setter functions

Credential sources:

  • addCredentialSource(CredentialSourceInput input) — Adds a source for a credential type. Reverts if the source already exists or if the maximum number of sources (8) for that credential type has been reached.
  • removeCredentialSource(bytes32 credentialTypeId, address identityRegistry, address credentialRegistry) — Removes a source. Reverts if the source is not found.

Credential requirements:

  • addCredentialRequirement(CredentialRequirementInput input) — Adds a requirement. Reverts if a requirement with the same ID already exists or if the configuration is invalid.
  • removeCredentialRequirement(bytes32 requirementId) — Removes a requirement. Reverts if the requirement ID is not found.

View functions

  • getCredentialSources(bytes32 credentialTypeId) — Returns all sources for a credential type.
  • getCredentialRequirement(bytes32 requirementId) — Returns a requirement's configuration.
  • getCredentialRequirementIds() — Returns all requirement IDs.

Use cases

  • KYC enforcement — Require that both sender and receiver hold a valid KYC credential before a token transfer.
  • Accredited investor checks — Restrict security token operations to accounts with accreditation credentials.
  • Sanctions screening — Use the invert flag to reject accounts that hold a sanctions credential.
  • Multi-source validation — Require credentials from multiple identity providers by configuring multiple sources and setting minValidations > 1.

Source

Get the latest Chainlink content straight to your inbox.