[Trivial] Log decoded settlement tx to simulation log during /solve

[fleupold]

Description

I'd like to see how a non-winning, non-colocated solver would have settled a transaction in case they had won. I believe this is currently not possible (we only log the transaction when a solver was selected for winning). This information shouldn't be publicly available (solvers only want to commit to a solution if they win), but logging it for debugging purposes should be fine.

I only log the internalized representation, because this is the one that would make it on-chain. Since we simplified buffer accounting (solver takes the risk), we probably no longer need to look at uninternalized calldata.

Changes

• add a tx field to the simulation log

[claude]

Claude finished @fleupold's task in 1m 58s —— View job

---

Claude PR Review

• Read PR diff
• Inspect the changed file in context
• Check for redaction / sensitive-data concerns around logging the tx
• Post review

Summary

LGTM — small, well-scoped change that does exactly what the description says: adds transaction = ?transaction.internalized to the existing tracing::debug!("simulated settlement") call at crates/driver/src/domain/competition/solution/settlement.rs:187, so the simulated tx is now available in driver logs even for non-winning solvers.

Observations

• Correctness. transaction is SettlementTx and internalized is eth::Tx (crates/driver/src/domain/blockchain.rs:25). It already derives derive_more::Debug with access_list marked #[debug(ignore)], so the line will print from, to, value, input — the calldata is the meaningful "decoded" bit anyone investigating a non-winning solver would want. No risk of a stack-overflow / recursive-Debug pitfall.
• Coverage gap (intentional?) Only the internalized tx is logged, not uninternalized. For most debugging that's fine, but if the question is ever "would this solver's committed solution have settled", the uninternalized form is the canonical one. Worth a quick thought on whether to also log it (or swap to uninternalized).
• Log level / volume. This is at debug!, so prod won't be flooded by default. The input blob can be large (a few KB), so when debug is enabled on this target, each simulated settlement line grows substantially — acceptable trade-off for a debug log, just flagging.
• Sensitivity. Description notes solvers don't want non-winning settlements publicly exposed; debug-level driver logs are internal, so this is fine. Just make sure these logs don't leak into anything externally shipped/aggregated without redaction.
• Redundancy. simulator::RevertError's Display already includes the tx on revert (crates/simulator/src/lib.rs:129), so on a reverting simulation the tx will now appear twice (once here, once in the error). Harmless, just noting.

Nits

• Field-name suggestion: transaction = ?transaction.internalized reads slightly awkwardly. tx = ?transaction.internalized would be a touch clearer and keeps the log key shorter. Pure preference — feel free to ignore.

Nothing blocking. Ship it.
· Branch: log_tx_during_solve

[gemini-code-assist]

Code Review

This pull request adds the transaction field (specifically transaction.internalized) to the debug log during simulated settlement inspection in settlement.rs. No critical issues were found, and there is no feedback to provide.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

[MartinquaXD]

Makes sense. 👌