Off-Chain Policy Execution

ACE policies are not limited to on-chain logic. Off-chain policy execution lets you enforce compliance rules that depend on data or systems outside the blockchain — your internal compliance engine, third-party risk APIs, or any custom business logic. The checks happen off-chain before the transaction, and the result is delivered on-chain as a cryptographic permit that authorizes the action.

ACE provides two ways to use offchain policies:

  • Managed wallet risk screening — An out-of-the-box policy that screens wallet addresses with TRM Wallet Screening. You configure the risk thresholds and call the ACE Evaluation API; Chainlink manages the CRE workflow and onchain permit delivery.
  • Custom offchain integrations — An advanced model for internal compliance systems, custom policy endpoints, and other business logic. These integrations require infrastructure hosted by your organization and assistance from Chainlink during Beta.

Why off-chain policies?

On-chain policies evaluate data that is already available in the transaction calldata or on the blockchain. But many compliance requirements depend on information that only exists off-chain:

  • Risk and sanctions databases — screen wallet addresses against external risk intelligence providers
  • Internal compliance systems — connect to proprietary risk models, approval workflows, or internal rule engines
  • Custom business logic — any HTTP-accessible data source or decision service your compliance process requires

Off-chain policy execution bridges this gap by running these checks through the Chainlink Decentralized Oracle Network (DON) and delivering the result on-chain.

Managed wallet risk screening

A protected function that requires off-chain verification will revert if the caller does not have a valid permit. Your application must obtain a permit from the Chainlink DON before the user can call the function.

  1. Your application calls the ACE Evaluation API with the transaction's caller, target, function, chain, and permit parameters.
  2. ACE triggers a managed CRE workflow. The workflow selects the configured addresses and calls TRM Wallet Screening using the credential your organization stores in Vault DON.
  3. The workflow compares TRM's results with the policy's global risk threshold, unknown-risk setting, and category-specific thresholds.
  4. If an address is rejected, the evaluation becomes rejected and no permit is created.
  5. If the evaluation passes, the workflow delivers a permit through the Keystone Forwarder. The CertifiedActionDONValidatorPolicy (CADV) stores it onchain.
  6. Your application polls the Evaluation API. When the status becomes ready, it submits the protected transaction.
  7. The onchain policy matches the action to the stored permit and consumes it after the call succeeds.

Each managed permit is scoped to a specific caller, target, function, and set of extracted parameters. In the current Beta release, permits are single-use and do not expire.

Custom offchain integrations

The custom model supports compliance requirements beyond the managed TRM policy. A Chainlink DON workflow can call a policy endpoint hosted by your organization, which can query internal systems or other external services and return an Allow or Deny decision.

Your application and policy endpoint can be the same server — they represent different roles in the flow, not necessarily separate deployments.

  1. Your application sends an action request describing the transaction and any context required by the custom policies.
  2. A DON workflow evaluates its policy pipeline and calls your policy endpoint where required.
  3. Your endpoint runs your business logic and returns an Allow or Deny decision.
  4. If every policy passes, the DON generates and delivers a permit onchain.
  5. Your application waits for confirmation and then submits the protected transaction.

Custom integrations are designed with Chainlink during Beta. Contact your Chainlink representative to discuss workflow design, endpoint authentication, permit lifetime, usage limits, and operational requirements.

What custom integrations can connect to

The custom offchain policy model is open-ended. Built-in rules can run directly inside the DON workflow, and your external policy endpoints can integrate with systems reachable over HTTP, including:

  • Third-party compliance APIs (wallet risk scoring, sanctions screening, AML checks)
  • Internal compliance engines and proprietary rule sets
  • Multi-step approval workflows involving multiple parties
  • Any combination of the above in a single evaluation pipeline

Policies in the pipeline are evaluated sequentially — the first policy to deny stops execution and no permit is generated. This flexibility means off-chain policies can enforce compliance requirements that would be impossible to implement purely on-chain.

On-chain enforcement

The on-chain side of off-chain policy execution is handled by the CertifiedActionDONValidatorPolicy contract. This policy is attached to your protected functions like any other policy in the chain. At transaction time, it checks whether a valid permit has been delivered by the DON — it does not re-run the off-chain logic. The permit serves as cryptographic proof that the off-chain checks passed.

From the policy engine's perspective, the CertifiedActionDONValidatorPolicy is just another policy in the evaluation chain. It can be combined with on-chain policies (allowlists, volume limits, pause toggles, etc.) in any order.

Get the latest Chainlink content straight to your inbox.