Beta Scope

ACE Beta is an early-access release for testing and integration on supported mainnet and testnet networks. The limitations listed below are all areas of active development. Each will be addressed as ACE progresses toward general availability.

Supported networks

ACE Beta is available on selected mainnet and testnet networks. Additional networks may be added before general availability (GA).

Custom extractors are registered by you, custom mappers are not available

ACE Beta provides a library of pre-built, audited policies (allowlists, volume limits, role-based access control, pause controls, and more) and pre-built extractors for ERC-20, ERC-3643, and CCIP-AdvancedPoolHooks function signatures. You can also register your own custom policies and custom extractors:

• Custom contract types: You can declare contract types with your own function ABIs via the Coordinator API, so contracts beyond ERC-20 and ERC-3643 (vaults, lending pools, custom token variants) are first-class citizens in the platform.
• Custom extractors: You write and deploy your own extractor contract (implementing IExtractor), then register it via the Coordinator API with its supported function signatures and per-chain deployment addresses. The platform does not write extractors for you: pre-built extractors cover ERC-20, ERC-3643, and CCIP-AdvancedPoolHooks signatures.
• Custom mappers: Deploying mapper contracts that transform or combine extracted parameters before they reach a policy is not available through the platform during Beta.

The built-in ERC-20 and ERC-3643 contract types get the full managed experience (policy configuration, reporting, and monitoring) through the Platform UI and Coordinator API, with extractors attached automatically. The built-in CCIP-AdvancedPoolHooks type covers the preflightCheck and postflightCheck hook functions; see Protect CCIP Token Pools with ACE. Custom contract types and extractors are managed through the Coordinator API. See Custom Contract Types & Extractors for the custom flow.

Self-deployed contracts are not visible in the platform

Contracts deployed outside the ACE Platform — for example, via Foundry scripts or direct factory calls — will not appear in the UI or API responses.

The ACE Platform only tracks and manages contracts it deploys. Self-deployed PolicyEngines, policies, registries, and extractors function onchain but will not appear in the UI, API responses, or reporting dashboards.

To use the full managed experience (UI dashboards, Reporting API queries, policy management), deploy contracts through the Platform UI or Coordinator API.

Credential data validation is a curated catalog

In addition to attestation-based checks (verifying whether a credential exists), the ACE Platform supports credential data validation — inspecting the contents of a credential's credentialData field for more granular checks. You link a data schema to a credential type, issue credentials that carry data, and attach a Data Validator to a policy's credential source to enforce rules on that data.

Data Validators are a curated catalog maintained by Chainlink, not something organizations deploy themselves. This is by design: curating the available validators and their data schemas ensures no personally identifiable information (PII) are used. The first available validator supports jurisdiction control using ISO 3166-1 alpha-2 country codes; Chainlink may add further validators over time. Bringing your own Data Validator is not offered — this is a permanent design choice, not a Beta limitation.

To get started, see Managing Data Validators. For the conceptual explanation of attestation-only vs. Credential Data Validator checks, see Cross-Chain Identity — Credential data and privacy.

Signing model is chosen at onboarding

ACE supports two signing models: delegated signing (Chainlink signs and executes transactions on your behalf) and self-signing (you sign operations yourself using the CRE Connect SDK). Your organization chooses its signing model during onboarding.

In both models, you retain full ownership of your contracts through the CRE Connect Wallet. See Signing & Ownership Model for details on how each model works.

Managed offchain risk policies are limited during Beta

ACE Beta provides a managed wallet_risk_scoring policy that screens transaction participants with TRM Wallet Screening and delivers approved permits onchain through a managed CRE workflow.

The following limitations apply:

• TRM access required — Your organization must have a TRM Labs account with Wallet Screening API access and provide its own API credential through CRE Vault DON.
• One policy type — wallet_risk_scoring is the only managed offchain policy available. Custom offchain integrations require assistance from Chainlink.
• One active policy per organization — Archive the existing offchain policy before creating another.
• Ten addresses per evaluation — A workflow execution can screen at most ten unique wallet addresses.
• Fixed permit lifetime and usage — Managed permits are single-use and do not expire. These values are not configurable in the current release.
• Extractor-dependent protection — Permit parameters must correspond to supported extractor outputs and exactly match the values extracted from the eventual onchain transaction.
• CRE quotas apply — Evaluations are subject to current CRE Service Quotas, including the HTTP trigger rate limit.

See Offchain Policies for an overview, Managing Offchain Policies (MVP) to configure wallet screening, and Requesting Offchain Permits to integrate evaluations into an application.