Summary
For payment.type === "sponsored", the relayer proceeds after simulation without enforcing that calldata actually transfers fees to the operator (src/methods/send_tx/shared.rs). The codebase even notes that error 4200 (Insufficient Payment) is not wired on the core relay path (src/utils/errors/rpc_errors.rs).
Risk
Misconfiguration or malicious clients can drain relayer ETH for transactions that never compensate the operator, if the smart account does not enforce payment in a way the relayer trusts.
Suggested mitigations
- Optionally decode calldata and assert expected fee transfer to
feeCollector before signing, or integrate an off-chain policy engine.
- Clearly document operational requirement for sponsored mode.
References
src/methods/send_tx/shared.rssrc/utils/errors/rpc_errors.rs (insufficient_payment_error comment)
Summary
For
payment.type === "sponsored", the relayer proceeds after simulation without enforcing that calldata actually transfers fees to the operator (src/methods/send_tx/shared.rs). The codebase even notes that error4200(Insufficient Payment) is not wired on the core relay path (src/utils/errors/rpc_errors.rs).Risk
Misconfiguration or malicious clients can drain relayer ETH for transactions that never compensate the operator, if the smart account does not enforce payment in a way the relayer trusts.
Suggested mitigations
feeCollectorbefore signing, or integrate an off-chain policy engine.References
src/methods/send_tx/shared.rssrc/utils/errors/rpc_errors.rs(insufficient_payment_errorcomment)