Overview

Identified by Christos - after merging of #608 , transactions would get stuck in the mempool and never enter a block:

Problem

Transactions that pass ZK proof/signature validation (well_formed()) but whose guaranteed part would fail against the current ledger state get stuck in the mempool indefinitely.

The root cause is a validation gap between pool admission and block authoring:

1. do_validate_transaction (pool entry/revalidation) only checks well_formed() — ZK proofs and signatures — but not whether the guaranteed part can actually be applied to the current ledger state
2. get_verified_transaction writes Ok(()) to the soft cache after well_formed() passes — so pool revalidation always sees a cached success, even though pre_dispatch keeps rejecting the tx
3. Result: transactions cycle indefinitely: "ready" → pre_dispatch reject → soft cache hit → still "ready" → repeat

Solution

Three targeted changes in ledger/src/versions/common/mod.rs, all focused on making do_validate_transaction the single owner of the soft cache:

1. Remove soft cache write from get_verified_transaction — the soft cache should only be written by do_validate_transaction, which has full context (including the apply result) to decide what to cache

2. Add dry-run apply() in do_validate_transaction — after well_formed() passes, dry-run the transaction against current ledger state. Only cache Ok(()) on success (Success or PartialSuccess). Failures are not cached, so the tx will be fully re-checked on next revalidation

3. Invalidate soft cache on entering do_validate_guaranteed_execution — always evict the soft cache entry when entering pre_dispatch, regardless of outcome. This forces the pool to fully re-validate the transaction after any block authoring attempt

Flow after fix

1. Tx enters pool → do_validate_transaction: well_formed() + apply() → if both pass, cache Ok(()) in soft cache
2. Pool revalidation → soft cache hit → Ok(()) → stays "ready"
3. Block author tries to include tx → do_validate_guaranteed_execution (pre_dispatch):

• Immediately invalidates soft cache entry (regardless of outcome)
• Does strict validation (apply check with real block context)

4. Pool revalidation after block → soft cache miss → full re-check (well_formed() + apply() against current state)

• If tx still valid: re-cached, stays in pool
• If tx now invalid: rejected, removed from pool

🗹 TODO before merging

• Ready

📌 Submission Checklist

• Changes are backward-compatible (or flagged if breaking)
• Pull request description explains why the change is needed
• Self-reviewed the diff
• I have included a change file, or skipped for this reason:
• If the changes introduce a new feature, I have bumped the node minor version
• Update documentation (if relevant)
• Updated AGENTS.md if build commands, architecture, or workflows changed
• No new todos introduced

🧪 Testing Evidence

Please describe any additional testing aside from CI:

• Additional tests are provided (if possible)

🔱 Fork Strategy

• Node Runtime Update
• Node Client Update
• Other:
• N/A

Links