Populate penalty_caps_native for fast-path orders

[AryanGodara]

Description

The fast-path handler earlier hardcoded 0 for penalty_cap_native, so fast-path settlements carried no enforceable cap. Now it computes the real cap for fast-path orders, the same way as a regular auction.

The cap depends only on the fixed side of the trade and native prices, not on the quote, and the handler already has both from the staged quote competition.
So this reuses the existing PenaltyCapCalculator rather than adding new logic, with no faspath specific changes.

Changes

• Share the existing PenaltyCapCalculator bw the regular auction loop and the fast-path handler, so the fast path reuses the same instance the regular loop keeps refreshed (its USD reference price feeds the absolute cap).
• Compute the cap in FastPathHandler::compute_and_persist_final_execution, replacing the hardcoded 0. Falls back to 0 only when penalty caps are disabled in the config.

How to test

• Calculator unit tests: cargo nextest run -p autopilot penalty
• New e2e test

Closes BE-281

[linear-code]

BE-291

BE-281

[claude]

Claude finished @AryanGodara's task in 3m 16s —— View job

---

PR Review: Populate penalty_caps_native for fast-path orders

Reviewed the shared-calculator wiring, the fast-path cap computation, and the e2e test. The approach is sound: reusing the same Arc<PenaltyCapCalculator> means the fast path benefits from the USD reference price the regular loop keeps refreshed via set_usd_price, and the Option → 0 fallback preserves the prior behavior when penalty caps are disabled. Sell-side caps match the regular auction exactly.

I posted one inline finding — a price-map divergence for buy-orders that buy native ETH (the regular loop injects the WETH price into the map before calling calculate, the fast path doesn't), which would silently apply the absolute USD cap instead of the volume cap for those orders.

Nothing else blocking. The e2e test is well-constructed (asserts the exclusivity window to prove the fast-path handler settled it, and checks both the competition_auctions row and the trade).

• Read the diff and understand context
• Review fast_path.rs changes
• Review run.rs / solvable_orders.rs wiring
• Review e2e test
• Post inline comments + summary
  · branch aryan/be-281-accounting-populate-competition_auctionspenalty_caps_native

[claude]

Claude finished @AryanGodara's task in 2m 51s —— View job

---

PR Review: Populate penalty_caps_native for fast-path orders

Reviewed the shared-calculator wiring, the fast-path cap computation, and the e2e test against the regular-auction path.

Verdict: Looks good — no blocking issues. The approach is sound and the one finding from the prior review round (buy-ETH price-map divergence) has been correctly addressed.

What I verified:

• Shared Arc<PenaltyCapCalculator> — the fast path reuses the same instance the regular loop keeps refreshed via set_usd_price (solvable_orders.rs:280-284), so its absolute USD cap tracks the same reference price. The initial price is fetched at startup (run.rs:818-827), so even before the first regular-loop tick the cap is valid, not zero.
• Price map — build_native_prices (quote_storage.rs:155) carries the sell/buy token prices; calculate only looks up the volume token, which is always present. The WETH-at-1.0 insertion (fast_path.rs:466-470) mirrors the regular loop (solvable_orders.rs:277-279) exactly, and self.eth.contracts().weth().address() is the same address SolvableOrdersCache uses — so buy-ETH orders get the volume cap rather than silently falling back to the absolute cap.
• Sell-side parity — sell orders (the only ones that fast-path settle today) key the volume token under its real address, present in the map. Caps match the regular auction.
• Fallback — Option → 0.into() preserves prior behavior when penalty caps are disabled.
• e2e test — well-constructed: the elapsed < exclusivity / 2 assertion proves the fast-path handler (not the regular fallback) settled it, and it checks both the competition_auctions row and the settled trade's penalty_cap_native. Helpers (penalty_caps_of_order, trade.penalty_cap_native) exist.

Minor design note (non-blocking, already acknowledged in the PR description): the absolute-cap leg uses the regular loop's latest USD reference price while scoring uses the staged quote-time prices, so a fast-path cap can differ slightly from what a hypothetical regular auction would compute. This is inherent to the fast-path design and monitored via the usd_price_last_update staleness metric — flagging only for awareness.

• Read the diff
• Review the penalty cap wiring & fast-path computation
• Compare with regular auction loop semantics
• Review e2e test
• Post findings
  · branch aryan/be-281-accounting-populate-competition_auctionspenalty_caps_native

[MartinquaXD]

Looks good overall. Just 2 small requests.