Conversation
|
@royvardhan let's default to the circle paymaster when it's available and when the user has USDC balance. Our custom paymaster should only be used in cases where there's no circle paymaster or the user |
Wizdave97
left a comment
There was a problem hiding this comment.
@royvardhan have we changed all the infinite approvals in simplex to per order approvals instead?
Yes. |
|
I'm not sure i like the fact that we're using chainlink? can't we get a twap/vwap from uniswap? |
Chainlink aggregates prices off-chain from multiple independent sources rather than relying on a single DEX pool, making it significantly harder to manipulate. It's also more gas-efficient and eliminates the need to find and track high-liquidity pools for reliable pricing. |
|
Looking more at this PR it appears it still doesn't support USDT, since USDT doesn't have EIP-2612. I think we should pause work on this pending we have a solution that supports USDT otherwise circle's paymaster is still the best choice, no additional infra overhead |
|
Can we split out DelegationService now delegates via bundler UserOp with paymaster paying gas — solver needs zero native tokens. To a different PR? |
Contract: Added
SimplexPaymaster.sol— onchain ERC-4337 v0.8 paymaster accepting USDC/USDT via Chainlink oracles, withPERMITandAPPROVEmodes.Deployment: Added
DeploySimplexPaymaster.s.soland paymaster config entries toconfig.mainnet.toml.SDK: Abstracted paymaster module
(src/services/paymaster/)with unifiedbuildPaymasterAndData()entry point. Prefers Circle Paymaster (USDC permit) where available and filler has USDC balance, falls back toSimplexPaymaster(USDC/USDT, permit or capped approval).Simplex:
DelegationServicenow delegates via bundlerUserOpwith paymaster paying gas — solver needs zero native tokens. Supports Pimlico, Alchemy, and generic bundler gas pricing. Falls back to direct tx.ContractInteractionServiceapproval scoped to exact required amount instead ofmaxUint256.