Race conditions between verify and settle

[adambalogh]

Description

State can change between verify() and settle() calls with no re-validation, leading to race conditions in concurrent scenarios.

Race Conditions Identified

1. Smart Wallet Deployment Race (EVM V1)

Between verification and settlement, a smart wallet could be deployed by a concurrent request. The code checks deployment status but the logic can race when multiple requests hit the same undeployed wallet simultaneously, potentially causing deployment conflicts or wasted gas.

2. Balance/Allowance State Change (All EVM Schemes)

• Payer's token balance can decrease between verify and settle (another transfer)
• Permit2 allowance can be consumed by another transaction
• Settlement fails with a cryptic on-chain error instead of a clear validation error

3. Transaction Expiration (SVM)

• Decoded transaction validity window is not checked at verification time
• By the time settlement executes, the transaction may have expired
• Results in wasted compute and failed settlement

Impact

• Verified transactions fail at settlement, wasting gas
• Concurrent requests for the same wallet can conflict
• Poor error messages when state-change failures occur

Fix

1. Re-validate critical state (balance, allowance, deployment status) at the start of settle()
2. Add distributed locking for smart wallet deployment (e.g., Redis-based lock by wallet address)
3. Check transaction expiration window during SVM verification
4. Add a staleness timeout — reject settlements if too much time has passed since verification