Tokenized funds, bonds and stablecoins carry the same legal obligations as their traditional versions. Only eligible investors may hold them, sanctioned addresses must be blocked and transfer limits must hold. A common answer has been to write those rules straight into the token contract. That works until a rule changes, an investor uses a second wallet or the asset moves to another chain.
Chainlink ACE (Automated Compliance Engine) moves those rules out of the token and into a separate, managed layer. The token asks ACE whether a transaction is allowed, ACE evaluates a configurable chain of policies and the transaction either proceeds or reverts. Identity works the same way: an investor is verified once, and the result is usable on every EVM chain the asset lives on.
This guide explains how ACE is built, how a compliance check actually runs, how cross-chain identity keeps personal data off-chain, how ACE connects to Proof of Reserve and CCIP and what the Beta covers today.
In short: ACE is a compliance layer for EVM smart contracts. A PolicyEngine runs modular policies (allowlists, volume limits, identity checks, reserve-backed minting) every time a protected function is called. A Cross-Chain Identifier links all of an investor’s wallets to one identity with credentials issued once. Rules can change without redeploying the token. ACE has been in Beta since April 2026, with mainnet support on five EVM networks since May 2026.
What Is Chainlink ACE?
ACE has two layers.
On-chain contracts do the enforcement. There are two sets: Policy Management, which decides whether a transaction is allowed, and Cross-Chain Identity, which records who an address belongs to and which credentials that identity holds. These contracts run at transaction time like any other smart contract.
The ACE Platform manages those contracts. Chainlink’s documentation lists four managers:
| Manager | What it does |
|---|---|
| Policy Manager | Configures and deploys compliance rules for your contracts (UI and API) |
| Identity Manager | Creates identity and credential registries and issues credentials (UI and API) |
| Reporting Manager | Read-only queries of policy runs, transactions and on-chain state (API) |
| Active Monitoring | Screens addresses on a schedule and acts on tokens that are already deployed (UI and API) |
The documentation names three audiences. Token issuers and asset managers enforce the rules. Identity verification providers issue the credentials. Compliance and legal teams manage rules and read the audit trail without writing code.
ACE was introduced by Chainlink in June 2025 and has been in a staged Beta since April 2026. Its management actions are executed through CRE Connect, Chainlink infrastructure built on the Chainlink Runtime Environment.
Why Compliance Moved Out of the Token Contract
Writing compliance logic into a token runs into three problems that ACE’s design addresses.
Rules change, contracts should not. A new jurisdiction restriction or a lower transfer limit means a contract upgrade or redeployment when the rule lives in the token. With ACE the token only knows that a function is protected. The rules themselves are policy contracts that can be added, removed or reordered through the platform while the token stays the same.
Identity fragments across chains. A KYC result recorded on Ethereum means nothing on Base unless someone re-verifies the investor or builds a bridge for the credential. As tokenized assets spread across chains, per-chain identity becomes the bottleneck. ACE’s Cross-Chain Identifier links all of an investor’s addresses to one identity.
Auditors need evidence, not code. A compliance team has to show which rule allowed or blocked a specific transfer. Every ACE policy run emits an on-chain event, and the Reporting API turns those events into a queryable history.
How a Compliance Check Runs
The enforcement path is short and fully on-chain.
- The application contract inherits PolicyProtected, and its sensitive functions (transfer, mint, a DEX trade) carry the
runPolicymodifier. - When a user calls such a function, control passes to the PolicyEngine registered for that contract.
- Extractors parse the call data into named parameters, such as
from,toandamount, so policies do not need to understand each contract’s ABI. - The engine runs the attached policies in order. Each returns one of three results: Reject (the transaction reverts), Allow (the transaction is approved and the remaining policies are skipped) or Continue (defer to the next policy).
- If every policy returns Continue, the engine applies a configurable default result.
- The engine emits a
PolicyRunCompleteevent, which Chainlink indexes for the Reporting API.
Because Allow ends the evaluation, order matters. Chainlink’s architecture guidance is to place restrictive policies, such as a credential check, before permissive ones, so that nothing approves a transaction a later check would have rejected. The one deliberate exception is the BypassPolicy, which Chainlink’s policy reference says to place first: if every address in the transaction is on its list, it allows the transaction and skips all remaining checks. Use it only for addresses that should skip every rule.
Chainlink’s own example makes the flow concrete. An institutional investor buys $50,000 of a tokenized bond on a DEX. The PolicyEngine first checks that the investor’s identity holds KYC and accredited investor credentials, then checks that the trade stays within the investor’s daily volume limit. Both pass, so the trade executes. If the issuer later adds a time-of-day restriction, it becomes one more policy in the chain, and the DEX contract does not change.
The policy library
ACE ships with audited, pre-built policies. Since July 2026 organizations can also register custom policies of their own.
- AllowPolicy and RejectPolicy: allowlists and blocklists of addresses.
- OnlyAuthorizedSenderPolicy: only listed senders may call the function.
- BypassPolicy: listed addresses skip all remaining policies.
- MaxPolicy: a ceiling on the value of a single transaction.
- VolumePolicy: a minimum and a maximum for the value of a single transaction.
- VolumeRatePolicy: cumulative volume limits per account within a time period.
- IntervalPolicy: transactions only inside defined time windows.
- RoleBasedAccess
ControlPolicy : which roles may call which functions. - PausePolicy: a pause switch for protected functions.
- CredentialRegistry
Identity : the caller’s identity holds the required credentials.ValidatorPolicy - GroupedIdentity
ValidatorPolicy : different credential requirements for different groups, such as individuals and businesses. - SecureMintPolicy: new supply stays within the reserves reported by a Proof of Reserve feed, with an optional margin.
- CertifiedAction
DON : a permit produced by an off-chain check, delivered on-chain by a Chainlink DON.ValidatorPolicy
Cross-Chain Identity: Verify Once, Use Everywhere
The identity layer has three on-chain parts:
- IdentityRegistry maps wallet addresses to a CCID, a
bytes32value that represents one identity across EVM chains. One CCID can be linked to many addresses on many chains. - CredentialRegistry attaches credentials to a CCID: KYC, AML, accredited investor status or custom types, each with a type identifier, an expiration and optional data.
- CredentialRegistry
Identity resolves the caller to a CCID at transaction time and checks the credentials.ValidatorPolicy
The credential lifecycle
- The investor completes verification with a Credential Issuer, typically an identity verification provider.
- The issuer runs its checks off-chain and generates a CCID.
- The issuer registers the identity on-chain, mapping the investor’s wallet to the CCID.
- The issuer registers the credential: type, expiration and optional data.
- From then on, the issuer is not involved in day-to-day checks. The registries and the validator policy answer every transaction.
Credentials expire at the time the issuer set, and the issuer can revoke one immediately if an investor’s status changes. The registries are themselves protected by a PolicyEngine, so only authorized issuers can write to them. Since July 2026, one organization can also grant another read access to its registry, so a second issuer or venue can rely on existing credentials instead of verifying the same investor again.
What stays private
No personally identifiable information is stored on-chain. Documents and checks stay with the issuer, and only the result, a credential linked to a CCID, is recorded, usually as a hash or a minimal reference.
There is one trade-off the documentation states openly: the mapping between a CCID and its addresses is public, so anyone can see which addresses belong to the same identity. That is what makes cross-chain verification possible. Where it is a concern, issuers can give the same person separate CCIDs for different applications and keep the link off-chain.
Credentials can also carry structured data for more precise rules. Chainlink keeps the validators for that data as a curated catalog, by design, so that no personal data enters a policy. The first one supports jurisdiction control with ISO 3166-1 alpha-2 country codes, which lets the application allow or deny holders by country. The credential then carries a country code, not the documents behind it.
Preventive and Continuous Compliance
ACE enforces compliance in two ways, and an issuer can use either or both.
| Preventive (Policy Manager and Identity Manager) | Continuous (Active Monitoring) | |
|---|---|---|
| When it acts | While the transaction executes | After a scheduled screening run detects a risk change |
| What it does | Reverts a transaction that breaks a policy | Calls an admin function on the token, flags a decision for review or records it |
| Contract changes | Yes, the contract must integrate with ACE | None, the issuer provides the ABI and grants an on-chain role |
| Weakness | Cannot react to a change after the tokens were received | Cannot stop a transaction before the next screening run |
Active Monitoring, released on 7 October 2026, covers the gap that preventive checks leave. An address can be compliant when it receives a token and become high risk a month later, for example after being added to a sanctions list. Active Monitoring screens a watchlist of addresses with TRM Labs on a schedule and, when an address’s risk level changes, applies the issuer’s rule: log it, flag it for a person to review or call an enforcement function such as a freeze. Because it calls functions the token already has, it works on tokens that cannot be upgraded, as long as they have such admin functions and the issuer grants ACE’s CRE Connect Wallet the role to call them.
Preventive checks can also use off-chain data. A managed policy screens transaction participants with TRM Wallet Screening through a CRE workflow, and the approval reaches the chain as a single-use permit that the transaction consumes. Chainlink labels this an MVP during the Beta.
How ACE Connects to the Rest of Chainlink
ACE is not a standalone product. Three of its features reuse other Chainlink services, which is why it matters to the oracle network as a whole.
Proof of Reserve. The SecureMintPolicy reads the latest reserve value from a Chainlink Proof of Reserve feed before every mint and rejects any mint that would push total supply past the configured limit. By default that limit is the reported reserves; an issuer can require a buffer above them or, for operational headroom, allow a small excess. For a stablecoin or a tokenized fund, that turns the backing rule from a statement into a check on every mint.
CCIP. Cross-chain transfers are where compliance usually breaks. ACE supports CCIP token pools through their AdvancedPoolHooks: the source pool can run a policy check before it locks or burns tokens, and the destination pool before it releases or mints them. Each chain is configured separately, so an issuer can enforce its rules on both sides of a CCIP transfer, or apply different policies in each direction.
CRE and Chainlink DONs. Management actions are executed through CRE Connect, and off-chain checks such as wallet screening run as CRE workflows. When a workflow approves an action, a Chainlink decentralized oracle network (DON) delivers the permit on-chain, where the CertifiedAction
What the Beta Covers Today
ACE has moved quickly through 2026. The release notes give the timeline:
| Date | Release |
|---|---|
| 15 April 2026 | ACE Beta, a private, testnet-only release with Policy, Identity and Reporting Managers |
| 26 May 2026 | Mainnet support on Ethereum, Arbitrum, Avalanche, Base and Polygon |
| 17 July 2026 | Beta+: custom policies, grouped identity validation, shared registries, credential data validation, self-signing, managed off-chain risk policies (MVP) |
| 14 September 2026 | Custom contract types and custom extractors, beyond ERC-20 and ERC-3643 |
| 7 October 2026 | Active Monitoring |
Teams evaluating ACE should plan around the current limits, which Chainlink’s documentation lists:
- Mainnet access is by request. Testnets are available once ACE is enabled for an organization, and mainnet access is requested through Chainlink.
- EVM only. All supported networks are EVM chains.
- The managed experience covers platform-deployed contracts. PolicyEngines, policies and registries deployed outside the platform, for example with Foundry scripts, work on-chain but do not appear in the UI or the Reporting API.
- Custom mappers are not available yet, although custom extractors and custom policies are.
- Off-chain risk policies and Active Monitoring depend on a TRM Labs account and have Beta limits, such as at most ten addresses per off-chain evaluation and a watchlist from which addresses cannot be removed once added.
What ACE Does Not Decide
ACE enforces rules. It does not decide which rules apply. Which investors are eligible, which jurisdictions are excluded and which limits a fund needs remain legal decisions for the issuer and its advisers. Likewise, the quality of an identity check depends on the credential issuer that performed it. ACE makes those decisions enforceable, consistent across chains and auditable. That is a large step for institutions putting assets on-chain, but it is a tool for a compliance program, not a replacement for one.
Sources & References
- Chainlink Documentation, What is Chainlink ACE?
- Chainlink Documentation, ACE Architecture
- Chainlink Documentation, Cross-Chain Identity
- Chainlink Documentation, Preventive and Continuous Compliance
- Chainlink Documentation, Policy Library
- Chainlink Documentation, Protect CCIP Token Pools with ACE
- Chainlink Documentation, ACE Beta Scope
- Chainlink Documentation, ACE Supported Networks
- Chainlink Documentation, ACE Release Notes
- Chainlink Blog, Automated Compliance Engine (ACE): Technical Overview
Work with Matrixed.Link
Matrixed.Link operates Chainlink oracle infrastructure, validator nodes and full-stack blockchain infrastructure for protocols and institutions that need institutional-grade reliability. Official Chainlink node operator running Data Feeds, CRE, SVR and Proof of Reserve. ISO/IEC 27001:2022 certified. AAA-rated provider on StakingRewards.
Contact Matrixed.Link to discuss Chainlink oracle infrastructure for your protocol.
