Special Format Decoder Guide
What Is a Special Format?
Most smart contract calls on Ethereum use standard ABI encoding — a well-defined format where the function selector (first 4 bytes) identifies the function and the remaining bytes encode parameters padded to 32-byte boundaries. The Calldata Decoder handles these automatically by looking up the selector in the ABI archive.
However, some protocols use non-standard encoding to optimize for gas or calldata size. Instead of ABI-encoded parameters, these functions pack values tightly into raw bytes with no padding. Standard ABI decoders cannot parse this data — the parameters have no ABI definition to match against.
Now I See Web3 includes Special Format Decoders that recognize these non-standard selectors and apply protocol-specific parsing logic. When a special format is detected, a colored tag appears next to "Decoded Calldata" to indicate which protocol format was used. Standard ABI-decoded calldata is labeled with a neutral ABI tag for distinction.
How It Works
When you submit calldata to the Calldata Decoder or Transaction Analyzer, the tool checks the 4-byte function selector against a registry of known special formats before attempting standard ABI decoding:
- Match found — The calldata is parsed using a dedicated decoder for that protocol format. The result shows all decoded fields with a protocol-specific tag.
- No match — The calldata flows through the standard ABI decoding pipeline as usual.
This means you don't need to do anything special. Paste the calldata, and the tool automatically detects and applies the correct decoder.
Supported Formats
Optimism: setL1BlockValuesJovian()
Optimism's setL1BlockValuesJovian() is a system transaction sent by the L2 sequencer at the beginning of every block. It relays critical L1 state to the L2 L1Block contract, enabling L2 contracts to access L1 block information like the base fee, blob base fee, and block hash.
Unlike normal contract calls, this function takes no ABI-encoded parameters. Instead, all 12 fields are tightly packed into raw msg.data to minimize calldata size and reduce L1 posting costs. This is why standard ABI decoders fail to parse it.
Calldata Layout (178 bytes)
| Bytes | Field | Type | Section |
|---|---|---|---|
| [0–3] | Function Selector | bytes4 | — |
| [4–7] | baseFeeScalar | uint32 | Ecotone |
| [8–11] | blobBaseFeeScalar | uint32 | Ecotone |
| [12–19] | sequenceNumber | uint64 | Ecotone |
| [20–27] | timestamp | uint64 | Ecotone |
| [28–35] | number | uint64 | Ecotone |
| [36–67] | basefee | uint256 | Ecotone |
| [68–99] | blobBaseFee | uint256 | Ecotone |
| [100–131] | hash | bytes32 | Ecotone |
| [132–163] | batcherHash | bytes32 | Ecotone |
| [164–167] | operatorFeeScalar | uint32 | Jovian |
| [168–175] | operatorFeeConstant | uint64 | Jovian |
| [176–177] | daFootprintGasScalar | uint16 | Jovian |
The first 164 bytes (Ecotone section) contain the base L1 block attributes introduced in the Ecotone upgrade. The last 14 bytes (Jovian section) add operator fee parameters and the DA footprint gas scalar introduced in the Jovian upgrade. All fields are big-endian with no padding between them.
Example
The following is a real setL1BlockValuesJovian() calldata from Optimism:
0x3db6be2b0000146b000f79c500000000000000040000000069c4e3cb00000000017981e2000000000000000000000000000000000000000000000000000000000224f1300000000000000000000000000000000000000000000000000000000000206311726031439452cc3d968be656b00b5912884ce0fb03a188684085ce7c6fa15bbf0000000000000000000000006887246668a3b87f54deb3b94ba47a6f63f329850000000000000000000000000190Decoded result:
baseFeeScalar= 5227blobBaseFeeScalar= 1014213sequenceNumber= 4timestamp= 1774511051number= 24740322basefee= 35975472blobBaseFee= 2122513hash= 0x7260...5bbfbatcherHash= 0x0000...2985operatorFeeScalar= 0operatorFeeConstant= 0daFootprintGasScalar= 400