ERC-7841 proposes a standard envelope format for EVM transactions that can be submitted to any compatible chain without reformatting. The envelope defines a fixed set of fields, including to, data, value, gas, and chainIds, where chainIds is a list rather than a single value. A solver or router that receives an ERC-7841 envelope decides which chain to execute on and constructs the chain-specific transaction internally, without going back to the originating dapp or user. The EIP was drafted in 2024 and targets intent-based execution systems that need to decouple transaction formatting from chain selection.
​

The core problem ERC-7841 addresses is that current EVM transaction formats are chain-specific by design. EIP-1559 transactions include a chainId field that is part of the signed payload, meaning a transaction signed for Ethereum cannot be submitted to Arbitrum or Base without a new signature. For users and dapps interacting with cross-chain intent systems, this means the signing step must be deferred until the chain is known, or separate signatures must be collected per chain. ERC-7841 restructures the problem: the user signs the envelope, and chain selection happens downstream at execution time.
​

The ERC-7841 envelope is an EIP-712 typed structure containing six top-level fields: to (destination address), data (calldata bytes), value (ETH amount in wei), gas (maximum gas units), chainIds (uint256 array of acceptable destination chains), and nonce (anti-replay identifier scoped to the envelope signer). The user signs this structure once; the signature is valid for execution on any chain listed in chainIds, subject to nonce state.
​

The ERC-7841 specification specifies that chainIds must be non-empty and must contain only chains where the to address is deployed and the calldata is semantically valid. The envelope does not include a fee field because the solver is responsible for paying gas on the execution chain and recovering costs through the solver's own settlement mechanism, typically from a separate payment commitment or through an ERC-7683 order structure.
​

The nonce in ERC-7841 is not the account's transaction nonce. It is an envelope-level nonce managed by an envelope registry contract, similar to the permit nonce pattern in EIP-2612. This means an ERC-7841 envelope can be invalidated without consuming an account transaction nonce, which matters for intent-based systems where the user may want to cancel a pending envelope without disrupting other pending transactions from the same account.
​

A solver receives an ERC-7841 envelope, evaluates the chainIds list against current gas prices, liquidity conditions, and its own chain presence, selects the optimal chain, constructs a standard EIP-1559 or EIP-4844 transaction targeting that chain, and submits it to the chain's mempool or sequencer. The solver includes the original signed envelope in the transaction's calldata or as a proof payload so the execution contract can verify the user's authorization.
​

The execution contract on the destination chain validates the EIP-712 signature over the envelope fields, confirms that the executed chain's chainId appears in the chainIds array, checks the envelope nonce against the registry, and executes the calldata. If any check fails, the transaction reverts. The ERC-7841 pull request includes a reference implementation of this validation logic in approximately 80 lines of Solidity.
​

Solver economics under ERC-7841 follow the same model as other intent-based systems. The solver fronts gas on the execution chain and receives compensation through the settlement layer. For cross-chain intents, the compensation typically comes from the ERC-7683 order fill flow, where the filler marks the fill on the destination chain and claims the input tokens on the source chain after a settlement window. ERC-7841 can be used as the execution layer within an ERC-7683 order: the order defines the payment terms, and the ERC-7841 envelope defines the execution action.
​

Current EVM transaction formats, defined by EIP-155 (replay protection), EIP-1559 (fee market), and EIP-4844 (blob transactions), all embed a single chainId in the signed payload. This design was intentional for security: signing a transaction for one chain should not produce a valid transaction for another. ERC-7841 achieves the same security goal differently, by making the chainIds list part of the signed payload and requiring destination chain validation at execution time. The signature is over the entire envelope including all permitted chains, so a solver cannot execute on a chain the user did not authorize.
​

The table below compares ERC-7841 envelopes to current EVM transaction types across the dimensions most relevant to cross-chain execution.
​

The mempool row is significant. ERC-7841 envelopes are not broadcast to the public mempool. They are submitted to a solver network, either through a private order flow channel or through a public intent mempool such as those operated by ERC-7683 infrastructure. This means ERC-7841 execution does not benefit from the decentralization guarantees of the public mempool, but it also means the user is not exposed to MEV frontrunning on the target chain selection.
​

ERC-7683 defines a standard for cross-chain intents: a user specifies an input token, an output token, and a destination chain, and a filler network executes the intent and claims the input tokens as payment. ERC-7841 addresses a different problem layer: it standardizes what the execution action looks like, not the settlement payment structure. The two standards are designed to compose, with ERC-7683 handling the financial settlement and ERC-7841 handling the execution payload.
​

The composition pattern works as follows. A user creates an ERC-7683 open order that specifies payment terms (input: 1,000 USDC on Ethereum; output: equivalent on destination chain within 60 seconds). The orderData field of the ERC-7683 order embeds an ERC-7841 envelope that defines what action the filler must execute on the destination chain to satisfy the order. The filler selects a chain from the envelope's chainIds list, executes the action, and claims the input tokens through the ERC-7683 settlement contract on Ethereum.
​

The ERC-7683 specification deliberately leaves the orderData field open-ended to allow exactly this kind of composition. ERC-7841 is one of several candidate standards that can occupy that field. Alternative approaches include embedding a raw signed transaction per chain or using a custom bytes format, but these lack the chain-agnostic property that ERC-7841 provides.
​

The blockchain interoperability layer Eco operates is architecturally aligned with this composition model. Eco Routes processes cross-chain stablecoin transfers through Hyperlane, and the routing layer that decides which chain and which path to use maps to the solver selection step in ERC-7841. As intent-based transaction formats standardize around ERC-7841 and ERC-7683, routing infrastructure like Eco's can consume standard envelope inputs rather than custom per-integration formats, reducing integration overhead for dapps building cross-chain stablecoin flows.
​

ERC-7841 addresses transaction formatting but does not address several adjacent problems that cross-chain execution requires. State divergence is the most significant: if the to contract has different state on Ethereum versus Base at execution time, the same calldata may produce different outcomes. A solver executing on the cheaper chain may succeed with calldata that would revert on the user's preferred chain. ERC-7841 does not define how to handle this case, though it does allow the envelope to include a minimum-output or slippage parameter via the data field itself, pushed to the application layer.
​

Address consistency is a related constraint. The envelope specifies a single to address that must be valid on every chain in chainIds. For protocols deployed via deterministic CREATE2 at the same address across chains, this is straightforward. For protocols with chain-specific deployment addresses, the dapp must either restrict chainIds to chains where the address matches or build address-routing logic into the envelope's calldata. The ERC-7841 specification notes this limitation explicitly and recommends that callers use CREATE2-deployed contracts as the target for envelope transactions.
​

Gas estimation is also deferred to the solver. The envelope includes a gas field, but it represents the maximum the user authorizes, not an estimate. The solver must independently estimate gas on the target chain and ensure the limit is sufficient. If gas usage on the selected chain exceeds the envelope's gas field, the transaction reverts, and the solver absorbs the loss. This creates a soft incentive for solvers to select chains where gas estimates are below the envelope cap with a safety margin.
​

Yes. Setting chainIds to an array containing one element makes the envelope equivalent to a chain-specific transaction, except that the user does not pay gas directly and the envelope nonce is registry-managed. This is useful when a user wants to use the solver payment model but has a chain preference, for example to execute on a specific rollup that holds their funds without maintaining gas tokens on that chain.
​

If the execution reverts on the selected chain, the solver absorbs the gas cost. The envelope nonce is consumed on revert, so the user cannot replay the same envelope on a different chain without issuing a new envelope. Some implementations may define a re-execution allowance where the solver can retry on another chain from the chainIds list, but this behavior is not specified in the base ERC-7841 standard; it would be defined by the intent settlement contract embedding the envelope.
​

Meta-transactions, defined by EIP-2771, allow a user to sign an off-chain message that a trusted forwarder submits on-chain while paying gas. ERC-7841 is different: it is not limited to a single forwarder or a single chain, and it targets solver networks rather than gas relay networks. ERC-7841 envelopes also encode a full calldata action rather than a forwarded call, and the chainIds field has no equivalent in the EIP-2771 model. See the blockchain interoperability explainer for how meta-transactions and intent-based execution fit into the broader cross-chain stack.
​

No. ERC-7841 is a contract-level standard implemented entirely in smart contracts. The envelope registry and execution validation contract deploy on existing EVM chains without any protocol-level changes. The standard does not require a new transaction type in the sense of EIP-1559 or EIP-4844; it operates through normal EVM transactions submitted by solvers. This makes ERC-7841 deployable on any EVM chain immediately once the registry contracts are live.
​

ERC-7683 filler networks are a natural execution layer for ERC-7841 envelopes. A filler that already monitors cross-chain orders can extend its logic to consume ERC-7841 envelopes in the order's orderData field, select a chain from chainIds, execute, and claim via ERC-7683 settlement. The two standards compose without requiring modifications to either specification, which is why the ERC-7841 authors cite ERC-7683 as the intended settlement companion in the EIP.
​

Sources and methodology. EIP text for ERC-7841 and ERC-7683 verified against the Ethereum EIPs repository on April 30, 2026. Reference implementation line count verified against the ERC-7841 pull request. No live market-data figures from the snapshot were required for this article.
​