Tempo v1.5.2 ships with a critical fee-recipient deprecation deadline, payload builder correctness fixes for AMM haircut accounting, and cleaner reorg handling by removing AA 2D transaction re-injection.

> impact

Tempo v1.5.2 landed this week with three notable changes that touch block building, transaction pool internals, and validator configuration. First, a bug fix in commit #3294 by Federico Gimenez corrects the best-payload fee comparison logic to properly account for AMM haircut deductions. Previously, the payload selection algorithm compared gross fees without subtracting the AMM haircut, which meant the builder could rank payloads incorrectly—choosing a payload that looked more profitable on paper but yielded less after deductions. The fix ensures net-fee-after-haircut is the comparison basis, directly improving block building profitability accuracy. Second, PR #3488 by Arsenii Kulikov removes the account abstraction (AA) 2-dimensional transaction re-injection mechanism that previously fired during chain reorganizations. The old behavior re-injected AA transactions into the mempool along two axes (nonce and validation context) whenever a reorg occurred, adding complexity and edge-case bugs to pool management. By removing this path, Tempo simplifies its reorg recovery flow and aligns AA transaction handling with the same single-pass re-injection strategy used for standard transactions. Node operators who had built monitoring or tooling around the previous AA reorg behavior should verify their setups still behave as expected after upgrading. Third—and most urgent for validators—the `--consensus.fee-recipient` CLI flag is now deprecated and will be fully removed in approximately two weeks. Fee-recipient configuration must be migrated to the on-chain Validator Config v2 contract before that deadline. The release also introduces the new `tempo_forkSchedule` RPC endpoint for querying upcoming fork activations, and includes additional mempool and validation hardening improvements that tighten transaction acceptance rules.

> Try this now

try this

# Migrating fee-recipient config to the on-chain Validator Config v2 contract
# before the --consensus.fee-recipient flag is removed (~2 weeks from now).
#
# Step 1: Confirm you're running Tempo v1.5.2+
# $ tempo --version
# tempo/v1.5.2-...
#
# Step 2: Query the new fork schedule endpoint to verify your node
# recognizes upcoming changes (useful for sanity-checking connectivity).
# $ curl -s -X POST http://localhost:8545 \
#   -H 'Content-Type: application/json' \
#   -d '{"jsonrpc":"2.0","method":"tempo_forkSchedule","params":[],"id":1}' | jq .
# You should see a JSON response listing scheduled fork activations.
#
# Step 3: Set your fee recipient on-chain via the ValidatorConfigV2 contract.
# Below is an ethers.js v6 example — adapt the RPC URL and signer to your setup.
#
# import { ethers } from 'ethers';
#
# const VALIDATOR_CONFIG_V2_ADDRESS = '0x<YourNetworkValidatorConfigV2Address>';
#
# // Minimal ABI — only the setFeeRecipient function
# const abi = [
#   'function setFeeRecipient(address recipient) external'
# ];
#
# const provider = new ethers.JsonRpcProvider('http://localhost:8545');
# const signer   = new ethers.Wallet(process.env.VALIDATOR_PRIVATE_KEY, provider);
# const config   = new ethers.Contract(VALIDATOR_CONFIG_V2_ADDRESS, abi, signer);
#
# const tx = await config.setFeeRecipient('0xYourFeeRecipientAddress');
# console.log('Tx submitted:', tx.hash);
# const receipt = await tx.wait();
# console.log('Confirmed in block:', receipt.blockNumber);
#
# Step 4: Once confirmed on-chain, remove the deprecated flag from your
# node startup command or systemd unit file:
#   BEFORE: tempo --consensus.fee-recipient 0xYourFeeRecipientAddress ...
#   AFTER:  tempo ...
#
# Step 5: Restart your node and verify fee-recipient is being read from
# the contract by checking builder logs for:
#   "Fee recipient sourced from ValidatorConfigV2"
#
# If you see a deprecation warning like:
#   "WARN: --consensus.fee-recipient is deprecated and will be removed"
# that means the flag is still present in your config — remove it now
# to avoid a hard failure when the flag is deleted in ~2 weeks.