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

Answering the Question

To preserve a failed‑deployment revert across the JSON‑RPC boundary you should:

• Record the chain ID, transaction hash, and the client name & version that returned the receipt.
• Store the raw revert bytes exactly as returned by the client (typically in the error or revertReason field).
• Keep the receipt status and the log list unchanged.

With that context you can decode the payload separately and classify the failure.

Confirmed Facts (from the research brief)

• Custom errors emit a selector + ABI‑encoded arguments; the ABI is required for decoding.
• A constructor revert produces a status 0 receipt with no logs.
• Clients vary: some expose the full revert payload, others only the selector, and some truncate payloads when gas is exhausted.
• Decoding failures or missing payloads must be treated as “unknown failure” but can be flagged as “possible constructor revert” if status 0 and no logs.

Practical Steps for Your Integration

1. Capture the receipt. Use the JSON‑RPC method that returns the full receipt (e.g., eth_getTransactionReceipt or an enhanced provider endpoint).
2. Persist context. Store chain ID, tx hash, client name, client version, and the raw revert bytes in a database or log entry.
3. Decode if possible. If the client provides the ABI for the custom error, use a library like ethers.js or web3.js to decode:

   const iface = new ethers.utils.Interface(["error MyError(uint256)""]); 
   const decoded = iface.parseError(rawBytes);

4. Fallback when ABI is missing. Keep the selector hex (first 4 bytes) and mark the payload as undecodable. Store the raw bytes for later analysis.
5. Classify the failure. Apply the following logic:
   • If status === 0 and logs.length === 0 and rawBytes.length > 0, label as deliberate constructor revert.
   • If status === 0 and rawBytes.length === 0, label as unknown failure (possible gas exhaustion or client truncation).
   • Otherwise, treat as a runtime revert and use the decoded reason if available.

Missing Diagnostic Detail

To fine‑tune the fallback logic, could you confirm whether your JSON‑RPC client returns the raw revert bytes in a field such as error or revertReason, or if it only exposes a selector? This detail may change the decoding strategy.