ERC-7779 is an Ethereum standard that extends ERC-7715 permission grants for smart accounts with cross-chain portability. Under ERC-7779, a permission granted on one EVM chain, such as allowing a specific dapp session key to spend up to 100 USDC, can be cryptographically verified and enforced on any other EVM chain without the user signing a new permission grant. The EIP was drafted by Moody Salem and Lukas Rosario in 2024 and sits within the ERC-7715 permissions ecosystem.
​

The practical problem this solves is friction. A user who has granted a dapp permission to execute on their behalf on Ethereum must re-sign that grant for Arbitrum, Base, and Optimism separately if the dapp needs to act cross-chain. For session-based applications, such as games, DeFi automation, or AI agents acting on a user's wallet, this per-chain signature requirement compounds quickly. ERC-7779 introduces a proof standard that lets the permission granted on the source chain serve as the credential on every other chain.
​

ERC-7715 is a standard for requesting and granting scoped permissions on EVM smart accounts. A permission is a signed statement that authorizes a specific caller, such as a dapp's session key, to perform a bounded set of actions on the user's smart account. Permissions can be scoped by token, amount, contract, function selector, and time window, giving users fine-grained control over what a dapp can do without exposing the full account.
​

The ERC-7715 specification defines a grantPermissions function that a smart account exposes to wallets and dapps. The return value is a signed permission object containing the signer address, the permission scope struct, and a chain ID. That chain ID field is the key constraint: under ERC-7715 alone, a permission is valid only on the chain where it was granted. ERC-7779 removes that constraint by adding a cross-chain proof root to the permission object.
​

Permissions under ERC-7715 are enforced at the smart account validator level. When a dapp submits a user operation signed by a session key, the account's permission validator module checks the session key against the stored permission grant, verifies that the action falls within scope, and approves or rejects the operation. This validator pattern is native to ERC-4337 account abstraction, where the validateUserOp entrypoint allows custom validation logic to be plugged into the account.
​

ERC-7779 extends the ERC-7715 permission object with a crossChainProofRoot field and specifies how that root is constructed and verified on destination chains. When a permission is granted on the source chain, the wallet signs not only the permission scope but also a Merkle root that commits to which destination chains the permission is valid on. A verifier on any of those destination chains can check the proof against the root without contacting the source chain.
​

The proof construction follows a Merkle tree pattern where each leaf encodes a (chainId, accountAddress, sessionKeyAddress) tuple. The root is committed in the permission object signed by the user's account key. On the destination chain, the MEE provider or solver submits the original signed permission plus a Merkle proof path for the destination chain's leaf. The smart account's permission validator re-derives the root from the proof path and compares it to the signed root. A match proves that the user authorized this session key on this destination chain at the time of the original grant.
​

The ERC-7779 draft specification specifies that the crossChainProofRoot must be included in the domain separator of the EIP-712 typed-data signature, binding the proof to the specific signer and context. This prevents a proof issued for one session key from being replayed under a different session key on the same destination chain. The nonce management rules in ERC-7779 also prevent a valid proof from being replayed after the session window expires.
​

ERC-7779 requires that a cross-chain permission carry a verifiable Merkle proof at the time of use on the destination chain. The proof must be submitted alongside the user operation or transaction that exercises the permission. The destination chain's permission validator re-derives the Merkle root from the proof path and checks it against the signed root in the permission object. If the root does not match, the validator rejects the operation as unauthorized.
​

The cryptographic design uses standard keccak256 hashing, the same hash function used throughout EVM state trees, making the verification logic gas-efficient and compatible with existing smart account modules. The ERC-7779 discussion thread notes that a four-chain inclusion proof costs approximately 3,200 gas to verify on a destination chain, measured against the Ethereum Cancun opcode pricing. For an eight-chain proof the estimate is approximately 5,600 gas, which remains within the validator budget of most ERC-4337-compliant accounts.
​

One constraint the EIP acknowledges is that the set of authorized destination chains must be committed at grant time. A permission granted for Ethereum, Base, and Arbitrum cannot later be extended to Optimism without the user signing a new permission object. This is intentional: the security model requires the user's signature to explicitly enumerate every chain where the session key is valid, preventing incremental scope expansion after the original grant.
​

ERC-7779's primary use cases are session-based applications where a dapp or agent needs to act on a user's behalf across multiple chains during a defined time window, without prompting the user for repeated approvals.
​

Cross-chain DeFi automation is the most common scenario. A user who wants a yield-optimization agent to rebalance positions across Aave on Ethereum, Morpho on Base, and Kamino on a bridged settlement layer currently must either grant each protocol a separate permission per chain or give the agent a broader key that exceeds the minimum-privilege principle. ERC-7779 lets the user define a single scoped permission, for example "call the rebalance function on contracts X, Y, Z with a spend cap of 5,000 USDC per day," and have that permission verified on all three chains from one signature.
​

AI agent wallets represent a second emerging use case. The ERC-7715 permission model was explicitly designed for agent-controlled smart accounts where an agent holds a session key and the user holds the root account key. ERC-7779 extends this model so an agent operating across chains can prove authority on each chain from the same session grant. This is particularly relevant for Multi-chain Execution Engine (MEE) providers that coordinate user operations across chains, where the MEE needs to present proof of permission on whichever chain it selects for execution.
​

Cross-chain gaming and subscription services are a third category. A game that runs its economy on one chain but its gameplay on another can grant a session key permission to spend in-game tokens on both chains from one user approval at the session start. A subscription smart contract that bills monthly across chains can verify the same permission on each chain where a billing event occurs, rather than requiring re-authorization each billing cycle.
​

Multi-chain Execution Engine (MEE) providers orchestrate user operations across multiple EVM chains, abstracting gas payments, sequencing, and bridge selection from the user. ERC-7779 is directly relevant to MEE architecture because the MEE acts as the entity submitting user operations on destination chains, and it needs to prove authorization for each chain independently.
​

Without ERC-7779, an MEE provider that receives a user's signed operation for Chain A must either request a separate signed operation for Chain B or hold a broad key that covers both chains. The broad-key approach weakens the security model; the separate-signature approach creates latency and UX friction. ERC-7779 lets the MEE carry the cross-chain proof as part of the original user operation payload, so it can execute on Chain B immediately after Chain A without a round-trip to the user.
​

The interaction pattern between ERC-7779 and MEE providers follows the ERC-4337 bundler model. The MEE acts as a bundler: it receives a user operation, augments it with the cross-chain proof for the destination chain, and submits it to the smart account's entrypoint on that chain. The entrypoint calls validateUserOp, which invokes the permission validator module, which checks the ERC-7779 proof. If valid, the operation proceeds. This design requires MEE providers to cache the full permission object, not just the operation, so the proof path is available at submission time.
​

Eco's cross-chain stablecoin routing infrastructure operates as a layer through which MEE-style execution flows. When a dapp built on ERC-4337 smart accounts submits a cross-chain transfer through Eco Routes, the permission model governing the transfer agent's authority is precisely the space ERC-7779 addresses. As MEE providers adopt ERC-7779, the permission proof becomes a standard payload component that routing infrastructure can pass through without modification.
​

ERC-7779 is designed for smart accounts and uses the ERC-4337 validator module pattern for permission checking. It does not require ERC-4337 at the protocol level; any smart account that implements the IPermissionValidator interface can use ERC-7779 cross-chain proofs. Externally owned accounts cannot use ERC-7779 directly because they lack an on-chain permission module. See ERC-4337 account abstraction for how smart account validation works.
​

Revocation in ERC-7779 follows ERC-7715's revocation model: the user calls revokePermission on the source chain, which increments the account's permission nonce. Any proof carrying the old nonce becomes invalid. Because destination chains check the proof against the signed root, which includes the nonce, they reject operations that use a revoked permission even without a direct cross-chain message. Revocation propagates through nonce invalidation, not through a cross-chain call.
​

If the destination chain's chainId is not committed in the Merkle root at grant time, no valid proof path exists for that chain. Any attempt to submit the permission on that chain will fail the Merkle root derivation check and be rejected by the permission validator. The user must grant a new permission that includes the additional chain. This is a deliberate security constraint in the ERC-7779 specification.
​

ERC-7779 is in draft status as of April 2026. No mainnet smart account wallet has formally shipped ERC-7779 support, though the ERC-7715 permissions ecosystem it builds on is actively being implemented by wallet providers including Safe and Biconomy. The ERC-7779 EIP draft is open for community review and the gas cost benchmarks are based on testnet measurements.
​

Sources and methodology. EIP text for ERC-7715 and ERC-7779 verified against the Ethereum EIPs repository on April 30, 2026. Gas cost estimates sourced from the ERC-7779 GitHub discussion thread. No live market-data figures from the snapshot were required for this article.
​