⚠️ Errors in the published specifications
Many specifications state their own ERC-165 interface id. Every such claim is checked against the id computed from the interface the spec declares. These 17 do not match, and in each case the published value is the one that is wrong.
| Proposal | Interface | Computed | Asserted | Why the parser is right |
|---|---|---|---|---|
| ERC-998 | ERC998ERC20BottomUp | 0x3617a1cb | 0xffafa991 | Asserted value is the XOR of only 4 of the 5 declared functions; it predates transferFromParentERC223(address,uint256,address,uint256,bytes). |
| ERC-1261 | IERC1261 | 0xf8779878 | 0x1d8362cf | Matches no subset of the 15 declared selectors, with or without the ERC-173/ERC-165 parents. The comment predates several signature edits. |
| ERC-1417 | IPoll | 0xd1983698 | 0x4fad898b | Asserted value is the XOR minus getVoterBaseDenominator() (0x9e35bf13), which was added to the body after the comment was written. |
| ERC-4353 | IERC721Staked | 0x5a459ed4 | 0x3a3d855f | Single-function interface, so the id is stakedAmount(uint256)'s selector by definition. The asserted value matches no signature in any upstream revision. |
| ERC-4393 | ITipToken | 0xe47a7022 | 0x985a3267 | The spec's own normative prose states 0xe47a7022, which agrees with the parser. The divergent value is a stray note inside an event's NatSpec. |
| ERC-5007 | IERC5007 | 0x7a0cdf92 | 0xf140be0d | The int64 to uint64 edit was to return types, which cannot change a selector, yet the comment was rewritten. The file's sibling IERC5007Composable still matches the parser exactly. |
| ERC-5496 | IERC5496 | 0xc906a5cb | 0x076e1bbb | Asserted value is reproducible only with setPrivilege(uint256,uint256,address,uint64); the body widened that parameter to uint256. |
| ERC-5635 | IERC5635DNFT | 0xbda94636 | 0xd584841c | The comment states a non-ERC-165 derivation, bytes4(keccak256("IERC5635DNFT{}")), which is also numerically wrong: that expression yields 0x37c007c8. |
| ERC-5635 | IERC5635Registry | 0x59213334 | 0xb5065e9f | Same name-hash formula used file-wide; bytes4(keccak256("IERC5635Registry{}")) is 0xc4859425, so the asserted value is wrong on its own terms. |
| ERC-5700 | IERC1155Bindable | 0xc6f44642 | 0xd0d555c6 | Matches no subset, no parent combination and no drafted variant. The corresponding prose literal 0xd0d55c6 is only 7 hex digits, so it is not a valid bytes4. |
| ERC-6059 | IERC6059 | 0xf71e99d2 | 0x42b0e56f | Asserted value requires addChild(uint256,uint256,bytes) and nestTransferFrom(...,bytes); the published body declares neither. |
| ERC-6353 | IERC20charity | 0xaceb828b | 0x557512b6 | Never matched the body in any published revision; exhaustive search over the 10 declared selectors plus ERC-20 and ERC-165 finds no combination producing it. |
| ERC-7204 | IERC7204 | 0x4b090fea | 0xf73edcda | The asserted value appears exactly once in the entire corpus and matches no subset of the 5 declared selectors, with or without ERC-165. |
| ERC-7401 | IERC7059 | 0x14a07a0c | 0x42b0e56f | ERC-7401 half-applied its own stated fix: it restored bytes data on nestTransferFrom but left addChild(uint256,uint256), which the asserted id requires with bytes. |
| ERC-7561 | IERC7561 | 0x304ad1f2 | 0xc1b31357 | Asserted value is a copy-paste of ERC-7196's id, the XOR of totalSupply(), balanceOf(address) and transfer(address,uint256). ERC-7561 declares no transfer(address,uint256). |
| ERC-5791 | IERC5791 | 0x83e70509 | 0x4901df9f | Asserted value is the XOR of tokenIdFor(address), isChipSignatureForToken(uint256,bytes,bytes) and the two removed transferTokenWithChip overloads, so it predates their replacement by transferToken(address,address,bytes,uint256,bool,bytes). Found by exhaustive subset search; no combination with ERC-721 or ERC-165 reproduces it. |
| ERC-7604 | IERC1155Permit | 0x29011db4 | 0x7409106d | No subset of the three declared selectors, alone or combined with the ERC-165, ERC-1155, ERC-5216, ERC-721 and ERC-1271 parents, reproduces the asserted value; nor does any non-canonical hashing of the signatures. The value appears in no other file in the corpus, so it is a hand-miscomputed literal. |
Each was verified by re-deriving the id from the signatures the spec declares and, where the cause was not obvious, by exhaustive subset search over the declared selectors.