Chainlink feeds for Cardano via Gummiworm

Chainlink is the dominant decentralized oracle network on Ethereum, providing tamper-resistant price feeds, verifiable randomness, and other real-world data to smart contracts. This article describes how existing Chainlink infrastructure can be deployed inside a Gummiworm EVM head, and how the resulting data feeds can be published to Cardano smart contracts via Gummiworm’s oracle mechanism.

The key motivation: Cardano lacks a mature decentralized oracle ecosystem comparable to Chainlink’s. Gummiworm’s EVM support creates a path for existing Chainlink operators to serve Cardano with minimal changes to their existing infrastructure, while Cardano dApps gain access to battle-tested oracle feeds.

Chainlink OCR background

Chainlink’s Off-Chain Reporting protocol (OCR) is designed to minimize on-chain transaction costs. Instead of each node independently submitting a price update on-chain, OCR nodes communicate peer-to-peer to reach consensus off-chain. A single designated transmitter then submits one on-chain transaction carrying an aggregated report signed by a threshold of participating nodes.

The on-chain aggregator contract verifies the aggregate signature against a registered set of node public keys, records the new round’s price, and distributes LINK token payments to participating nodes from a pre-funded pool.

This design is well-suited to a Gummiworm head: the aggregation happens off-chain or as a fast, cheap EVM transaction inside the head, and the L1 publishing step produces exactly the oracle utxo that Cardano contracts need.

Deploying the feed

A Chainlink feed operator deploys the standard Chainlink aggregator contracts into the Gummiworm EVM head exactly as they would deploy to any EVM chain. The only difference is that the RPC URL points at the Gummiworm head’s JSON-RPC endpoint.

To fund node payments, the feed operator deposits LINK tokens into the head. LINK is a Cardano native token in this setting — it is accessible to the aggregator contract via the multi-token precompile described in EVM as L2. The aggregator contract’s payment logic runs unchanged inside the EVM; node operators receive L2 LINK and can withdraw to their preferred Cardano L1 address using the bridge precompile whenever they choose.

Node operator configuration

Chainlink node operators configure their OCR jobs to target the Gummiworm head:

• The OCR contractAddress is the aggregator contract deployed in the EVM head
• The chainID is the Gummiworm head’s configured EVM chain ID
• The RPC endpoint is the Gummiworm head’s JSON-RPC endpoint

The OCR off-chain peer-to-peer consensus process is unchanged. Nodes communicate directly with each other, agree on the latest price, and the transmitter calls transmit() on the aggregator contract as a normal EVM transaction. From the node software’s perspective, the Gummiworm head is simply another EVM chain.

Because the Gummiworm head processes EVM transactions with sub-second latency and negligible fees, node operators can submit price updates to the L2 aggregator far more frequently than is economical on Ethereum mainnet, allowing tighter heartbeat intervals and lower deviation thresholds. However, the rate at which updated prices become visible to Cardano L1 contracts is bounded by Gummiworm’s settlement frequency and Cardano’s block time — oracle utxo updates reach L1 on the order of minutes, not milliseconds. For most price feed use cases this is acceptable, but latency-sensitive applications should account for it.

Publishing to Cardano L1

After the aggregator contract records a new price round, the oracle data needs to be made available to Cardano smart contracts. This is done using Gummiworm’s oracle mechanism, described in Oracles.

An oracle publisher — which may be the feed operator, a node operator, or an automated Gummiworm node component — submits a transaction request that:

1. Calls latestRoundData() on the Chainlink aggregator contract to read the latest aggregated price
2. Calls the bridge precompile to produce an L1-bound output to the head’s native script address, with the oracle price packed into the oraclePayload datum field

The resulting utxo on Cardano L1 contains the Chainlink price data and an authentication token (deposited into the head by the feed operator in advance). Any Cardano smart contract can reference this utxo as a price feed using Cardano’s standard reference input mechanism.

Cardano contracts verify authenticity in the same way as any other Gummiworm oracle: by checking for the presence of the feed operator’s authentication token in the utxo.

The update cycle

In steady state, a price feed operates as follows:

1. Chainlink OCR nodes observe prices off-chain and reach consensus
2. The transmitter submits the aggregated report as an EVM transaction to the Gummiworm head
3. The aggregator contract verifies the report, records the new round, and distributes LINK payments to nodes
4. The oracle publisher submits an EVM transaction reading the new price and calling the bridge precompile to produce an L1-bound oracle output
5. Gummiworm includes this output in the next settlement transaction on Cardano
6. The oracle utxo appears on Cardano L1, referenceable by any contract as a price feed
7. On the next update cycle, the publisher uses the internal deposit mechanism described in Oracles to refresh the oracle atomically within a single settlement, without waiting for a new external deposit

Steps 4–7 can be fully automated: the oracle publisher can be a Gummiworm node component that watches the aggregator contract for AnswerUpdated events (emitted when the consumer-facing answer changes) and automatically triggers oracle refresh.

Benefits

For Chainlink operators: existing node software, contracts, and tooling work unchanged. Operators access a new revenue stream by serving Cardano with marginal additional configuration. Lower per-update costs inside the Gummiworm head may allow more frequent updates and finer-grained feeds.

For Cardano developers: access to Chainlink’s established network of operators and data sources, consumed using Cardano’s standard reference input pattern. No new oracle infrastructure or trust assumptions beyond what Gummiworm already provides.

For the broader ecosystem: demonstrates EVM composability as a bridging mechanism — not just for running EVM contracts natively, but for connecting the wider Ethereum application ecosystem to Cardano without requiring those applications to be rewritten.