Status & Confirmation

EIP-155 adds chain ID to the replay-protected transaction signing path, while preserving the legacy six-field v=27/28 signature path for compatibility. Show the wallet's actual target chain and transaction envelope; a chain ID does not make every signature universally chain-bound.

Category: Security & Trust

EIP-658 receipts report whether top-level execution succeeded or failed. Inclusion, execution success, the intended application result, and finality are different states. JSON-RPC encodes status as 0x1 or 0x0; normalize the representation returned by your SDK before displaying an outcome.

Category: Infrastructure

EIP-695 defines the eth_chainId RPC method, which lets a provider report the chain ID used by the connected endpoint. A client can compare that value with its target network, while wallet support, endpoint trust, network names, and switching remain separate concerns.

Category: Comprehension & Display

EIP-1344 adds the CHAINID opcode, which returns the configured numeric chain ID to contract code. A contract must compare or bind that value in its own logic; the opcode is not a named-network attestation or automatic replay protection.

Category: Security & Trust

EIP-2124 defines compact fork identifiers for peer-to-peer node compatibility checks. Nodes cross-validate fork history and the next scheduled fork using the specified rules; different fork IDs can still be compatible while syncing. This is a node diagnostic signal, not an RPC network identity or cryptographic proof of a chain.

Category: Comprehension & Display

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

Category: NFT Capabilities

EIP-2718 defines a typed transaction envelope: a type byte followed by a type-specific payload, plus a corresponding typed receipt envelope. Later specifications define each payload and signing rule. Clients may choose to show type-specific details, but EIP-2718 itself does not prescribe wallet UI or guarantee support for any particular type.

Category: Comprehension & Display

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-5528 defines escrow refund and withdrawal interfaces for token sales; it does not guarantee full refunds or prevent every rug pull. The deployed escrow's conditions, refund rate, eligibility, and caller requirements determine what the user can claim.

Category: Security & Trust

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

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-7540 adds optional asynchronous deposit and/or redemption flows to ERC-4626 vaults. A deployed vault can keep one side synchronous while requests on the other side settle later, which helps real-world-asset, illiquid, and delayed-settlement strategies expose their timing clearly.

Category: DeFi Patterns

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-7950 encodes an EIP-155 chain ID and a transaction hash as chainId:txHash:tx. Compatible apps can use that reference for chain-aware lookup and sharing. The reference is not itself an explorer URL or proof of payment, and wallets and explorers choose whether to support it.

Category: Cross-Chain

ERC-1191 is an opt-in variant of the ERC-55 address checksum that incorporates chain ID on adopting networks. It can catch some address-entry mistakes there. Ethereum and networks that have not adopted the variant continue to use ERC-55. A checksum does not identify the intended destination chain or replace explicit network selection.

Category: Comprehension & Display

ERC-2266 defines an HTLC-based American Call Option for peer-to-peer token exchanges. It coordinates initiator and participant assets, a premium, separate timelocks, and redeem/refund calls; settlement and refund availability depend on the option state and the relevant deadlines.

Category: DeFi Patterns

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-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.

Category: Transaction Friction

ERC-7930 defines a versioned, length-prefixed binary envelope for chain-specific account identifiers. Pair it with a human-readable companion such as ERC-7828 or a CAIP-350 display profile when showing chain context to users; the ERC-7930 wire format is not itself a user-facing prefix string.

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

Monad's asynchronous execution is a protocol-level separation between consensus and execution. Consensus can agree on the ordered transactions without executing them first, while execution runs in a separate, slightly lagged lane. Nodes may speculatively execute a Proposed block before it finalizes, but consuming that data is optional, so a receipt or execution outcome and finality are separate product states.

Category: Infrastructure

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

Current Monad documentation lists 300 ms blocks and a 600 ms full-finality protocol figure. Those figures describe block production and consensus, not end-to-end wallet or application completion. Show completion from the observed execution outcome and required block commitment; a speculative receipt can precede Finalized, while Verified is a later agreement on execution output.

Category: Comprehension & Display