Transaction Friction

ERC-223 defines a tokenReceived callback for ERC-223 transfers to contracts. A compliant token transfer to a contract without the required handler reverts, while transfers to EOAs proceed without a callback. This can make compatible contract deposits one transaction, but it does not protect arbitrary wrong addresses, other token standards, or a recipient's business logic.

Stages: Executing Transactions

ERC-777 is a token standard with sender and recipient hooks plus operator permissions. It can support hook-aware transfers and operator-managed sends, but those semantics are different from ERC-1363 payable callbacks and ERC-4337 account-abstraction infrastructure. Treat adoption, integration, and hook reentrancy risk as separate design and security questions.

Stages: Approving & Permissioning, Executing Transactions

ERC-1363 defines transferAndCall and approveAndCall receiver interfaces for tokens and compatible contracts. When both sides implement the relevant callback, one transaction can transfer tokens and invoke a contract action; callback success does not by itself guarantee the business service outcome.

Stages: Executing Transactions, Gas & Fees

ERC-2612 adds an optional permit(owner, spender, value, deadline, v, r, s) path to an ERC-20 token. A signed permit can set an allowance without an approval transaction; an integrating router or relayer may combine that permit with an action, but the permit deadline only limits submission of the signature and does not expire the resulting allowance.

Stages: Approving & Permissioning, Executing Transactions

ERC-4337 supports smart-account flows that can offer sponsored fees, batched actions, or account recovery when the chosen implementation supports them. Show which options are available, who pays, and what happens if an operation fails. These features are not guaranteed by ERC-4337 alone.

Stages: Executing Transactions, Gas & Fees +1

EIP-5792 defines wallet_sendCalls, wallet_getCallsStatus, and wallet_getCapabilities for wallet-mediated call batches. Atomicity is capability- and request-dependent: use atomicRequired: true only when the wallet advertises the atomic capability for the target chain, and show the status result.

Stages: Executing Transactions, Status & Confirmation

EIP-7702 lets an existing externally owned account delegate execution to contract code while keeping its address. Delegation persists until replaced or cleared and gives the code unrestricted account access. The wallet must audit the code; applications must not request authorization signatures. Batching, sponsorship, and scoped app permissions depend on compatible wallet implementations.

Stages: Approving & Permissioning, Executing Transactions +1

EIP-7825 caps an Ethereum transaction's gas limit at 16,777,216 gas (2^24) on networks that activate it. Ethereum included the cap in Fusaka, which activated on mainnet on December 3, 2025. Large batch and deployment flows need a network-aware preflight and a recovery path that splits or redesigns oversized operations; eth_call is not subject to this transaction cap.

Stages: Executing Transactions, Gas & Fees +1

MIP-4 adds a precompile at 0x1001 with dippedIntoReserve(), which returns an ABI-encoded bool describing whether the current execution state has dipped into reserve across all accounts touched by the transaction. It is an in-execution contract check, not a reserve-amount query or a wallet preflight for an arbitrary unsigned transaction.

Stages: Asset Discovery & Display, Executing Transactions +1

ERC-5008 is the ERC-721 Nonce Extension. It exposes nonce(tokenId), and an implementation updates that nonce when a transfer or other relevant state change invalidates pending orders. It provides a stale-order and replay-protection signal; it does not define permit(), signatures, listing approval, an EIP-712 domain, or gasless NFT transfers.

Stages: Approving & Permissioning

ERC-5216 adds per-token-ID allowances to ERC-1155 contracts that implement the extension. A user can authorize an operator for a quantity of one token ID while keeping other IDs outside that allowance. It coexists with ERC-1155's broader setApprovalForAll operator permission, so the UI must show which mechanism the deployed collection supports and which scope the user is granting.

Stages: Approving & Permissioning

ERC-5453 builds on ERC-5750 to let an opted-in contract method accept endorsement data for a relayed call. It is not a universal permit for every function: the target contract must implement the relevant method and final bytes extraData shape, and execution/atomicity remain contract and relayer behavior.

Stages: Approving & Permissioning, Gas & Fees +1

ERC-7677 defines the Paymaster Web Service Capability for EIP-5792. It describes wallet capability discovery and service RPCs such as pm_getPaymasterStubData and pm_getPaymasterData; it is not a universal paymaster contract interface and does not guarantee sponsorship.

Stages: Executing Transactions, Gas & Fees

ERC-8019 defines an optional wallet-managed policy for auto-signing matching SIWE requests. A wallet may auto-sign when domain, URI prefix, chain, resources, and expiry constraints match; the app must still validate the SIWE message and manage its own session.

Stages: Authentication & Identity

ERC-7715 requests execution permissions for a designated account. A wallet or account implementation may return a bounded permission, but the standard does not itself create a session key; supported rule types, the returned scope, and revocation behavior are integration-specific.

Stages: Approving & Permissioning, Executing Transactions

EIP-8141 is a Draft frame-transaction proposal for native account abstraction. Its current design can let compatible accounts use default code for batching or alternative fee payment, but it does not configure universal recovery or key rotation for every existing account.

Stages: Executing Transactions, Gas & Fees

EIP-3326 defines wallet_switchEthereumChain, a request for a wallet with an active-chain concept to switch to a known chain. The specification is Stagnant and recommends explicit confirmation and cancellation of chain-specific pending work; implementation details, supported chains, and error handling remain wallet-specific.

Stages: Discovery & Connection, Executing Transactions

EIP-7702 is opt-in code delegation for EOAs on Monad. While delegated, a transaction that reduces the EOA's balance below the applicable reserve threshold reverts, subject to the documented max-gas-fee allowance. The current reserve parameter is 10 MON, not a required deposit; sponsored low-balance calls can work when the balance is unchanged or increased. Delegated accounts cannot use the emptying exception.

Stages: Approving & Permissioning, Executing Transactions +1

Monad's Reserve Balance mechanism coordinates consensus-time inflight gas budgets with execution-time ending-balance checks. The current system parameter is user_reserve_balance = 10 MON, but outcomes depend on lagged and starting balances, gas and value spend, delegation, recent activity, and emptying eligibility. It is not a universal balance-minus-10-MON formula or an upfront deposit.

Stages: Asset Discovery & Display, Executing Transactions +1

Monad has no global mempool: an RPC owner node checks and forwards valid transactions to upcoming leaders, while validators keep local mempools and the owner tracks inclusion. This can reduce propagation overhead and time to inclusion, but transactions can still wait, be evicted, be included with a reverted execution, or face application-specific market and MEV risk. Monad does not provide a network-wide pending lookup through the documented `newPendingTransactions` subscription.

Stages: Executing Transactions, Status & Confirmation

Monad uses a chain-specific gas schedule and charges the signed gas limit at the applicable price, so fee previews need an estimate for the actual transaction and active revision. Page and account access, operation, and state growth determine gas; a blanket Ethereum multiplier cannot describe that behavior.

Stages: Gas & Fees