Executing Transactions

ERC-20 defines a common interface for fungible token balances, transfers, and approvals. A client can integrate a token through these functions, but metadata methods, return values, fee behavior, and compatibility depend on the deployed contract.

Category: DeFi Patterns

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.

Category: Transaction Friction

ERC-721 defines non-fungible tokens (NFTs). Unlike ERC-20 where every token is identical, each ERC-721 token has a unique ID. This enables digital art, collectibles, game items, membership passes, and anything where each item is distinct. It specifies ownership, transfers, approvals, and an optional metadata extension — the foundation of the NFT ecosystem.

Category: NFT Capabilities

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.

Category: Transaction Friction

ERC-1155 defines balances by account and token ID, allowing one contract to represent fungible quantities and unique items. Its batch transfer moves multiple IDs and amounts to one recipient in a transaction. Clients still need receiver handling, metadata and indexing support; actual fees depend on the transaction and network.

Category: NFT Capabilities

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.

Category: Transaction Friction

Batch minting/transfer events — efficiently create or move thousands of consecutive tokens in one transaction.

Category: NFT Capabilities

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.

Category: Transaction Friction

ERC-2771 defines a contract-level protocol for recipients that accept meta-transactions through trusted forwarders. A gas relay may submit a signed request and pay gas, but gasless interaction requires a recipient integration, trusted-forwarder verification, an available relay, and any sponsor policy the product chooses.

Category: Onboarding & Access

ERC-3156 standardizes flash loans: a receiver borrows without upfront collateral, uses the funds, and repays principal plus fee in one transaction. If repayment or the callback fails, the loan state reverts, while gas is still spent and unsafe approvals or untrusted lenders remain risks.

Category: DeFi Patterns

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.

Category: Transaction Friction

ERC-5564 standardizes one-time stealth-address generation and announcements that compatible recipients scan to discover payments. It can reduce public links to a recipient's main wallet, but funding, onward transfers, and other disclosed metadata can reveal those links.

Category: Identity & Privacy

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.

Category: Transaction Friction

EIP-6110 moves Ethereum validator-deposit processing into execution-layer block data and consensus-layer execution requests. After Pectra activation, a staking product can track a deposit from the deposit-contract event through execution inclusion, consensus processing, pending balance, and validator activation; a successful deposit transaction alone does not mean the validator is active.

Category: DeFi Patterns

ERC-6538 defines a registry that maps a registrant address and schemeId to stealth meta-address bytes. It helps an ERC-5564 client discover a private-receive key; it does not define name resolution, profile verification, unregister/privacy erasure, or payment settlement.

Category: Identity & Privacy

Streamlined multi-token with granular per-token-type approvals and no mandatory callbacks — simpler than ERC-1155.

Category: NFT Capabilities

EIP-7002 supplies the execution-layer request path for validator exits and withdrawals. Under Electra's integrated processing, a request whose source address matches a validator's 0x01 or 0x02 execution withdrawal credential can request a full exit with amount=0; a positive amount requests a partial withdrawal only for a 0x02 compounding credential when effective balance is at least 32 ETH and balance exceeds 32 ETH plus pending partial withdrawals. Ethereum activated the path in Pectra; requests enter an execution-layer queue, pay a dynamic request fee, and are then processed by the consensus layer.

Category: DeFi Patterns

EIP-7044 makes a correctly signed voluntary exit remain valid across future Ethereum upgrades by fixing its signing domain to Capella. Dencun activated the change on Ethereum mainnet. It simplifies delegated staking operations, but a signed exit is still an authority-bearing artifact: users need to see the validator, signer, fork/domain, custody relationship, and the fact that the signature cannot be revoked by this EIP.

Category: Security & Trust

EIP-7251 raises Ethereum's validator maximum effective balance to 2048 ETH while keeping the 32 ETH minimum activation balance. Validators with a 0x02 compounding withdrawal credential can earn rewards above 32 ETH, top up in flexible amounts, and participate in consolidation flows; the credential, validator state, queues, and network activation determine which controls are available.

Category: DeFi Patterns

ERC-7401 is the Final successor to ERC-6059 for parent-governed NFT nesting. It preserves the nesting model while correcting the interface identifier; compatible collections can expose accepted and pending children, and products should verify the target implementation before promising transfer or extraction behavior.

Category: NFT Capabilities

NFTs can have a maximum count for native ERC-721 transfers. After the cap is reached, the implementation chooses the resulting state; locking, burning, or another action is not mandated by ERC-7634.

Category: NFT Capabilities

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.

Category: Transaction Friction

ERC-7786 standardizes gateway source/recipient message calls and attributes. Applications can send a message through a compliant gateway, while route discovery, bridge health, status, post-processing, retry, and refunds remain adapter/provider-specific.

Category: Cross-Chain

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.

Category: Transaction Friction

ERC-7943 defines uRWA interfaces for transfer eligibility, frozen balances, and privileged enforcement actions across ERC-20, ERC-721, ERC-1155, and ERC-6909 assets. Concrete implementations such as CMTA's CMTAT-ACE integration expose these controls, but the standard does not define a universal compliance policy, legal reason, authority, or wallet UI; applications must feature-detect the base and uRWA interfaces and show the actual contract policy.

Category: Physical & Real World

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.

Category: Transaction Friction

ERC-5164 standardizes message dispatch and destination execution interfaces for cross-chain applications. A bridge adapter can carry a dispatcher message to a destination executor, while bridge selection, timing, security, status, and recovery remain provider-specific.

Category: Cross-Chain

ERC-6551 defines a registry that computes deterministic token-bound account addresses for NFTs and can deploy them as smart-contract accounts. A deployed or counterfactual account can hold assets, but each NFT may have multiple accounts across implementations, registries, chains, and salts; sale contents must be rechecked at settlement.

Category: NFT Capabilities

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.

Category: Transaction Friction

ERC-7828 defines a human-readable chain-aware name format and ENS chain resolution. Applications can use the resolved chain context to prompt a user to switch networks, while routing and wallet switching remain application behavior with explicit user consent.

Category: Cross-Chain

ERC-7683 defines a solver-facing resolver interface for opaque cross-chain protocol payloads. Applications can express protocol-specific intents and let resolvers evaluate them, while order shape, settlement, fills, pricing, and recovery remain properties of the selected protocol rather than guarantees of the ERC.

Category: Cross-Chain

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.

Category: Transaction Friction

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.

Category: Transaction Friction

EIP-3085 defines wallet_addEthereumChain, a request for a wallet to validate and add an EVM chain. The Stagnant specification requires chain-ID and RPC-URL validation and recommends explicit user consent. Wallets control additional metadata requirements and post-add selection; current implementations such as MetaMask Connect document their own confirmation and error behavior.

Category: Onboarding & Access

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.

Category: Transaction Friction

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.

Category: Transaction Friction

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.

Category: Transaction Friction

Monad executes transactions in parallel by default while preserving the serial semantics of a linearly ordered block. The execution system checks dependencies and merges state updates in block order, so parallel execution is not a user-controlled ordering feature. A feed's arrival order does not prove execution order, and network capacity does not promise a result or latency for one consumer.

Category: Infrastructure

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.

Category: Transaction Friction