Allow multiple parallel settlements from one solver by fafk · Pull Request #4167 · cowprotocol/services

fafk · 2026-02-18T11:03:19Z

Description

Resolves #3966.

Enable parallel settlement submission from a single solver by using EIP-7702 delegation. When a solver wins multiple solutions in overlapping auctions, each settlement can now be submitted concurrently through independent submission EOAs instead of waiting in a sequential queue.

The solver EOA delegates its code to a CowSettlementForwarder contract via EIP-7702. Approved submission EOAs call forward(target, data) on the solver EOA, which forwards to the actual target (settlement contract, wrapper, or flashloan router) with msg.sender = solver EOA — preserving the existing whitelisting.

Changes

CowSettlementForwarder.sol — New forwarder contract with caller whitelist. Supports forwarding to any target (settlement contract, wrappers, flashloan router) via forward(address target, bytes data)
SubmissionAccountPool type: a channel-based pool that lends submission accounts for the duration of a settlement and reclaims them afterward. In EIP-7702 mode, settle requests are spawned as concurrent tasks instead of processed sequentially
submission_accounts config that allows specifying accounts that are whitelisted to submit settlements. If omitted we fallback to non-delegated submissions directly from the solver EOA

Requirements before deployment

Deploy & verify the CowSettlementForwarder contract
Set up EIP7022 delegation to whitelisted solver EOAs to the newly deployed contract
Create new submissions accounts and fund them with eth (or other base token) & monitor their eth balance
Whitelist the submissions accounts on the solver EOA (CowSettlementForwarder code)

Only then can the submissions accounts be configured and deployed.

How to test

cargo nextest run -p e2e local_node_parallel_settlement --test-threads 1 --run-ignored ignored-only

gemini-code-assist

Code Review

This pull request introduces parallel settlement submission for a single solver using EIP-7702 delegation, which is a significant improvement. The implementation involves a new forwarder contract, a submission account pool, and updates to the settlement processing logic. My review identified two main issues: a critical discrepancy between the Solidity source code and its compiled artifact, and a high-severity resource leak risk in the submission account pool handling. Addressing these will improve the robustness and security of the new functionality.

MartinquaXD

Looks really good already.
Nice test and I like the logic of passing around account claims via channels.

gemini-code-assist

Code Review

This pull request introduces a well-designed implementation for parallel settlement submission using EIP-7702, featuring the new CowSettlementForwarder contract, SubmissionAccountPool, and robust delegation setup. However, a critical privilege escalation vulnerability was identified in the CowSettlementForwarder smart contract, where an approved caller can use the forward function to modify the whitelist via setApprovedCallers on the solver EOA. This requires mitigation by preventing self-calls in the forward function. Additionally, a high-severity issue exists in the AccountGuard's drop implementation, which could lead to a panic during application shutdown.

gemini-code-assist · 2026-02-24T16:05:25Z

+    function forward(address target, bytes calldata data) external payable {
+        if (!isApprovedCaller[msg.sender]) revert Unauthorized();
+        (bool success, bytes memory result) = target.call{value: msg.value}(data);
+        assembly {
+            switch success
+            case 0 { revert(add(result, 32), mload(result)) }
+            default { return(add(result, 32), mload(result)) }
+        }
+    }


The forward function allows an approved caller to execute arbitrary calls as the solver EOA. If the target is set to address(this), the call is executed with msg.sender set to the solver EOA itself. This allows an approved caller to call setApprovedCallers and modify the whitelist, bypassing the intended access control which requires msg.sender == address(this). This is a privilege escalation vulnerability where a submission EOA can take full control over the whitelist and potentially other sensitive functions of the solver EOA.

Recommendation: Add a check in the forward function to ensure that the target is not address(this).

function forward(address target, bytes calldata data) external payable { if (!isApprovedCaller[msg.sender]) revert Unauthorized(); if (target == address(this)) revert Unauthorized(); (bool success, bytes memory result) = target.call{value: msg.value}(data); assembly { switch success case 0 { revert(add(result, 32), mload(result)) } default { return(add(result, 32), mload(result)) } } }

gemini-code-assist · 2026-02-24T16:05:25Z

+        if let Some(account) = self.account.take() {
+            let sender = self.release_sender.clone();
+            tokio::spawn(async move {
+                if sender.send(account).await.is_err() {
+                    tracing::error!("failed to return submission account to pool: channel closed");
+                }
+            });
+        }


Using tokio::spawn directly within a Drop implementation can lead to a panic if the AccountGuard is dropped while the Tokio runtime is shutting down. This would cause an ungraceful shutdown. A more robust approach is to acquire a handle to the current runtime and spawn the task on it, which gracefully handles cases where the runtime is not available or is shutting down.

if let Some(account) = self.account.take() { let sender = self.release_sender.clone(); if let Ok(handle) = tokio::runtime::Handle::try_current() { handle.spawn(async move { if sender.send(account).await.is_err() { tracing::error!("failed to return submission account to pool: channel closed"); } }); } else { // This can happen during a panic or when the runtime is shutting down. // The account is not returned to the pool, which is acceptable. tracing::warn!("no tokio runtime, submission account will not be returned to pool"); } }

MartinquaXD

Looks really good over all. Mostly nits and code golf suggestions.

Comments on the contract code mostly have production deployment in mind but for e2e tests it's definitely fine.

MartinquaXD · 2026-02-24T16:12:48Z

+
+    /// @notice Set approved callers.
+    function setApprovedCallers(address[] calldata callers, bool approved) external {
+        if (msg.sender != address(this)) revert Unauthorized();


I might be missing some solidity details but it seems like the way to use this contract is to first have an EOA delegate to it and then send a message from the EOA to itself to call this function. Is that correct?

IIRC the state (allow list mapping) will be stored in the EOA so theoretically all solvers could use the same instance of this contract, right?

We should probably address the question whether we want to have a function cleaning up the EOAs storage or leave things as is and consider the EOAs as forever tainted once they use this contract. Probably not a big concern since attacks would require the EOA to delegate to a second malicious contract that exploits the set state.

MartinquaXD · 2026-02-24T16:13:59Z

+/// is deployed once and shared across all solver EOAs — each gets its own
+/// independent `isApprovedCaller` mapping in its own storage.
+contract CowSettlementForwarder {
+    mapping(address => bool) public isApprovedCaller;


Storing the approved addresses in storage means we'd have to do an additional SLOAD for every settlement. Not sure if the SC team will have concerns about that. At least for e2e testing purposes this contract seems to be sufficient.

Is there an alternative? I can only think of baking the submission EOAs into the contract itself via a constructor, but that would make it very inflexible to update.

Also SOAD is 2100 gas which is ~nothing compared to the total costs of forwarding the calldata. 🤔

Yes, baking the addresses into the contract is what some external solvers teams did when they rolled their own 7702 solution. I think the SC team should ultimately give the green light for the final contract. Just wanted to point that out since @fedgiac always sounds so scared about introducing SLOADs. 😄

MartinquaXD · 2026-02-24T17:32:42Z

+    const POLL_INTERVAL: Duration = Duration::from_secs(3);
+    const MAX_WAIT: Duration = Duration::from_secs(90);


This is a potentially long restart that can ultimately lead to a panic. I'm not really sure if the driver should automatically set up new callers TBH. Have to think more about it.

I was thinking about doing this outside of the driver, but we're using KMS here which the driver is well equipped to use unlike a script where you need AWS access.

It is one-time cost, I think the submission acc set is not really going to be changing often at all.

MartinquaXD · 2026-03-03T11:35:58Z

-    fn deref(&self) -> &Account {
-        &self.account
+impl SubmitterGuard {
+    fn delegation_context(&self) -> Option<DelegatedSubmission> {


I wonder if it would be nicer to return an enum here so that we don't have to rely on the tx having the correct from set in the Direct case. 🤔

Mhm. We would have to carry around the solver address in Direct as well we wouldn't actually get to delete wrap_for_delegated_submission, so I don't think it's a big win.

This was not about deleting any code - just about making the important information available in the same place. It's a bit strange that submission data for EIP 7702 comes from the SubmitterPool while direct submission relies on the tx being created with the correct from address.

Okay. I made it explicit: https://github.com/cowprotocol/services/pull/4167/changes/b628585bed3b19cf7a30aa64d7d15fa7a2fa1e98..31d1eecaecfb9a6cb757a3c1cc5f3ad5d2db0e30

MartinquaXD

All my comments got addressed. 👍

fafk requested a review from a team as a code owner February 18, 2026 11:03

fafk marked this pull request as draft February 18, 2026 11:03

gemini-code-assist Bot reviewed Feb 18, 2026

View reviewed changes

Comment thread crates/contracts/solidity/CowSettlementForwarder.sol

Comment thread crates/driver/src/domain/competition/mod.rs Outdated

MartinquaXD reviewed Feb 18, 2026

View reviewed changes

fafk changed the title ~~Allow multiple parallel settlements from 1 solver~~ Allow multiple parallel settlements from one solver Feb 23, 2026

fafk marked this pull request as ready for review February 24, 2026 15:43

gemini-code-assist Bot reviewed Feb 24, 2026

View reviewed changes

MartinquaXD reviewed Feb 24, 2026

View reviewed changes

fafk force-pushed the parallel-submission-7702 branch from fa14015 to a498412 Compare March 2, 2026 14:54

MartinquaXD reviewed Mar 3, 2026

View reviewed changes

fafk added 20 commits March 3, 2026 14:07

Allow multiple parallel settlements from 1 solver

f6f2b92

Simulate the change tx

9972b5a

Allow all acc types

3c6daa1

Fix botched rebase

2544fa7

Fix test

a7da27f

Use proper forwarder contract

409069e

Comment

a6a53b6

Add delegation setup at startup

6beab1b

Remove deleted contract from make

33f724d

Regenerate contract interface json

8294c1f

Use correct nonce

8cde112

Use nonce

62be441

Print debug info

7fa8fd9

Wait for in-flight txs

48f9dd1

Use RAII for submission accs

e12612e

Improve comments, simplify test

082ccc8

Nuke setup which now is done by driver

1bc5a73

Refactor guard

1db378e

Rename field

7f17178

Remove solver param

f3a2afe

fafk added 16 commits March 3, 2026 14:07

Fmt

620e3d2

Refactor wrapping into a fn

feffa9c

Remove default

b6f6ffe

Tracing not needed on method

541e837

Make code more consise

b47cf8d

Use context shortcut

64a4085

Move early return to method

cb19670

Fix cmt

93c82c2

Use 7702 only when needed

15d0a7d

Fix test

353508c

Fmt

ffae152

Fmt

fb57e45

Encapsulate submission logic in SubmissionPool type

03b65c7

Use select_biased

6e970d5

Set tx.from explicitly for direct submission

2a16d4d

Comment

d679caa

fafk force-pushed the parallel-submission-7702 branch from 31d1eec to d679caa Compare March 3, 2026 13:07

MartinquaXD reviewed Mar 3, 2026

View reviewed changes

Comment thread crates/driver/src/domain/competition/mod.rs Outdated

Make sure failure in one doesn't affect the other

a5253e2

MartinquaXD approved these changes Mar 4, 2026

View reviewed changes

fafk added this pull request to the merge queue Mar 4, 2026

Merged via the queue into main with commit b79d812 Mar 4, 2026
19 checks passed

fafk deleted the parallel-submission-7702 branch March 4, 2026 08:39

github-actions Bot locked and limited conversation to collaborators Mar 4, 2026

		const POLL_INTERVAL: Duration = Duration::from_secs(3);
		const MAX_WAIT: Duration = Duration::from_secs(90);

Conversation

fafk commented Feb 18, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Description

Changes

Requirements before deployment

How to test

Uh oh!

gemini-code-assist Bot left a comment

Choose a reason for hiding this comment

Code Review

Uh oh!

Uh oh!

Uh oh!

MartinquaXD left a comment

Choose a reason for hiding this comment

Uh oh!

gemini-code-assist Bot left a comment

Choose a reason for hiding this comment

Code Review

Uh oh!

gemini-code-assist Bot Feb 24, 2026

Choose a reason for hiding this comment

Uh oh!

gemini-code-assist Bot Feb 24, 2026

Choose a reason for hiding this comment

Uh oh!

MartinquaXD left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

MartinquaXD left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

fafk commented Feb 18, 2026 •

edited

Loading