Introducing OpenZeppelin Contracts 5.7: Account Abstraction Paymasters, Crosschain Token Bridges, and New Deployment Primitives

OpenZeppelin Contracts 5.7 is now available. This release expands the library in three directions that reflect where onchain development is heading: sponsored transactions through a full suite of ERC-4337 paymasters, crosschain movement of non-fungible and multi-token assets, and a set of new utilities for deterministic deployment and safer contract interaction.

As with every release, each addition follows the same principle that has guided OpenZeppelin Contracts for a decade: provide secure, audited, and battle-tested building blocks so developers do not have to reinvent security-critical infrastructure. The library now underpins more than $36 trillion in value transferred onchain, and this release continues to raise that standard.

Here is what is new in 5.7.

A Complete Paymaster Suite for Account Abstraction

With ERC-4337 now finalized, sponsored transactions are moving from experimentation to production. Version 5.7 introduces a modular paymaster framework that covers the most common sponsorship models out of the box:

• Paymaster: A minimal base implementation of an ERC-4337 paymaster, designed to be extended.
• PaymasterERC20: Sponsors user operations in exchange for payment in ERC-20 tokens, enabling gas payment in stablecoins or any other token.
• PaymasterERC20Guarantor: Extends the ERC-20 model by allowing third parties to guarantee user operations, prefunding gas costs upfront with repayment handling for successful operations.
• PaymasterERC721Owner: Approves sponsorship based on ownership of an ERC-721 token, useful for membership or access-pass models.
• PaymasterSigner: Approves sponsorship based on a cryptographic signature verified by the paymaster, the standard pattern for centralized sponsorship services.

Each variant addresses a distinct trust model, and all of them inherit the same audited base. Rather than writing custom sponsorship logic, developers can now compose these extensions and focus on their application.

Alongside the paymaster suite, the ERC-4337 files have dropped their draft- prefix to reflect the finalized standard. Imports must be updated from account/utils/draft-ERC4337Utils.sol to account/utils/ERC4337Utils.sol, and from interfaces/draft-IERC4337.sol to interfaces/IERC4337.sol.

Crosschain Support Extends to ERC-721 and ERC-1155

Version 5.6 introduced fungible token bridging built on ERC-7786. Version 5.7 completes the picture for the remaining token standards:

• BridgeERC721: A bridge contract that handles crosschain movement of ERC-721 tokens.
• BridgeERC1155: An equivalent bridge contract for ERC-1155 tokens.
• ERC721Crosschain and ERC1155Crosschain: Token extensions that embed an ERC-7786 based bridge directly in the token contract, removing the need for a separate bridge deployment.

Crosschain governance also takes a step forward. The new CrosschainRemoteExecutor relays transactions from a controller on a remote chain, and GovernorCrosschain is a governor module that facilitates the execution of crosschain operations through remote executors and ERC-7786 gateways. Together, they allow any smart contract on one chain, whether a governor, an account, or another controller, to govern contracts deployed on another, using standardized messaging rather than bespoke integrations. The same architecture enables accounts that effectively live crosschain, controlling remote executors from a single home chain.

Bridges remain among the most heavily exploited components in the industry. Providing standardized, audited implementations for every major token standard is a direct response to that risk.

New Utilities for Deployment, Rate Limiting, and Safe Interaction

The Utils section receives five new libraries, several of which address long-standing gaps in the deployment and interaction toolkit:

• Create3: Deploys contracts using the CREATE3 mechanism, where the deployment address depends only on the salt and the deployer, independently of the deployed bytecode. This makes consistent multi-chain addresses practical even when bytecode differs across compiler versions or chains.
• ERC1967Clones: Deploys minimal ERC-1967 proxies via CREATE or CREATE2, complementing the existing Clones library with an upgradeable-compatible storage layout.
• RateLimiter: Primitives for limiting the rate at which an action can be performed, with two complementary strategies: a refilling token bucket and a sliding window counter. Rate limiting is a common requirement for bridges, minting schedules, and withdrawal controls, and until now most teams implemented it from scratch.
• SimulateCall: Call simulation utilities that allow inspecting return data from contract calls by executing them in a non-mutating, revert-based context.
• BlockHeader: A library for verifying and parsing block headers, a building block for trust-minimized crosschain and historical-state proofs.

On the token side, ERC20TransferAuthorization implements ERC-3009 transfers with authorization using parallel nonces, the pattern popularized by major stablecoins for gasless transfers. SafeERC20 gains a tryGetDecimals helper that safely queries a token's decimals() without reverting, and the ERC-6909 extensions now support ERC-165 interface detection.

Hardening Across Access Control, Governance, and Meta-Transactions

Beyond new features, 5.7 includes a series of defensive improvements:

• AccessManager now treats setAuthority differently in canCall, preventing a path where the updateAuthority security could be bypassed through an execute call.
• Governor strictly enforces the expected proposal state depending on proposalNeedsQueuing when calling execute, and replaces GovernorQueueNotImplemented with the more precise GovernorProposalQueueingNotRequired and GovernorProposalQueueingFailed errors.
• ERC2771Forwarder now reverts the entire atomic batch if a call with value fails, closing an inconsistency in partial batch execution.
• WebAuthn verification returns false instead of reverting on out-of-bounds challenge indices, and ERC7913WebAuthnVerifier adds an overridable _requireUV check.
• Arrays reduces reliance on recursion to prevent stack overflow and support larger arrays, and several memory-safety refinements land in Memory, RLP, and InteroperableAddress.

Deprecations and Breaking Changes

Two items deserve attention when upgrading:

• The at function in Checkpoints, DoubleEndedQueue, EnumerableMap, and EnumerableSet is deprecated in favor of new pos functions for accessing a specific index. The change follows Solidity's introduction of at as a reserved keyword, which triggers compiler warnings when the function name is used.
• The Governor error replacement noted above is a breaking change for integrations that match on GovernorQueueNotImplemented.

Both changes follow the library's standard deprecation practice: clear migration paths, documented in the changelog, with backward compatibility preserved wherever possible.

Getting Started

OpenZeppelin Contracts 5.7 is available now:

npm install @openzeppelin/contracts@5.7.0

The full changelog, including every pull request referenced in this post, is available on GitHub. As always, the library is open source, and contributions, issues, and feedback from the community shape every release.

Security reviews for this release followed the same process applied to every version of the library. If your team is deploying contracts that manage significant value, we encourage pairing the library with a dedicated security review of your integration, since the most common vulnerabilities arise in application logic rather than in the primitives themselves.