{"id":"EIP-2718","name":"Typed Transaction Envelope","status":"Final","chain":"both","category":{"id":"comprehension","name":"Comprehension & Display","description":"Making blockchain data readable to humans"},"journeyStages":[{"id":"status","name":"Status & Confirmation","description":"Waiting for and confirming outcomes"}],"uxImpact":"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.","officialUrl":"https://eips.ethereum.org/EIPS/eip-2718","lastReviewed":"2026-09-18","lastUpdated":"2026-09-18","kind":"proposal","hasDetailedContent":true,"content":{"id":"EIP-2718","summary":"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.","applicability":{"whenToUse":["A client parses or displays supported Ethereum transaction types.","The review screen needs type-specific fields and an unknown-type fallback."],"whenToAvoid":["Your client cannot safely parse the selected transaction type.","You need a type’s signing or fee rules; read that type’s own specification."]},"designerTakeaways":["Support the transaction formats available on the selected network and provide an unknown-type fallback.","Preserve a readable transaction summary across legacy and typed envelopes.","Parse the type byte when supported, then show fields defined by that transaction type; keep an unknown-type fallback."],"problemsSolved":[{"problem":"Adding a new transaction format would disrupt legacy parsers","oldWay":"A client sees one legacy envelope and cannot distinguish later payload formats safely","newWay":"New transaction types can use a type byte and their own payload and signing specification","impact":"critical"},{"problem":"Backwards compatibility concerns","oldWay":"Changing tx format would break everything","newWay":"Existing clients can continue to parse known formats while new types are introduced with their own specifications","impact":"high"},{"problem":"No context for transaction interpretation","oldWay":"All transactions looked the same","newWay":"A supporting client can use the type byte to select the correct parser and optional display path","impact":"high"},{"problem":"Fee fields differ between transaction types","oldWay":"A client applies one fee parser to every transaction","newWay":"A type-specific specification can define fields such as EIP-1559's fee model without changing other envelopes","impact":"high"}],"uxPatterns":[{"name":"Transaction Type Indicator","description":"Show a supported transaction type and its relevant fields when that improves review","userFlow":["User initiates transaction","Client detects or receives the transaction type","Supported type-specific UI is shown","User sees relevant fields when available","Confirms with full context"]},{"name":"Legacy vs Modern Transaction Choice","description":"Expose type choice only when the client and network support a meaningful product decision","userFlow":["User opens advanced settings","Transaction types explained","Recommendation highlighted","User selects appropriate type","Type determines gas UI"]},{"name":"Transaction History by Type","description":"Filter and view transactions by type","userFlow":["User views transaction history","Each tx shows its type","Can filter by type","Understand different tx behaviors"]},{"name":"Type-specific authorization transaction","description":"A type-specific flow such as EIP-7702's authorization transaction when that EIP and network are supported","userFlow":["User reviews the account authorization","Type 4 transaction created","Type-specific fields explained clearly","Address and delegated code context shown","Authorization result confirmed"]}],"uiComponents":[{"name":"TransactionTypeBadge","description":"Visual indicator of transaction type","states":["type-0","type-1","type-2","type-3","type-4"],"props":["type","showName","showDescription"]},{"name":"TypeSpecificGasUI","description":"Gas settings appropriate for transaction type","states":["legacy","eip1559","eip7702"],"props":["type","gasParams","onChange"]},{"name":"TransactionTypeSelector","description":"Advanced option to choose transaction type","states":["collapsed","expanded"],"props":["availableTypes[]","selected","onSelect","recommendation"]}],"antiPatterns":[{"pattern":"Hiding transaction type from users","why":"Users can't understand why gas UI differs","instead":"Show type badge with brief explanation","severity":"medium"},{"pattern":"Selecting a type without checking network and wallet support","why":"A type-specific fee model or payload may be unsupported or misrepresented","instead":"Choose a supported type for the network and use a compatibility fallback when needed","severity":"high"},{"pattern":"Same gas UI for all types","why":"Type 2 has different fields than Type 0","instead":"Type-specific gas inputs and explanations","severity":"medium"},{"pattern":"Not explaining new transaction types","why":"Users confused by Type 4 (7702) when it appears","instead":"Clear explanation of what new types enable","severity":"medium"}],"relatedStandards":[{"id":"EIP-1559","relationship":"EIP-1559 introduced Type 2 transactions via EIP-2718"},{"id":"EIP-7702","relationship":"EIP-7702 introduced Type 4 transactions for account upgrades"},{"id":"EIP-658","relationship":"Defines the receipt execution status; EIP-2718 supplies the typed receipt envelope."},{"id":"EIP-155","relationship":"Introduces chain-ID replay protection for legacy transactions; later typed formats specify their own chain-ID fields."}],"specConstraints":[{"id":"typed-envelope-discovery","constraint":"Clients can distinguish typed transactions from legacy transactions by inspecting the first byte.","appliesTo":"wallet","normativity":"backwards-compatibility","specQuote":"Clients can differentiate between the legacy transactions and typed transactions by looking at the first byte.","specSection":"Backwards Compatibility","specUrl":"https://eips.ethereum.org/EIPS/eip-2718#backwards-compatibility","designImplication":"Keep a readable transaction-type label and an unknown-type fallback. Do not assume every typed envelope has the same fee, payload, or signing fields."},{"id":"typed-signing-domain","constraint":"New transaction types should include the type byte in the signed payload to reduce cross-type signature reuse risk.","appliesTo":"account-implementation","normativity":"security-considerations","specQuote":"When designing a new 2718 transaction type, it is **STRONGLY** recommended to include the transaction type as the first byte of the signed payload. If you fail to do this, it is possible that your transaction may be signature compatible with transactions of another type which can introduce security vulnerabilities for users.","specSection":"Security Considerations","specUrl":"https://eips.ethereum.org/EIPS/eip-2718#security-considerations","designImplication":"For signing UI and account implementations, bind the displayed transaction type to the signed payload when the selected type specifies that rule. Surface the type and keep unknown or unsupported signing paths blocked."}],"lastUpdated":"2026-09-18","technicalNotes":"EIP-2718 specifies TransactionType || TransactionPayload and the corresponding typed receipt envelope. Each transaction-type specification defines its payload and signing rules. Common examples include legacy type 0, access-list type 1, fee-market type 2, blob type 3 and authorization-list type 4. Feature support is network- and client-dependent; unknown types need a safe fallback. EIP-658 supplies receipt status, not receipt type parsing.","lastReviewed":"2026-09-18","sources":[{"label":"EIP-2718 official specification","url":"https://eips.ethereum.org/EIPS/eip-2718","type":"official-spec"}]},"sources":[{"label":"Official specification","url":"https://eips.ethereum.org/EIPS/eip-2718","type":"official-spec"},{"label":"Discussion search","url":"https://ethereum-magicians.org/search?q=EIP-2718","type":"discussion"}],"urls":{"canonical":"https://www.eipsfordesigners.com/standards/EIP-2718","markdown":"https://www.eipsfordesigners.com/standards/EIP-2718/content.md","agent":"https://www.eipsfordesigners.com/standards/EIP-2718/agent.md","api":"https://www.eipsfordesigners.com/api/standards/EIP-2718","official":"https://eips.ethereum.org/EIPS/eip-2718","discussion":"https://ethereum-magicians.org/search?q=EIP-2718"},"freshness":{"lastReviewed":"2026-09-18","lastUpdated":"2026-09-18"}}