fix(contracts): default _validUntil to now + 1h instead of 0#157
fix(contracts): default _validUntil to now + 1h instead of 0#157MuncleUscles merged 1 commit intomainfrom
Conversation
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.
|
Warning Rate limit exceeded
Your organization is not enrolled in usage-based pricing. Contact your admin to enable usage-based pricing to continue reviews beyond the rate limit, or try again in 1 minutes and 30 seconds. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Picks up genlayerlabs/genlayer-js#157 — the SDK now passes a future timestamp for _validUntil in v6 addTransaction calls, so deploys to Bradbury from the Studio frontend actually land instead of reverting inside the EVM wrapper with no reason string.
1 participant
Summary
The v6 `addTransaction` signature on the consensus contract carries a `_validUntil` field. The SDK was hardcoding `0n` for it.
Empirically on Bradbury, deploys with `_validUntil = 0` are mined and then reverted inside the EVM wrapper (plain `revert()` — no reason string). The same tx with `_validUntil = block.timestamp + N` succeeds end-to-end through GenLayer consensus.
The public consensus source (e.g. `phases/IdlenessPhase.sol`, `ActivationPhase.sol`, `FinalizationPhase.sol`) treats 0 as "no expiry" (`validUntil != 0 && validUntil < block.timestamp`), so this looks like a behavioural divergence between the deployed contract on Bradbury and the public source — I've flagged it separately with the contracts team. In the meantime, this patch unblocks users so their deploys actually land.
Default chosen: `now + 3600` (1 hour). Long enough for wallet confirmation and mining; short enough that stale signed txs don't hang around.
Evidence pair (Bradbury):
Unblocks the Studio frontend's runtime network selector (`genlayerlabs/genlayer-studio#1606`).
Test plan