ERC-1066 tries to solve a lower-layer interface problem, not a product-specific one: smart contracts usually expose only true/false, a revert, or a project-local enum, while the proposal defines a shared one-byte vocabulary that other contracts and tools can react to without knowing each app’s internal semantics.
The decisive mechanism is the 16x16 hex matrix. The high nibble encodes a broad category such as permission/control, negotiation/governance, availability/time, finance, identity/proofs, or off-chain actions, while the low nibble encodes the reason or state inside that category.
The ERC is explicit that status codes are complementary to reverts and revert strings rather than a replacement. The point is to preserve machine-readable signaling for automation, debugging, and structured UX even when execution does not simply halt.
The proposal reserves unspecified codes instead of treating them as arbitrary app space. That matters because ERC-1066 is trying to create a shared semantic layer rather than just another loose enum convention.
The application-specific 0xA* range is the main extension valve. It lets protocols keep custom states while still anchoring them to the broader failure/success/awaiting/info structure of the common table.
The FISSION library is useful evidence that ERC-1066 was meant as an actual developer substrate, not just a theoretical EIP. Its README frames the standard as shared status-code infrastructure for contract interoperability, translated messages, runtime inspection, and autonomous handling of collaborator-contract responses.
Specific source signals worth retaining
ERC motivation: strongest source for the claim that booleans are too semantically thin and revert-only flows are too human-intervention-heavy for richer contract autonomy.
ERC specification: best source for the category matrix itself, the first-return-value convention, and the distinction between common codes and app-specific codes.
ERC rationale: most useful section for why the proposal keeps status codes orthogonal to revert strings and why it reserves much of the space for further specification.
FISSION README: strongest implementation-context source showing how the status-code layer was expected to pair with helper libraries and later translation/localization work such as ERC-1444.
Why this entry belongs in the corpus
It gives the tokenized-asset cluster a still-lower bound beneath ERC-1404, ERC-1462, ERC-1594, and ERC-1400-family flows by making the reason-code vocabulary itself explicit.
It exposes a hidden control surface that later standards often flatten away: who defines machine-readable failure/success semantics, and whether downstream contracts or wallets can react to them generically.
It also creates a bridge into UX and localization work, because once status signaling becomes shared infrastructure, translation layers such as ERC-1444 become separate comparison objects rather than implementation footnotes.