Transaction Type
Pronunciation: tran-ZAK-shun TYPE
Definition
A transaction type is a protocol-defined category that determines how a transaction is decoded, validated, priced, signed, or executed. Examples can distinguish legacy transfers, dynamic-fee transactions, contract deployments, staking actions, or versioned message formats. The type must be read from authoritative protocol fields rather than inferred only from the recipient or application label. Practical use requires recognizing that a business label such as payout or refund does not identify the consensus format that nodes process.
Overview
A transaction type selects the rule set applied to a transaction. In Ethereum, typed envelopes allow different field layouts and fee mechanisms to coexist. Other networks classify transactions by message version, action code, module entry function, or instruction set. The type can affect required fields, signature preimage, fee calculation, replay protection, and node compatibility.
Protocol type should be distinguished from business categorization. A payment processor may label a transaction as deposit, refund, or payout even though all three use the same on-chain type. Conversely, one business payment can involve several protocol types across approval, swap, and settlement steps. Both classifications are useful, but they answer different questions.
Unknown or unsupported types require safe handling. A decoder should not force unfamiliar bytes into a legacy schema, because the same positions may have different meanings. Hardware wallets and signing services must understand type-specific fields before asking for authorization. New types introduced through upgrades may also change replacement or fee-bumping behavior.
Infrastructure should store the native type identifier, protocol version, decoded fields, and original Transaction Envelope. Monitoring and analytics should avoid grouping transactions solely by method name when the envelope changes security or pricing properties. Compatibility testing should cover every type that an application can construct, sign, submit, and reconcile.
Audit and recovery workflows should preserve the native type code, protocol version, decoder used, signing rules, fee model, and receipt interpretation. These records help because a business label such as payout or refund does not identify the consensus format that nodes process. Production safeguards need to fail safely on unknown types and maintain compatibility tests for construction through reconciliation.
The decoder should use the native type before interpreting the Transaction Body or requesting a signature.
Key Takeaway
A transaction type selects protocol rules for encoding and processing, while business labels describe the transaction’s operational purpose.
Sources
- EIP-2718: Typed Transaction Envelope — Ethereum Improvement Proposals (2026-08-02)
- Ethereum Transactions — Ethereum.org (2026-08-02)
- Solana Transaction Structure — Solana Foundation (2026-08-02)