.validTo(<currentPOSIXTime>) requires minimum delay time which is not mentioned by lucid, resulting giving txHash but actually failing the transaction onchain.

[snehasishpaul]

const slot = lucid.currentSlot();
const POSIXTime = lucid.utils.slotToUnixTime(slot);

await lucid.newTx()
.collectFrom([utxo], redeemer)
.payToAddress(buyerAddr, utxo.assets)
.payToAddress(sellerAddr, { lovelace: PRICE + utxoLovelace })
.attachSpendingValidator(escrowScript)
.validTo(Number(BigInt(POSIXTime)))

If I add [ .validTo(Number(BigInt(POSIXTime))) ]
This Transaction passes the validation of TIME-CHECK of my Escrow Smart Contract and txHash is generated.
BUT THE Transaction do not reflect onchain as it fails when submitting. But Lucid doesn't give any error, instead it gives TxHash and positive response.

BUT IF I ADD [ .validTo(Number(BigInt(POSIXTime) + 60000n)) ]
This transaction also succeeds as well as the Transaction is actually reflected on chain which denotes that the transaction has been executed successfully.

The Problem is when I am giving the current Posixtime, Lucid takes time to convert everything and actually execute the code onchain. So when the transcation is actually executed onchain, the validity time already passed and its in history, and cardano doesnt allow transaction to be executed which has --invalid-hereafter < actual current Posixtime.

Lucid needs to FIX this as this is a potential BUG for Validity check with Deadline PosixTime.
Lucid should accomodate the current PosixTime in their code when actually submitting the transaction onchain
OR
Lucid should expose MINIMUM DELAY REQUIRED time that we need to add when doing transaction through LUCID.

[alessandrokonrad]

I don't think this is a Lucid issue per se. A block on Cardano is generated about every 20 seconds, then you have to take network delay and queued txs into consideration. It's very unlikely the current time passes (but possible). Just add a delay/threshold like you did in your second example. Verifying off-chain if the tx will actually make it with that validity interval is impossible, because you don't know when the next block is generated, it could be that a couple spos miss their blocks and so the next block is in 60s for instance. I can't check that prior.

Also you could just do:

.validTo(Date.now() + 60000)

lucid.currentSlot() is deprecated/no longer exists since 0.20

[AIQUANT3]

I don't think this is a Lucid issue per se. A block on Cardano is generated about every 20 seconds, then you have to take network delay and queued txs into consideration. It's very unlikely the current time passes (but possible). Just add a delay/threshold like you did in your second example. Verifying off-chain if the tx will actually make it with that validity interval is impossible, because you don't know when the next block is generated, it could be that a couple spos miss their blocks and so the next block is in 60s for instance. I can't check that prior.

Also you could just do:

.validTo(Date.now() + 60000)
lucid.currentSlot() is deprecated/no longer exists since 0.20

But when I did it in On-Chain. It takes the Slot and that Slot converted into POSIX Time So, it takes the Current Time of the transaction. So, in the Off-Chain part did that time should work. Rather than not give the future time for do the transaction.

What I think that @snehasishpaul described it is an issue.

Suppose in @snehasishpaul above code ".validTo(Number(BigInt(POSIXTime)))" if there is a deadline to be matched and I have to send the current POSIX time with Lucid with 1 Min delay in above, So, the actual deadline becomes (Deadline - 1 Min).
If 3:00 PM is the deadline, I have to submit at 2:59 PM or else it should not submit the Tx.