# EIP-2718: Typed Transaction Envelope

Source: https://www.eipsfordesigners.com/standards/EIP-2718
Agent brief: https://www.eipsfordesigners.com/standards/EIP-2718/agent.md
Machine-readable JSON: https://www.eipsfordesigners.com/api/standards/EIP-2718
Last reviewed: 2026-04-05
Last updated: 2026-04-05

| Field | Value |
| --- | --- |
| Status | Final |
| Chain | both |
| Category | Comprehension & Display |
| Journey stages | Status & Confirmation |
| Detailed guide | Yes |
| Official specification | https://eips.ethereum.org/EIPS/eip-2718 |
| Discussion search | https://ethereum-magicians.org/search?q=EIP-2718 |

## UX Impact

Different transaction types (legacy, EIP-1559, EIP-4844 blobs) coexist seamlessly — users don't need to understand encoding differences. Design implications: abstract transaction type complexity from users, show relevant fields per type (maxFeePerGas vs gasPrice), indicate transaction type in history views for debugging. Design decisions: whether to expose transaction type in UI at all, how to handle wallets that don't support newer types, default type selection logic, backwards compatibility messaging.

## Summary

EIP-2718 introduced typed transaction envelopes - a way to define different transaction formats. Instead of one transaction format forever, new types can be added: Type 0 (legacy), Type 1 (access lists), Type 2 (EIP-1559), Type 4 (EIP-7702). Wallets show different UIs based on transaction type, and the ecosystem can evolve without breaking old transactions.

## For Designers

- You can design UI that delivers new transaction types can be added (Type 2.
- You can design UI that delivers old types still work, new types opt-in.
- You can design UI that delivers type byte tells wallets how to parse and display.

## Applicability

### When to Use

- Your product addresses: no way to add new transaction features.
- Your product addresses: backwards compatibility concerns.
- The flow should deliver: new transaction types can be added (Type 2, Type 4, etc.).
- You are designing a transaction type indicator experience with visible states and recovery paths.

### When to Avoid

- Default to Type 2 unless compatibility requires legacy.
- Show type badge with brief explanation.
- Type-specific gas inputs and explanations.
- Users never see addresses, amounts, or signing payloads in your UI.

## Problems It Solves

### No way to add new transaction features

Impact: critical

Old way: Transaction format was fixed, new features impossible

New way: New transaction types can be added (Type 2, Type 4, etc.)

### Backwards compatibility concerns

Impact: high

Old way: Changing tx format would break everything

New way: Old types still work, new types opt-in

### No context for transaction interpretation

Impact: high

Old way: All transactions looked the same

New way: Type byte tells wallets how to parse and display

### Gas pricing couldn't evolve

Impact: high

Old way: Single gas price field forever

New way: Type 2 added base fee + priority fee via new format

## Anti-Patterns

### Using legacy (Type 0) by default

Severity: high

Misses EIP-1559 benefits, wastes user money

Instead: Default to Type 2 unless compatibility requires legacy

### Hiding transaction type from users

Severity: medium

Users can't understand why gas UI differs

Instead: Show type badge with brief explanation

### Same gas UI for all types

Severity: medium

Type 2 has different fields than Type 0

Instead: Type-specific gas inputs and explanations

### Not explaining new transaction types

Severity: medium

Users confused by Type 4 (7702) when it appears

Instead: Clear explanation of what new types enable

## UI Components

### TransactionTypeBadge

Visual indicator of transaction type
States: type-0, type-1, type-2, type-4
Props: type, showName, showDescription

### TypeSpecificGasUI

Gas settings appropriate for transaction type
States: legacy, eip1559, eip7702
Props: type, gasParams, onChange

### TransactionTypeSelector

Advanced option to choose transaction type
States: collapsed, expanded
Props: availableTypes[], selected, onSelect, recommendation

## On Monad

### Transaction Type Support

Ethereum: Types 0, 1, 2, 4 all supported

Monad: Monad supports the same transaction types

Design implication: Same type-based UI works on Monad

### EIP-1559 on Monad

Ethereum: Type 2 widely used for predictable fees

Monad: Type 2 works but fees already very low

Design implication: Still recommend Type 2 for consistency

### EIP-7702 Benefits

Ethereum: Type 4 for smart wallet upgrades

Monad: Same benefits plus faster execution

Design implication: Encourage Type 4 adoption for smart wallet features

## UX Patterns

### Transaction Type Indicator

Show users which transaction type they're signing

User flow:

- User initiates transaction
- Wallet detects/selects transaction type
- Type-specific UI shown
- User sees relevant gas options
- Confirms with full context

Mockup registry key: `concept/gas-abstraction` (React UI on the live standard page).

### Legacy vs Modern Transaction Choice

Let users choose transaction type when relevant

User flow:

- User opens advanced settings
- Transaction types explained
- Recommendation highlighted
- User selects appropriate type
- Type determines gas UI

Mockup registry key: `concept/gas-abstraction` (React UI on the live standard page).

### Transaction History by Type

Filter and view transactions by type

User flow:

- User views transaction history
- Each tx shows its type
- Can filter by type
- Understand different tx behaviors

Mockup registry key: `concept/gas-abstraction` (React UI on the live standard page).

### EIP-7702 Transaction

Special UI for account upgrade transactions

User flow:

- User enables smart wallet
- Type 4 transaction created
- Features explained clearly
- Address confirmation shown
- Upgrade executed

Mockup registry key: `generic/instant-confirm` (React UI on the live standard page).

## Related Standards

- EIP-1559: EIP-1559 introduced Type 2 transactions via EIP-2718

- EIP-7702: EIP-7702 introduced Type 4 transactions for account upgrades

- EIP-658: Transaction receipts include type for proper parsing

- EIP-155: Chain ID included in typed transaction encoding