[AztecBot]

Closes AztecProtocol/aztec-claude#2425

Problem

ScheduledValueChange::get_time_horizon treats any pending scheduled change as a bound on how long the value read at the anchor block stays current, clamping the horizon to timestamp_of_change - 1. It does so even when the scheduled post equals pre, i.e. the change does not move the value. That state is produced by the documented cancellation mechanism (scheduling the current value) and by any idempotent setter such as ContractInstanceRegistry::update re-applying the class a contract already runs.

Because the private kernel folds the registry entry's horizon into expiration_timestamp for every private call to that contract, a cancelled or idempotent update pins every caller's deadline to the phantom instant for a full delay period. As the anchor approaches it, the inclusion window shrinks to zero: at anchor == timestamp_of_change - 1 the kernel emits expiration_timestamp == anchor_block_timestamp, which the rollup rejects for every later block.

Fix

In get_time_horizon, take the "no change ahead" branch (anchor_block_timestamp + minimum_delay) when self.pre == self.post. Such a change cannot alter the current value, so the earliest a different value can take effect is bounded by minimum_delay, exactly as when no change is pending. The method gains a T: Eq bound; its caller compute_delayed_public_mutable_time_horizon already requires T: Eq.

The clamp for a genuine pending change (pre != post) is unchanged. Which of pre or post a read returns (get_current_at) is unchanged.

Not covered

A contract that has never been updated has the stored class id 0, which the kernel reads as "use the original class". Cancelling that contract's first update needs update(original class), which stores (0, original, toc). The two values mean the same class but are not equal, so the clamp still applies. This is safe (the horizon is too early, never too late). Covering it needs a kernel-level comparison that maps 0 to the original class id.

Scope and cost

• Private kernel VKs change for private_kernel_init, private_kernel_inner and their batched variants: +5 ACIR opcodes per private call. private_kernel_reset_tail is unchanged.
• Genesis does not move. The protocol contracts compile to identical bytecode with and without the change.

Tests (red → green)

• types: test_get_time_horizon_change_to_same_value_in_near_future asserts the horizon is anchor + minimum_delay and checks the existing horizon invariants. Fails without the fix (returns timestamp_of_change - 1).
• private_kernel_lib (private_kernel_init), driven through the real registry hint with a rebuilt public-data tree:
  • expiration_timestamp_not_constrained_by_pending_contract_update_to_same_class: a change to the class the contract already runs at anchor + 1 yields expiration_timestamp == anchor + DEFAULT_UPDATE_DELAY - 1. Fails without the fix (emits anchor).
  • expiration_timestamp_constrained_by_pending_contract_update: control pinning that a genuine pending update at anchor + 1 still collapses the deadline to anchor.

The patch applies to next @ 551aa413aec with no changes beyond a 3-line hunk offset. Full types / private_kernel_lib suites and nargo fmt --check passed on the same change against the private mirror of next; CI covers this branch.

Labeled port-to-v6.

---

Created by claudebox · group: slackbot · requested by Mike (@iAmMichaelConnor) · Slack thread

[iAmMichaelConnor]

I'll nurse the required ports to the various branches