<p>This is the flow from Playground to the onchain validator:</p>
<p><strong>Playground</strong> (grab) --&gt; <strong>endpoints</strong> --&gt; <strong>grab</strong> (offchain contract) --&gt; <strong>validator</strong> (onchain).</p>
<p><strong>txInfoValidRange</strong> is set by <strong>grab</strong> (offchain contract) in the following expression:</p>
<p>[line 115-117]</p>
<pre><code>tx :: TxConstraints Void Void
tx = mconcat [Constraints.mustSpendScriptOutput oref unitRedeemer | oref &lt;- orefs] &lt;&gt;
             Constraints.mustValidateIn (from now)
</code></pre>
<p>where <code>Constraints.mustValidateIn (from now)</code> specifically establishes that the transaction being built must validate <strong>from now to the eternity</strong>. If you don't set this Constraint, the default <strong>txInfoValidRange</strong> (all the time) will set.</p>

CC BY-SA 4.0
2022-02-17T05:51:33.590Z
Ahh, that was the gap in my understanding. The off chain code runs first and sets the TxInfo ValidRange. The validator run onchain and validates the transaction submitted by the offchain code.
Eric H.
CC BY-SA 4.0
2022-02-11T18:34:52.170Z
2022-02-11T18:53:58.170Z
2022-02-11T18:53:58.170Z
kindofdev
<p>In lecture 3 of the Plutus Pioneer Program <a href="https://github.com/input-output-hk/plutus-pioneer-program/blob/79b0816b6f84f171c8f01073e5445033869c41b7/code/week03/src/Week03/Vesting.hs" rel="nofollow noreferrer">Vesting.hs</a>, I noticed that the example vesting give/ grab endpoints work by waiting a number of slots after the deadline. The script then checks <code>deadlineReached = contains (from $ deadline dat) $ txInfoValidRange info</code>.</p>
<p>However, <a href="https://plutus-pioneer-program.readthedocs.io/en/latest/pioneer/week3.html#txinfovalidrange" rel="nofollow noreferrer">these docs</a> for <code>txInfoValidRange</code> say that the default range is infinite. In the lecture video and in the playground, I don't see that we set the txInfoValidRange explicitly, so I assumed it was infinite, but that means a from range would never contain it.</p>
<p>I must be misunderstanding the linked documentation. At some point, the <code>txValidRange</code> must be getting set on the transactions submitted through the playground, otherwise, <code>deadlineReached</code> would always be false. I can't find where this default is being set though.</p>
<p>Is this set by Plutus clients? In this case, the Playground?</p>
<p>There is a related question <a href="https://cardano.stackexchange.com/questions/909/does-txinfovalidrange-adjust-as-time-continues-on/1916#1916">here</a>, but I understand the <code>contains</code> function. What I don't understand is <em>how</em> the <code>txInfoValidRange</code> is set.</p>

<plutus-pioneer-program><tx><txinfovalidrange>
Where is the txValidRange default value set?
# Where is the txValidRange default value set?

(Asked by: username_0 on 2022-02-11)

In lecture 3 of the Plutus Pioneer Program [Vesting.hs](https://github.com/input-output-hk/plutus-pioneer-program/blob/79b0816b6f84f171c8f01073e5445033869c41b7/code/week03/src/Week03/Vesting.hs), I noticed that the example vesting give/ grab endpoints work by waiting a number of slots after the deadline. The script then checks `deadlineReached = contains (from $ deadline dat) $ txInfoValidRange info`.

However, [these docs](https://plutus-pioneer-program.readthedocs.io/en/latest/pioneer/week3.html#txinfovalidrange) for `txInfoValidRange` say that the default range is infinite. In the lecture video and in the playground, I don't see that we set the txInfoValidRange explicitly, so I assumed it was infinite, but that means a from range would never contain it.

I must be misunderstanding the linked documentation. At some point, the `txValidRange` must be getting set on the transactions submitted through the playground, otherwise, `deadlineReached` would always be false. I can't find where this default is being set though.

Is this set by Plutus clients? In this case, the Playground?

There is a related question [here](https://cardano.stackexchange.com/questions/909/does-txinfovalidrange-adjust-as-time-continues-on/1916#1916), but I understand the `contains` function. What I don't understand is *how* the `txInfoValidRange` is set.

**Tags:** plutus-pioneer-program, tx, txinfovalidrange

---

## 1 answers

### Answer by username_1 on 2022-02-11. Score: 2 | Accepted answer

This is the flow from Playground to the onchain validator:
Playground (grab) --> endpoints --> grab (offchain contract) --> validator (onchain).
txInfoValidRange is set by grab (offchain contract) in the following expression:
[line 115-117]
tx :: TxConstraints Void Void
tx = mconcat [Constraints.mustSpendScriptOutput oref unitRedeemer | oref <- orefs] <>
             Constraints.mustValidateIn (from now)

where Constraints.mustValidateIn (from now) specifically establishes that the transaction being built must validate from now to the eternity. If you don't set this Constraint, the default txInfoValidRange (all the time) will set.

> **Comments:**
> **username_0**: Ahh, that was the gap in my understanding. The off chain code runs first and sets the TxInfo ValidRange. The validator run onchain and validates the transaction submitted by the offchain code.  

---

