Key Terms and Concepts

This glossary defines the key terms used throughout the ACE documentation. Use it as a quick reference when reading other pages.

Access grant

A cross-organization link that gives another organization read access to one of your resources. For registries, an access grant lets a grantee organization read a grantor's registry and use it as a credential source. Grants are active or revoked, and only the resource owner can create or revoke them. Learn more in External Registries.

ACE Platform

The complete user-facing layer of ACE, consisting of the Platform UI (app.chain.link), the Coordinator API (create, configure, and deploy ACE resources), the Evaluation API (request managed offchain permits), and the Reporting API (query onchain state and transaction history). Everything you can do in the UI is also available through the Coordinator API.

AML (Anti-Money Laundering)

A set of laws, regulations, and procedures designed to prevent criminals from disguising illegally obtained funds as legitimate income.

CCID (Cross-Chain Identifier)

A 32-byte identifier that uniquely represents an entity across multiple EVM blockchains. A CCID links one or more wallet addresses — potentially on different chains — to a single identity. Credentials like KYC or AML status are attached to the CCID, not to individual addresses, making them portable across chains. Learn more in Cross-Chain Identity.

Composability

The ability to combine modular components in a flexible manner. In ACE, composability means you can chain multiple policies together on a single function, use Policy Management with or without Cross-Chain Identity, and reuse the same policies across different contracts and functions.

Context parameter

A bytes field passed through the policy execution flow, used to supply arbitrary transaction-specific data to policies. Common uses include offchain signatures, Merkle proofs for allowlist verification, and dynamic risk parameters. Learn more in Policy Management Concepts.

Coordinator API

The management API for creating, configuring, and deploying ACE resources (policy engines, policies, identities, credentials). Part of the ACE Platform. Everything available in the Platform UI is also available through this API. See the interactive API reference for details.

CRE Connect

Chainlink infrastructure that routes ACE Platform actions to the blockchain. When you trigger an action (deploy a policy, register an identity), CRE Connect prepares and executes the blockchain transaction through your CRE Connect Wallet.

CRE Connect Wallet

A dedicated onchain smart contract wallet deployed for your organization on each network where you use ACE. Your wallet owns the CRE Connect Wallet, and the CRE Connect Wallet owns all your ACE contracts (policy engines, registries, policies). Chainlink is registered as an authorized operator, allowed to execute operations on your behalf but unable to change ownership or authorization settings. Learn more in Signing & Ownership Model.

Credential

A verifiable attribute linked to a CCID, such as KYC verification, AML clearance, or accredited investor status. Credentials are stored in a Credential Registry and can be validated onchain without revealing sensitive information. Only hashes or minimal references are stored on the blockchain — the actual PII stays offchain.

Credential Data Validator

An optional onchain contract (also called a Data Validator) configured on a Credential Source that inspects the contents of a credential's credentialData field. This enables decisions based on what's inside a credential (for example, a jurisdiction code), not just whether the credential exists. ACE provides a pre-built AllowDenyList Data Validator for jurisdiction control; when no validator is configured, a source is attestation-only. Learn more in Managing Data Validators and Cross-Chain Identity — Credential data and privacy.

Credential Issuer

A trusted offchain entity (for example, a KYC/AML provider) authorized to perform real-world identity verification, generate CCIDs, and register the resulting credentials onchain. The Credential Issuer's write access to the registries is governed by policies in the PolicyEngine, ensuring only authorized issuers can create identities and issue credentials.

Credential Registry

An onchain contract that manages the lifecycle of credentials linked to CCIDs, including registration, validation, renewal, and removal. Each credential record includes a credential type identifier, an expiration timestamp, and optional credential data (typically a hash for privacy).

Credential Source

An onchain data structure that tells the Identity Validator which Identity Registry and Credential Registry to trust for a given credential type. A single source can handle multiple credential types. Sources are configured when setting up the CredentialRegistryIdentityValidatorPolicy.

Credential Type Identifier

A bytes32 value that denotes the type of credential (for example, KYC, AML, or accredited investor). Identifiers are generated using keccak256 of a namespaced string: keccak256("common.kyc") for standard types, or keccak256("com.yourapp.custom") for application-specific types. The common. prefix is reserved for standard credential types like common.kyc, common.aml, common.kyb, and common.accredited.

Custom policy

A policy implemented by your own contract (rather than the pre-built library) and registered with the ACE Platform. Custom policy implementations are scoped to your organization and, once registered, are used exactly like library policies. Learn more in Custom Policies.

Data Schema

A reusable definition of the shape and format of a credential's data, linked to a Credential Type so that credentials issued against it carry validated structured data (for example, ISO 3166-1 alpha-2 country codes). Data schemas make a credential type typed rather than attestation-only. Learn more in Managing Credential Types.

Default result

The PolicyEngine's fallback decision when every policy in a policy chain returns Continue and none makes a final Allow or Reject decision. The default result can be set to either allow or reject, and it is configured per target contract via the desired_default_allow field. Learn more in Policy Ordering & Composition.

Delegated signing

One of two signing models available in ACE. Chainlink signs and executes blockchain transactions on your behalf via the CRE Connect Wallet. You retain full ownership of all contracts. The signing model is chosen during onboarding. Learn more in Signing & Ownership Model.

DON (Decentralized Oracle Network)

A network of independent Chainlink oracle nodes that reach consensus on offchain computations and deliver certified results onchain. The CertifiedActionDONValidatorPolicy uses a DON to validate that a transaction has been approved through an offchain workflow before allowing it to proceed.

ERC-20

A widely used Ethereum token standard defining rules for fungible tokens. ACE provides a reference implementation (ComplianceTokenERC20) that adds policy-protected transfers, minting, and burning to a standard ERC-20.

ERC-165

An Ethereum standard that enables contracts to declare the interfaces they implement. ACE contracts use ERC-165 for interface detection during policy registration and validation.

ERC-3643

A regulated token standard (also known as T-REX) designed for securities and permissioned tokens. ACE provides a reference implementation (ComplianceTokenERC3643) that replaces the canonical T-REX identity (ONCHAINID) and compliance (ModularCompliance) systems with ACE equivalents. Learn more in Building an ERC-3643 Compliance Token.

Evaluation API

The MVP runtime API for requesting and monitoring managed offchain policy evaluations. An application submits a transaction intent, receives a deterministic permit ID, and polls until the permit is ready onchain or the evaluation is rejected or fails. Contact your Chainlink representative for help with setup, and see Requesting Offchain Permits and the interactive API reference.

External registry

A registry owned by another organization that has been shared with yours through an access grant. From the grantee's perspective it appears with access_type: "granted" and is read-only — you can reference its identities and credentials as a credential source but cannot write to it. Learn more in External Registries.

Extractor

A helper contract that parses raw transaction calldata for a specific function signature and decodes it into a list of named parameters. The PolicyEngine uses extractors to provide each policy with the specific parameters it needs. For example, an ERC20TransferExtractor parses transfer(address,uint256) calls into from, to, and amount parameters.

Identity Manager

The ACE Beta product for managing cross-chain identities and credentials via the platform UI or API. Identity Manager operates on the Cross-Chain Identity onchain contracts (Identity Registry and Credential Registry).

Identity Registry

An onchain contract that maintains mappings between wallet addresses and CCIDs. Each address maps to exactly one CCID, though a single CCID can be associated with multiple addresses across multiple chains.

Identity Validator

An onchain contract (typically the CredentialRegistryIdentityValidatorPolicy) that verifies whether a given account meets a set of credential requirements. When a user calls a protected function, the Identity Validator resolves the user's address to a CCID, then checks whether that CCID holds the required credentials from trusted Credential Sources.

KYC (Know Your Customer)

A compliance process requiring financial institutions to verify the identity of their clients. In ACE, KYC is represented as a credential type (common.kyc) attached to a user's CCID after offchain verification by a Credential Issuer.

Managed offchain policy

An MVP offchain compliance rule delivered as a managed service. You configure the rule and attach it to a target function; Chainlink manages the CRE workflow, external provider call, CADV deployment, and onchain permit delivery. ACE Beta provides the wallet_risk_scoring policy for TRM Wallet Screening. Contact your Chainlink representative for help with setup, and see Managing Offchain Policies (MVP).

Mapper

An optional helper contract used to transform or combine parameters extracted from transaction data before passing them to a policy. Mappers are needed only for advanced scenarios — for example, calculating a USD value from a token amount and price before passing it to a volume policy. In most cases, the PolicyEngine's built-in name-based parameter mapping is sufficient.

Permit

An onchain authorization for one specific transaction intent. A managed offchain permit binds the caller, target, function selector, and ordered extractor parameters. The DON publishes it to a CertifiedActionDONValidatorPolicy before the user submits the protected transaction. Managed wallet risk permits are single-use and do not expire in the current Beta release.

PII (Personally Identifiable Information)

Information that can identify an individual, such as a name, address, or national ID number. ACE's Cross-Chain Identity system avoids storing PII onchain, using hashed references instead to preserve privacy.

Platform UI

The web interface at app.chain.link for managing ACE resources visually — deploying policy engines, configuring policies, registering identities, and issuing credentials. Part of the ACE Platform. Everything available in the UI is also available through the Coordinator API.

Policy

A self-contained onchain contract that holds a single compliance rule. Each policy implements a run() function that receives parameters and returns a verdict: Allowed (final approval), Continue (defer to the next policy), or reverts with PolicyRejected (final rejection). Policies can optionally implement a postRun() function for state changes after a check passes (for example, incrementing a volume counter). See the Policy Library for all pre-built policies.

Policy chain

The ordered sequence of policies attached to a specific function selector on a target contract. The PolicyEngine executes policies in chain order; each policy's result (Reject, Allow, or Continue) determines whether subsequent policies run. Learn more in Policy Ordering & Composition.

Policy Engine

The central onchain orchestrator. The PolicyEngine holds the registry of all policies attached to a protected contract's function selectors. When a protected function is called, the PolicyEngine calls the relevant Extractor to parse the transaction data, then executes each attached policy in order. A single PolicyEngine can manage policies for multiple contracts and functions.

Policy implementation

The reusable template (contract code + configuration schema) that a policy instance is created from. Implementations are either pre-built library types (global) or custom types registered by an organization (org-scoped). See Managing Policies.

Policy Management

The onchain framework for defining, executing, and managing dynamic compliance rules. It consists of PolicyProtected contracts (the hook), the PolicyEngine (the orchestrator), Policies (the rules), and Extractors (the data parsers). Learn more in Policy Management Concepts.

Policy Manager

The ACE Beta product for managing policy engines, policy instances, extractors, and protected contracts via the platform UI or API. Policy Manager operates on the Policy Management onchain contracts.

PolicyFactory

An onchain factory contract that deploys policy instances by cloning a policy implementation. When you create a policy instance, the PolicyFactory clones the implementation, initializes it, and verifies the implementation supports the IPolicy interface via ERC-165.

PolicyProtected

An abstract contract that your application inherits from. It provides the runPolicy modifier, which acts as the hook into the policy system. When a user calls a function decorated with runPolicy, the modifier intercepts the call and asks the PolicyEngine to evaluate all attached policies before allowing execution to proceed.

Proof of Reserve (PoR)

A Chainlink data feed that reports the real-world reserves backing a tokenized asset. The SecureMintPolicy uses a PoR feed to verify that minting new tokens will not exceed proven reserves. Learn more in the SecureMintPolicy reference.

Protected function

A function on your smart contract that is guarded by the runPolicy modifier. When called, the modifier intercepts execution and routes it through the PolicyEngine for policy evaluation before allowing the function body to proceed.

Reporting API

The API for querying onchain state, transaction history, and policy run results. Chainlink's indexing infrastructure monitors onchain events emitted by your PolicyEngines and makes the data available through this API. Part of the ACE Platform. See the interactive API reference for details.

Reporting Manager

The ACE Beta product for querying onchain state, transaction history, and policy run results. Currently available via API only. Reporting Manager exposes data from the Reporting API, which indexes onchain events and state.

Self-signing

One of two signing models available in ACE. ACE prepares unsigned draft operations; you poll, sign (EIP-712), and submit them using the CRE Connect SDK. You retain full ownership of all contracts. The signing model is chosen during onboarding. Learn more in Signing & Ownership Model.

Trusted Verifier

See Credential Issuer. A trusted verifier is an offchain entity authorized to conduct external checks (KYC, AML, document verification) and register the resulting credentials onchain.

Active Monitoring terms

The following terms are specific to Active Monitoring. Some reuse words from Policy Management, such as decision and operation, with a different meaning.

Active Monitoring

The ACE capability that screens the addresses on a watchlist with TRM on a schedule, applies a monitoring rule to each change of risk level, and acts on tokens that are already deployed, without changing their contracts. It is the continuous counterpart of the preventive Policy Manager and Identity Manager. Learn more in What is Active Monitoring? and Preventive and Continuous Compliance.

Associated contract

A contract registered with a monitored token, other than the token itself, on which an enforced action can run. A separate blocklist contract is a common example. Learn more in Monitored Tokens and Associated Contracts.

Balance condition

The option Only execute if the address holds a balance on this token on an enforced action. Active Monitoring reads the balance of the screened address with balanceOf(address) and runs the action only if the balance is greater than zero. Learn more in Monitoring Rules and Responses.

Decision

The record that Active Monitoring keeps each time a monitoring rule matches a risk event for an address on one network. The Decisions log lists decisions. A decision holds the TRM result, the rule that matched, the outcome, and the operation. It is unrelated to a policy run in Policy Management. Learn more in Decisions, Review, and Audit Trail.

Enforced action

One call to an enforcement function, defined in the Enforce response of a monitoring rule. It names the contract, the function, and a parameter mapping for each argument. Learn more in Monitoring Rules and Responses.

Enforcement function

A write function on your token, or on an associated contract, that Active Monitoring calls when a rule enforces an action, such as a freeze or a blocklist function. You select it when you register the contract. It must have named inputs, no array or tuple inputs, and at least one input. Learn more in Monitored Tokens and Associated Contracts.

Monitored token

A token contract registered with Active Monitoring, optionally with associated contracts. A monitored token has one monitoring rule. It is not a target: a target is a contract protected by a PolicyEngine. Learn more in Monitored Tokens and Associated Contracts.

Monitoring rule

The rule of a monitored token that maps each TRM risk level to a response. A monitoring rule cannot be edited: you delete it and create a new one. It is not a policy. Learn more in Monitoring Rules and Responses.

Operation

An onchain call that CRE Connect executes through your CRE Connect Wallet. Active Monitoring creates one operation for each enforced action. Its status moves from Submitted to Success or Failed, with Pending signature under self-signing. See Limits, Statuses, and Values.

Parameter mapping (Active Monitoring)

In Active Monitoring, the choice of a value for each argument of an enforcement function: Screened address, Balance, or a constant. It is unrelated to the extractor and mapper pattern of Policy Management. See Mapper and Monitoring Rules and Responses.

Response

What a monitoring rule does for a risk level: Silently log records the decision, Flag waits for a person to review it, and Enforce creates an operation for each enforced action. Learn more in Monitoring Rules and Responses.

Risk event

A change in the TRM risk level of a watchlist address, or its first screening. A risk event is what a monitoring rule reacts to: each rule that matches creates a decision. An address that stays at the same level raises no new event. Learn more in Watchlist and Screening.

Risk level (TRM risk score)

The highest risk level that TRM reports for an address: Severe (score 15), High (10), Medium (5), Low (1), or Unknown (0). A monitoring rule maps each level to a response. See Limits, Statuses, and Values.

Screening interval

The number of hours between two Active Monitoring screening runs. The Platform UI offers 6, 12, and 24 hours. Learn more in Watchlist and Screening.

TRM API key

Your TRM Labs API key, which Active Monitoring uses to screen the watchlist. You store it in General settings > API access. It is different from your ACE organization API key, and from the credential used by managed offchain policies. See Configure the TRM API Key and Screening Schedule.

Watchlist

The list of wallet addresses that Active Monitoring screens with TRM. Learn more in Watchlist and Screening.