# Beta Scope
Source: https://docs.chain.link/ace/beta-scope
Last Updated: 2026-09-23

> For the complete documentation index, see [llms.txt](/llms.txt).

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](/ace/supported-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](/ace/reference/policy-library) (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](/ace/guides/policy-manager/custom-policies) and [custom extractors](/ace/guides/policy-manager/contracts/custom-contract-types):

- **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](/ace/guides/policy-manager/ccip-token-pools). Custom contract types and extractors are managed through the Coordinator API. See [Custom Contract Types & Extractors](/ace/guides/policy-manager/contracts/custom-contract-types) 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](https://en.wikipedia.org/wiki/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](/ace/guides/policy-manager/manage-data-validators). For the conceptual explanation of attestation-only vs. Credential Data Validator checks, see [Cross-Chain Identity — Credential data and privacy](/ace/concepts/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](https://github.com/smartcontractkit/crec-sdk)). Your organization chooses its signing model during onboarding.

In both models, you retain full ownership of your contracts through the [CRE Connect Wallet](/ace/concepts/signing-ownership). See [Signing & Ownership Model](/ace/concepts/signing-ownership) 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.

> **CAUTION: MVP feature**
>
> Managed offchain risk policies and the Evaluation API are an MVP. Their interfaces and capabilities can change during
> Beta. Contact your Chainlink representative before using this feature and for help with setup.

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](https://docs.chain.link/cre/service-quotas), including the HTTP trigger rate limit.

See [Offchain Policies](/ace/guides/policy-manager/offchain-policies) for an overview, [Managing Offchain Policies (MVP)](/ace/guides/policy-manager/offchain-policies/manage-offchain-policies) to configure wallet screening, and [Requesting Offchain Permits](/ace/guides/policy-manager/offchain-policies/request-offchain-permits) to integrate evaluations into an application.