XDC accepts three transaction types: legacy (type 0), EIP-2930 access-list (type 1) and EIP-1559 dynamic-fee (type 2). On Ethereum, type 1 starts at Berlin and type 2 at London. On XDC both start at a separate fork row, Eip1559Block, which comes later than Berlin and London on mainnet and Apothem. Blob (type 3) and set-code (type 4) transactions are not accepted. xOneRS follows the geth-XDC rule and tests it at the pool and in the state-test runner.
Which transaction types does XDC accept?
| Type | Name | Accepted from (XDC) | Ethereum |
|---|---|---|---|
| 0 | Legacy (homestead or EIP-155 signature) | always | always |
| 1 | EIP-2930 access list | Eip1559Block |
Berlin |
| 2 | EIP-1559 dynamic fee | Eip1559Block |
London |
| 3 | EIP-4844 blob | not accepted | Cancun |
| 4 | EIP-7702 set code | not accepted | Prague |
The XDC rule is in spec/chainspec/eip1559-decoupled-from-london.md: "Type 1 and type 2 transactions are accepted from Eip1559Block (signer choice)", from geth-XDC core/types/transaction_signing.go:52-57.
At which block does each network accept type 1 and type 2?
From the generated fork table:
| Row | mainnet (50) | Apothem (51) | net2040 (2040) |
|---|---|---|---|
berlinBlock |
76,321,000 | 61,290,000 | 9,000 |
londonBlock |
76,321,000 | 61,290,000 | 9,000 |
eip1559Block |
98,800,200 | 71,550,000 | 12,600 |
So on Apothem, a type 1 or type 2 transaction is refused before block 71,550,000, although Berlin and London started at 61,290,000. On mainnet the first block is 98,800,200. Compare it with your node's eth_blockNumber before you send a typed transaction.
How does the xOne transaction pool decide?
The pool checks three gates in order, as geth-XDC's validation.go:88-99 does (crates/xone-builder/src/txpool/validate.rs). Each gate gives error transaction type not supported:
- A typed transaction before Berlin:
type N rejected, pool not yet in Berlin. - A typed transaction before
Eip1559Block:type N rejected, XDC pool not yet at EIP-1559. - A type 2 before London:
type N rejected, pool not yet in London.
On mainnet and Apothem the second gate is the one that matters, because Eip1559Block is the latest of the three. Types 3 and 4 do not get to these gates: the decoder does not know them, so they are transaction type not supported at once, as a block that carried them would be refused (spec/txpool/admission.md).
Two pool scenarios recorded from the pinned geth-XDC pool check this: type-gating-pre-eip1559 (block 65,000,000, "types 1 and 2 are refused before Eip1559 on XDC") and type-gating-eip1559 (block 80,000,000, "types 1 and 2 are accepted from Eip1559").
What else changes at Eip1559Block?
Several rules that Ethereum starts at Berlin, London or Shanghai start on XDC at Eip1559Block:
- EIP-2929 cold and warm access costs.
- EIP-3860 initcode limit: a contract creation with more than 49,152 bytes of initcode is refused with
max initcode size exceeded. - EIP-3529 refund cap of 1/5 (1/2 before).
- The base fee in the header, as a fixed tier chosen by the block number.
For a type 2 transaction, the pool compares the fee cap (not the tip) with the gas-price floor of the next block. See the gas limit rule for the block side.
How is this tested in the state-test runner?
xone evm statetest runs the forks Frontier to ConstantinopleFix. PR #1032 added the only type 1 and type 2 cases of those forks in EEST v5.4.0: TYPE_1_TX_PRE_FORK and TYPE_2_TX_PRE_FORK at Frontier, Homestead, Byzantium and ConstantinopleFix. xOne rejects all 8 with the state untouched. The fixture is conformance/vectors/statetest/typed-tx-before-fork.json, and the test typed_transactions_before_their_fork_are_rejected_with_the_state_untouched also fails on a wrong state root.
Every other typed case in that EEST release belongs to Berlin or later, which this runner does not run yet (conformance/statetest/RUNS.md):
| Type | EEST v5.4.0 cases at Berlin or later | Run by xOne |
|---|---|---|
| 1 | 2,446 | no (counted as skipped) |
| 2 | 2,318 | no (counted as skipped) |
| 3 | 1,883 | no (counted as skipped) |
| 4 | 612 | no (counted as skipped) |
Running them needs an Ethereum-rules mode or --state.xdc, which is an owner decision (issues #26 and #230). See the EEST run and the state-test runner.
Frequently asked questions
Why is my EIP-1559 transaction refused on Apothem below block 71,550,000?
XDC accepts type 1 and type 2 only from Eip1559Block, which is 71,550,000 on Apothem, not from London at 61,290,000. Send a legacy transaction before that block.
Does XDC support blob or EIP-7702 transactions?
No. xOne does not decode type 3 or type 4, and answers transaction type not supported.
Is the access-list transaction (type 1) available from Berlin on XDC?
No. On XDC it waits for Eip1559Block, like type 2.
Does xOne run the EEST typed-transaction tests?
Only the 8 pre-fork rejection cases. The 7,259 typed cases at Berlin or later are counted as skipped.
Sources
This article describes the source and evidence at its review date. Check the linked repository for current implementation and qualification status.
Explore the engineering evidenceEdit this page on GitHub opens the Markdown source (content/blog/xdc-transaction-types/index.md). GitHub may ask you to sign in. Report a correction opens a prefilled GitHub issue for this page.