Solidity Custom Errors and JSON-RPC Clients: Preserving Failed-Deployment Revert Data Across the Boundary

An application integrating Solidity contracts with off-chain EVM/JSON-RPC clients needs to classify failed deployments, but a reverted constructor produces a failed receipt and no ordinary logs, so log-based diagnostics miss the reason. Custom errors encode a revert payload with a selector and ABI-encoded arguments, but clients vary in exposing raw bytes or decoded reasons.

When a client lacks the custom-error ABI, it may return only a selector or generic failure. An absent payload does not confirm no revert, since gas exhaustion or retrieval limits can also leave no reason. Constructor and runtime reverts share the same channel, so decoded errors cannot be assumed to originate in constructor code. Because receipt status, transaction-error fields, and error formatting vary across clients and versions, the exact representation should be verified against the production toolchain.

How should an integration preserve raw revert bytes and decode them separately while recording chain, transaction hash, and client context? What fallback classification is appropriate when decoding fails or no payload is exposed? How can deployment tooling distinguish a deliberate constructor revert from other execution failures without assuming a single client API shape?