ERC-7785 is an Ethereum standard that lets smart contracts lock ERC-20 token balances for a specific purpose — such as paying transaction gas fees or settling a cross-chain intent — without requiring a full token transfer. The locked amount remains in the holder's wallet but is ring-fenced: only the designated locker contract can claim it, and only for the declared use case. The proposal targets two concrete pain points in 2026 Ethereum: account abstraction paymasters that need capital commitment before gas execution, and cross-chain intent systems that need collateral reserved during a settlement window.
​

The ERC-7785 specification describes the interface as two core functions: lock(address locker, uint256 amount, bytes calldata data) to reserve funds, and unlock(address holder, uint256 amount) to release them. A separate lockedBalanceOf(address holder, address locker) view returns how much a given holder has reserved for a given contract. The standard is composable: a single holder can have multiple concurrent locks across different locker addresses, each with its own reserved amount and release condition.
​

ERC-7785 is a token-level locking standard that reserves a portion of an ERC-20 balance for a specific contract without moving tokens out of the holder's address. No escrow takes custody. Locks are created by the holder's explicit lock() call, and the transferable balance equals total balance minus all active locks.
​

Compared to ERC-20 token allowances, which grant open-ended permission to pull any amount up to a ceiling, ERC-7785 locks commit a specific amount for a specific purpose. An allowance of 1,000 USDC to a paymaster contract means the paymaster can drain 1,000 USDC at any time for any reason. A lock of 5 USDC to the same paymaster for a specific transaction bundle means exactly 5 USDC is reserved, and only for that bundle; the paymaster cannot exceed it. This precision matters for user trust and for building composable financial abstractions where multiple systems need simultaneous capital guarantees.
​

The ERC-7785 mechanism has three states: open (full balance freely transferable), locked (amount reserved against a locker address), and settled (locker calls claim() to consume, or holder calls unlock() after expiry). A lock() call transitions a specific amount to locked with optional metadata in the data parameter binding the lock to a purpose.
​

The mechanics work as follows. Suppose a user holds 100 USDC in a smart account and wants to pay for a batch of ERC-4337 UserOperations using USDC. The paymaster calls the user's ERC-7785-compatible token to lock 12 USDC before submitting the bundle to the EntryPoint. During bundle execution, transfer() calls on the token check that the user's free balance (88 USDC in this case) is sufficient; the locked 12 USDC cannot be spent on anything else. Once the EntryPoint confirms execution, the paymaster calls claim(locker=paymaster, amount=12). If execution fails, the lock expires per the pre-committed timeout and the user calls unlock() to recover the 12 USDC.
​

The EIP specification allows the locker to pass arbitrary bytes in the data parameter. This extension point enables locking for typed payloads: a cross-chain intent protocol can pass a hash of the intent order in the data field, so the lock is semantically bound to that specific order and not reusable for a different one.
​

ERC-7785 was designed with ERC-4337 account abstraction in mind. In ERC-4337, a paymaster contract sponsors UserOperation gas fees on behalf of a user, and the EntryPoint contract calls validatePaymasterUserOp before execution. Without a resource lock, the paymaster must either hold its own capital float or rely on a broad token allowance from the user, both of which have capital efficiency or trust drawbacks.
​

With ERC-7785, the paymaster can require a pre-execution lock as part of its validation logic. The flow integrates with the ERC-4337 account abstraction lifecycle at the validatePaymasterUserOp step: the paymaster reads the user's locked balance via lockedBalanceOf, confirms the reserved amount covers the estimated gas cost, and proceeds. Because the locked amount cannot be moved by the user between validation and execution (the token contract enforces this in _beforeTokenTransfer), the paymaster has a hard guarantee that gas capital is available when the EntryPoint calls postOp to settle.
​

This is meaningfully different from prior paymaster designs. Pimlico's ERC-4337 paymaster infrastructure and the Alchemy modular account system both require the paymaster to hold an internal deposit at the EntryPoint contract, funded from the paymaster's own treasury. ERC-7785 allows the gas capital to remain in the user's own token balance, reducing the paymaster's required float. At scale, with ERC-4337 processing over 3 million UserOperations per month across major chains as of Q1 2026 (per BundleBear UserOp analytics), the float reduction across thousands of concurrent sessions compounds into meaningful capital savings for paymaster operators.
​

Cross-chain intent settlement requires a solver to commit output capital on the destination chain before the origin chain releases the user's tokens. ERC-7785 provides the locking primitive that makes this commitment verifiable onchain: a solver locks output tokens before signing the intent fill, giving the origin chain's settlement contract a proof of reserved liquidity.
​

The flow in a system like Across Protocol or a compatible intent settlement network works as follows:

Without ERC-7785, solvers either need to hold large liquidity floats or rely on post-hoc proofs that introduce latency. The lock primitive reduces the trust window from minutes (waiting for origin finality) to seconds (waiting for lock confirmation on the destination chain). Eco's cross-chain routing infrastructure, which settles stablecoin transfers across 15 chains, aligns with this intent settlement architecture; ERC-7785 is the token-layer primitive that makes solver capital commitments auditable without custodying funds.
​

ERC-7785 locks differ from ERC-20 allowances in scope, reversibility, and precision. An allowance is a blanket permission with no purpose binding; an ERC-7785 lock is a time-bounded, purpose-bound reservation. Both leave tokens in the holder's wallet, but only ERC-7785 prevents the holder from spending the reserved amount elsewhere during the lock window.
​

The table below compares the four main mechanisms for committing ERC-20 capital to a contract.
​

The key differentiator is that ERC-7785 preserves holder custody while providing a contract-verifiable guarantee. ERC-20 approve gives the spender an open permission to pull, which creates the well-documented approval exploit surface where malicious contracts drain allowances. ERC-7785 limits the spender to exactly the locked amount for exactly the declared purpose, and the lock expires if the locker does not claim within the timeout. Projects like Permit2 (Uniswap's cross-protocol signature-based approval standard) moved toward tighter scoping for similar reasons; ERC-7785 takes the next step by making the scope enforceable at the token contract level rather than at the approval-router level.
​

ERC-7785 requires the token contract itself to implement the locking interface, which USDC and USDT as deployed on Ethereum mainnet today do not. Developers have two options: a wrapper contract that holds the underlying token and issues a locking-aware version, or a protocol-level adapter that enforces the lock through a separate accounting layer without changing the token itself.
​

The wrapper approach is the simpler path. A WrappedUSDC contract accepts USDC deposits and issues wrapped tokens that implement the ERC-7785 interface. Paymaster and intent systems interact with the wrapper token rather than the underlying USDC. The drawback is fragmentation: wrapped tokens require liquidity incentives to gain adoption and introduce a custody layer (the wrapper contract holds the underlying USDC).
​

The protocol adapter approach avoids wrapping by implementing ERC-7785's accounting in the application layer rather than the token layer. The paymaster or intent contract maintains its own mapping of locked amounts per user per purpose, enforced during the settlement step rather than during token transfer. This approach is less permissive (the token contract does not enforce the lock, so a malicious transaction could transfer the underlying USDC between validation and settlement if the paymaster is not carefully designed), but it avoids the liquidity fragmentation problem.
​

Native stablecoin issuers, including Circle for USDC, have discussed adding programmable transfer restrictions to future token versions. An ERC-7785-compatible USDC would enable paymasters and intent solvers to use the full locking primitive without a wrapper. As of Q1 2026, Circle's USDC circulates at $77.3B across multiple chains (DeFiLlama stablecoin data, April 2026); even a fraction of that supply flowing through ERC-7785-aware systems would represent meaningful adoption of the primitive.
​

ERC-7683 defines a canonical order format for cross-chain intents; ERC-7785 provides the capital reservation primitive solvers need when filling those orders. ERC-7683 standardizes the schema so any solver can parse any intent; ERC-7785 standardizes how a solver proves it has committed output capital before the origin chain releases input funds.
​

In a combined ERC-7683 plus ERC-7785 flow, the user signs an ERC-7683 GaslessCrossChainOrder specifying input token, output token, amounts, and deadline. A solver that wants to fill the order calls lock(intentSettler, outputAmount, keccak256(orderHash)) on the destination chain's token. This lock can be read (via a cross-chain message or an optimistic attestation) by the origin chain's settlement contract as proof that the solver has committed the output. The origin chain then releases the input tokens and the solver claims the lock on the destination chain atomically with the settlement.
​

The Across Protocol contracts on GitHub implement an earlier version of this pattern using their own capital commitment interface. ERC-7785 generalizes that interface so any intent protocol, not just Across, can use a common lock standard. As of Q1 2026, Across had settled over $12B in cross-chain volume; ERC-7785 adoption would allow that capital commitment pattern to be reused by any protocol building on the ERC-7683 order standard without a custom lock implementation.
​

ERC-7785 introduces three security surfaces that ERC-20 tokens do not have: the locker contract trust model, lock expiry race conditions, and free-balance miscalculation in transfer hooks. Auditors reviewing ERC-7785 integrations should verify that the token contract correctly enforces the free-balance ceiling, that lock expiry times are not manipulable by block producers, and that the locker contract cannot re-lock funds after claiming.
​

The most common misconfiguration is a transfer hook that reads balanceOf instead of freeBalanceOf. If the token contract's _beforeTokenTransfer does not subtract locked amounts from the spendable ceiling, a user can transfer their full balance even while a lock is active, leaving the locker with a claim against an empty wallet. The specification requires token implementors to define a freeBalanceOf(address holder) function that returns balanceOf(holder) - totalLockedBy(holder), and to use this value in the transfer guard.
​

Lock expiry race conditions arise in high-throughput scenarios. If a lock expires at block N and the locker's claim() transaction and the holder's unlock() transaction are both submitted in block N, the outcome depends on transaction ordering within the block. ERC-7785 implementations should use a grace period of at least 1 block (approximately 12 seconds on Ethereum mainnet) after nominal expiry before the holder can call unlock(), giving the locker time to claim first. The Ethereum MEV documentation discusses block-ordering assumptions relevant to any time-sensitive onchain finality claim.
​

ERC-7785 directly addresses stablecoin payment systems that require capital pre-commitment before funds release. A solver can lock 99.5 USDC for a 100 USDC transfer intent in one destination-chain transaction, giving the settlement contract a verifiable proof of committed funds before the origin chain releases its input USDC. No float is held at the protocol level.
​

For enterprise treasury teams, ERC-7785 enables a new pattern for scheduled payments. A corporate treasury contract holds 1M USDC for vendor payouts due at end of month. Rather than pre-approving each vendor contract to pull up to 1M USDC — creating an approval surface across dozens of vendor addresses — the treasury can lock specific amounts for specific vendor contracts on specific dates. Each vendor's lock is visible onchain, auditable by the company's finance team, and bounded to the declared invoice amount. This is meaningfully different from the approval patterns that enterprise EVM wallets like Gnosis Safe have relied on, which provide no per-vendor spending guarantees at the token level.
​

Eco's stablecoin routing infrastructure, which routes USDC and other stablecoins across 15 chains, benefits from the ERC-7785 pattern in cross-chain payment contexts. A payment initiated on Ethereum that settles in USDC on Base requires a solver to reserve Base USDC before the Ethereum input releases. ERC-7785-native USDC on Base would make that reservation verifiable at the token layer, tightening the trust model for all parties in the settlement flow — user, solver, and routing infrastructure alike.
​

A minimal ERC-7785 deployment adds three functions to an existing ERC-20 contract: lock(), unlock(), and freeBalanceOf(). The deployment also modifies _beforeTokenTransfer to use freeBalanceOf instead of balanceOf as the spendable ceiling. That modification is the most critical and most error-prone step, because any ERC-20 fork that does not update all transfer-guard paths to use the free balance creates the silent drain vulnerability described in the security section.
​

A practical deployment follows four steps. First, inherit the ERC-7785 interface alongside ERC-20. Second, add a mapping(address holder => mapping(address locker => uint256 amount)) private _locks storage variable and a mapping(address holder => uint256 total) private _totalLocked for efficient free-balance computation. Third, implement lock() with a free-balance check before writing to _locks. Fourth, update _beforeTokenTransfer to check balanceOf(sender) - _totalLocked[sender] >= amount.
​

Projects shipping ERC-7785 tokens should additionally emit a Locked(address indexed holder, address indexed locker, uint256 amount, bytes data) event on every successful lock call, and an Unlocked or Claimed event on resolution. These events allow block explorers, wallet providers, and auditing tools to index the complete lock history without reading contract storage directly. The EIP-7785 specification includes a recommended event interface that implementors should follow to maintain interoperability with indexing infrastructure.
​

OpenZeppelin has discussed adding an ERC-7785 module to its contracts library, which would allow projects to add locking support to an existing ERC-20 in two lines: one import and one mixin. Until an audited reference implementation ships, projects should treat ERC-7785 as pre-production and budget for a full audit of the transfer-hook modifications, which are the highest-risk surface in any ERC-20 extension.
​

Sources and methodology. ERC-7785 specification details from the Ethereum Improvement Proposals repository. ERC-4337 UserOperation volume from BundleBear, Q1 2026. Across Protocol intent settlement mechanics from across.to documentation. Permit2 source from Uniswap/permit2 GitHub. Protocol figures as of Q1 2026.
​

By Eco research. Updated Apr 2026.
​

An ERC-20 allowance lets a contract pull any amount up to a ceiling at any time. An ERC-7785 lock reserves a specific amount for a specific contract and purpose, and prevents the holder from spending that amount elsewhere during the lock window. The lock expires automatically if the locker does not claim it within the set timeout.
​

Yes. ERC-7785 extends ERC-20 without breaking the base interface. Standard wallets and DeFi protocols interact with the token normally. The locking layer only activates when a contract explicitly calls lock(). A holder's free balance behaves identically to a normal ERC-20 balance for all standard transfer and approval operations.
​

Yes. ERC-7785 supports multiple concurrent locks from different locker addresses. Each lock is tracked separately by lockedBalanceOf(holder, locker). The transferable ceiling is the holder's total balance minus the sum of all active locks. If concurrent locks exceed the total balance, the lock() call should revert, so the token contract must validate available free balance before accepting a new lock.
​

Without ERC-7785, a paymaster holds a deposit at the ERC-4337 EntryPoint to cover gas for users, requiring it to maintain a capital float. With ERC-7785, the capital stays in the user's own wallet and is locked just before the transaction bundle executes. The paymaster reads the locked balance as a hard guarantee and never needs to hold its own float for that user's session, reducing paymaster capital requirements at scale.
​