<p>At hydra we do have a protocol which ensures something is not happening before some given deadline. The system would need to submit a transaction to set the deadline (<code>txA</code>) and another transaction once this deadline passed <code>txB</code>. The deadline is determined from a <code>txA</code>s upper validity bound given as slot <code>sA</code> . Let's assume that deadline is at slot <code>sT</code> and our scripts will ensure that <code>txB</code>s lower validity bound <code>sB</code> is <code>sB &gt; sT</code>.</p>
<p>How would should our application determine the &quot;right time&quot; to publish transaction <code>txA</code> and <code>txB</code>?</p>
<p>We would need to know about current time (in slots) to kick things off by determining <code>sA</code> and <code>sT</code>. But also to know when <code>sB</code> is to not have a failing <code>txB</code>. So far we have tried two approaches:</p>
<ol>
<li>Use <code>getLocalChainTip</code> from <code>cardano-api</code> to get the slot of the current chain tip. This seems to be the slot of the last seen block and hence up to <code>~20</code> seconds in the past. Which is fine for <code>txA</code>, but problematic for <code>txB</code> as we would need to know that offset for correctly determining sB .</li>
<li>Use <code>wallclockToSlot</code> from <code>ouroboros-consensus</code> to get the current slot given wall clock. This gives us the projected, actual slot (even hard-fork and era history compatible?) so it's better in determining slots <code>sA</code> and <code>sB</code>. However, we get a ledger error when submitting <code>txB</code> as the ledger seems to think it's still slot of the last block (like option 1). For example: <code>ApplyTxError [UtxowFailure (UtxoFailure (FromAlonzoUtxoFail (OutsideValidityIntervalUTxO (ValidityInterval {invalidBefore = SJust (SlotNo 220), invalidHereafter = SNothing}) (SlotNo 211))))]</code> when wall clock time and the <code>cardano-node</code> logs confirm was around slot <code>220</code> and the last block was forged at slot <code>211</code>.</li>
</ol>
<p>Any other options or ideas how to handle this in a properly integrated, non-hacky fashion?</p>

CC BY-SA 4.0
2022-07-20T11:10:16.680Z
What is the scale of difference in time between `sA` and `sT`?
Fermat
CC BY-SA 4.0
2022-07-20T11:16:52.510Z
Does this difference have bounds? Preferably, a lower one?
Fermat
CC BY-SA 4.0
2022-07-21T14:15:37.190Z
For this issue at hand here we can assume `sT - sA` to be sufficiently low, say `20` to `50` slots. (We have other problems of the period being too high and not being able to compute the POSIXTime equivalent as it's "past the horizon")
Sebastian Nagel
<cardano-node><ledger>
Handling time & slots in cardano-node clients
# Handling time & slots in cardano-node clients

(Asked by: username_0 on 2022-07-20)

At hydra we do have a protocol which ensures something is not happening before some given deadline. The system would need to submit a transaction to set the deadline (`txA`) and another transaction once this deadline passed `txB`. The deadline is determined from a `txA`s upper validity bound given as slot `sA` . Let's assume that deadline is at slot `sT` and our scripts will ensure that `txB`s lower validity bound `sB` is `sB > sT`.

How would should our application determine the "right time" to publish transaction `txA` and `txB`?

We would need to know about current time (in slots) to kick things off by determining `sA` and `sT`. But also to know when `sB` is to not have a failing `txB`. So far we have tried two approaches:

1. Use `getLocalChainTip` from `cardano-api` to get the slot of the current chain tip. This seems to be the slot of the last seen block and hence up to `~20` seconds in the past. Which is fine for `txA`, but problematic for `txB` as we would need to know that offset for correctly determining sB .
2. Use `wallclockToSlot` from `ouroboros-consensus` to get the current slot given wall clock. This gives us the projected, actual slot (even hard-fork and era history compatible?) so it's better in determining slots `sA` and `sB`. However, we get a ledger error when submitting `txB` as the ledger seems to think it's still slot of the last block (like option 1). For example: `ApplyTxError [UtxowFailure (UtxoFailure (FromAlonzoUtxoFail (OutsideValidityIntervalUTxO (ValidityInterval {invalidBefore = SJust (SlotNo 220), invalidHereafter = SNothing}) (SlotNo 211))))]` when wall clock time and the `cardano-node` logs confirm was around slot `220` and the last block was forged at slot `211`.

Any other options or ideas how to handle this in a properly integrated, non-hacky fashion?

**Tags:** cardano-node, ledger
> **Comments:**
> **username_1**: What is the scale of difference in time between `sA` and `sT`?  
> **username_1**: Does this difference have bounds? Preferably, a lower one?  
> **username_0**: For this issue at hand here we can assume `sT - sA` to be sufficiently low, say `20` to `50` slots. (We have other problems of the period being too high and not being able to compute the POSIXTime equivalent as it's "past the horizon")  

---

## 0 answers

