This means that the following fields in the current Candid definition of a TransactionReceipt are wrongly declared mandatory and should be made optional:
to (e.g., null for contract creation such has in this transaction 0x2b8e12d42a187ace19c64b47fae0955def8859bf966c345102c6d3a52f28308b)
status (null for transactions before the Byzantium upgrade, e.g. 0x5a9d77909e77eee0a768d4160155c60fa77ae5b621e3c6f4fe6c54f509ea8c33)
Although type is not mandatory according to the specification, it was introduced in a backwards-compatible way by EIP-2718 in the Berlin fork, so that even the first ever Ethereum transaction 0x5c504ed432cb51138bcf09aa5e8a410dd4a1e204ef84bfed1be16dfba1b22060 (which predates the Berlin fork) also has a type returned when its receipt is queried.
According to the Ethereum JSON-RPC specification only the following fields in a
TransactionReceiptrecord are required:blockHashblockNumberfromcumulativeGasUsedgasUsedlogslogsBloomtransactionHashtransactionIndexeffectiveGasPriceThis means that the following fields in the current Candid definition of a
TransactionReceiptare wrongly declared mandatory and should be made optional:to(e.g., null for contract creation such has in this transaction0x2b8e12d42a187ace19c64b47fae0955def8859bf966c345102c6d3a52f28308b)status(null for transactions before the Byzantium upgrade, e.g.0x5a9d77909e77eee0a768d4160155c60fa77ae5b621e3c6f4fe6c54f509ea8c33)Although
typeis not mandatory according to the specification, it was introduced in a backwards-compatible way by EIP-2718 in the Berlin fork, so that even the first ever Ethereum transaction0x5c504ed432cb51138bcf09aa5e8a410dd4a1e204ef84bfed1be16dfba1b22060(which predates the Berlin fork) also has atypereturned when its receipt is queried.