Repository navigation
[evm]: Select UserOpHash instead of solver address in solver selection #816
Description
Background
Currently, solver selection authorizes a solver address — the session key signs SelectSolver(bytes32 commitment, address solver), and fillOrder checks msg.sender == stored solver. This means the session key's authorization is bound to a solver identity, but not to the specific UserOperation being executed.
Proposed Change
Replace address solver with bytes32 userOpHash in the SelectSolver EIP-712 struct. The session key would sign over the specific UserOperation hash, creating a tighter binding — a solver couldn't reuse a session signature with different calldata or gas parameters.
Blockers
fillOrderneeds to verify the currently executing userOpHash against the stored value.IEntryPoint.getCurrentUserOpHash()is only available in EntryPoint v0.9. The move to v0.9 is tracked in the EntryPoint v0.9 milestone: [evm]: migrate SolverAccount to EntryPoint v0.9 #1366 forSolverAccount, [evm]: migrate SimplexPaymaster to EntryPoint v0.9 #1365 forSimplexPaymaster, [sdk, simplex]: sign and submit bids against EntryPoint v0.9 #1367 for the SDK and simplex, and [indexer]: index fills executed through EntryPoint v0.9 #1368 for the indexer.
The Circle paymaster's limit to v0.7 and v0.8 no longer blocks this. Bids are sponsored by our own SimplexPaymaster, which moves to v0.9 in #1365.
Action
Ship in the EntryPoint v0.9 milestone, with or after the migrations above. #1366 asks whether this goes out in the same SolverAccount deployment, since every new deployment means each solver re-delegates.
Affected Files
evm/src/apps/intentsv2/IntentsBase.sol—SELECT_SOLVER_TYPEHASH,_selectevm/src/apps/IntentGatewayV2.sol—fillOrdersolver checkevm/src/apps/intentsv2/SolverAccount.sol—validateUserOpsdk/packages/core/contracts/apps/IntentGatewayV2.sol—SelectOptionsstructsdk/packages/sdk/src/protocols/intents/CryptoUtils.ts—signSolverSelectionsdk/packages/sdk/src/protocols/intents/Bid.ts— signs the selection for a bidsdk/packages/sdk/src/protocols/intents/BidManager.ts—selectBid
Activity
[-]Select userOpHash instead of solver address in solver selection[/-][+][evm]: Select UserOpHash instead of solver address in solver selection[/+]Psalmuel01 commentedon May 23, 2026
I'd like to work on this issue.
The current
SelectSolver(bytes32 commitment, address solver)flow binds authorization to a solver identity, but not to the specificUserOperationbeing executed. Replacingaddress solverwithbytes32 userOpHashwould tighten the authorization scope and prevent reuse of solver selection signatures across modified calldata or gas configurations.Proposed Approach
Solidity Changes
IntentsBase.solUpdate
SELECT_SOLVER_TYPEHASH:Refactor
_select()to accept/storeuserOpHashinstead of solver addressIntentGatewayV2.solfillOrder()withIEntryPoint.getCurrentUserOpHash()userOpHashmatches the stored authorizationSolverAccount.solvalidateUserOp()flow to compute/pass the relevantuserOpHashSDK Contract Types
Update
SelectOptions:SDK Updates
CryptoUtils.tsSELECT_SOLVER_TYPEHASHsignSolverSelection()to signuserOpHashaddress→bytes32BidManager.tsselectBid()to passuserOpHashthrough the signing flowTesting
I also plan to add regression tests covering:
UserOperations fail authorization checksCurrent Blocker
The main dependency here is EntryPoint v0.9, since
getCurrentUserOpHash()is only available there. Current Circle paymaster support appears limited to v0.7/v0.8, so this likely needs to land alongside (or after) the v0.9 migration.A few questions before I begin:
Happy to take this on once direction around the v0.9 migration is clarified.