pod network integration (Shadow mode)

[AryanGodara]

New Crates & Modules

• winner-selection: Deterministic solution hashing and combinatorial auction arbitration logic

Driver Pod Flow

• After computing a solution, driver submits bid to pod network
• Waits for auction deadline, fetches all bids, runs local winner selection
• Shadow mode: bid failures log warnings only, never block main flow

Configuration

• New [pod] TOML section: endpoint, auction_contract, wallet config
• Nonce/balance logging on provider init for debugging

E2E Tests

• pod_test_basic: Single solver bid submission + winner verification
• pod_test_multi_order: Multiple orders in single auction
• pod_test_multi_solver: Competing solvers with haircut-based score differentiation

Bug Fixes

• Dynamic WETH address lookup
• Graceful handling of None scores
• Shadow mode for pod failures (non-blocking)

How to Test

Local Services

1. Start anvil in fork mode for mainnet.

1a. state override to bypass solver whitelisting requirement

❯ cast rpc -r http://127.0.0.1:8545 anvil_setCode \     
  0x2c4c28DDBdAc9C5E7055b4C863b72eA0149D8aFE \
  0x600160005260206000F3

2. Start services DB and perform migrations (if not running)

3. Start services (update configs with actual working values for DB URL, etc. for your local machine; you don't have to make any changes to existing configs to support the pod-network addition

cargo run -p driver -- --config configs/local/driver.toml
cargo run -p autopilot -- --config configs/local/autopilot.toml
cargo run -p orderbook -- --config configs/local/orderbook.toml

5. Submit order via API and check logs for:

#    - "pod provider initialized" with signer_address, balance, nonce
#    - "preparing bid submission" with score and payload_len
#    - "bid submitted successfully" OR "pod bid submission failed (shadow mode)"
#    - "fetched bids" with num_participants

E2E Tests

# Run all pod tests
cargo nextest run -p e2e pod_test --run-ignored ignored-only --test-threads 1

---

Known Issues (waiting on response)

Pending TX on Pod Network

Bid submission fails with:

error code -32603: failed to send transaction: 
Another transaction 0x... is still pending

Details:

• Pod endpoint: http://cow.pod.network:8545
• Auction contract: 0xeDD0670497E00ded712a398563Ea938A29dD28c7
• Affected address: 0xf985d2cf3f3c5cfc798d8e9e4ebdd6777653c3cb
• Current nonce: 47, balance: ~10 ETH

Forwarded to pod team - tests will fail until resolved. Shadow mode ensures main flow continues.

---

Related

• Closes Pod Integration (Shadow Mode) #4126
• Supersedes feat: pod integration #4052 (rebased onto main, cleaned up, and polished)

[github-actions]

All contributors have signed the CLA ✍️ ✅
_{Posted by the CLA Assistant Lite bot.}

[github-actions]

This pull request has been marked as stale because it has been inactive a while. Please update this pull request or it will be automatically closed.

[jmg-duarte]

This should be moved to the start_driver_with_config_override callsite where you setup your e2e

[github-actions]

This pull request has been marked as stale because it has been inactive a while. Please update this pull request or it will be automatically closed.

[AryanGodara]

Pod Integration: Design Decisions (more context apart from PR description)

Shadow Mode Architecture

Pod integration runs in shadow mode, so bid submission failures are logged as warnings but never block the protocol flow.

Haircut-Based Score Differentiation (fo rthe e2e Tests)

Since i'm using 2 instances of baseline solvers to simulate competition for the e2e tests; they produce the same flowTwo solvers competing for the same order find identical routes → identical scores.

Solution

Use haircut_bps parameter to artificially differentiate scores:

• Solver A: haircut_bps = 0 (full score)
• Solver B: haircut_bps = 5000 (50% haircut → lower score)

This reliably produces different scores for testing pod winner selection without complex liquidity setup.

Nonce/Pending TX Handling

Current Issue

Pod network rejects new TXs when previous ones from same sender are pending:

error code -32603: Another transaction 0x... is still pending

Approach

• Log nonce on provider init for debugging
• Shadow mode ensures failures don't block main flow
• Pod team to resolve stuck TXs on their end
• Future: pod-sdk should handle nonce conflicts internally (replace-by-fee)

Deterministic Test Addresses

E2E tests use deterministic addresses derived from Anvil's default mnemonic. Pre-funding these on pod network:

• 0xf985d2cf3f3c5cfc798d8e9e4ebdd6777653c3cb - solver 1
• 0x9315fc8ffae493123b9b6b1c93d50c9b9eef0344 - solver 2

Both funded with ~10 ETH on pod network.

Config Structure

[pod]
endpoint = "http://cow.pod.network:8545"
auction-contract = "0xeDD0670497E00ded712a398563Ea938A29dD28c7"

Wallet uses existing [account] section - no separate pod wallet config needed.

[ogabrielides]

I have read the CLA Document and I hereby sign the CLA

[gemini-code-assist]

Code Review

This pull request implements integration with the pod network to support decentralized solver competitions. Key changes include upgrading the Alloy dependency suite to version 1.8.3, introducing deterministic solution hashing within the winner-selection crate, and adding a pod_flow to the driver for bid submission and local arbitration. The PR also includes new E2E tests, local configurations, and account recovery logic for the pod network. Feedback was provided regarding the fragility of the bid-fetching process, where a single malformed bid currently causes the entire batch to fail; it is recommended to collect individual errors instead of aborting the process.

[gemini-code-assist]

Aborting the entire bid fetching process due to a single malformed bid is fragile. However, simply skipping the error is insufficient. According to our rules, when fetching a batch of items where individual fetches can fail, the API response should explicitly indicate which items failed and provide error details for each failure, rather than silently ignoring them.

        let mut errors = Vec::new();
        for bid in bids {
            match serde_json::from_slice::<dto::SolveResponse>(bid.data.as_slice()) {
                Ok(resp) => {
                    for solution in resp.solutions {
                        participants.push(Bid::new(solution));
                    }
                }
                Err(e) => {
                    tracing::error!(error = %e, "failed to deserialize SolveResponse");
                    errors.push((bid.id, e.to_string()));
                }
            }
        }

References

1. When fetching a batch of items where individual fetches can fail, do not silently ignore errors. The API response should explicitly indicate which items failed and provide error details for each failure.