# Verifiable Events
Source: https://docs.chain.link/crec/concepts/verifiable-events
Last Updated: 2026-05-01

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

A **verifiable event** is the unit of observation that CRE Connect delivers to your application. Every event a channel emits — whether it represents a contract log, a watcher state change, a wallet state change, or an operation status — is signed by the Chainlink **Decentralized Oracle Network (DON)** using the <a href="/architecture-overview/off-chain-reporting" target="_blank" rel="noopener noreferrer">**Off-Chain Reporting (OCR)**</a> protocol. Your application can re-verify that signature locally before acting on the data.

This is the property that makes the events *verifiable*: applications do not have to trust CRE Connect's delivery infrastructure. CRE Connect is just a delivery mechanism — the cryptographic proof of authenticity is generated by the DON and travels with the event.

## Event envelope

Every event carries the same envelope:

- An identifier and the channel that produced it.
- A **type** tag (one of the four kinds of events listed below).
- A **proof** — an OCR proof signed by the DON, made up of the underlying OCR report, replay-protection context, and a set of OCR signatures.
- The typed **payload**, decoded according to the event type.
- The timestamp at which CRE Connect received the event from the DON.

The proof is what makes the event verifiable: an application can recompute the report hash, recover the signer addresses from the signatures, and check that those signers belong to the expected DON signer set, with at least a configured quorum of distinct valid signatures. The detailed algorithm is described in [Event Verification](/crec/concepts/event-verification).

## Event types

CRE Connect emits four kinds of events. All of them share the verifiable envelope above; they differ only in what the payload contains.

| Event type         | Source                                                                                    | Typical payload                                                                                                                               |
| ------------------ | ----------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------- |
| `watcher.event`    | A [watcher](/crec/concepts/watchers) observed a matching log on-chain.                    | The decoded event from the underlying contract, plus the on-chain transaction hash, block number, and confidence level.                       |
| `watcher.status`   | The lifecycle state of a watcher changed.                                                 | The new watcher status (e.g. `pending`, `active`, `archiving`, `archived`, `failed`, `archive_failed`) and an optional human-readable reason. |
| `wallet.status`    | The lifecycle state of a Smart Account wallet changed.                                    | The new wallet status (e.g. `pending`, `deploying`, `deployed`, `archived`, `failed`) and metadata about the deployment chain.                |
| `operation.status` | The on-chain Smart Account emitted an `OperationExecuted` log for one of your operations. | The wallet operation ID, the new operation status, and — on `confirmed` — the chain transaction hash and per-transaction execution result.    |

## What "verifiable" really means

The verifiable property gives applications three concrete guarantees:

- **Authenticity.** A successful verification proves that an OCR-signed quorum of DON nodes attested to the underlying observation. A malicious or compromised delivery layer cannot forge an event because it does not have the DON's signing keys.
- **Integrity.** Any tampering with the payload, the report, the context, or the signatures causes verification to fail. The OCR report binds the event hash, and the signatures bind the report.
- **Replay protection.** The OCR context (epoch / round / config hash) is part of the signed message, so signatures are not reusable across rounds or configurations.

It does **not** give you:

- **Non-repudiation across tenants.** Other tenants of CRE Connect cannot verify *for whom* an event was generated unless they have access to the same Smart Account / wallet metadata. Verification is about authenticity, not authorization.
- **Real-time finality.** Verifiability is independent of the [confidence level](/crec/concepts/confidence-levels) at which the underlying observation was made. A `latest` event is just as cryptographically valid as a `finalized` one — but it can still be reorganized away by the chain.

> **CAUTION: Always verify before acting**
>
> Treat unverified events as untrusted data. Verification is not automatic, because it has a small CPU cost and some
> pipelines (read-only dashboards, tail-following loggers) do not need it. For any code path that triggers a side effect
> — a database write, a fund flow, a downstream API call — verify before acting.

## Related

- [Event Verification](/crec/concepts/event-verification) — the algorithm used to validate an event.
- [Confidence Levels](/crec/concepts/confidence-levels) — the orthogonal property: chain finality vs cryptographic authenticity.
- [Watchers](/crec/concepts/watchers) — the source of `watcher.event` records.