<p>If &quot;too many transactions want to consume the oracle eUTxO&quot;, you can implement a deadline and after deadline the oracle's utxo is no longer usable(or consumable) and can only be updated by oracle operator.</p>

CC BY-SA 4.0
2022-01-24T10:08:16.530Z
2022-01-24T23:08:28.347Z
2022-01-24T23:08:28.347Z
Tuvshintsenguun
<p>After <a href="https://github.com/cardano-foundation/CIPs/pull/159" rel="nofollow noreferrer">CIP-31</a> is implemented, none of this will be an issue.</p>
<p>This Cardano Improvement Proposals adds what is called &quot;reference UTxOs&quot; which are read-only. So if the Oracle provider has write access and everyone else only has read access, then the Oracle will never have anyone to collide with other than herself.</p>

CC BY-SA 4.0
2022-01-24T23:39:09.470Z
2022-01-24T23:39:09.470Z
Mitchell Turner
<p>In the Plutus Pioneer example in lecture 6, the oracle's UTxO is identified by an NFT. Any transaction that wants to consume this, whether it be a transaction wanting to access the information in the oracle, or whether it be a transaction created by the oracle provider to update the value, would first find the UTxO by looking for the NFT.</p>
<p>If another transaction has consumed the oracle UTxO as an input, it must have created a new oracle UTxO as an ouput. This new UTxO may have the the same Datum, or an updated Datum depending on the reason for consumption, but as part of the transaction constraints, it must also contain the NFT.</p>
<p>The next transaction that tries to consume the oracle UTxO will then find this new UTxO rather than the previous one, as this is now where the NFT is sitting.</p>

CC BY-SA 4.0
2021-07-07T23:42:27.543Z
2021-07-07T23:42:27.543Z
Chrismo
<p>If they are consumed, the provider would just create new UTXOs from the fees they have collected.</p>
<p>Keep in mind, an oracle would have to consume all of its UTXOs anyway to update the price.</p>

CC BY-SA 4.0
2021-05-27T21:07:57.480Z
The oracle validator in the Plutus Pioneer Program example is programmed in a way that a user has to provide the exact same datum (which contains the oracle information) at the new oracle eUTxO: `Use    -> traceIfFalse "oracle value changed"       (outputDatum == Just x)`

So the provider does not create a new eUTxO but ensures through the validator that the consumer does.
Johannes Sirsch
CC BY-SA 4.0
2021-05-27T21:14:05.023Z
That an oracle would have to consume its own (or by a user) provided eUTxO is exactly the problem that I am stating in the question. I'm wondering if the oracle provider could often be to late because someone else submitted a transaction for use first.
Johannes Sirsch
CC BY-SA 4.0
2021-05-27T21:18:20.930Z
If an oracle provides multiple eUTxOs, it can update the provided values one by one. So there is no need to do that all at once. And because of the same reasons, that I'm discussing here in this question, I doubt that an oracle provider can guarantee that all oracle eUTxO (if he provides multiple) datum values will always be in sync.
Johannes Sirsch
CC BY-SA 4.0
2021-05-27T12:35:08.677Z
2021-05-27T12:35:08.677Z
Marek Mahut - StakeNuts
<p>After reading the question <a href="https://cardano.stackexchange.com/questions/722/general-approach-for-allowing-multiple-smart-contract-transactions-per-block">General approach for allowing multiple smart contract transactions per block</a> I'm wondering how an oracle can guarantee update rates respectively uptime.<br></p>
<p>If too many transactions want to consume the oracle eUTxO, wouldn't this prevent the oracle provider itself from calling its update endpoint because the eUTxO will often be consumed before he can do it?</p>

<smart-contract><oracles>
How can an oracle guarantee certain update rates respectively uptime?
# How can an oracle guarantee certain update rates respectively uptime?

(Asked by: username_0 on 2021-05-27)

After reading the question [General approach for allowing multiple smart contract transactions per block](https://cardano.stackexchange.com/questions/722/general-approach-for-allowing-multiple-smart-contract-transactions-per-block) I'm wondering how an oracle can guarantee update rates respectively uptime.

If too many transactions want to consume the oracle eUTxO, wouldn't this prevent the oracle provider itself from calling its update endpoint because the eUTxO will often be consumed before he can do it?

**Tags:** smart-contract, oracles

---

## 4 answers

### Answer by username_1 on 2022-01-24. Score: 1

If "too many transactions want to consume the oracle eUTxO", you can implement a deadline and after deadline the oracle's utxo is no longer usable(or consumable) and can only be updated by oracle operator.


---

### Answer by username_2 on 2022-01-24. Score: 0

After [CIP-31](https://github.com/cardano-foundation/CIPs/pull/159) is implemented, none of this will be an issue.

This Cardano Improvement Proposals adds what is called "reference UTxOs" which are read-only. So if the Oracle provider has write access and everyone else only has read access, then the Oracle will never have anyone to collide with other than herself.


---

### Answer by username_3 on 2021-07-07. Score: 0

In the Plutus Pioneer example in lecture 6, the oracle's UTxO is identified by an NFT. Any transaction that wants to consume this, whether it be a transaction wanting to access the information in the oracle, or whether it be a transaction created by the oracle provider to update the value, would first find the UTxO by looking for the NFT.

If another transaction has consumed the oracle UTxO as an input, it must have created a new oracle UTxO as an ouput. This new UTxO may have the the same Datum, or an updated Datum depending on the reason for consumption, but as part of the transaction constraints, it must also contain the NFT.

The next transaction that tries to consume the oracle UTxO will then find this new UTxO rather than the previous one, as this is now where the NFT is sitting.


---

### Answer by username_4 on 2021-05-27. Score: 0

If they are consumed, the provider would just create new UTXOs from the fees they have collected.

Keep in mind, an oracle would have to consume all of its UTXOs anyway to update the price.

> **Comments:**
> **username_0**: The oracle validator in the Plutus Pioneer Program example is programmed in a way that a user has to provide the exact same datum (which contains the oracle information) at the new oracle eUTxO: `Use    -> traceIfFalse "oracle value changed"       (outputDatum == Just x)`  So the provider does not create a new eUTxO but ensures through the validator that the consumer does.  
> **username_0**: That an oracle would have to consume its own (or by a user) provided eUTxO is exactly the problem that I am stating in the question. I'm wondering if the oracle provider could often be to late because someone else submitted a transaction for use first.  
> **username_0**: If an oracle provides multiple eUTxOs, it can update the provided values one by one. So there is no need to do that all at once. And because of the same reasons, that I'm discussing here in this question, I doubt that an oracle provider can guarantee that all oracle eUTxO (if he provides multiple) datum values will always be in sync.  

---

