<p>Accessing any runtime information (including current slot) should not be possible in the validator by design. The reason is that transaction validity needs to be deterministic on construction. The only reason a transaction cannot be executed afterwards would be, if a UTXO was already consumed or the slot is outside of <code>txInfoValidRange</code> (as explained <a href="https://youtu.be/Lk1eIVm_ZTQ?t=727" rel="nofollow noreferrer">in this Youtube video</a>).</p>
<p>There might be other use cases, but making sure expired oracle data isn't consumed anymore could also be achieved by deactivating an oracle (which would require the oracle contract to support it). And also it is in the best interest of the party creating a transaction to make sure only trustworthy oracle data is consumed.</p>

CC BY-SA 4.0
2021-05-16T09:12:04.367Z
Does this mean that there is no way other than putting the burden on the oracle's users to check for expiration? The users may not even know what's the appropriate update-cycle for the data they want.

As an oracle provider, I would know about the reliability of my data source. And I might want to set an expiration date in case my network/blockchain access is broken, etc.
Similarly, SSL certificates also have an expiration date because it is a reasonable default: "not doing anything" means automatically invalidated. This is more secure because it removes the "zombies".
thebrandre
CC BY-SA 4.0
2021-05-16T18:36:47.120Z
Users of an oracle should be able to acquire this information about an oracle. After all you really have to trust an oracle, so the provider should be as transparent as possible.
The oracle could also provide an expiration Slot in it's Datum and only validate transactions that are valid before that expiration (according to txInfoValidRange). The user then needs to restrict transaction validity to a specific slot range.
tobxy123
CC BY-SA 4.0
2021-05-15T22:48:02.483Z
2021-05-16T23:14:45.497Z
2021-05-16T23:14:45.497Z
tobxy123
<p>At the time the Plutus validator script runs, the transaction is not yet part of the blockchain. But the targeted slot of a transaction is known when a node processes the script. Is it possible to access the target slot inside the validator script?</p>
<ul>
<li><p>The context of a validator script <a href="https://github.com/input-output-hk/plutus/blob/04ffe9084aa8c6fc5f21fc5ca3d0d68f299665b1/plutus-ledger-api/src/Plutus/V1/Ledger/Contexts.hs" rel="noreferrer">Plutus.V1.Ledger.Contexts.ScriptContext</a> gives access to the transaction where <code>txInfoValidRange</code> may provide upper/lower bounds of the slot. This, however, requires that a <a href="https://github.com/input-output-hk/plutus/blob/04ffe9084aa8c6fc5f21fc5ca3d0d68f299665b1/plutus-ledger/src/Ledger/Constraints/OnChain.hs" rel="noreferrer">Ledger.Constraints.mustValidateIn</a> constraint has been specified when the transaction was submitted (as done in <a href="https://github.com/input-output-hk/plutus-pioneer-program/blob/36084859defd87c6f13eb166ec64f0d6c6db1242/code/week03/src/Week03/Vesting.hs" rel="noreferrer">this example</a>).</p>
</li>
<li><p>I understand that it is considered to be bad practice for a Plutus validator script to depend on the state of the whole blockchain or unpredictable input such as the target slot because it limits verification/testing possibilities.</p>
</li>
</ul>
<p>Nevertheless, there might be plenty of good use cases for using the current slot; for example, an oracle might check if its data is expired and does not want to enforce its users to provide an upper limit in the <code>mustValidateIn</code> constraint.</p>

<plutus>
How to access the current slot in a Plutus validator script?
# How to access the current slot in a Plutus validator script?

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

At the time the Plutus validator script runs, the transaction is not yet part of the blockchain. But the targeted slot of a transaction is known when a node processes the script. Is it possible to access the target slot inside the validator script?

* The context of a validator script [Plutus.V1.Ledger.Contexts.ScriptContext](https://github.com/input-output-hk/plutus/blob/04ffe9084aa8c6fc5f21fc5ca3d0d68f299665b1/plutus-ledger-api/src/Plutus/V1/Ledger/Contexts.hs) gives access to the transaction where `txInfoValidRange` may provide upper/lower bounds of the slot. This, however, requires that a [Ledger.Constraints.mustValidateIn](https://github.com/input-output-hk/plutus/blob/04ffe9084aa8c6fc5f21fc5ca3d0d68f299665b1/plutus-ledger/src/Ledger/Constraints/OnChain.hs) constraint has been specified when the transaction was submitted (as done in [this example](https://github.com/input-output-hk/plutus-pioneer-program/blob/36084859defd87c6f13eb166ec64f0d6c6db1242/code/week03/src/Week03/Vesting.hs)).
* I understand that it is considered to be bad practice for a Plutus validator script to depend on the state of the whole blockchain or unpredictable input such as the target slot because it limits verification/testing possibilities.

Nevertheless, there might be plenty of good use cases for using the current slot; for example, an oracle might check if its data is expired and does not want to enforce its users to provide an upper limit in the `mustValidateIn` constraint.

**Tags:** plutus

---

## 1 answers

### Answer by username_1 on 2021-05-15. Score: 9

Accessing any runtime information (including current slot) should not be possible in the validator by design. The reason is that transaction validity needs to be deterministic on construction. The only reason a transaction cannot be executed afterwards would be, if a UTXO was already consumed or the slot is outside of `txInfoValidRange` (as explained [in this Youtube video](https://youtu.be/Lk1eIVm_ZTQ?t=727)).

There might be other use cases, but making sure expired oracle data isn't consumed anymore could also be achieved by deactivating an oracle (which would require the oracle contract to support it). And also it is in the best interest of the party creating a transaction to make sure only trustworthy oracle data is consumed.

> **Comments:**
> **username_0**: Does this mean that there is no way other than putting the burden on the oracle's users to check for expiration? The users may not even know what's the appropriate update-cycle for the data they want.  As an oracle provider, I would know about the reliability of my data source. And I might want to set an expiration date in case my network/blockchain access is broken, etc. Similarly, SSL certificates also have an expiration date because it is a reasonable default: "not doing anything" means automatically invalidated. This is more secure because it removes the "zombies".  
> **username_1**: Users of an oracle should be able to acquire this information about an oracle. After all you really have to trust an oracle, so the provider should be as transparent as possible. The oracle could also provide an expiration Slot in it's Datum and only validate transactions that are valid before that expiration (according to txInfoValidRange). The user then needs to restrict transaction validity to a specific slot range.  

---

