Smart Contract Analysis Statement

Contract Analysis

The ATSRemotePaymaster v2 contract is a revision of the previously audited cross-chain ERC-4337 v0.8 paymaster. It pays the gas of operations on a destination chain without taking any token there, because the user has already paid in ATS on BSC through the ATSGasCollector. The paymaster only checks a signature from a trusted backend key that vouches for that payment, together with an absolute per-operation gas cap set by the owner and a per-operation cap signed by the backend. The paymaster data layout and the signed digest are unchanged from the first audit. New in v2 are mandatory signature windows: every authorisation must state a start and an end time at most one hour apart. The re-audit covered the source verified on Sourcify with an exact match on Arbitrum Sepolia, Base Sepolia and Polygon Amoy; all three deployments share one source tree.

Ownership Privileges

The ownership is held through a two-step handover. On the three v2 testnet deployments the owner is still the deploying EOA and no transfer is pending; for mainnet the team intends the same 2-of-3 Safe that owns the legacy contracts. The owner retains the following privileges:

• Setting and rotating the backend signer; rotation invalidates every signature of the previous key
• Setting the absolute per-operation gas cap, where zero keeps sponsorship closed
• Pausing and resuming all sponsorship
• Withdrawing the EntryPoint deposit and any stake
• The owner cannot renounce ownership
• No owner action takes effect with a delay, as no timelock is in place

Security Features

The contract implements several positive security features:

• Every authorisation must carry an explicit window of at most one hour, so leaked, hoarded or pre-rotation signatures expire on their own
• Signatures are bound to the full operation, the chain id and the paymaster address, which rules out replay across operations, chains and contracts
• Invalid signatures return a failed-signature result instead of reverting, while malformed data and owner policy revert with custom errors
• Fail-closed defaults: sponsorship stays closed until the owner sets both a signer and a gas cap
• No post-operation logic, no token handling and no rescue function, which keeps the attack surface minimal
• The trust model, the limits of maxCostCap and the off-chain nature of settlementId are documented plainly in English NatSpec

Re-audit Outcome

The reverting signature check, the documentation of maxCostCap and settlementId, the custom errors and the English documentation are fixed. The central trust concern is acknowledged by design and only partially mitigated: the new signature windows stop old signatures from living on, but whoever holds the backend key can still sign fresh operations for accounts they control and collect the gas as bundle beneficiary until the deposit is empty, which we confirmed again in testing. No on-chain budget was added. On the testnets the same backend EOA signs for both paymasters on every chain, and it is the same key that controls the still-funded legacy remote paymasters. Keeping the deposits small, moving the key to KMS or HSM custody and using a separate signer per chain and paymaster remain the main controls. No new vulnerability was introduced by the changes, and Slither and Aderyn reported no new valid issue.

Note - This re-audit report consists of a security analysis of the ATSRemotePaymaster v2 smart contract. This analysis did not include economic analysis of the contract's tokenomics. Moreover, we only audited the main contract for the ATSRemotePaymaster team. Other contracts associated with the project were not audited by our team. The legacy remote paymasters remain deployed and funded on mainnet until the v2 contracts replace them. We recommend investors do their own research before investing.