Verifying CRE Reports Offchain

This guide is for the receiver side: you already received a CRE report package (usually via HTTP) and need to prove it is authentic before using the payload.

When a workflow delivers results via HTTP (or another offchain channel), nothing onchain automatically validates the report. You must verify signatures before trusting the data.

The CRE SDK provides Report.parse() to do this inside a workflow. Verification runs offchain in your callback: signatures are checked with local cryptography, while authorized signer addresses are loaded via read-only calls to the onchain Capability Registry (default: Ethereum Mainnet). Results are cached per DON.

Where this guide fits

Receiver flow:

1. HTTP trigger (or your API) receives the POST payload.
2. Decode hex fields into bytes.
3. Report.parse(): verify signatures and read metadata.
4. Use trusted body() in your logic.

For the full sender → receiver overview, see API Interactions: CRE reports over HTTP.

What you'll learn

• When to verify reports offchain vs relying on onchain forwarders
• How Report.parse() validates signatures and reads metadata
• How to build a receiver workflow that accepts reports over HTTP
• How to restrict verification to specific CRE environments or zones

Prerequisites

• SDK: @chainlink/cre-sdk v1.8.0 or later (report verification support)
• Familiarity with Submitting Reports via HTTP (report structure and JSON payload patterns)
• For HTTP-triggered receivers: HTTP Trigger configuration

Onchain vs offchain verification

Offchain verification still uses onchain data as a trust anchor: the first time a DON is seen, the SDK reads the production Capability Registry on Ethereum Mainnet to learn f and authorized signer addresses.

Default (productionEnvironment()):

• Chain: Ethereum Mainnet (chain selector 5009297550715157269)
• Registry: 0x76c9cf548b4179F8901cda1f8623568b58215E62

How verification works

1. Parse the report header from rawReport (109-byte metadata + body).
2. Fetch DON info from the registry (if not cached): fault tolerance f and signer addresses.
3. Verify signatures: compute keccak256(keccak256(rawReport) || reportContext), recover signers, require f+1 valid signatures from authorized nodes.
4. Return a Report object with accessors for workflow ID, owner, execution ID, body, and more.

If verification fails, Report.parse() throws (for example, unknown signer, insufficient signatures, or registry read failure).

Complete example: HTTP receiver workflow

This workflow accepts a JSON payload (matching the format from Submitting Reports via HTTP), verifies it, then processes the trusted body.

import {
  HTTPCapability,
  handler,
  Report,
  type HTTPPayload,
  type Runtime,
  type SecretsProvider,
} from "@chainlink/cre-sdk"
import { hexToBytes } from "viem"
import { z } from "zod"

export const configSchema = z
  .object({
    authorized_key: z.string(),
  })
  .transform((data) => ({
    authorizedKey: data.authorized_key,
  }))

export type Config = z.infer<typeof configSchema>

type ParsedPayload = {
  report: string
  context: string
  signatures: string[]
}

export async function run(runtime: Runtime<Config>, payload: HTTPPayload): Promise<boolean> {
  const parsed: ParsedPayload = JSON.parse(new TextDecoder().decode(payload.input))

  const rawReport = hexToBytes(`0x${parsed.report}`)
  const reportContext = hexToBytes(`0x${parsed.context}`)
  const sigs = parsed.signatures.map((s) => hexToBytes(`0x${s}`))

  const report = await Report.parse(runtime, rawReport, sigs, reportContext)

  runtime.log(`Verified report from workflow ${report.workflowId()}, execution ${report.executionId()}`)

  // Use report.body() for your application logic (ABI-encoded payload from the sender workflow)
  void report.body()

  return true
}

export const initWorkflow = (config: Config, _secretsProvider: SecretsProvider) => {
  const http = new HTTPCapability()
  return [
    handler(http.trigger({ authorizedKeys: [{ type: "KEY_TYPE_ECDSA_EVM", publicKey: config.authorizedKey }] }), run),
  ]
}

What's happening:

1. An external system POSTs hex-encoded report, context, and signatures to your HTTP trigger.
2. Report.parse() verifies signatures against the production CRE registry.
3. On success, you read metadata and body() safely.

Report payload format

Receivers need three fields (plus optional metadata your API may add):

The reportContext layout used by the SDK:

• Bytes 0–31: config digest
• Bytes 32–39: sequence number (big-endian uint64)

API reference

See SDK Reference: Core: Report verification for full signatures, types, and configuration.

Report.parse()

Report.parse(
  runtime: Runtime,
  rawReport: Uint8Array,
  signatures: Uint8Array[],
  reportContext: Uint8Array,
  config?: ReportParseConfig,
): Promise<Report>

Parses and verifies a report. Throws if verification fails.

Report accessors

After a successful parse:

ReportParseConfig

import { productionEnvironment, zoneFromEnvironment, type ReportParseConfig } from "@chainlink/cre-sdk"

const config: ReportParseConfig = {
  acceptedZones: [zoneFromEnvironment(productionEnvironment(), 1)],
  acceptedEnvironments: [productionEnvironment()],
  skipSignatureVerification: false,
}

Most workflows should use the default config (production environment only).

Best practices

1. Verify before side effects: Call Report.parse() before writing to databases, chains, or external systems.
2. Permission on metadata: After verification, check workflowId(), workflowOwner(), or donId() match your expectations.
3. Deduplicate by execution ID: Use executionId() or keccak256(rawReport) to reject replays (see Submitting Reports via HTTP).
4. Do not skip signature verification in production unless you have another trust path.

Troubleshooting

invalid signature / unknown signer

• Signatures may be from a different DON or stale registry config.
• Confirm the sender workflow used production CRE and the report was not tampered with.

wrong number of signatures

• At least f+1 valid signatures are required. Extra invalid signatures are skipped; too few valid ones fails verification.

could not read from chain ...

• Registry read failed (RPC/network). Retry or check simulation vs production EVM access.

raw report too short

• rawReport is missing the 109-byte metadata header.

Learn more

• API Interactions: CRE reports over HTTP: sender → receiver overview
• Submitting Reports via HTTP: sender workflow; create and POST the report
• SDK Reference: Core: Report verification: Report.parse, accessors, and ReportParseConfig
• HTTP Trigger Overview: trigger deployed receiver workflows
• Submitting Reports Onchain: onchain forwarder verification path
• Building Consumer Contracts: permissioning onReport with workflow metadata