10 min read

Introducing the Cardano Open Oracle Protocol (COOP)

Introducing the Cardano Open Oracle Protocol (COOP)

The Cardano Open Oracle Protocol (COOP) is a set of technical guidelines that enables the publishing and consuming of off-chain data by Cardano smart contracts.

These data leverage the CIP-31 Reference Inputs introduced in Cardano’s Vasil hard fork. This enhancement allows a datum written to a single eUTXO to be read by multiple consumers without competing with each other for exclusive access to transaction output.

The guidelines are supported by an open-source reference implementation that will be made publicly accessible at https://github.com/mlabs-haskell/cardano-open-oracle-protocol/.

This post describes the COOP technical architecture. A previous technical update describes what an oracle is and what problems they are meant to solve.

Background

Software development of the COOP is led by MLabs with product direction provided by the Orcfax project which is implementing the COOP in its Cardano oracle service.

Orcfax oracles publish high-quality, structured data as Cardano eUTXO datum. It refers to these as “fact statements” to reflect their premium design over context-less data points. The same terminology is used within the COOP to described published data points.

Please note that the free and open-source COOP design and reference implementation only address the publication and consumption of data points as Cardano eUTXO datum. Oracle service providers willl integrate their own value-add features with COOP. For example the Orcfax oracle service has integrated high-quality data collection, validation, and archiving to deliver a comprehensive, Cardano-native oracle platform.

Design goals

The main design goals for the Cardano Open Oracle Protocol (COOP) are:

  1. Financial sustainability – minimize the cost and deposit needed to post, maintain, and use on-chain fact statements, providing opportunities to share costs amongst stakeholders.
  2. Data accessibility – minimize the probability of fact statements referenced by users not being available for their dApp transactions.
  3. Security – minimize the risk of exposure for the cryptographic keys used in verifying the authenticity of fact statements.

There is a trade-off between the first two goals. Optimizing for data accessibility tends to require more space on-chain—including older fact statements that may be referenced by users that are lagging in their synchronization of the blockchain—whereas financial sustainability includes reclaiming the eUTXO deposits for fact statements that are no longer needed on-chain. We seek a healthy balance between them.

Operating a Publisher service

In this oracle protocol, a Publisher is a trusted party that attests to the validity of fact statements and authorizes their publication on-chain using the Cardano Open Oracle Protocol (COOP).

Each fact statement is uniquely identified within a catalogue that the Publisher provides a search interface for. This can be used to determine the fact statement types made available by this Publisher, their publication frequency, and the fee charged per publication transaction. It also allows the data consumer to determine whether a given fact statement has already been published on-chain and is available to read for free as a CIP-31 Reference Input.

The catalogue of fact statements and its search interface are not in scope under COOP and will be developed by publishers to work alongside their own COOP implementation on their chosen technical infrastructure. For the purposes of this protocol, we assume that the user is able to obtain a fact statement ID from the Publisher via their catalogue search interface.

The core value that a COOP Publisher delivers is their guarantee that the fact statement which bears its digital signature is validated to be accurate and authentic. This means that unrelated third parties and counter parties can mutually trust this data to execute their shared smart contract logic, with potentially significant economic and/or social impacts at stake.

A token-based security model

The integrity of the COOP protocol rests on the reputation of the Publisher, its quality controls, and the security of the cryptographic keys used to authorize the publication of fact statements. If a publisher’s keys are compromised, then the provenance from the publisher is compromised for any fact statements published with those keys. Therefore, it is critical to ensure that publisher keys are managed securely in COOP.

We provide a novel token-based security mechanism in COOP. This design enables a publisher to mint ephemeral authorization tokens in a secure environment. These authorization tokens are then used by the publisher’s user-facing service to publish fact statements—one authorization token spent per publication. A publisher’s authorization tokens can only be minted with the publisher’s signature, so the presence of such a token in a published fact statement proves provenance from the publisher.

User interaction with a Publisher

The following interaction lies at the core of this design. It is between a user seeking to reference a given fact statement to interact with another on-chain application, and the COOP Publisher that is the authoritative source for that fact statement:

1. User inquiry. The user obtains the fact statement ID of interest from the Publisher’s online catalogue and determines its current publication status:

  • If the fact statement is currently published, the user may skip a publication request and proceed to reference the fact statement as desired, without further interaction with the Publisher.
  • Otherwise, the user requests a publication offer from the Publisher, indicating the fact statement ID and a payment input UTXO that they will use to pay for publication.

2. Publication offer. Upon receiving the user’s request, the Publisher constructs, validates, and returns to the user an authorized publish transaction with:

  • Payment input – an input from the user's wallet, containing payment. This must be the UTXO that the user identified in the original request.
  • Authorization input from Publisher – an input that contains an authorization token from the Publisher.
  • Fact statement output – an output locked under the publication deposit script, containing the requested fact statement value, contextual metadata, and the Publisher’s authorization token.
  • Payment output to Publisher – an optional output sent to the Publisher's wallet, containing a payment for the costs incurred to issue the fact statement. This feature enables financial sustainability by allowing COOP publishers to share their infrastructure costs with users, and optionally to generate a profit for a commercial business model.
  • Change output – an output sent to the user, containing any remaining balance of their original UTXO input payment.

3. User acceptance. Upon receiving the authorized publish transaction, the user adds her signature to the transaction and submits it to the blockchain. When the user references the fact statements in their dApp or smart contract, their code is responsible for verifying the authenticity of the Publisher’s authorization token.

Now there is an immutable Cardano transaction datum published on-chain that contains a fact statement verified by an authorization token from the Publisher and a signed receipt from its user.

4. Exclusive first user access. The fact statement output datum becomes available to the user’s smart contract, dApp, or Plutus script during the same block in which it is published. In other words, the business logic transaction can be triggered immediately after the fact statement publish transaction (if the user submitted it herself), without waiting for it to be confirmed on the blockchain.

This gives users willing to pay for first access to COOP fact statements a business advantage over users that only consume fact statements that have already been published in previous transactions.

5. Deposit reclamation. When a fact statement is no longer relevant, its deposit (Cardano requires minimum 2 ADA per UTXO) may be returned to the user that paid for the publish transaction.

Specifically, the fact statement output from the publish transaction is locked by a script that allows it, after its time-to-live (TTL) deadline, to be spent in a reclaim deposit transaction. This transaction burns the publisher’s authorization token and returns the remaining ADA back to that user. Therefore the funds locked in UTXO deposits are bounded and the only ongoing variable cost for fact statement publication is any applicable transaction fee for the publish transaction.

6. Downstream use in other dApps. Before the TTL for a fact statement expires it is available for free to any on-chain code as CIP-31 Reference Input datum. After the TTL expires and the deposit has been “garbage collected”,  the datum still remains reference-able indefinitely via full nodes and Cardano blockchain explorers. The Cardano blockchain contains the full history of all transactions and all outputs (spent or unspent) that have ever existed since the genesis block that started the blockchain.

The difference between a spent transaction output and an unspent transaction output (UTXO) is that every transaction can only spend or reference outputs that are unspent at the time of the transaction. Thus, an on-chain oracle feed is naturally partitioned into an active set of fact statements (contained in unspent transaction outputs) and an inactive set of archived fact statements. Only the active fact statements can be referenced by dApps.

Submitters and Consumers

Users play two different roles in a COOP interaction: firstly to request the publication of a fact statement and secondly to reference that fact it in the user’s smart contract or dApp. A user that requests and posts a fact statement is a Submitter (steps 1,2,3,5). A user that just reads the contents of a fact statement is called a Consumer (steps 4,6) .

Long-term data accessibility

The fact statement's time-to-live (TTL) can be set by a Submitter appropriate to its user demand, ideally for a lengthy period so that others users can expect that it will be available when they attempt to reference it. Multiple consumers of the same data type feeds can pool their funds in an escrow account that ensures payment for consistent feed updates and their long-term availability as an on-chain UTXO input.

On the other hand, user demand for something like a ADA/USD price feed is expected to drop off rapidly—e.g. an hour after publication, no user is expected to reference it as the current price. Thus, a TTL of one hour (perhaps even less) would be appropriate for this type of fact statement. In general, the TTL for a fact statement should be calibrated to its semantic domain and target audience.

In a subsequent version of the COOP, we will explore a mechanism to re-publish an archived fact statement back into the active set of fact statements, effectively reversing the fact statement's reclaim deposit transaction. Naively implemented, this feature can undermine the financial sustainability of the protocol by allowing users to avoid sharing the publication cost, or even to avoid paying the publisher at all, so more sophisticated on-chain logic will likely be required to mitigate/eliminate this risk.

Appendix 1: Key features introduced in the Vasil hard fork

This COOP design is made possible thanks to these key new features introduced in Cardano's Vasil hardfork combinator (HFC) event in September 2022:

  • Reference inputs (CIP-31) – Transactions can reference some of their inputs instead of consuming them, keeping those inputs intact for other transactions to consume or reference. Previously, transactions were required to consume their inputs, making those inputs unavailable to other transactions. This was referred to as the “concurrency problem” in pre-Vasil Cardano and was the primary blocker to launching fully permissionless oracle services on Cardano.
  • Inline datums (CIP-32) – Transaction outputs will be able to store their datums directly. Previously, transaction outputs could only store hashes of datums, with the actual datums stored in the transaction body's datum hash table. This incurred a significant burden on users, who would have to provide the datums corresponding to the datum hashes for the inputs used in their transactions. This burden translated into an infrastructure requirement for an off-chain index from datum hashes to datums for all UTXOs on the blockchain, to allow users to efficiently retrieve the datums they need to provide in their transactions. This burden is eliminated for transaction outputs with inline datums.
  • Reference scripts (CIP-33) – Inline scripts may be attached to transaction outputs, and subsequent transactions can reference those outputs to access their scripts and use them during validation. Previously, transactions had to include all of their scripts in their transaction bodies, bloating transaction sizes and blockchain space usage. With reference scripts, a dApp can optimize its space usage on-chain by efficiently reusing a set of general and stable scripts across multiple transactions.

Reference inputs are fundamentally important in the context of oracles, which are primarily concerned with the dissemination of information. Prior to reference inputs, oracle designs had to contend with exclusive consumption and mitigated the challenges of concurrent use by relying on off-chain coordination, redundant publication, and explicit re-publication of spent outputs. With reference inputs, oracles can publish information on-chain once and have users access that information concurrently and non-exclusively.

Reference inputs may limit our design flexibility with respect to sharing publication costs/deposits equitably across stakeholders—once information is published on-chain, and as long as it remains available on-chain, no restrictions or conditions may be placed on anyone's ability to reference it in their transactions.

This means that information from reference-input-based oracles is free to use after its first use. Freedom of information on the blockchain aligns with decentralization values and the movement to secure permissionless access to shared, open, consensus data. That said, the COOP design also allows for the introduction of sustainable business models for high-quality, boutique, and/or affordable data publication services.

Inline datums and reference scripts are tools that may be useful in pursuit of financial sustainability for the oracle protocol by reducing transaction costs and infrastructure requirements. They are not essential to the oracle design, but should prove valuable in practice.