DEV Community: Ramprasad Edigi

Chainlink Runtime Environment (CRE)

Ramprasad Edigi — Tue, 04 Aug 2026 13:32:58 +0000

Read this first if your upkeep stopped executing

Chainlink Automation v1.x sunset on June 30, 2026. Chainlink Automation v2.1 sunset on July 31, 2026, four days ago.If you had a production upkeep running on Automation and haven't migrated yet, it has already stopped being performed. The Chainlink Automation App will show a "deprecated" notice for any upkeep on a registry earlier than v2.1, and as of the v2.1 sunset date, that now includes v2.1 itself.

The replacement is the Chainlink Runtime Environment (CRE), and Chainlink Labs built a specific migration path, called the Automation Migration template, precisely so this transition doesn't require rewriting your existing contracts from scratch. This article is the fastest path from "my upkeep stopped running" to "I have a working CRE workflow," using the official bridge pattern.

This is day 22 of the 28-day Chainlink architecture series, but today isn't theory. It's a checklist, and if you're reading this because something in production broke, start executing it now.

What actually changes, in plain terms

In Automation, you registered an upkeep with two functions: checkUpkeep(), simulated off-chain by the Automation network, and performUpkeep(), executed on-chain when checkUpkeep() returned true.

In CRE, the equivalent unit is a workflow: a TypeScript or Go project compiled to WebAssembly and registered with the network. Workflows are started by triggers (a cron schedule, an HTTP request, or an on-chain log event), run your logic off-chain with no gas constraints during the check phase, and write results on-chain through a signed report delivered via the CRE KeystoneForwarder to any contract implementing IReceiver.

CRE is a strict superset of Automation. Everything Automation does, CRE does, and several patterns that used to require multiple separate upkeeps now collapse into a single workflow.

Here's the direct terminology mapping so you're not translating concepts on the fly:

Chainlink Automation	Chainlink CRE
Upkeep registration	CRE workflow deployment
Upkeep contract	Existing target contract + an `IReceiver` bridge
`checkUpkeep()` function	Workflow logic inside the handler
`performUpkeep(bytes performData)`	`onReport(metadata, report)` on an `IReceiver`, then a bridge call to your target contract
Time-based Upkeep	Built-in Cron trigger
Log Trigger Upkeep	EVM Log trigger
Custom Logic Upkeep	Cron trigger + `evmClient.callContract()` in the handler
Automation Forwarder	CRE `KeystoneForwarder` + your receiver authorization

The fastest path: the Bridge pattern

Here's the part that matters most if you're migrating today under time pressure. You do not need to reimplement checkUpkeep, checkLog, or performUpkeep inside your existing contract. The official Automation Migration template uses a Bridge pattern: you deploy a generic AutomationReceiver.sol contract that receives CRE reports and forwards approved calls to your existing Automation contract, unchanged.

The only thing you may need to touch in your existing contract is a permission check. If your contract currently checks msg.sender against an Automation Forwarder allowlist, or has role-based permissions gating who can call performUpkeep, you need to authorize the new AutomationReceiver address or adjust that permission boundary. Otherwise, your business logic stays exactly as it is.

Migration steps, in order

Step 1: Scaffold the migration project

cre init --template=automation-migration-go --project-name my-automation-migration --workflow-name my-workflow

This pulls the official template directly, available in both Go and TypeScript. Use whichever matches your team's existing stack.

Step 2: Deploy the Bridge contract

Deploy AutomationReceiver.sol from the template to your target chain, passing your chain's CRE KeystoneForwarder address to the constructor. The forwarder address is chain-specific. Check the Forwarder Directory in the CRE docs for the correct address before deploying; passing the wrong forwarder address means your receiver will never accept valid reports.

Step 3: Configure your workflow

Update my-workflow/config.test.json with your previously deployed AutomationReceiver address, your target contract address, the migration type (CRON, CUSTOM, or LOG depending on which upkeep type you're migrating), and the schedule or log filters that match your original upkeep configuration.

Step 4: Authorize the call

This is the step people miss and then wonder why their workflow fails silently. Before your workflow can actually call your target contract through the receiver, you need to run a setCallAllowed() transaction:

Function: setCallAllowed(address,bytes4,bool)
target: <your existing Automation upkeep contract address>
selector: <the 4-byte function selector for the function being called>
allowed: true

Compute the function selector with the cast CLI tool:

cast sig 'performUpkeep(bytes)'
# Output: 0x4585e33b

If you're calling a custom function instead of performUpkeep, compute the selector for that function specifically. This step is what tells the AutomationReceiver it's allowed to forward calls to your specific target and function. Skip it, and every execution reverts with CallNotAllowed.

Step 5 (production, don't skip this): set workflow identity checks

The generic receiver, as configured after step 4, will forward calls from any workflow that references your target contract and approved selector. For a migration test, that's fine. For production, it's a real security gap: anyone who deploys a CRE workflow calling your AutomationReceiver with the right target and selector could trigger your contract's function.

Lock this down with the identity setters:

setExpectedAuthor(address _author)
setExpectedWorkflowId(string _workflowId)
setExpectedWorkflowName(string _workflowName)

Set at least one of these before you consider the migration production-ready. A generic receiver accepting arbitrary (target, data) calls from any workflow is convenient for testing and a genuine vulnerability if left open in production.

Step 6: Simulate before deploying

cre workflow simulate my-workflow --target=test-settings

For log-trigger migrations specifically, provide a transaction hash containing the actual event so the simulator doesn't sit waiting for a live event to fire:

cre workflow simulate my-workflow \
  --target=test-settings \
  --non-interactive \
  --trigger-index=0 \
  --evm-tx-hash=0x... \
  --evm-event-index=0

Step 7: Deploy to production

cre workflow deploy my-workflow --target=production-settings

If your workflow fails with CallNotAllowed

This is the most common failure during migration. Four things to check in order:

Function selector mismatch.The selector configured in setCallAllowed() must exactly match the function your workflow is actually calling. Recompute it with cast sig and compare byte for byte.
Permission not actually set. Confirm setCallAllowed() was called with allowed: true for the specific target and selector pair you're using. A transaction that reverted or was sent with the wrong parameters leaves the permission unset.
Workflow identity mismatch. If you configured setExpectedAuthor, setExpectedWorkflowId, or setExpectedWorkflowName in Step 5, verify the workflow you're deploying actually matches those values. A typo here silently blocks every execution.
Wrong forwarder address. Verify the KeystoneForwarder address passed to your AutomationReceiver constructor matches the correct address for your specific chain. This is set once at deployment and can't be changed after, so if it's wrong, you need to redeploy the receiver.

What this means beyond the migration deadline

The Bridge pattern is a migration convenience, not the end state. Once your upkeep is running on CRE, the actual value of the platform is that a workflow isn't limited to one trigger and one on-chain call the way an upkeep was. A single CRE workflow can combine multiple triggers, multiple off-chain HTTP calls, reads and writes across multiple chains, and conditional logic that would have required several separate upkeeps under the old model.

That's a conversation for a future article once you're back up and running. Right now, if your upkeep stopped executing, the priority is getting through the seven steps above to restore service.

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.

CCIP End-to-End: Tracing One Cross-Chain Message From the First Function Call to the Final Receipt

Ramprasad Edigi — Mon, 03 Aug 2026 13:24:47 +0000

Why this article exists

Days 12 through 20 of this series covered CCIP in pieces: the onchain components, the offchain Role DON and OCR plugins, the token transfer mechanisms, the CCT standard, and rate limiting with institutional deployments. Each article explained one layer. None of them traced a single message all the way through from start to finish.

This is the article that does that.

One concrete example: a sender on Ethereum wants to send 1,000 USDC and a message payload to a receiver contract on Arbitrum. We'll trace every step from the sender calling Router.ccipSend() to the receiver's ccipReceive() being called on Arbitrum. Every contract that touches the message is named. Every event emitted is named. Every offchain component is identified at the moment it acts.

This is day 21 of the 28-day Chainlink architecture series. If you've read days 12 through 20, you already know each component. Today you see how they fit together.

The setup

Source chain: Ethereum mainnet
Destination chain: Arbitrum One
Payload: 1,000 USDC + arbitrary bytes message data
Sender: a smart contract that has already computed the message and approved USDC spending
Receiver: a contract on Arbitrum that implements ccipReceive()

Before the sender calls ccipSend(), one prerequisite: the fee. The sender calls Router.getFee(destinationChainSelector, message). Internally, the Router delegates this to the OnRamp, which calls the FeeQuoter. The FeeQuoter prices the fee based on destination gas limit, message size, token count, current gas prices on the destination chain, and the current LINK/ETH exchange rate. It returns a fee in the sender's chosen fee token (either LINK or ETH). The sender must have approved the Router to spend this fee amount before calling ccipSend().

Phase 1: Source chain — from sender to CCIPMessageSent

Step 1: Sender calls Router.ccipSend(destinationChainSelector, message)

The Router is the only stable address in the system. It's the single immutable user-facing entry point on Ethereum. The Router:

Looks up the correct OnRamp for the Ethereum → Arbitrum lane
Calls isCursed() on the RMNRemote contract. If Ethereum or Arbitrum is currently cursed, this reverts immediately before anything else happens
Validates that the destination chain selector exists in its routing table
Collects the fee from the sender

Step 2: Router forwards to OnRamp

The Router passes the message to the OnRamp for the Ethereum → Arbitrum lane. The OnRamp:

Validates message parameters: token count (max 10), gas limit, data payload length
Calls isCursed() on RMNRemote again (separate check at the OnRamp level)
Checks the sender allowlist if one is configured for this lane
Calls the FeeQuoter to finalize the fee calculation
For the 1,000 USDC: looks up the USDC Token Pool address from the Token Admin Registry and calls TokenPool.lockOrBurn(). Since USDC on Ethereum uses Lock-and-Mint for the Arbitrum lane, the USDC is locked in the Token Pool vault. The Token Pool checks the outbound rate limit bucket before allowing the lock.
Assigns a sequence number to this message (the last used sequence number incremented by 1)
Generates a unique messageId (a bytes32 hash of the message content and metadata)

Step 3: OnRamp emits CCIPMessageSent

The OnRamp emits CCIPMessageSent containing:

messageId: the unique identifier for this specific message
sequenceNumber: this message's position in the lane's ordered sequence
sourceChainSelector: Ethereum
destChainSelector: Arbitrum
sender: the address that called ccipSend()
receiver: the Arbitrum contract address
The full encoded message (data + token amounts + gas limit)

This event is now permanently on-chain on Ethereum. The transaction is complete from the sender's perspective. The sender's USDC is locked. The fee is paid. The message is recorded. The sender cannot cancel or modify what happens next.

Phase 2: Offchain — Commit DON builds and submits the Merkle root

Step 4: Commit OCR plugin detects the event

The Role DON's nodes running the Commit OCR plugin are continuously monitoring Ethereum's OnRamp for CCIPMessageSent events. Each node independently observes the event and records:

The message's sequence number
The full message contents (to compute the Merkle tree)

The Commit plugin uses OCR3's three-round structure:

Round 1 — Observation: Each node calls LatestMsgSeqNum() on the source OnRamp and GetExpectedNextSequenceNumber() on the destination OffRamp to determine the range of new messages to include in the next commit report. Our message's sequence number falls in this range.

Round 2 — Merkle construction: The merkleroot.Processor reads the full message data for all messages in the batch (our message may be batched with other messages on the same lane). It computes a Merkle tree over the batch and produces a Merkle root. Because this is an EVM-to-EVM lane that requires RMN signatures (the blessed chain configuration), the rmn.Controller requests RMN blessing signatures from the Risk Management Network nodes for this Merkle root. The RMN nodes independently verify the Merkle root matches the source chain events, then sign.

Round 3 — OCR consensus and transmission: The Commit DON reaches OCR3 consensus on the Commit Report, which contains:

The Merkle root of the batch of messages
The sequence number range covered
RMN blessing signatures (where required)
Price updates for fee tokens (LINK/ETH/USDC price data for the destination FeeQuoter)

One node, selected by the randomized OCR3 transmission schedule, submits this Commit Report to the destination chain.

How long does this take? The Commit DON waits for the configured number of source-chain block confirmations before committing. For Ethereum mainnet as the source chain, this is typically 64 block confirmations, roughly 13 minutes, to protect against chain reorganizations. The message has been on Ethereum for those 13 minutes before the Commit DON acts.

Phase 3: Destination chain — Commit Report accepted

Step 5: OffRamp processes the Commit Report

On Arbitrum, the OffRamp receives the Commit Report from the Commit DON transmitter. The OffRamp:

Validates the quorum of OCR signatures on the report (this is the on-chain trust verification: the OffRamp doesn't trust whoever submitted the transaction, it trusts that enough independent signers agreed on this exact payload)
Calls isCursed() on Arbitrum's RMNRemote contract
Stores the Merkle root in contract storage, keyed by the source chain selector and sequence number range
Processes any price updates included in the report (updates the FeeQuoter on Arbitrum with current token prices)

Step 6: OffRamp emits CommitReportAccepted

This event confirms that a valid commit has been accepted. At this point, the message's existence on Ethereum has been attested to by a quorum of the Role DON and recorded on Arbitrum. The tokens are still locked on Ethereum. The receiver hasn't been called yet.

Phase 4: Offchain — Execute DON prepares execution

Step 7: Execute OCR plugin detects CommitReportAccepted

The Role DON's nodes running the Execute OCR plugin monitor the Arbitrum OffRamp for CommitReportAccepted events. When they detect our commit report, they identify pending messages in that commit:

Round 1: execute.Plugin calls CommitReportsGTETimestamp() on the OffRamp to find unexecuted commit reports.

Round 2: The Execute DON reads the full message data from the source Ethereum OnRamp via MsgsBetweenSeqNums(), independently verifying the message contents. It computes a Merkle proof for our specific message against the committed Merkle root. It verifies this proof matches. It checks that our message hasn't already been executed (preventing double execution). It calculates whether the gas limit we specified is sufficient for execution.

Round 3: The Execute DON reaches OCR3 consensus on an Execute Report containing the message and its Merkle proof, then one node transmits it to the Arbitrum OffRamp.

Note: the Execute OCR plugin runs without signature verification (unlike the Commit plugin). The security comes from the Merkle proof verification on-chain, not from OCR signature verification at the execution stage.

Phase 5: Destination chain — execution

Step 8: OffRamp executes the message

The Arbitrum OffRamp receives the Execute Report. It:

Validates the Merkle proof for our specific message against the stored Merkle root. If the proof doesn't match, execution reverts
Calls isCursed() on Arbitrum's RMNRemote
Checks that this exact message ID hasn't been executed before (replay protection)

For the 1,000 USDC:

Looks up the USDC Token Pool address on Arbitrum from the Token Admin Registry
Calls TokenPool.releaseOrMint() on the Arbitrum USDC pool
The Token Pool checks the inbound rate limit bucket before allowing the mint
Since this is Lock-and-Mint for this lane: the Arbitrum USDC pool mints 1,000 USDC to the receiver address

For the arbitrary message data:

The OffRamp calls the Router to deliver the CCIP message to the receiver
The Router calls receiver.ccipReceive(message) with the full Client.Any2EVMMessage struct containing the message ID, source chain, sender address, data payload, and token amounts

Step 9: OffRamp emits ExecutionStateChanged

The final event. Status is either Success or Failure.

Success: ccipReceive() executed without reverting, 1,000 USDC arrived, message data was delivered
Failure: ccipReceive() reverted (insufficient gas limit, logic error in receiver, receiver not implementing the interface correctly)

If Failure: the message is not lost. The permissionLessExecutionThresholdSeconds is a configured waiting period after which anyone can re-execute the failed message without DON involvement. Manual execution provides the Merkle proof directly to the OffRamp's manuallyExecute() function with a higher gas limit.

The complete timeline

Step	Chain	What happens	Time from Step 1
1-3	Ethereum	Sender calls ccipSend, OnRamp locks USDC, CCIPMessageSent emitted	~30 seconds (1-2 blocks)
4	Offchain	Commit DON waits for 64 block confirmations	~13 minutes
5	Offchain	Commit DON builds Merkle root, reaches OCR consensus	~1-2 minutes
6	Arbitrum	OffRamp records Commit Report, CommitReportAccepted emitted	~30 seconds
7	Offchain	Execute DON reads message, computes proof, reaches consensus	~1-2 minutes
8-9	Arbitrum	OffRamp executes, USDC minted, ccipReceive called, ExecutionStateChanged emitted	~30 seconds
Total		~17-20 minutes for Ethereum → Arbitrum

This timeline is dominated by the 64-block finality requirement on Ethereum. L2-to-L2 messages (Arbitrum to Base, for example) are significantly faster because L2 finality is measured in seconds rather than minutes.

What to trace when something goes wrong

If you're debugging a CCIP message that didn't arrive, the trace gives you the exact places to check in order:

Did CCIPMessageSent emit on the source chain? If not, the transaction reverted before the OnRamp. Check the sender's fee approval and token allowance.
Did CommitReportAccepted emit on the destination chain? If not, the Commit DON hasn't processed the message yet. Check the source chain block confirmations — it may still be within the finality window.
Did ExecutionStateChanged emit? If not, the Execute DON hasn't transmitted yet. Check the time elapsed since commit — if it has been more than a few minutes, check whether permissionLessExecutionThresholdSeconds has passed and consider manual execution.
Did ExecutionStateChanged emit with Failure? Check the receiver contract's ccipReceive implementation and verify the gas limit set at send time is sufficient.

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.

CCIP Quarterly Volume Hit $4.9B, Up 353% Year-Over-Year. Here's the Rate Limiting Architecture That Makes That Scale Safe.

Ramprasad Edigi — Tue, 28 Jul 2026 13:26:33 +0000

The number that reframes everything

CCIP processed $4.9 billion in quarterly volume in Q1 2026, a 353% increase year-over-year. That number matters not just as a growth stat but as a stress test: when billions move through a cross-chain protocol every quarter, the safety mechanisms underneath it aren't theoretical. They're being tested continuously by real institutional capital.

In July 2026, DTCC ran its first production trades of tokenized assets on its Tokenization Service, with over 30 participating firms including BlackRock, Vanguard, Goldman Sachs, JPMorgan, and Microsoft. CCIP was the cross-chain layer. The full DTCC Tokenization Service is scheduled for general launch in October 2026. That's not a pilot. That's production infrastructure for the firms that collectively manage tens of trillions in assets.

The question worth asking is not "why is institutional adoption accelerating?" The question is: what specifically is the architecture that makes moving this kind of value across chains safe enough for institutions to approve?

This is day 18 of the 28-day Chainlink architecture series. Today covers the rate limiting model that contains risk on individual lanes, the lane configuration choices that let institutional deployments tune safety parameters independently, and the real institutional use cases worth understanding in detail.

What rate limits are actually doing

Rate limits in CCIP are defensive mechanisms, not throughput controls. The distinction matters.

A throughput control would limit transfers to protect network performance. A defensive mechanism limits transfers to contain the blast radius of an unexpected event. Those are the same technical implementation but completely different design philosophies, and CCIP's rate limits are explicitly the second one.

The official documentation states this plainly: rate limits are designed to limit the volume of tokens that can move across a specific CCIP lane over time, reducing the blast radius of unexpected behavior and helping manage operational risk.

If something goes wrong on a lane, whether a compromised token pool, an exploit in a receiver contract, or an anomaly the Risk Management Network flags before the curse mechanism fires, the rate limit bounds how much value can exit before the problem is contained. A protocol with a $10M rate limit per hour can lose at most $10M in that window from this attack surface. A protocol without rate limits has no such bound.

The capacity bucket model, explained precisely

Rate limits in CCIP use a token bucket model. Every token pool maintains two independent buckets per connected chain:

Outbound rate limit: how much of this token can be sent from this chain to the remote chain.

Inbound rate limit: how much of this token can be received from the remote chain into this chain.

Each bucket has two parameters: a capacity (the maximum amount the bucket can hold) and a refill rate (how quickly capacity replenishes after it's been drawn down).

Here's how a transfer interacts with the bucket:

Capacity refills continuously at the configured rate. A bucket with $1M capacity and a $100K/hour refill rate that gets fully depleted will be back to $500K in five hours and $1M in ten. Transfers that would deplete remaining capacity before refill are rejected until sufficient capacity exists.

The outbound and inbound limits are configured independently and can differ. In practice, outbound limits are often set slightly lower than inbound to provide an additional buffer for source-chain risk. This asymmetric configuration is a deliberate choice that lets operators tune risk differently depending on which direction a given token flow is more sensitive.

Why each lane is configured independently

A lane in CCIP is a unidirectional path between two specific chains. Ethereum to Arbitrum is one lane. Arbitrum to Ethereum is a different lane. Both have their own rate limits, configured separately.

This independence is the key architectural property that makes CCIP viable for institutional deployments at different risk levels simultaneously.

Consider what a bank needs for tokenized bond settlement versus what a DeFi protocol needs for a liquidity bridge between L2s. The bank wants conservative limits, deep finality requirements (64 block confirmations on Ethereum mainnet, around 13 minutes), and potentially a sender allowlist that restricts which addresses can use the lane at all. The DeFi protocol wants higher throughput, faster finality on L2s, and no sender restrictions.

If all lanes shared a single global configuration, neither use case could be optimized for its actual risk profile. With per-lane configuration, a bank operating a private CCIP lane for cross-border bond settlement can specify:

Custom rate limits sized to expected settlement volumes, not to DeFi liquidity flows
Deep finality requirements suited to regulatory standards
A sender allowlist ensuring only pre-approved counterparties can initiate transfers
Specific token pools with only the assets relevant to their use case

None of those configurations affect any other lane. A conservative institutional lane and a high-throughput DeFi lane can coexist in the same CCIP network, each optimized for its own risk profile, without either constraining the other.

The real institutional deployments, each precisely

DTCC Smart NAV and the July 2026 production trades

DTCC, which clears over $2 quadrillion in US securities annually, integrated CCIP into its Smart NAV pilot to distribute net asset value data from fund administrators across multiple chains simultaneously. Instead of each chain requiring a separate integration with a fund's NAV data, DTCC publishes once and every CCIP-connected chain receives it.

In July 2026, DTCC ran its first production tokenized asset trades using this infrastructure, with 30+ institutional participants. The full Tokenization Service is scheduled for October 2026. This is the system that settles US securities moving into tokenized form on-chain, and CCIP is the cross-chain layer it chose.

SWIFT and 12 banks: the settlement messaging pilot

SWIFT, the messaging network connecting over 11,000 financial institutions globally, completed pilots with 12 banks demonstrating tokenized asset settlement messages routed through SWIFT's existing infrastructure and executed on-chain via CCIP. Follow-on pilots in 2024 expanded participation. The technical design lets banks initiate blockchain settlement without replacing existing SWIFT messaging infrastructure. Their current workflow triggers CCIP execution downstream.

ANZ Bank: the first regulated bank settlement on a public protocol

ANZ Bank, one of Australia's four major banks with over $1 trillion in assets under management, used CCIP to settle a tokenized treasury bill purchase between Ethereum and Avalanche in November 2023. This was the first regulated bank settlement on a public blockchain messaging protocol, a specific category that mattered for regulatory precedent. ANZ subsequently used CCIP in Australia's Project Acacia regulatory pilots and Phase 2 of Hong Kong's e-HKD program for cross-jurisdictional e-HKD transfers.

BlackRock BUIDL: cross-chain fund accounting

BlackRock's BUIDL tokenized money market fund crossed $2 billion in AUM in 2024. CCIP coordinates fund accounting and yield distribution across Ethereum and other supported networks. For a fund of this size, the cross-chain accounting problem is real: shares might be issued on one chain but yield needs to be distributed to holders on multiple chains. CCIP handles the cross-chain coordination while BlackRock retains control of the fund mechanics.

DvP settlement between the Central Bank of Brazil and HKMA

Chainlink powered delivery-versus-payment settlement between the Central Bank of Brazil and the Hong Kong Monetary Authority, a use case that represents cross-jurisdiction central bank digital currency interoperability. ANZ, China AMC, and Fidelity International were among the participants. The Chainlink Automated Compliance Engine (ACE) provided jurisdiction-specific compliance enforcement alongside CCIP's messaging layer.

Aave's infrastructure migration

In 2026, Aave made CCIP the default cross-chain infrastructure across its deployments, replacing older bridge integrations. Aave is one of the largest DeFi protocols by total value locked, and its infrastructure choice represents exactly the kind of institutional-grade adoption the rate limiting model was designed to enable: high-volume, high-value flows where the blast-radius containment of per-lane rate limits is a genuine security requirement rather than a performance consideration.

What to verify before relying on a CCIP lane's rate limits

Five checks that matter in practice:

1. Are rate limits enabled and explicitly configured?
Rate limits can be disabled. A lane with disabled rate limits has no blast-radius containment. For any integration where the value at risk exceeds what you'd be comfortable losing in a one-hour window, confirm that rate limits are active and that the capacity and refill rate match the actual risk exposure.

2. Are the capacity values appropriate for both normal volume and attack scenarios?
Rate limits sized only for normal transfer volume can be inadequate under attack. If the capacity is $10M and normal daily volume is $1M, a malicious actor who drains the bucket in one hour has extracted ten times normal daily volume before the limit bites. Size limits relative to acceptable loss, not just expected volume.

3. Are outbound and inbound limits both configured?
Token pools maintain two independent limits. An integration that configures outbound limits but leaves inbound limits at default or disabled has only half the protection.

4. Is there a sender allowlist for high-value institutional lanes?
For lanes handling regulated asset flows, a sender allowlist restricts which addresses can initiate transfers. Without one, any address can send to the lane up to the rate limit capacity. For a bank lane handling tokenized bond settlement, that's unacceptable. For a DeFi liquidity lane, it may be intentional. Know which applies to the lane you're integrating.

5. Do rate limit changes take effect immediately?
Yes, per the official documentation: rate limit changes are applied on-chain and take effect immediately. This is important for incident response: if a lane is experiencing anomalous behavior, rate limits can be tightened immediately without a timelock delay. The flipside is that a misconfigured rate limit change also takes effect immediately, so configuration changes should be tested on testnet first.

The architecture picture this completes

At this point in the series, the full CCIP onchain and offchain architecture is covered:

Day 12: Router, OnRamp, OffRamp, Token Pools, RMN Contract (the onchain components)
Day 15: Role DON, Commit OCR plugin, Execute OCR plugin, the v1.6 correction (the offchain components)
Day 16: Burn-and-Mint, Lock-and-Mint, Lock-and-Unlock, CCT standard (the token transfer mechanisms)
Today: Per-lane rate limits, per-token bucket model, institutional deployment patterns

Together these form the complete picture of how a message goes from a sender on one chain to a receiver on another, why it can be trusted, and what contains the damage if something goes wrong.

Tomorrow's topic: CCIP's place in the broader Chainlink ecosystem and how it connects to CRE, ACE, and the institutional tokenization stack.

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.

CCIP Has Three Ways to Move Tokens Cross-Chain. Choosing the Wrong One Is an Audit Finding.

Ramprasad Edigi — Wed, 22 Jul 2026 13:59:21 +0000

Every CCIP token transfer uses one of three mechanisms. Most content about CCIP treats this as a dropdown choice with no meaningful consequence. Pick whichever. They're all equally secure.

They aren't.

Each mechanism has a distinct trust model, a distinct set of risks, and a distinct failure mode that becomes an audit finding if the wrong one is deployed for the wrong token. The difference between them isn't implementation detail. It's a fundamental choice about where custody lives and who bears the risk if something goes wrong on the source chain.

This is day 17 of the 28-day Chainlink architecture series. Today covers all three transfer mechanisms, when each is the right choice, the Cross-Chain Token standard that lets anyone deploy permissionlessly, and the five audit checks every CCIP token integration needs.

Mechanism 1: Burn-and-Mint

The cleanest mechanism. Tokens are burned on the source chain and minted on the destination chain. Total supply across all chains remains constant at all times. There are no wrapped versions, no synthetic representations, no liquidity pool requirements. The same canonical token exists natively on every chain it's deployed to.

When it's the right choice: any token where the issuer controls the token contract and can grant minting rights to the CCIP Token Pool on each destination chain. Native stablecoins, protocol tokens, and tokenized assets where the issuer manages deployment across chains. Tether moved USDt to the CCT standard using this mechanism. When an institution like Tether controls token issuance on every chain, Burn-and-Mint is straightforward: destroy tokens on chain A, create them on chain B, supply never fluctuates.

The security trade-off: the Token Pool on the destination chain must have minting authority over the token. If the Token Pool contract is compromised, an attacker can mint tokens without a corresponding burn on the source chain, inflating supply. This is the same risk as any contract with unlimited mint authority: the security of the token is now partially contingent on the security of the Token Pool.

The trust model: you're trusting that the CCIP Token Pool contract on the destination chain will never mint tokens without a valid, verified burn event on the source chain. The DON's OCR verification of the Merkle root is what enforces this. Rate limits on the Token Pool are the safety valve if that enforcement fails.

Mechanism 2: Lock-and-Mint

Tokens are locked in a Token Pool vault on the source chain. A wrapped, synthetic representation is minted on the destination chain. The original tokens never leave the source chain's Token Pool. The wrapped versions exist only on destination chains.

When it's the right choice: any token where the issuer doesn't control the contract and can't grant minting rights to foreign chain pools. Bitcoin on Ethereum is the canonical example: you can't modify Bitcoin's contract to let an Ethereum Token Pool mint BTC. You lock BTC in a vault on the Bitcoin chain (or a bridge layer), mint WBTC on Ethereum. Backward-compatible with literally any token because no changes to the original contract are required.

The security trade-off: the source chain vault is a honeypot. All locked tokens live in one contract. If that contract is exploited, all the wrapped versions on all destination chains are instantly worthless because the backing is gone. This is the failure mode behind every major bridge hack in history. Ronin Bridge, Wormhole, Nomad, all had variations of this problem: the vault on one end was exploitable, and the minted representations on the other end became unbacked.

Lock-and-Mint also introduces wrapped token risk for any protocol that accepts the wrapped version as collateral. If a DeFi protocol on Ethereum accepts WBTC and the BTC vault gets drained, the protocol's collateral is now worthless even though the token hasn't been "hacked" from the Ethereum smart contract perspective.

The trust model: you're trusting the source chain vault's security. The larger and older that vault, the more attractive it becomes as an attack target.

Mechanism 3: Lock-and-Unlock

Tokens are locked on the source chain and pre-existing tokens are released from a liquidity pool on the destination chain. No minting, no wrapping. Destination chain receivers get the same token that already existed there.

When it's the right choice: two-way flows between chains that both have genuine liquidity in the token. A stablecoin like USDC that already has deep liquidity on both Ethereum and Arbitrum can use Lock-and-Unlock: lock USDC on Ethereum, release USDC from Arbitrum's pool. No synthetic versions involved, native USDC on both ends.

The security trade-off: the destination chain pool must have sufficient liquidity to fulfill transfers. If the destination pool runs low, transfers queue or fail until liquidity is replenished. This creates a liquidity management burden that doesn't exist with Burn-and-Mint. It also means large transfers can deplete destination liquidity in one shot, making the system temporarily unavailable for others until it rebalances.

The trust model: you're trusting that both chains have sufficient pre-existing liquidity. The security of the transferred token on the destination chain is the same as native token security: there are no wrapped versions to de-peg.

The CCT Standard: permissionless cross-chain deployment

Before the Cross-Chain Token standard, deploying a token across CCIP required going through a manual process with Chainlink Labs as a gatekeeper. You had to apply, wait, and rely on a third party to enable your token. That model doesn't scale to thousands of tokens across dozens of chains.

The CCT standard changed this entirely. It is an open, permissionless framework that lets any token issuer deploy a single token across multiple chains with native cross-chain transfers built in, no central bridge operator required. Any developer can now go from zero to cross-chain compatible in minutes, autonomously, without involving Chainlink Labs.

Three things the CCT standard provides that the old approach didn't:

Self-service deployment. Token developers deploy their own Token Pool contracts, register them in the Token Admin Registry, and configure rate limits themselves. No waiting for approval. No dependency on a third party to update a whitelist.

Full developer ownership. Token developers retain control of their token contracts and pool contracts. They set rate limits. They choose the transfer mechanism. They can add or remove chain support. The token issuer remains the authority, not a bridge operator.

Token Developer Attestation. Token developers have the option of adding additional external verifiers to their CCTs, enabling token developers to participate in the verification process for transferring CCTs cross-chain by attesting to token burn or lock events on source chains before CCIP can mint or release tokens on destination chains. This was specifically requested by stablecoin issuers, RWA developers, and wrapped asset protocols that need more granular control over cross-chain transfer authorization for compliance purposes.

The real-world adoption tells the story clearly. Tether deployed USDt on the CCT standard. BlackRock's BUIDL fund uses CCIP for cross-chain accounting. These aren't small experiments. They're production deployments by institutions that did extensive due diligence on the trust model before committing.

Programmable Token Transfers: tokens and data in one transaction

One capability the CCT standard unlocks that isn't possible with traditional bridges: Programmable Token Transfers (PTT). CCIP supports sending tokens and arbitrary message data in a single atomic cross-chain transaction. The data arrives with the tokens and is executed on the destination chain in the same transaction that releases or mints.

In practice, this means a cross-chain DeFi operation like "send 1,000 USDC to Arbitrum and deposit it into Aave on arrival" can be a single user action rather than two separate transactions the user has to monitor and execute independently. The deposit instruction travels with the tokens and executes automatically upon arrival.

For institutional use cases like BlackRock's BUIDL fund, this is what makes CCIP genuinely different from a simple token bridge: accounting instructions, settlement parameters, and compliance data can travel with the assets themselves, not in a separate coordinated workflow that requires human orchestration.

5 audit checks for any CCIP token integration

1. Is the transfer mechanism appropriate for this token's ownership model?
Burn-and-Mint requires minting rights on destination chains. If the token developer doesn't control the destination chain contract, they can't grant those rights, and Burn-and-Mint isn't viable regardless of how desirable it is. Audit question: does the token pool contract on the destination chain actually have minting rights? Is that right revocable by the token issuer if the pool is compromised?

2. For Lock-and-Mint: what is the TVL in the source chain vault, and what protects it?
Every Lock-and-Mint deployment creates a high-value vault. Audit question: what are the access controls on the Token Pool vault contract? Who can pause it? Who can upgrade it? Is there a timelock on upgrades? A vault holding hundreds of millions in locked tokens with a one-step upgrade path controlled by a single key is a critical finding.

3. Are rate limits set appropriately for the mechanism and value at risk?
Rate limits are the safety valve when something goes wrong. They bound how much damage can be done in a given time window. Audit question: are rate limits enabled and set relative to the expected transfer volume and the value at risk in the vault? A rate limit of $100M/day on a vault holding $50M is effectively no rate limit.

4. For CCT deployments: is Token Developer Attestation implemented where compliance requires it?
Stablecoins, RWAs, and regulated assets often need the issuer to have a veto on cross-chain transfers. Audit question: if this token is a regulated asset, has the developer implemented Token Developer Attestation? If not, cross-chain transfers can proceed without the issuer's explicit approval, which may create compliance exposure.

5. Does the receiver contract handle both token delivery and message data correctly?
For Programmable Token Transfers, the receiver contract gets both tokens and a data payload. Audit question: does ccipReceive handle both correctly? Does it check that the token amount matches what the message expects? A contract that ignores the data payload and just credits the tokens silently drops the instruction, which may leave the cross-chain operation in a partial state.

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.

[Boost]

Ramprasad Edigi — Tue, 21 Jul 2026 10:13:22 +0000

Ramprasad Edigi

Jul 21

CCIP Doesn't Run Two DONs Anymore. Here's What v1.6 Actually Changed.

6 min read

CCIP Doesn't Run Two DONs Anymore. Here's What v1.6 Actually Changed.

Ramprasad Edigi — Tue, 21 Jul 2026 10:12:29 +0000

The thing most content gets wrong about CCIP

Search for "CCIP architecture" today and most of what you find still describes two separate oracle networks: a Committing DON and an Executing DON, two distinct networks with different node sets, each responsible for a different phase of cross-chain message delivery.

That description was accurate before v1.6. It isn't anymore.

As of CCIP v1.6, the architecture changed to a single DON called the Role DON that includes all participating nodes. Two OCR plugins run on these nodes: one for committing and one for executing. They are not separate networks. They are subsets of the same node set, distinguished solely by their assigned roles.

This distinction matters more than it sounds. The security model, the trust assumptions, and the way you should think about CCIP's decentralization are all different depending on which version of this architecture you're working from. If you're writing about CCIP, auditing a CCIP integration, or preparing for a technical interview at Chainlink, saying "two separate DONs" in 2025 or 2026 signals that your knowledge predates v1.6.

This is day 15 of the 28-day Chainlink architecture series. Today covers everything off-chain in CCIP: the Role DON, the Commit OCR plugin, the Executing OCR plugin, and a critical update about the Risk Management Network that most content has not caught up to.

Why the single Role DON model is the right design

The old two-DON model had a coherent rationale: separate the concerns, give each phase its own dedicated node set, make it easier to reason about what each group of nodes is responsible for. The problem is that two separate networks means two separate trust assumptions, two separate quorum requirements, and two separate potential failure points. Compromising either one independently breaks the whole system.

The Role DON collapses this into one. All nodes participate in the same DON. The OCR protocol assigns roles: some nodes run the Commit plugin for a given source chain, some run the Execute plugin for a given destination chain, but they're all members of the same network. A quorum of the full Role DON must agree on the state of the system, not two smaller, independent quorums of two different networks.

From a trust-minimization standpoint, this is strictly better. An attacker targeting the commit process now has to compromise nodes from the same set they'd need to compromise to attack the execution process. There's no weaker link between the two phases.

The Commit OCR Plugin: three phases

The Commit plugin handles the first half of message delivery. Here's how it works across three distinct phases.

Observation phase. The Role DON contains subcommittees, groups of nodes assigned to read from specific source chains. Each subcommittee independently reads the source chain's OnRamp for new messages, identifies the range of sequence numbers to include in the next batch, and computes a Merkle root over those messages. A minimum threshold of valid observations is required to proceed. No single node controls what gets included.

Query phase. The designated leader for the current OCR round assembles a proposed Commit Report from the observations and shares it with all other nodes in the Role DON for validation. Nodes that submitted invalid observations get their contributions dropped. The remaining valid observations must meet the threshold to achieve consensus. This is the off-chain Byzantine fault-tolerance step: nodes can verify each other's work before anything goes on-chain.

Reporting phase. A subcommittee of nodes assigned to write to the destination chain submits the final Commit Report on-chain to the OffRamp contract. The report can include Merkle roots from multiple source chains in a single submission. It can also include price reports for fee tokens. The FeeQuoter needs up-to-date token prices to calculate costs, and the Commit plugin handles delivering those updates to avoid requiring a separate price oracle call per message.

The OffRamp contract stores the committed Merkle root. Nothing gets executed at this stage. Committing is only an attestation that a set of messages exists on the source chain and has been verified by a quorum of the Role DON.

The Executing OCR Plugin: three phases

The Executing plugin takes over after a Merkle root has been committed on-chain. It handles the second half of message delivery.

Pending execution check. The subcommittee connected to the destination chain scans the OffRamp for committed Merkle roots that haven't yet been fully executed. These represent messages that have been verified at the commit stage but not yet delivered to their receivers. This is the "pending" queue.

Validation and optimization. The DON goes back to the source chain to verify the individual events corresponding to the pending messages. This is the crucial double-check: the Commit plugin attested to the Merkle root, and the Execute plugin independently verifies that the messages actually exist on the source chain before executing anything. Once validated, the Executing DON optimizes the batch, considering gas limits, destination chain constraints, and message ordering, to determine which messages to include in the current execution transaction.

Execution. The optimized batch of messages is executed on the destination chain. The OffRamp validates the Merkle proofs for each individual message against the stored root, then calls the relevant token pools and receiver contracts. ExecutionStateChanged events are emitted with either Success or Failure status. Failed executions remain available for permissionless manual re-execution.

The important update on the Risk Management Network

Most content written about CCIP describes the Risk Management Network as an independently operated off-chain monitoring layer that watches for anomalies in committed Merkle roots and can trigger an emergency halt across the system.

The current official docs state clearly that this has changed: the Risk Management Network's automated off-chain role is no longer active in current CCIP deployments, but is expected to be offered as an optional validation layer in future releases.

What remains active is the on-chain RMN Contract. The Router, OnRamp, OffRamp, and Token Pool contracts all still call isCursed() on the RMN Contract before processing transactions. Manual curse initiation by the CCIP Owner is still available as an emergency safeguard for per-chain or network-wide halts when required.

What this means in practice: the automated off-chain anomaly detection layer that independently watched for suspicious commit patterns has been paused. The on-chain emergency brake still functions. CCIP's current risk controls rely on configurable rate limits, developer token attestations, and monitoring capabilities rather than an active off-chain RMN node network.

This is an important nuance to get right. Saying "the RMN provides an independent off-chain monitoring layer watching every Merkle root" is describing intended future functionality, not current behavior. The contracts call isCursed(), but that flag can only be set manually right now, not automatically by off-chain RMN nodes detecting anomalies.

How the two plugins coordinate

One detail worth being explicit about: the Commit and Execute plugins don't run in strict sequence waiting for each other. The Commit plugin runs continuously, committing new batches as messages arrive on source chains. The Execute plugin also runs continuously, checking for new committed roots and processing them into executions as fast as the destination chain's gas and confirmation requirements allow.

They operate as parallel pipelines on the same Role DON node set. A single node might be running the Commit plugin for one source chain and the Execute plugin for a different destination chain simultaneously, depending on its assigned roles within the network. The Role DON architecture makes this possible precisely because it's one unified network rather than two separate ones with their own separate job assignments.

What this means for auditors and builders

The terminology audit. Any CCIP documentation, code comment, or architecture diagram you encounter that still refers to "the Committing DON" and "the Executing DON" as separate networks was written before v1.6. Treat it as potentially outdated on other architecture details too.

The RMN audit. Any security analysis of a CCIP integration that relies on the RMN's off-chain automated monitoring as a defense layer should note that this layer is currently inactive. The on-chain curse mechanism still exists, but it requires manual intervention to trigger, not automatic detection.

The execution failure path. When ExecutionStateChanged emits a Failure status, that message isn't lost. It remains committed on-chain, available for permissionless manual execution after a configured delay. A receiver contract that handles a message for the first time should be idempotent: able to handle re-execution without double-applying effects, because the same message may arrive more than once if the first attempt fails and a manual re-execution is triggered. This is the same idempotency point from Day 12's onchain architecture article, reinforced here at the off-chain layer where the failure is generated.

Source: docs.chain.link, CCIP Offchain Architecture Overview

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.

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

Ramprasad Edigi — Fri, 17 Jul 2026 09:43:42 +0000

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.

I Asked in a Chainlink Discord: "Is Chainlink Building Any AI?" The Answer Sent Me Down a Rabbit Hole for Three Days.

Ramprasad Edigi — Tue, 14 Jul 2026 11:04:30 +0000

I Asked in a Chainlink Discord: "Is Chainlink Building Any AI?" The Answer Sent Me Down a Rabbit Hole for Three Days.

Last Friday, I dropped a question in a Chainlink Discord server I've been active in.

Simple question: "Is Chainlink building its own AI?"

I expected a yes or no. What I got was one of the sharpest one-liners I've seen explaining what Chainlink is actually doing in the AI space:

"Chainlink Labs isn't building a master AI model. Instead, they are building the security and verification layer for everyone else's AI. While OpenAI & Anthropic build the brains, Chainlink is building the guardrails."

I sat with that for a while. Then I spent the weekend going deep on it.

This is what I found.

Why AI Agents Touching Smart Contracts Is a Genuinely Hard Problem

AI models are non-deterministic by design. Give GPT-4 the same prompt twice and you can get two different answers. They hallucinate. They can be manipulated by carefully crafted inputs. And they're single points of failure.

Now give that model permission to execute a smart contract.

A wrong answer from an AI deciding a price isn't a chatbot embarrassment. It's an irreversible on-chain action. You can't call the bank and reverse a blockchain transaction. Once it settles, it settled.

This is the actual problem Chainlink is solving. Not "how do we make AI smarter." That's OpenAI's job. The question Chainlink is answering is: how do we verify that an AI ran correctly, on trustworthy data, and that the result wasn't changed between execution and delivery, without introducing a new single point of trust to check all of that?

What Actually Happened With 24 Banks and a $58 Billion Problem

In March 2026, Chainlink ran a project with 24 of the world's largest financial institutions including Swift, DTCC, Euroclear, and BNP Paribas.

The problem they were tackling: corporate actions processing. Dividend announcements, stock splits, rights offerings. This data lives in PDFs, press releases, and unstructured documents. Traditional systems can't parse and reconcile it reliably at scale. The global financial industry spends an estimated $58 billion annually dealing with this inefficiency.

The solution they built used AI models to extract data from those documents, and Chainlink DONs to verify it. Multiple independent AI instances ran on different nodes, each independently parsing the same source. The DON then reached consensus across all of them before writing anything on-chain.

Result: 100% consensus agreement across all evaluated corporate actions events.

The output became what they called an "Onchain Golden Record." An immutable, cryptographically verified source of financial truth that any smart contract can read and trust.

That's not a demo. That's production infrastructure with institutions settling real financial events against it.

The Technical Mechanism: Why This Is Different From Trusting One AI

The key insight is the same one that makes Chainlink's price feeds trustworthy: you don't trust one source, you aggregate many independent ones and make manipulation expensive.

Applied to AI:

Instead of trusting one model's answer, multiple independent LLM instances run on different DON nodes. Each generates its own output independently. The DON runs consensus across all of them before delivering anything to a contract.

If 19 of 21 nodes running independent instances agree on a dividend amount and 2 return outliers, the consensus mechanism filters those outliers the same way it filters a bad price data point. One model hallucinating doesn't corrupt the output when you need a supermajority to agree.

Chainlink Labs tested this on real Polymarket prediction data. 1,660 real betting outcomes, each with over $100,000 in trading volume. The AI oracle system correctly resolved up to 89% of cases, with each answer grounded in verifiable web sources and a transparent reasoning chain.

89% is a benchmark for a specific task type, not a universal claim. But the architecture of grounded reasoning plus decentralized verification is what makes the output usable on-chain rather than just in a chatbot.

The Four Layers Chainlink Provides

Layer 1: Multi-model consensus.
Multiple independent AI instances. DON aggregation. Hallucination filtering by supermajority agreement. Same principle as price feed decentralization.

Layer 2: Verifiable offchain compute via CRE.
AI models can't run on-chain. Too expensive. Non-deterministic. The Chainlink Runtime Environment is the orchestration layer where AI inference runs off-chain, DON nodes verify and sign the result, and the contract receives a cryptographically attested answer. Not a raw AI output. A verified one.

For sensitive inputs, Chainlink's Confidential Compute layer adds a Trusted Execution Environment: a cryptographic attestation that the correct model ran on the correct data, without exposing either. A bank running a proprietary trading algorithm through an AI oracle doesn't expose the algorithm to the verifying nodes. The TEE attestation proves correctness without revealing content.

Layer 3: Verified data inputs.
Garbage in, garbage out is a security problem when the output triggers a smart contract. An AI agent deciding whether to trigger a DeFi liquidation needs verified price data, not a data source it can be tricked into trusting. Data Feeds, Data Streams, and PoR feeds serve as the verified input layer for AI models. The same infrastructure I've written about in this series, now serving as the AI's eyes.

Layer 4: CCIP for cross-chain AI agent action.
An AI agent operating across multiple chains needs to move value and data between them. CCIP gives AI agents the same verified cross-chain capability that institutional protocols use. No new trust assumptions for the cross-chain step. The AI agent's action is as trustworthy as the CCIP message itself, with everything that comes with it: Router validation, Merkle verification, RMN curse checking.

The Part of This That's Still Early

The 89% Polymarket figure is for a specific, well-structured task type where source documents are findable and the correct answer is verifiable. Domains where AI needs to reason about genuinely ambiguous situations, or where AI models might all be confidently wrong in different directions, are harder. The consensus mechanism doesn't fully solve for that.

The corporate actions project worked precisely because the data was structured enough for AI models to extract reliably. Not every use case has that property.

If you're building AI agents that interact with on-chain systems today, the relevant question isn't "does this AI produce correct outputs in demos?" It's: what happens when it doesn't, and how does your architecture prevent a wrong AI output from causing an irreversible on-chain action?

Chainlink's verification layer is the most production-grade available answer to that question. It isn't the final answer.

What the Discord Reply Got Right

"While OpenAI and Anthropic build the brains, Chainlink is building the guardrails."

The guardrails-building is the less visible, less celebrated, deeply technical work. It doesn't have a demo that makes headlines. It doesn't have a chatbot you can screenshot.

What it has is 24 of the world's largest financial institutions running production corporate actions processing against it, with 100% consensus, on a live blockchain.

The brain-building is the glamorous part. The guardrails are the part that determines whether any of those brains ever get to touch real money.

One question for you: what would you build with a verified AI oracle that you currently can't trust enough to build with an unverified one?

Resources:
https://blog.chain.link/onchain-golden-record/
https://blog.chain.link/oracle-networks-ai/
https://blog.chain.link/ai-oracles/
https://chain.link/article/why-ai-need-blockchain-oracles
https://chain.link/article/ai-agents-and-stablecoins
https://chain.link/article/chainlink-privacy-standard
https://chain.link/article/why-ai-need-blockchain-oracles#:~:text=data%20into%20computational%20models%20and%20safely%20relay,models%20and%20onchain%20smart%20contracts%20can%20process

Writing through Chainlink's full architecture and ecosystem daily. Follow for the rest.

CCIP's Router Pattern: Why a Single Immutable Contract Per Chain Is the Entire Security Bet

Ramprasad Edigi — Fri, 10 Jul 2026 10:47:56 +0000

Why cross-chain bridges keep getting drained

Between 2021 and 2023, cross-chain bridges lost over $2.5 billion to exploits. Not because the blockchain technology was wrong. Because the trust models were. Most bridge architectures concentrate trust in one or two contracts that, if compromised, hand an attacker complete control over both the source and destination sides of every transfer in flight.

The Ronin Bridge ($625M, March 2022) was drained when an attacker compromised 5 of 9 validator private keys, signed fraudulent withdrawal transactions, and extracted funds before anyone noticed. The Wormhole exploit ($320M, February 2022) exploited a signature verification bug that let an attacker fake guardian approvals. In both cases, the single layer of trust wasn't enough.

This is day 12 of the 28-day Chainlink architecture series and the start of Week 3, the CCIP deep dive. Today covers the onchain architecture specifically: the Router, OnRamp, OffRamp, Token Pools, Fee Quoter, Token Admin Registry, and RMN Contract. The offchain components (the Role DON, Committing and Executing OCR plugins, and the Risk Management Network) come tomorrow. Understanding the onchain layer first is the right sequence because the contracts define the security surface, and every audit starts with the contracts.

The Router: one per chain, immutable, the only stable address

The Router is the single user-facing entry point for CCIP on each blockchain. One Router contract per chain. Users and dApps call Router.getFee() to estimate costs and Router.ccipSend() to dispatch a cross-chain message or token transfer. The Router is the contract you can hardcode. Everything else in the CCIP contract set is internal, can upgrade, and should be derived from the Router rather than assumed to be at a fixed address.

This design is a deliberate architectural security decision. The Router is immutable. If Chainlink needs to upgrade the OnRamp or OffRamp to add features, fix bugs, or respond to a security finding, it can do so without changing the address that every integration, every UI, and every contract in the ecosystem has bookmarked. From the user's perspective, nothing changes. From the internal architecture's perspective, the underlying implementation can evolve.

The Router validates that the destination chain exists in its routing table before passing anything to an OnRamp. It also checks whether the destination chain is cursed (more on that below) before processing the message. These checks happen before any fees are taken or any state is modified.

The OnRamp: source-chain processing, per lane

Each lane (unidirectional path between two chains) has its own OnRamp contract on the source chain. When the Router forwards a ccipSend call, the OnRamp takes over:

Fee collection: the OnRamp calls the Fee Quoter to get the precise fee for this specific message (size, token count, destination gas limit, current gas prices, and current LINK/ETH price all factor in). The calculated fee is collected from the sender in the specified fee token.

Message validation: the OnRamp checks parameters including the number of tokens in the message (currently capped at 10 tokens per message), the gas limit for the callback on the destination chain, and the data payload length.

Curse check: the OnRamp calls isCursed() on the RMN Contract to verify the destination chain is not currently flagged as compromised or under active monitoring. If the destination is cursed, the transfer is rejected at this point.

Token handling: if the message includes tokens, the OnRamp interacts with the Token Pool for each included token, calling lockOrBurn. The specific mechanism (lock vs burn) depends on how the token pool is configured for that token.

Message dispatch: after all validations pass, the OnRamp assigns a sequence number to the message, generates a unique message ID, and emits a CCIPMessageSent event. This event is what the offchain Committing DON monitors.

One important implementation detail: the OnRamp address can change when CCIP ships product updates. Integrating contracts should never hardcode the OnRamp address. They should derive it from the Router. The Router always knows the current OnRamp for each lane.

The OffRamp: destination-chain processing, per lane

The OffRamp is the destination-chain counterpart. It's an internal contract that only the CCIP DONs can call to process incoming messages. Two distinct phases happen at the OffRamp.

Commit phase: the Committing DON calls commit() on the OffRamp with a Commit Report containing a Merkle root of a batch of messages from the source chain, along with price update data. The OffRamp stores this Merkle root. It emits a CommitReportAccepted event. The OffRamp does not execute anything at this stage. It just records that a DON has attested to this Merkle root being valid.

Execution phase: the Executing DON (or a manual executor in fallback scenarios) provides a Merkle proof for a specific message against a stored root. The OffRamp validates the proof, checks the source chain is not cursed, checks message-level rate limits, and if everything passes, executes:

For token transfers: the OffRamp retrieves the relevant Token Pool from the Token Admin Registry and calls releaseOrMint. Tokens are released (if lock-and-release) or minted (if burn-and-mint) to the specified receiver.
For messages with data: the OffRamp calls the Router to deliver the arbitrary bytes payload to the receiver contract's ccipReceive function.

The OffRamp emits ExecutionStateChanged with a final status of either Success or Failure. If execution fails (due to insufficient gas limit in the receiver's callback or a logic error in the receiver contract), the message doesn't disappear. It remains available for permissionless manual execution after a configured time delay. This fallback path ensures message delivery is guaranteed as long as someone eventually triggers execution with sufficient gas.

Like the OnRamp, the OffRamp address can change. Always derive it from the Router.

The Lane: the unit of configuration

A Lane is the conceptual unidirectional path between two chains. Ethereum to Arbitrum is one lane. Arbitrum to Ethereum is a different lane. They're configured independently. This matters more than it sounds.

Each lane has its own settings for:

How many source-chain block confirmations to wait before the Committing DON posts a Merkle root (Ethereum mainnet sources typically use 64 confirmations, roughly 13 minutes, for deep finality guarantees)
Which tokens are supported
Rate limits per token per direction
Whether an allowlist restricts which senders can use the lane

The independence of lane configuration is what lets institutional deployments tune their risk parameters specifically. A lane connecting a bank's private chain to Ethereum for high-value settlements can be configured with deeper finality requirements, more conservative rate limits, and a sender allowlist. A lane connecting two DeFi protocols for retail-scale token flows can be configured with lighter finality and higher throughput. Neither configuration affects the other.

Token Pools and rate limits: the capacity bucket model

Each token has its own Token Pool on each chain. The OnRamp and OffRamp use the Token Admin Registry to look up which Token Pool handles a given token before calling lock/burn or release/mint. Token Pools are deployed by token developers and exist independently of the core CCIP contracts.

Rate limits in Token Pools use a capacity bucket model: the pool has a maximum capacity and a refill rate. Transfers draw down capacity from the bucket. If insufficient capacity is available, the transfer is rejected until enough has refilled. Crucially, each token pool maintains two independent limits: an outbound rate limit (from this chain to a remote chain) and an inbound rate limit (from a remote chain into this chain). Inbound and outbound limits can differ in capacity and refill rate, allowing asymmetric risk tuning depending on the direction of value flow.

Rate limits are configured per token per lane. Changing a rate limit affects only that specific token on that specific lane, not all CCIP traffic. Disabling rate limits entirely removes an important safety mechanism and should only be done deliberately.

The RMN Contract and the curse mechanism

The RMN (Risk Management Network) Contract is deployed on every CCIP-enabled chain. It serves two functions that are both security-critical.

Curse detection: the Router, OnRamp, OffRamp, and Token Pool contracts all call isCursed() on the RMN Contract before processing transactions. If the chain is marked as cursed, all CCIP operations involving that chain halt. A curse can be initiated manually by the CCIP Owner if an active threat is detected, or propagated by the Risk Management Network's offchain nodes if they detect anomalies in the Merkle roots being committed. The curse mechanism is the emergency brake, and it operates across the entire stack: the source chain's OnRamp won't dispatch, and the destination chain's OffRamp won't execute, while a curse is active.

Upgrade control: all security-critical configuration changes and infrastructure upgrades for CCIP pass through a Role-based Access Control Timelock contract. This provides a review period during which CCIP node operators can veto an upgrade, or in time-sensitive situations, explicitly approve it before the timelock expires. This prevents a compromised governance key from instantly pushing a malicious upgrade through.

Audit checklist for any CCIP integration

1. Is ccipReceive access-controlled?
The most common CCIP integration mistake: a receiver contract that doesn't verify the caller is the legitimate Router. Any address can call ccipReceive on an unprotected contract and inject arbitrary data.

function ccipReceive(Client.Any2EVMMessage memory message) 
    external override onlyRouter {
    // onlyRouter modifier checks msg.sender == i_router
}

2. Are OnRamp and OffRamp addresses derived from the Router, not hardcoded?
Both can change with product updates. A contract that hardcodes an OnRamp or OffRamp address will silently break after an upgrade.

3. Is the gas limit set high enough for ccipReceive?
The gas limit for the destination callback is set at the source chain when ccipSend is called. If ccipReceive runs out of gas, execution fails and the message sits in a failed state until manually re-executed. Profile the receiver's gas consumption before setting this value.

4. Does ccipReceive handle failed execution gracefully?
If the receiver logic reverts, the message can be manually re-executed permissionlessly. Make ccipReceive idempotent: check whether the message has already been processed before acting on it, so re-execution doesn't double-apply effects.

5. Is the message ID stored and checked?
Track which message IDs have been processed. Even with permissionless manual execution, a receiver that processes the same message twice because it doesn't track IDs can produce unintended outcomes.

6. Are Token Pool rate limits appropriate for the volume and risk profile?
Rate limits that are too high provide no protection during an exploit. Rate limits that are too low throttle legitimate volume. For each token on each lane your protocol uses, verify the outbound and inbound limits are explicitly configured and match the expected flow, not defaulted to off.

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.

Chainlink Staking Isn't a Yield Farm. It's Cryptoeconomic Security With Real Consequences.

Ramprasad Edigi — Wed, 08 Jul 2026 10:36:58 +0000

The framing that gets this product wrong

Browse Chainlink Staking content on crypto Twitter and you'll find two framings: "earn 4.32% APY on your LINK" or "Chainlink is printing rewards to keep holders happy." Both miss the actual mechanism. The yield is a side effect. The product is cryptoeconomic security, and the way it produces security is by making dishonest or negligent behavior expensive enough that rational actors don't bother.

This is day 11 of the 28-day Chainlink architecture series. Today covers the complete staking v0.2 model: the two staker types, the slashing mechanism that gives the whole thing teeth, the alerting system, and what this is actually adding to Chainlink's security posture beyond "more LINK locked up."

Two staker types with fundamentally different roles

Staking v0.2 has a 45,000,000 LINK total capacity split between two groups who are not doing the same job.

Community Stakers: anyone can participate, minimum 1 LINK, maximum 15,000 LINK per address. The community pool has 40,875,000 LINK allocated to it and filled within six hours of Early Access opening in December 2023, where it remains today. Community stakers earn a base floor reward rate, currently producing about 4.32% annually after the delegation mechanism is accounted for. Community stakers are not at risk of slashing in the current configuration.

Node Operator Stakers: professional node operators who service Chainlink Data Feeds, minimum 1,000 LINK, maximum 75,000 LINK. The remaining 4,125,000 LINK in the pool is allocated to this group. Node operator stakers can earn up to around 7% including delegation rewards from community stakers. They also face slashing risk if they fail to meet performance requirements. This is the group where the security mechanism actually lives.

The delegation mechanic connecting the two groups is worth understanding precisely. The base floor rate for community stakers starts at 4.5%. Of that, 4% is redirected as a Delegation Reward to node operator stakers, proportional to how much each operator has staked. Community stakers end up with roughly 4.32% net. This mechanism means community stakers are financially backing node operators specifically, not just the network abstractly. The community pool's size directly influences how much additional stake supports node operator security.

What slashing actually does, with real numbers

Slashing is where most staking explainers stop at "bad nodes get penalized" without explaining the mechanism. Here's the actual design.

At launch, staking v0.2 secures the ETH/USD Data Feed on Ethereum. This is the highest-value, most-watched Chainlink feed, a deliberate choice for an initial secured service since any malfunction would be immediately visible to the community.

The alerting condition: if the ETH/USD feed has been down for more than three hours since the last valid oracle report, a valid alert can be raised. Node operator stakers get a 20-minute priority window to raise the alert first. If no node operator raises the alert within 20 minutes, community stakers can raise it.

When a valid alert is raised: each node operator staker serving the ETH/USD feed is slashed 700 LINK. The alerter, whoever raised the valid alert, receives 7,000 LINK as a reward.

These numbers are deliberate. 700 LINK slashed per operator, with potentially dozens of operators serving a single feed, means a significant amount of total stake is forfeited for a sustained outage. The 7,000 LINK reward creates a financial incentive for alert-raising that anyone holding LINK can participate in, not just insiders. The 20-minute node operator priority window means that operators have a brief window to self-report issues, which is a reputational and economic incentive for transparency over concealment.

The unbonding mechanism is designed to ensure stake is available to be slashed. If an operator could instantly unstake the moment they saw an alert being raised, slashing would have no teeth. Instead, v0.2 requires a 28-day cooldown after initiating an unstake, followed by a 7-day claim window during which the LINK can actually be withdrawn. If you don't act during the claim window, the stake automatically re-enters v0.2. Slashing can occur during the cooldown and claim window periods, which means initiating an unstake doesn't protect an operator from a slash for past misbehavior.

Locked Rewards and the alignment mechanism

Staking rewards come in two forms that behave differently.

Claimable Rewards can be withdrawn at any time. Straightforward.

Locked Rewards go through a 90-day ramp-up period. The longer a staker remains in v0.2, the more of these locked rewards unlock over time. If a staker exits before the 90-day period completes, any unvested Locked Rewards are forfeited and redistributed to other community stakers who maintained their positions.

This creates a real alignment incentive: stakers who commit for longer and exit less frequently capture more rewards than those who treat staking as a short-term position to rotate in and out of. Combined with the 28-day unbonding cooldown, the economic structure discourages transient participation and rewards the kind of long-term commitment that produces genuine security value rather than superficial TVL numbers.

Why reputation alone isn't sufficient (and why slashing is necessary)

Chainlink's pre-staking security model relied heavily on node operator reputation. The argument was that established operators, running mission-critical infrastructure for well-known DeFi protocols, had strong reputational incentives to behave honestly. Reputation loss from misbehavior would cost them future business far more than any single service manipulation could gain.

That argument is real and continues to be part of the security picture. But reputation alone has limits. Reputation is effective against known actors with established histories. It's less effective against a newer operator who hasn't built a track record yet, or against a sophisticated adversary willing to sacrifice one operator's reputation for a sufficiently large payoff. It also doesn't create a direct, transparent, on-chain consequence that anyone can verify.

Slashing adds a second layer that addresses these gaps. When a node operator has 700 LINK at risk per alerting event (with more operators meaning a larger total slash), the cost of negligence or misbehavior is an immediate, concrete, on-chain loss that isn't contingent on anyone choosing to stop working with them afterward. Combined with the 7,000 LINK reward for raising a valid alert, the mechanism creates a community-powered monitoring system where financial incentives align everyone's interests toward detecting and reporting feed failures.

The Chainlink Rewards program (Economics 2.0 in practice)

Staking v0.2 introduced a dynamic rewards mechanism designed to support multiple future sources of rewards beyond token emissions. In May 2025, the first concrete example of this went live: Chainlink Rewards, starting with Space and Time (SXT), which made SXT tokens claimable by LINK stakers during a 90-day claim window.

This is the beginning of what Chainlink's Economics 2.0 whitepaper describes as the transition from relying on token emissions for staking rewards to eventually incorporating direct user fees from oracle services. The idea is that as CCIP, Data Feeds, and other Chainlink services generate fee revenue, a portion of that revenue flows back to stakers as additional rewards on top of the base rate. The SXT integration is an early step toward a multi-source reward model, though the pure user-fee component has not yet materialized at meaningful scale as of mid-2026.

What this means if you're auditing a protocol that uses Chainlink

The staking architecture has a specific implication for security reviews: a protocol using a Chainlink feed that is secured by staking has a different, additional security layer compared to one using a feed that is not yet secured by staking.

As of mid-2026, staking v0.2 at launch secured the ETH/USD Data Feed on Ethereum. The planned expansion to additional services, including CCIP, has been signaled but not yet delivered at full scale. This means the staking-backed security guarantee is not uniform across all Chainlink products. If you're auditing a protocol and it matters to your threat model whether the oracle feed it uses is staking-backed, verify this at data.chain.link for the specific feed rather than assuming all Chainlink feeds carry the same slashing-backed accountability.

The alerting mechanism also has a practical implication for protocols relying on the ETH/USD feed: a sustained feed downtime beyond three hours will trigger the alert and slash cycle. That's a signal to any protocol reading that feed that something has gone wrong at the oracle layer, not a normal market event. Protocols that monitor on-chain alerting events for the feeds they depend on can use this as an early warning signal, separate from their own staleness checks, that is worth integrating into incident response procedures.

What this adds to the architecture picture

Day 3 of this series established the distinction between DON consensus (which provides data integrity through independent aggregation) and governance-layer trust (which relies on multisig-controlled parameters). Staking v0.2 adds a third layer to Chainlink's security model: cryptoeconomic accountability. Independent aggregation makes manipulation statistically difficult. Governance-layer multisig provides controlled upgradeability. Staking with slashing makes sustained service failure economically costly.

None of these three layers alone is sufficient. Independent aggregation doesn't prevent all forms of coordinated failure. Governance multisig doesn't prevent operational negligence. Staking doesn't prevent a well-funded adversary who's willing to absorb the slash as a cost of attack. Together, they create the defense-in-depth model that Chainlink's architecture is explicitly designed around: multiple independent failure conditions that an attacker has to satisfy simultaneously rather than one single point to compromise.

want to go through official links??
here you go:
https://blog.chain.link/chainlink-staking-v0-2-overview/
https://chain.link/economics/staking
https://blog.chain.link/chainlink-staking-v0-2-now-live/
https://blog.chain.link/chainlink-rewards/
https://staking.chain.link/

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.

TerraUSD Collapsed With $18B in Circulation. Chainlink Proof of Reserve Would Have Caught It Earlier

Ramprasad Edigi — Tue, 07 Jul 2026 11:40:44 +0000

If you're building or auditing anything that handles collateral, this day matters more than most

UST had $18 billion in circulation at its peak. It died not because a smart contract had a bug, but because the reserve backing it was entirely circular: UST was backed by LUNA, and LUNA derived its value largely from UST's demand. There was no independent, automated, on-chain mechanism continuously verifying that the collateral was genuinely worth what the protocol assumed it was worth. When the peg cracked, protocols had no circuit breaker. They kept accepting UST as collateral, kept issuing loans against it, and kept running liquidations based on a price that was evaporating in real time.

This is day 10 of the 28-day Chainlink architecture series. Today covers two products that solve different versions of the same fundamental problem: Chainlink Proof of Reserve (is this asset actually backed?) and Chainlink Data Streams (is this price actually current enough for a derivatives trade?). Both exist because the Day 5 staleness footgun, trusting oracle output without verifying its freshness or correctness, has different flavors depending on what the oracle is measuring and what the protocol is doing with the result.

Proof of Reserve: automated collateral verification, not periodic audits

Traditional reserve verification works like this: a custodian holds assets, an auditor checks them once a month or once a quarter, and publishes a report. Everyone trusts the report until the next one. In between, anything could happen.

Chainlink Proof of Reserve replaces that model with a DON-powered data feed that continuously monitors and publishes collateral data on-chain. The same infrastructure as Price Feeds, deviation thresholds and heartbeat intervals, applied to reserve balances instead of asset prices. Smart contracts can query this feed the same way they query latestRoundData() on a price feed, and apply the same staleness checks.

Three specific problems PoR addresses:

Fractional reserve practices. If a stablecoin issuer is quietly holding less fiat than the token supply suggests, a PoR feed catches that discrepancy automatically, without waiting for a quarterly audit.

Infinite mint attacks. Without PoR, a compromised or malicious bridge can mint wrapped tokens against non-existent collateral. Chainlink's Secure Mint mechanism integrates PoR verification directly into the mint function itself: before new tokens are issued, the contract checks that reserves are sufficient to back the new issuance. No valid reserve attestation, no mint.

Cross-chain collateral opacity. A token on Ethereum backed by Bitcoin held on the Bitcoin chain has reserves that neither Ethereum nor its contracts can natively see. PoR feeds provide a verified, DON-sourced bridge between those two realities.

What PoR actually verifies, and what it doesn't

Being precise here matters because PoR gets overstated in marketing and dismissed in technical circles for different reasons, and both miss the real point.

What PoR verifies: that the on-chain data published by the DON matches what the DON's node operators observed from the custodian's system or API at the time of the last update. For assets backed by on-chain collateral (like wrapped Bitcoin), nodes verify the underlying chain directly. For assets backed by off-chain collateral (like fiat-backed stablecoins), nodes verify data provided by the custodian or a professional auditor.

What PoR doesn't verify: the custodian's honesty in their own reporting. If a custodian deliberately provides false data to the DON's API endpoint, PoR propagates that false data accurately but doesn't catch the underlying fraud. PoR is tamper-resistant to third-party manipulation, but it's not magic. It shifts trust from "trust the issuer's quarterly press release" to "trust that a decentralized network of independent operators correctly relayed what the custodian reported." That's a meaningful improvement in transparency and automation, not a complete substitution for custodian honesty.

The correct framing: PoR makes reserve data programmable and continuous. It makes discrepancies detectable sooner and actionable by smart contract logic rather than requiring a human to read a PDF.

Real deployment: Deutsche Börse Group, September 2025

In September 2025, Crypto Finance, a Deutsche Börse Group subsidiary, went live with Chainlink Proof of Reserve for nxtAssets' Bitcoin and Ethereum Exchange Traded Products. The reserve data is orchestrated by CRE (Chainlink Runtime Environment), published on Arbitrum, and publicly viewable. Custodial assets are cryptographically verified without disclosing sensitive wallet addresses or private data.

This matters as a case study because it's an institutional-grade deployment, a FINMA-regulated custodian and a Deutsche Börse subsidiary, choosing automated on-chain reserve verification over periodic manual audits. That's not a DeFi protocol experimenting with novel infrastructure. That's traditional finance infrastructure explicitly adopting the continuous verification model.

Data Streams: pull oracles for derivatives, perpetuals, and anything latency-sensitive

Chainlink Data Feeds update on a push model: deviation threshold or heartbeat fires, a new round gets submitted on-chain, consuming contracts read it. For most use cases, that works well. For a spot lending protocol reading ETH/USD, a one-hour heartbeat and a 0.5% deviation threshold is fine.

For a perpetuals exchange, it isn't. Here's why.

A perp trader opens a $1 million position. If the price feed is two seconds behind the real market, a sophisticated adversary can observe the upcoming price update, know the on-chain price is about to move, and execute a trade against the protocol that's essentially risk-free: buy before the feed updates, take profit, exit. The protocol eats the loss. That's not a hack. It's latency arbitrage, and it's a structural property of push-based oracles on any system where updates are predictable in timing.

Data Streams solves this with a pull model and a commit-and-reveal mechanism.

The pull model: rather than publishing data to a chain on a schedule, DON nodes continuously generate signed price reports and store them off-chain. Your application fetches the latest report via REST API or WebSocket when it needs it, not when the DON decides to push. For a perpetuals exchange handling a trade, this means the price can be as fresh as the latest DON report, potentially sub-second latency, not constrained by block time or heartbeat interval.

The commit-and-reveal mechanism: the user submits a transaction committing to the trade before the price is revealed on-chain. The price report is included atomically in the same transaction. This makes the trade data and the stream data visible simultaneously on-chain, eliminating the window between "I saw this price" and "this transaction executed." No frontrunning window, because there's no advance on-chain signal for a frontrunner to observe and act on first.

On-chain verification: even though the report is fetched off-chain, it doesn't get used without verification. The Verifier contract on-chain checks the DON's signatures on the report before any trade logic executes. Same quorum-signature trust model as Data Feeds, applied on demand instead of on a schedule.

Two implementation paths and when to use each

Data Streams offers two implementation approaches:

Standard API implementation: your application fetches reports directly via REST or WebSocket and submits them to the Verifier contract when needed. Best for applications that control their own transaction flow and want maximum flexibility over how and when they pull data.

Streams Trade implementation: combines Data Streams with Chainlink Automation's log triggers. An Automation Upkeep detects when a new report is available and automatically executes the downstream transaction with frontrunning protection. Best for protocols that want automated trade execution without managing the report-fetching pipeline manually.

GMX, the decentralized perpetuals exchange on Arbitrum, was among the first production deployments of Data Streams. The commit-and-reveal mechanism specifically addresses the toxic-flow and adverse-selection problems that plague DEX-based derivatives markets, where sophisticated traders systematically profit against the protocol by exploiting oracle latency.

Audit checklist: PoR integrations

1. Is the PoR feed's staleness checked before the reserve data is used?
PoR feeds have their own heartbeat and deviation thresholds. A PoR feed with a 24-hour heartbeat that goes stale for 23 hours is still stale. The same updatedAt check from Day 5 applies here, with MAX_DELAY set relative to this specific feed's published heartbeat.

2. Is Secure Mint actually enforced in the mint function, or just advisory?
The most common integration mistake: deploying PoR but not wiring it into the mint function itself. A reserve check that's queryable but not enforced is transparency theater, a dashboard number, not a security control.

function mint(address to, uint256 amount) external {
    (, int256 reserveBalance,, uint256 updatedAt,) = 
        reserveFeed.latestRoundData();
    require(updatedAt >= block.timestamp - MAX_DELAY, "Stale reserve data");
    require(reserveBalance >= int256(totalSupply() + amount), 
        "Insufficient reserves");
    _mint(to, amount);
}

3. Who provides the data that feeds the PoR DON?
For on-chain collateral (wrapped Bitcoin), DON nodes verify the source chain directly. For off-chain collateral (fiat stablecoins), DON nodes relay data from a custodian API or professional auditor. Auditing question: if the custodian controls that API, what prevents them from lying? The answer is reputation, legal obligation, and the fact that discrepancies become publicly visible on-chain faster than under a quarterly audit model. That's better than the alternative, but it's a different trust assumption than fully trustless on-chain collateral.

Audit checklist: Data Streams integrations

1. Is the Verifier contract call checking the report's validity before execution?
Reports fetched off-chain must be verified on-chain via the Verifier contract before the protocol acts on them. A contract that accepts a signed report without calling Verifier is trusting whoever submitted it, not the DON.

2. Is the report's timestamp validated against the trade's execution window?
Even a pull oracle can go stale if the application caches a report for too long before submitting it. The report's observationsTimestamp should be checked against the current block timestamp with an appropriate tolerance.

3. Does the protocol handle Verifier contract reverts?
If the Verifier contract rejects a report (invalid signatures, wrong feed ID, expired report), the integration needs a defined fallback. A bare revert with no fallback path is the same DoS vector as an unguarded oracle call in a Data Feeds integration.

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.

Chainlink Functions Is Serverless Compute With Oracle Guarantees. Here's the Full Request Lifecycle.

Ramprasad Edigi — Mon, 06 Jul 2026 09:55:42 +0000

The mental model most people have is too simple

"Chainlink Functions lets smart contracts call APIs." That's true the same way "Ethereum lets people send money" is true. Technically accurate, misses almost everything that makes the product interesting and almost everything that matters for security.

Chainlink Functions is better understood as a decentralized serverless compute platform: arbitrary JavaScript runs across every node in a DON, each node executes independently, OCR aggregates the results, and the aggregated output gets delivered back to the consumer contract through a verified callback. The "API call" is just one of the things that JavaScript can do inside that environment. The DON consensus and the threshold-encrypted secrets model are what make it meaningfully different from a centralized API proxy.

This is day 9 of the 28-day Chainlink architecture series. Today covers the full request lifecycle, every contract in the chain, how threshold encryption protects secrets without exposing them to any individual node, and the integration mistakes that come from misunderstanding how billing and callbacks actually work.

The four contracts you need to understand

Before tracing the full lifecycle, it helps to know exactly which contract does what.

FunctionsRouter: the stable, immutable entry point for consumers. Manages subscriptions and authorized consumer contracts. Its interface doesn't change when the underlying implementation upgrades, consumer contracts call sendRequest here and only here. Also handles billing: estimates fulfillment cost at request time and finalizes it at response time.

FunctionsCoordinator: the interface between the Router and the DON. Emits the OracleRequest event that DON nodes watch for. Handles fee distribution to transmitters via a fee pool. Inherits from OCR2Base, meaning the full OCR consensus machinery runs here. This contract can be upgraded independently of the Router, which is why the Router exists as a stable facade in front of it.

FunctionsClient: a base contract your consumer inherits. Handles the handleOracleFulfillment callback correctly and exposes sendRequest/sendRequestCBOR to you. If you're writing a consumer contract from scratch without inheriting FunctionsClient, you're taking on the responsibility of implementing the callback correctly yourself, which is where most custom integrations introduce bugs.

Your consumer contract: calls sendRequest on the Router, implements fulfillRequest(bytes32 requestId, bytes memory response, bytes memory err) to receive the result.

The full request lifecycle, step by step

Here's every step from sendRequest to your contract receiving the result. This is the complete picture most tutorials skip.

Step 1: Consumer calls sendRequest.
Your contract calls sendRequest on the FunctionsRouter, passing the JavaScript source code (or a DON-hosted secrets slot ID referencing pre-uploaded code), the subscription ID that pays for the request, the callback gas limit, and any arguments to pass into the script.

Step 2: Router estimates billing and reserves funds.
The Router immediately estimates the total fulfillment cost using the current gas price, the gas overhead of the Router and Coordinator contracts, your callback gas limit, and the ETH/LINK price feed to translate everything into LINK. It blocks (reserves) that estimated amount from your subscription balance. If your balance is too low, the request reverts here.

Step 3: Router calls FunctionsCoordinator.
The Router routes the request to the appropriate FunctionsCoordinator for the DON ID specified in the request. The Coordinator emits an OracleRequest event with everything the nodes need: the request ID, the encoded source code or reference, the subscription ID, and the encrypted secrets reference if provided.

Step 4: DON nodes decrypt secrets.
This is the step most architecture diagrams skip. If the request includes secrets (API keys, auth tokens, anything that should be private), those secrets are encrypted using the DON's threshold public key before being uploaded. The decryption requires participation from multiple nodes simultaneously. No single node can decrypt secrets alone, because the decryption key is split across the DON using threshold cryptography. A compromised individual node can't exfiltrate your API key, because that node only holds a fragment of the key needed to decrypt it.

Step 5: Each node executes the JavaScript independently.
Every node in the DON runs your JavaScript source code in its own isolated Deno sandbox. The sandbox has no access to the file system, no environment variables, no network permissions beyond HTTP requests made through the Functions.makeHttpRequest helper. Execution time limit is 10 seconds total, with any single external API call required to respond within 9 seconds. If execution exceeds the time limit, the node returns an error in bytes, not a revert.

Step 6: OCR aggregates the results.
Each node's execution produces a return value, which must be a Uint8Array. The DON runs OCR to aggregate those values. For numeric responses, this is typically a median. The OCR consensus round here works exactly like Day 4's coverage of OCR generally: nodes share observations, reach agreement, sign a report.

Step 7: FunctionsCoordinator receives the aggregated result.
One node transmits the signed OCR report to the FunctionsCoordinator on-chain. The Coordinator validates the quorum signatures, exactly like the aggregator contract in Data Feeds and the Registry in Automation.

Step 8: Router finalizes billing and calls your callback.
The Router calculates the actual fulfillment cost (which may differ slightly from the estimate in Step 2), adjusts your subscription balance, distributes fees to the DON's transmitters, and then calls fulfillRequest on your consumer contract with the aggregated response and any err.

How threshold encryption works for secrets, precisely

Most explainers say "secrets are encrypted to the DON" and leave it there. Here's what that actually means.

Before making a request that requires an API key, you encrypt your secret using the DON's public key, which is derived from the individual key shares held by each node. You can do this locally using the Functions SDK. The encrypted secret gets uploaded either to a URL you host (off-chain secrets) or to a DON-hosted secrets slot (on-chain via the Coordinator).

When a request comes in that references a secret, the DON nodes cooperate to decrypt it using threshold decryption. This requires a quorum of nodes to participate, because each holds only a fragment of the private key needed to decrypt. A single compromised node is not sufficient to decrypt the secret. The attacker would need to compromise enough nodes to meet the threshold, at which point they've already compromised the broader DON consensus, which is a much larger and more difficult attack than targeting a single node.

The key implication for security design: the threat model for Functions secrets is the same as the threat model for the DON's data integrity generally. You're not trusting any individual node with your API key. You're trusting that the DON's threshold remains intact, the same trust assumption you're already making when you use Data Feeds from the same network.

The Deno sandbox: what your code can and can't do

Each node executes your JavaScript in a Deno runtime. Specific constraints worth knowing before you write a Functions script:

What you can do:

Make HTTP requests via Functions.makeHttpRequest (this is the only allowed network call)
Use top-level await for async operations
Pass args (string array) and bytesArgs (hex-encoded bytes) from your contract call into the script
Import modules, with the caveat that download time counts toward your 10-second execution budget and modules cannot use Deno permissions (file system, env vars, etc.)
Return any value encoded as a Uint8Array using the Functions.encodeUint256, Functions.encodeInt256, Functions.encodeString helpers

What you cannot do:

Access the file system
Read environment variables
Open network connections other than HTTP via the Functions helper
Exceed 10 seconds total execution time
Have a single external API call take longer than 9 seconds

If your script returns an error (timeout, HTTP failure, explicit throw), the error is returned as bytes in the err parameter of your callback, not as a revert. Your fulfillRequest function receives both a response and an err and should handle both cases explicitly.

Billing: what you're actually paying for

This is the most commonly misunderstood part of Functions' cost model.

Billing is denominated entirely in LINK, but you're not directly paying LINK for compute time. You're paying for the on-chain gas cost of fulfilling the request, translated into LINK using a price feed, plus a premium fee that compensates the DON for their off-chain work.

The estimate at request time uses an intentionally overestimated gas price (higher than current) to ensure the request will be fulfilled even if gas prices spike between request and fulfillment. Your subscription is charged the actual cost at fulfillment time, not the estimate. The difference is returned to your subscription balance.

Premium fees are USD-denominated but paid in LINK. The LINK equivalent is calculated at request time using the ETH/LINK or relevant native-to-LINK price feed. If that price feed is unavailable, the FunctionsCoordinator falls back to a hardcoded Wei-to-LINK ratio stored in its config.

One practical implication: subscription balance monitoring matters even more for Functions than for Automation, because a Functions request that fails at Step 2 (insufficient balance) silently doesn't execute, with no on-chain error visible to your contract. Your contract called sendRequest, the call reverted, and nothing happened. The revert is not surfaced through fulfillRequest since no request was ever accepted.

5 audit checks for any Functions integration

1. Is fulfillRequest handling both response AND err?
Every callback receives both parameters. A contract that blindly decodes response without checking whether err is non-empty will silently act on a failed request's empty response bytes. Always check err.length == 0 before trusting response.

2. Is the consumer contract in the subscription's authorized consumer list?
The FunctionsRouter only accepts sendRequest calls from consumer contracts that are explicitly authorized on the subscription. If your contract isn't listed, sendRequest reverts. Simple to verify, easy to forget when deploying to a new network or a new contract version.

3. Is the callback gas limit sufficient?
The callback gas limit is set at request time inside sendRequest. If fulfillRequest's execution exceeds this limit, the callback fails silently and response/err are never delivered. The maximum allowed callback gas is 300,000. If your callback does anything complex, profile it before setting this value.

4. Are secrets stored with appropriate TTL?
DON-hosted secrets have a Time-To-Live (TTL) in minutes. After expiry, nodes delete the secret and any request referencing it will fail with a secrets-unavailable error. For production integrations, either refresh secrets before TTL expiry or use off-chain secrets with a URL you control.

5. Is the subscription balance monitored?
An empty or below-minimum subscription causes sendRequest to revert silently from your contract's perspective (unless you explicitly catch the revert). Fund the subscription with a buffer above the minimum and alert before it gets low.

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.