Five Chainlink Products. One Architecture. The DON+OCR Pattern Underneath Everything.

The shortcut nobody tells you

When developers first encounter Chainlink, they learn the products one at a time. Data Feeds. Then VRF. Then Automation. Then Functions. Then CCIP. Each has its own docs page, its own interface, its own set of concepts to memorize. By the time you've read through all of them, it feels like you've learned five separate systems.

You haven't. You've seen the same system five times wearing different clothes.

Every Chainlink product, without exception, is built on the same two-layer skeleton: a Decentralized Oracle Network (the trust layer, independent nodes that can't easily collude) running the Offchain Reporting protocol (the coordination layer, how those nodes reach consensus off-chain and write a single attested result on-chain). Once you see that skeleton clearly, you stop learning products and start recognizing patterns. That shift is worth months of reading time.

This is day 14 of the 28-day Chainlink architecture series. Days 8 through 13 covered Automation, Functions, VRF, Data Feeds, Proof of Reserve, Data Streams, Staking, and CCIP individually. Today pulls all of it together into the one mental model that should have come first.

The skeleton, stated precisely

The DON+OCR pattern has three steps that repeat across every product:

Step 1 — Independent observation. Every node in the network makes its own observation of whatever the product is measuring: a price, a random number request, an upkeep condition, a JavaScript execution result, a Merkle root of cross-chain messages. Each node acts independently. No node sees another's observation before making its own.

Step 2 — Off-chain consensus. Nodes share their observations over a peer-to-peer network and run the OCR protocol to reach agreement. One signed report is assembled containing the aggregated result. A quorum of nodes must sign it. The computation is expensive. The consensus is cheap. The blockchain never sees the intermediate steps.

Step 3 — On-chain verification. One node submits the signed report to a smart contract. That contract verifies the quorum's signatures and exposes the result. The verification is what the blockchain actually does. Not the computation, not the consensus. Just the final check that enough independent signers agreed on this exact payload.

Everything else about each product, the specific interface you call, the kind of result that gets delivered, the billing model, the callback pattern, is detail layered on top of that skeleton. The skeleton itself never changes.

Seeing it in each product

Here is every product from the past seven days of this series, mapped to the same three steps:

Data Feeds

• Observe: each node fetches the asset price from multiple independent data aggregators and computes its own median
• Consensus: OCR round produces one signed report containing the network's aggregated median
• Verify: the AccessControlledOffchainAggregator contract checks quorum signatures, exposes latestRoundData()

VRF

• Observe: the VRF oracle node generates a random value and cryptographic proof using its pre-committed private key and finalized block data
• Consensus: in v2.5, the VRF Coordinator handles the proof verification; the observation and proof generation happen as a single atomic step per oracle
• Verify: the VRF Coordinator contract validates the cryptographic proof on-chain before delivering the random word to the consumer contract

Automation

• Observe: every Automation node independently simulates checkUpkeep against its own view of the chain state
• Consensus: OCR3 round produces a signed report containing performData for eligible upkeeps
• Verify: the Registry contract validates the quorum signatures before calling performUpkeep

Functions

• Observe: every DON node independently executes the JavaScript source code in its own isolated Deno sandbox and produces a return value
• Consensus: the DON runs OCR to aggregate all nodes' execution results (typically a median for numeric outputs)
• Verify: the FunctionsCoordinator contract validates the quorum signatures and the FunctionsRouter calls the consumer's fulfillRequest callback

Proof of Reserve

• Observe: each node independently queries the custodian's reserve data (for off-chain collateral) or verifies the underlying chain directly (for on-chain collateral)
• Consensus: OCR round produces one signed report of the current reserve balance
• Verify: the same AccessControlledOffchainAggregator pattern as Data Feeds, exposing latestRoundData() with a reserve balance instead of a price

CCIP

• Observe: the Committing DON nodes independently monitor the source chain for CCIPMessageSent events and build Merkle trees from batches of messages
• Consensus: OCR (Commit plugin) produces a signed Commit Report containing the Merkle root; separately, the Executing DON runs the Execute plugin to validate and prepare execution
• Verify: the OffRamp contract validates the quorum signatures on the Commit Report before accepting the Merkle root; separately verifies Merkle proofs before executing each individual message

What changes between products, and what doesn't

The three-step skeleton is constant. What varies is the answer to three questions:

What is being observed? A price. A random number. An upkeep condition. A JavaScript execution result. A reserve balance. A cross-chain message batch. The observation layer is where each product diverges.

What OCR version runs the consensus? Data Feeds and VRF use OCR2. Automation uses OCR3 (lower latency, batching support). CCIP runs two separate OCR plugins (Commit and Execute) on the same Role DON. Functions uses OCR2. The version choice reflects the latency and throughput requirements of each product, not a fundamental difference in the consensus model.

What does the on-chain contract do with the result? Data Feeds expose a price. VRF Coordinator validates a cryptographic proof and delivers randomness. The Registry executes a keeper job. FunctionsCoordinator routes the result to a callback. The OffRamp stores a Merkle root or executes a message. Each product's on-chain contract is essentially a specialized consumer of the same OCR-attested report format.

Why this matters for audits specifically

If you're reviewing contracts that integrate Chainlink, the DON+OCR mental model gives you one consistent set of questions that applies across every product, not five separate mental models to switch between.

Trust boundary question (applies everywhere): what address is the consumer contract trusting to call it, and does that match the legitimate address derived from the product's architecture? A ccipReceive function that doesn't verify msg.sender == router, a VRF callback that doesn't check msg.sender == vrfCoordinator, an Automation performUpkeep that doesn't check msg.sender == forwarder. All three share are the same vulnerability class. Unverified caller on the trusted callback. The surface is different each time. The root cause is identical.

Report verification question (applies everywhere): is on-chain signature verification actually happening before the result is consumed? The aggregator checks quorum signatures before exposing latestAnswer. The Registry checks them before calling performUpkeep. The FunctionsCoordinator checks them before triggering fulfillRequest. The OffRamp checks them before storing a Merkle root. In a custom or forked integration, this verification might be missing or weakened. The question is always the same: does the on-chain contract verify that enough independent signers agreed on this exact payload before acting on it?

Staleness question (applies everywhere): how old is the last attested result, and does the consumer contract check that before using it? This shows up most obviously in Data Feeds (the updatedAt check from Day 5) and Proof of Reserve, but the principle applies to Automation (what if the DON stopped simulating upkeeps?), Functions (what if a request was never fulfilled?), and CCIP (what if a message sat pending because execution failed?). The specific field name and threshold differ. The failure mode is the same.

The evolution: from DON to CRE

The DON+OCR pattern that underlies every product today is itself evolving. The Chainlink Runtime Environment (CRE) is changing how capabilities are organized: instead of one monolithic DON doing everything for one service, individual capabilities run on dedicated DONs and compose into workflows. A pricing capability DON, a computation capability DON, a cross-chain messaging capability DON, all orchestrated together rather than bundled into one.

The three-step skeleton stays the same in CRE. What changes is the granularity: instead of "one DON handles all of Automation," each atomic capability of Automation becomes its own DON-backed service that can be reused across other workflows. The mental model you just built doesn't break under CRE. It scales.

Days 22 through 24 in this series go deep on CRE specifically. The foundation you have now is exactly what makes that section make sense.

The one-sentence version to carry forward

Every Chainlink product is independent nodes observing something, OCR reaching consensus off-chain, one signed report verified on-chain. The observation changes. The consensus protocol version changes. The on-chain consumer changes. The skeleton never does.

If you're studying for a technical interview, building an integration, or doing an audit review, start every Chainlink-related question with that skeleton. The answer to almost every "how does X work?" question in Chainlink is "the same three steps, with X as the observation."

---

I'm a smart contract security researcher writing through Chainlink's full architecture for 28 days. Follow along at ramprasadgoud.dev or on X @0xramprasad.