Verifiable Events
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 Off-Chain Reporting (OCR) 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.
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 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 at which the underlying observation was made. A
latestevent is just as cryptographically valid as afinalizedone — but it can still be reorganized away by the chain.
Related
- Event Verification — the algorithm used to validate an event.
- Confidence Levels — the orthogonal property: chain finality vs cryptographic authenticity.
- Watchers — the source of
watcher.eventrecords.