support parallel transaction submission using EIP 7702

[MartinquaXD]

Background

Now that we have combinatorial auctions (where 1 solver can provide multiple winning solutions) and with the autopilot not waiting for solutions to be fully settled (or timed out) before arbitrating the next auction the reference driver really needs to be able to handle multiple solution submissions in parallel.
The problem always was ethereum's nonce and tx pool management. You can't submit multiple txs for the same signer + nonce without replacing the pending ones. And even if you could submit 2 txs for the same signer + nonce executing one of them will automatically invalidate the other one since the nonce is now too low.
Historically there were really only 2 ways to solve this problem:

• allow list multiple EOAs as solvers
• allow list a smart contract as the solver and allow multiple EOAs to trigger auctions from that

Both of these require a lot of management operations on the cow protocol settlement authentication contract which is risky and generally a PITA.
With the introduction of EIP 7702 solvers can keep the one already allow listed EOA while also enabling multiple other EOAs to submit txs on its behalf. This can be achieved by building a smart contract that first checks that the caller is some permissioned address (i.e. one of a couple EOAs controlled by the solver) and then forwards the call to the settlement contract.
Then the solver simply sets the EIP 7702 delegation of the one already allow listed EOA to that helper contract. Now the solver is suddenly in control of multiple EOAs that are able to submit transactions on behalf of the one allow listed "primary" EOA. This greatly alleviates the mentioned nonce management issues since it's cheap to generate as many EOAs as you need (let's say 10 EOAs for 10 tx submissions in parallel).

Implementation

Assumptions

The driver will assume that the helper contract supports the same ABI as the real settlement contract. In other words the same calldata the driver builds today will be compatible with the new helper contract. This can easily be achieved by using a fallback function in the helper contract. Note that the tx.to will have to change depending on the submission strategy (regular: tx.to = settlement_contract, 7702: tx.to = solver_eoa).

Configuration

First of all we need a way to configure all the new addresses. For every solver we'll have to have 1 solver address (which can be a public address) and we need to configure n submission accounts (private key, KMS, even public addresses are possible if the RPC has the associated PKs configured). Unfortunately today's setup (without EIP 7702) can't be configured using those options so we need another option for that. One option for this would be to configure a PK for the "solver" account and 0 submission addresses.

Submission Management

The driver already implements submission logic for 1 EOA. This logic will have to be put into a separate component to allow replicating it. Then we just need another component deciding which submission EOA to use next. Whenever you call Orchestrator.submit(tx) (dummy names and API) it has to pick any of the sub-components managing an individual submission EOA which is currently idle (i.e. no pending tx). If all of the sub-components are currently busy the Orchestrator has to wait until one finishes the tx submission and becomes idle again.

There is one last important change. If a subcomponent uses EIP 7702 submission the target of the tx must not be the actual settlement contract - instead it needs to be the solver EOA.

Acceptance criteria

For every solver it's possible to configure multiple "submission EOAs" which send transactions to 1 configured "solver EOA". Additionally the driver will monitor the submission progress of each submission EOA and pick which one to submit the next tx from.

[mayanksharma-eth]

This makes sense and addresses a real constraint that is becoming more painful with combinatorial auctions + autopilot advancing without waiting for full settlement finality.

The core issue is not solver logic but Ethereum nonce semantics: a single allow-listed EOA cannot truly submit multiple candidate settlements in parallel without replacement / invalidation. Using EIP-7702 to turn the already allow-listed solver EOA into a smart-EOA that authorizes multiple “submission EOAs” is a clean way to preserve Settlement authentication while unlocking parallel submission lanes.

A few points worth explicitly calling out / validating as we move forward:

Chain support gating – this needs to be feature-gated per network (L1 / L2) based on EIP-7702 availability and RPC support, otherwise fallback to single-EOA submission.

Delegate contract safety – since the solver EOA effectively becomes a smart account, the helper contract must be extremely minimal and well-audited (strict caller allowlist, no storage footguns, no upgrade surprises). A proxy-style pattern with explicit initialization guards may be worth standardizing.

Execution semantics – parallel submission ≠ parallel success; later txs will likely revert once the first settlement lands. That’s fine, but the driver should treat this as expected behavior and not as an error condition.

Driver architecture – the proposed orchestrator + per-submission-EOA state machine seems like the right abstraction. We’ll likely want explicit “occupied / idle / stuck” tracking per submitter and clear replacement / cancellation policies.

Overall this feels like the right direction to unblock solver throughput without expanding allowlists on Settlement. Happy to help review the delegate contract interface or driver refactor once there’s a concrete proposal.