feat(PFW): compute_probe_amount and compute_average_price_impact

[tamaralipows]

Task

Context: In the PFW algorithm, after we route the full trade through the best single path (via BF), we want to know: is there a second path worth splitting to? We can't just re-run BF at the full trade amount - BF would find the same path again because nothing changed. Instead, we:

1. "Degrade" the pools on the first path (simulate their post-swap state, as if the trade already went through)
2. Run BF again with a small probe amount on all pools, including those degraded pools, in oder to discover a candidate second path.

Note: This part of the task is not relevant yet, but we should keep in mind that when calling these methods:

gas_cost_output_tokens is obtained from ctx.gas_price_wei and the output token's price from ctx.token_prices. If token price data is unavailable, fall back to total_amount * 0.10 (10% of trade) and always return Some.

[dianacarvalho1]

Thank you @tamaralipows ! 🙏🏼 it looks good to me! only have 1 question for my understanding

[dianacarvalho1]

in which case is this possible? 🤔

[tamaralipows]

The pool has a flat pricing curve (e.g. stable-swap pools within their peg range). A verrryyy real example: WETH-ETH unwrapping.

[dianacarvalho1]

why isn't this a method of the Algorithm struct? same for the compute_average_price_impact

[tamaralipows]

I've left them free because neither function needs &self - they're pure computations with explicit inputs. Keeping them as free functions also makes tests simpler: you can call them directly without constructing a full PathFrankWolfeAlgorithm (which in turn requires setting up BellmanFordAlgorithm).

I can also see the organization benefit of moving them into the algorithm though - so please see commit c8308f7 and let me know if you like that better!

[Troshchk]

Thank you!
I have a general question: why do we degrade the pools on the first path, as if the full trade already went through? Why would not we use max_probe, for example?

[tamaralipows]

I have a general question: why do we degrade the pools on the first path, as if the full trade already went through? Why would not we use max_probe, for example?

@Troshchk There is more context about this in the story. This is actually a core property of the Frank-Wolfe method. In particular this line:

Ask: "If I were already routing everything through this path, where would BF send a small probe trade?" BF sees the pool states after the big trade, so it finds a path that possibly avoids the now-depleted pools. This is the candidate second path.

Keep in mind this step doesn't determine the split amount - it only finds candidate paths. We degrade by the full amount because that's what Frank-Wolfe requires: evaluate the descent direction at the current allocation (initially 100% on path 1). If we degraded by less, BF would see a less-stressed pool and might miss better alternatives or pick the wrong one.

The actual split fraction is decided afterwards by golden-section line search (step 2f), which finds the optimal balance between the existing allocation and the new candidate. So this full degradation is just "where should I look next?", not "how much should I send there?"

[louise-poole]

Small error message feedback, otherwise approved! Looks good 🚀

[louise-poole]

Nice! Happy with this 👍

[dianacarvalho1]

✨ ✨ ✨

[github-actions]

No API Breaking Changes Detected

The PR title signals breaking changes, but cargo-semver-checks found none.
If the breaking change is behavioral, CLI, or config-level (not public Rust API), this is expected.
Otherwise, consider using fix: instead of feat: in the PR title.

[propellerci]

This PR is included in version 0.75.0 🎉