Chainlink Sets July 31 Deadline for Automation v2.1 Migration

Chainlink Automation v2.1 Ends July 31

Automation is Chainlink’s system for scheduling or triggering smart-contract actions. Under the older model, a project registers an upkeep and implements a checkUpkeep() function for offchain simulation plus a performUpkeep() function for onchain execution.

Chainlink’s migration documentation says the v2.1 sunset is July 31 and instructs developers to move existing upkeeps before then to avoid disruption. The company describes CRE as a replacement that can handle what Automation does today and additional workflow patterns.

The timing gives the story clear search intent: teams now searching for “Chainlink Automation v2.1 sunset” or “migrate upkeeps to CRE” need a production response, not a price forecast. Chainlink did not disclose how many v2.1 upkeeps remain un-migrated or identify applications that could be affected.

The shutdown also arrives as the industry expands its infrastructure for automated actions. Our coverage of AI agents driving onchain activity examined a separate growth trend, but both cases put execution controls and reliability at the center of a system that can move assets without an operator pressing a button each time.

Chainlink CRE Replaces Upkeeps With Workflows

CRE changes the execution model from an upkeep registration to a workflow. Chainlink says a workflow can begin with a cron schedule, an HTTP request or an onchain log event, run offchain logic, then write a signed report onchain for a receiving contract to process.

The documentation maps time-based upkeeps to a cron trigger and log-triggered upkeeps to an EVM Log trigger. Custom logic upkeeps can use a cron trigger plus an onchain contract call in the workflow handler, according to Chainlink.

For migration, the company provides an AutomationReceiver bridge template. The bridge receives CRE reports and forwards approved calls to a target contract, allowing many existing contracts to retain their performUpkeep() execution path rather than requiring a full application rewrite.

Chainlink says CRE supports every chain that the older Automation service supports today. That continuity is important for cross-network applications, particularly where a migration that works on one chain but not another could create uneven operating risk. The same interoperability question appears in institutional settings, including Chainlink’s work with banks on stablecoin foreign-exchange workflows.

The new workflow model does not remove the need to test. Chainlink’s guide calls for project initialization, bridge deployment, receiver configuration, simulation and workflow deployment, leaving the exact production sequence dependent on each contract and its security model.

Chainlink Migration Requires a Permission Review

The receiver bridge can reduce code changes, but Chainlink cautions that existing target contracts may still require updated permissions. A contract that checks msg.sender, uses an Automation Forwarder allowlist or depends on role-based access may need to authorize the new AutomationReceiver before it can accept CRE-routed calls.

The guide recommends limiting the receiver to approved targets and function selectors and configuring workflow identity checks in production. It warns that a generic receiver able to accept arbitrary target-and-data calls should not remain broadly reusable without explicit authorization controls.

That distinction is consequential for protocols that treat automation as part of their safety system. A rushed permission change can create a new attack surface, while an incomplete migration can leave expected maintenance calls unexecuted. Readers following the wider security picture can compare the concern with our report on the Gnosis Pay Delay Module exploit, where transaction controls were central to the incident.

Broader sentiment remained subdued. The Crypto Fear & Greed Index was at 29, or Fear, on July 29. The Bitcoin-weighted index does not measure Chainlink Automation or a project’s migration readiness, but it provides the market backdrop for LINK trading while developers face an immediate operations deadline.

The main remaining questions are how many v2.1 upkeeps have moved before July 31 and whether applications that have not publicly disclosed their architecture complete the permission and testing work in time. Chainlink’s dashboard provides the cutoff and migration destination, but it does not publish a network-wide readiness figure or an extension plan.