Decode the intended ZKsync paymaster flow before approving a transaction
The paymaster address names a sponsor, while paymasterInput selects how the account and sponsor interact. A wallet needs both to explain whether an ERC-20 allowance may be involved.
Identify the flow selector
Decode the first four bytes of paymasterInput against the supported paymaster-flow interface. In an approval-based flow, verify the token, minimum allowance and inner payload against the user’s intent. In a general flow, interpret innerInput using the sponsor’s documented scheme.
general(bytes innerInput)
approvalBased(address token, uint256 minimalAllowance, bytes innerInput)
If the intended token is X but the encoded approval-based flow names Y, reject the proposed transaction even when the sponsor address is familiar. The encoded minimum allowance indicates the requested setup; it does not independently state the final token charge.
Inspect custom validation as well
A custom account may implement the flows differently, and the paymaster can impose additional conditions during validation. Simulate the complete transaction with the actual account, sponsor and payload, and recheck the final signed fields. docs.zksync.io ZKsync documentation