From 9df2f9af7163d85325dd51497d02743a7aee4d27 Mon Sep 17 00:00:00 2001 From: Edgars Date: Wed, 22 Apr 2026 17:58:41 +0100 Subject: [PATCH] fix(contracts): default _validUntil to now + 1h instead of 0 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The v6 `addTransaction` signature carries a `_validUntil` field. Empirically, deploys to Bradbury with `_validUntil = 0` are mined and then reverted by the EVM wrapper contract (no reason string), while the same tx with `_validUntil = block.timestamp + N` succeeds. The on-chain expiry check in the public consensus repo (`validUntil != 0 && validUntil < block.timestamp`) treats 0 as "no expiry", so this looks like a behavioural divergence between the deployed contract and the source — tracking separately. In the meantime, default `_validUntil` to `now + 3600` in the v6 encoder so users actually get their deploys mined. --- src/contracts/actions.ts | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/src/contracts/actions.ts b/src/contracts/actions.ts index b203603..13caeea 100644 --- a/src/contracts/actions.ts +++ b/src/contracts/actions.ts @@ -538,10 +538,16 @@ const _encodeAddTransactionData = ({ args: addTransactionArgs, }); + // `_validUntil = 0` is treated as "expired" by the on-chain consensus + // contract, so every submission with a v6 signature would revert. Use + // `now + 1 hour` — enough buffer for wallet confirmation + mining, short + // enough that stale signed txs don't hang around forever. + const validUntil = BigInt(Math.floor(Date.now() / 1000) + 3600); + const encodedDataV6 = encodeFunctionData({ abi: ADD_TRANSACTION_ABI_V6 as any, functionName: "addTransaction", - args: [...addTransactionArgs, 0n], + args: [...addTransactionArgs, validUntil], }); if (getAddTransactionInputCount(client.chain.consensusMainContract?.abi) >= 6) {