6.1 Users undercharged due to erroneous cost calculation
During a user operation execution, the paymaster’s postOp flow is triggered when a non-empty context is provided by the validation step. The _postOp function is responsible for executing the postOp logic. It calculates the total cost of the userOp, including preOp, userOp execution, and an estimated postOp execution cost. This total cost is then converted into a token amount using the exchange rate provided in the UserOp struct, and the corresponding amount is transferred from the user to the treasury address.
function _postOp(PostOpMode _postOpMode, bytes calldata _context, uint256 _actualGasCost) internal {
// ...
ERC20PostOpContext memory ctx = _parsePostOpContext(_context);
uint256 actualUserOpFeePerGas = _calculateActualUserOpFeePerGas(ctx.maxFeePerGas, ctx.maxPriorityFeePerGas);
//@audit _actualGasCost should not be divided by actualUserOpFeePerGas
uint256 costInToken = getCostInToken(
_actualGasCost / actualUserOpFeePerGas, ctx.postOpGas, actualUserOpFeePerGas, ctx.exchangeRate
) + ctx.constantFee;
bool success = SafeTransferLib.trySafeTransferFrom(ctx.token, ctx.sender, ctx.treasury, costInToken);
// ...
}
The getCostInToken function computes the total cost in tokens, with the first parameter representing the actual gas cost (in wei) consumed by the userOp, excluding the postOp.
function getCostInToken(...) public pure returns (uint256) {
return ((_actualGasCost + (_postOpGas * _actualUserOpFeePerGas)) * _exchangeRate) / 1e18;
}
However, the current implementation divides the _actualGasCost by the actualUserOpFeePerGas before passing it to getCostInToken. This results in the value representing gas units instead of the correct wei amount, leading to an incorrect estimation of the total gas cost. As a result, the gas cost is under-calculated, and users are charged less than what the paymaster actually pays.
Recommendation
Remove the erroneous division by actualUserOpFeePerGas in the first parameter passed to getCostInToken.
6.2 User is not charged when first postOp call reverts
The SingletonPaymasterV6 contract implements the Pimlico paymaster, compatible with EntryPoint v6. In this version, the EntryPoint executes the user operation ( userOp), followed by attempting to execute the postOp on the paymaster. The mode of the postOp can either be opSucceeded or opReverted. If the postOp execution reverts, the error is caught by EntryPoint, reverting the state to before the userOp execution, and a second call is initiated with the mode postOpReverted.
The postOp implementation in SingletonPaymasterV6 attempts to charge the user for the actual cost of the userOp. However, during the second call (with postOpReverted mode), the function returns before the user has been charged. As a result, in cases where the userOp execution leads to a decrease in the user's token approval or balance (making it insufficient to cover the userOp cost), the second postOp call does not enforce the charge after the userOp state changes are reverted. Consequently, the paymaster ends up covering the gas fees.
function _postOp(PostOpMode _postOpMode, bytes calldata _context, uint256 _actualGasCost) internal {
if (_postOpMode == PostOpMode.postOpReverted) {
// @audit User is not charged yet due to the first call falling
return;
}
// ...
bool success = SafeTransferLib.trySafeTransferFrom(ctx.token, ctx.sender, ctx.treasury, costInToken);
// ...
emit UserOperationSponsored(ctx.userOpHash, ctx.sender, ERC20_MODE, ctx.token, costInToken, ctx.exchangeRate);
}
Recommendation
The postOp should charge the user even when the mode is postOpReverted.
6.3 Paymaster and bundler financial loss risks in ERC20 mode
In the ERC20 mode, the Pimlico team performs an off-chain verification of the user's balance to ensure it can cover the userOp fees and prevent the execution from reverting. However, without on-chain verification during the validation phase, the user's balance or approvals to the Paymaster can be manipulated so that the user does not have the funds to pay for the operation in the postOp phase. The user's token balance/allowance can be manipulated at two key time points:
- During the execution of the userOp itself;
- Between the off-chain balance check and the point when the userOp is processed by the bundler (front-running the call to
handleOps(...) function);
// SingletonPaymasterV7.sol
function _postOp(
// ...
uint256 _actualGasCost,
uint256 _actualUserOpFeePerGas
)
internal
{
// ...
uint256 costInToken = getCostInToken(
actualGasCost, ctx.postOpGas,
_actualUserOpFeePerGas, ctx.exchangeRate
) + ctx.constantFee;
// @audit-issue If the user does not have enough tokens,
// or the approval is insufficient, the post op reverts.
SafeTransferLib.safeTransferFrom(
ctx.token, ctx.sender, ctx.treasury, costInToken
);
// ...
}
Suppose the _postOp(...) execution fails due to the revert in safeTransferFrom(...) caused by insufficient balance or allowance. In that case, the execution will continue in the _executeUserOp(...) on the Entrypoint side, where it will finish without charging the user for the operation. Even though the action specified by the user in the userOp (the calldata portion) was reverted due to insufficient payment, the paymaster pays for the wasted gas and compensates the bundler.
The first scenario, where the userOp itself modifies the user's token balance to cause the postOp(...) to revert, is less likely since the bundler is expected to simulate the operation before submitting it on-chain. It can still happen if the bundler performs limited validation, e.g., does not simulate the execution itself but only the validation phase.
The second scenario, where the user front-runs the bundler's call to handleOps(...) is more likely to happen. While there is no direct incentive for the user to do so, a griefer or market competitor of Pimlico might want to cause a financial loss to the Paymaster at no upfront cost.
In certain cases, the attacker might also be able to shift the financial loss from the Paymaster to the Bundler. By deliberately causing postOp(...) to revert, the additional gas overhead from post-execution failure handling logic could exceed the prefunded amount. If the Entrypoint contract's gas prefund is insufficient to cover these costs, the Paymaster will be unable to compensate the Bundler, resulting in a financial loss for the Bundler. If this happens repeatedly, the Paymaster could be throttled or banned.
Since the attacker controls the gas limits and max gas fees, they also control the prefund taken by the Entrypoint contract. To exploit this, the attacker must set these parameters so that they pass the bundler's simulation under normal conditions but fail when additional failure-handling logic is triggered.
// Entrypoint.sol (V7)
function _postExecution(
// ...
UserOpInfo memory opInfo,
uint256 actualGas
)
private
returns (uint256 actualGasCost)
{
// ...
actualGasCost = actualGas * gasPrice;
// @audit The user controls the prefund amount. It is influenced by gas
// limits and max gas fees selected.
uint256 prefund = opInfo.prefund;
if (prefund < actualGasCost) {
// @audit This branch may be hit once the postOp reverts due
// to payment failure caused by the user.
if (mode == IPaymaster.PostOpMode.postOpReverted) {
// @audit-issue The difference betwee actual gas cost and prefund
// is the financial loss that the bundler will take.
// The bundler is compensated with the actual gas cost.
actualGasCost = prefund;
emitPrefundTooLow(opInfo);
emitUserOperationEvent(
opInfo, false, actualGasCost, actualGas
);
}
// ...
}
}
Recommendation
Consider charging users in advance. This, however, may conflict with the current project requirement that allows users to pay for the operation only after execution, as they may need to acquire tokens first. An alternative approach is for the Paymaster to absorb the loss, relying on the fact that every protocol user must have a valid RPC URL, allowing for off-chain penalties. However, this would require the Paymaster to reserve additional tokens to cover cases where the Bundler incurs a loss.
Resolution
We have added optional prefund: PR 13. To clarify this commit: Since the suggestion is to charge users in advance, we’ve added an optional pre-fund option. If a user has a known malicious history, we’ll require pre-funding during the validation phase to reduce the risk of losing reputation or money on-chain. If the user has no history of malicious behaviour, we’ll allow sponsorship without pre-funding, but only up to a limit. This helps prevent our paymaster and us from being rigged by front-running. I also understand the audit's concern about the prefund < actualGasCost case, where the paymaster might be throttled due to losses incurred by the bundler. To address this, we’ve decided to include an additional paymasterPostOpGasLimit off-chain to account for the revert gas limit so that pre-fund is always enough.
6.4 Redundant signing of paymaster address
The paymaster backend signs the user operation along with other parameters, this signature is appended to the userOp.paymasterAndData field and is verified on-chain during the verification phase.
The _getHash function returns the hash of the structure signed by the backend. It hashes the full userOp structure, excluding the paymasterAndData field, which is hashed up to the signature bytes. This field contains the paymaster address (first 20 bytes) along with other parameters that vary based on the mode. After this, the hash is combined with the chainId and address(this), which refers to the paymaster address. As a result, the paymaster address is signed twice: once as part of the paymasterAndData field and again when added separately with address(this). This redundant signing unnecessarily increases gas costs.
function _getHash(UserOperation calldata _userOp, uint256 paymasterDataLength) internal view returns (bytes32) {
bytes32 userOpHash = keccak256(
abi.encode(
// ...
// hashing over all paymaster fields besides signature
keccak256(_userOp.paymasterAndData[:PAYMASTER_DATA_OFFSET + paymasterDataLength])
)
);
//@audit signing address(this) is redundant
return keccak256(abi.encode(userOpHash, block.chainid, address(this)));
}
Recommendation
Remove the redundant inclusion of address(this) in the hashed data.
6.5 Unnecessary calculation of preFund amount
During the verification phase of an ERC20 mode userOp, a context is generated via the _createPostOpContext function. This context is then passed by the EntryPoint to the postOp function for further use in its logic.
The _createPostOpContext function populates various fields in the ERC20PostOpContext struct, eventually, it calculates the preFund amount that was paid by the paymaster using the _getRequiredPrefund function.
However, the actual preFund amount is already passed by the EntryPoint to the validatePaymasterUserOp function. Therefore, the computation in the paymaster contract is redundant.
function _validatePaymasterUserOp(
UserOperation calldata _userOp,
bytes32 _userOpHash,
uint256 /* maxCost */ // @audit required preFund amount passed by the EntryPoint
)
internal
returns (bytes memory, uint256)
{
// ...
bytes memory context;
uint256 validationData;
if (mode == VERIFYING_MODE) {
(context, validationData) = _validateVerifyingMode(_userOp, paymasterConfig, _userOpHash);
}
if (mode == ERC20_MODE) {
//@audit context is generated by recomputing the required preFund amount
(context, validationData) = _validateERC20Mode(_userOp, paymasterConfig, _userOpHash);
}
return (context, validationData);
}
Recommendation
Use the maxCost parameter directly to generate the ERC20 context, eliminating the redundant calculation of the preFund amount in the paymaster contract.
6.6 Unused imports
The following interfaces are imported but never used.
SingletonPaymasterV6.sol
import { IEntryPoint } from "@account-abstraction-v6/interfaces/IEntryPoint.sol"
MultiSigner.sol
import { IManagerAccessControl } from "./ManagerAccessControl.sol";
import { IERC165 } from "@openzeppelin-v5.0.2/contracts/utils/introspection/IERC165.sol";
BasePaymaster.sol
import { IManagerAccessControl } from "./ManagerAccessControl.sol";
import { IERC165 } from "@openzeppelin-v5.0.2/contracts/utils/introspection/IERC165.sol";
import { MultiSigner } from "./MultiSigner.sol";
Recommendation
Remove unused imports.
