{"id":"EIP-658","name":"Transaction Status Code in Receipts","status":"Final","chain":"both","category":{"id":"infrastructure","name":"Infrastructure","description":"Foundational patterns enabling other standards"},"journeyStages":[{"id":"status","name":"Status & Confirmation","description":"Waiting for and confirming outcomes"}],"uxImpact":"EIP-658 receipts report whether top-level execution succeeded or failed. Inclusion, execution success, the intended application result, and finality are different states. JSON-RPC encodes status as 0x1 or 0x0; normalize the representation returned by your SDK before displaying an outcome.","officialUrl":"https://eips.ethereum.org/EIPS/eip-658","lastReviewed":"2026-09-18","lastUpdated":"2026-09-18","kind":"proposal","hasDetailedContent":true,"content":{"id":"EIP-658","summary":"EIP-658 receipts report whether top-level execution succeeded or failed. Inclusion, execution success, the intended application result, and finality are different states. JSON-RPC encodes status as 0x1 or 0x0; normalize the representation returned by your SDK before displaying an outcome.","applicability":{"whenToUse":["Your Ethereum-compatible transaction UI reports receipt success or failure.","Users need to distinguish pending transactions from included execution outcomes."],"whenToAvoid":["No receipt is available yet; keep the action pending or unknown.","You need a revert reason, application outcome or finality proof; receipt status alone does not supply those."]},"designerTakeaways":["Keep a missing receipt pending or unknown rather than marking it failed.","Show execution failure separately from inclusion and finality.","Verify the expected application result and use additional data for a failure reason when available."],"problemsSolved":[{"problem":"No reliable way to know if transaction succeeded","oldWay":"Compare gas used to gas limit, hope remaining gas indicated success","newWay":"Receipt contains explicit status: 1 = success, 0 = failure","impact":"critical"},{"problem":"Users saw \"confirmed\" but funds didn't move","oldWay":"Transaction confirmed but reverted, user confused why nothing happened","newWay":"Clear \"Transaction Failed\" message with status","impact":"critical"},{"problem":"Apps couldn't reliably track transaction outcomes","oldWay":"Complex heuristics to guess success, sometimes wrong","newWay":"Normalize the receipt status returned by the RPC or SDK to identify top-level execution success or failure.","impact":"high"},{"problem":"Block explorers showed ambiguous results","oldWay":"\"Transaction included in block\" with unclear outcome","newWay":"Green checkmark for success, red X for failure","impact":"high"}],"uxPatterns":[{"name":"Transaction Status Indicator","description":"Clear visual feedback for transaction outcome","userFlow":["User submits a transaction","Show submitted or pending while no receipt is available","Normalize receipt status, for example 0x1/0x0 from JSON-RPC","Display execution success or failure","Check the intended application effect and required commitment before marking the task complete"]},{"name":"Failed Transaction Explanation","description":"Help users understand why transaction failed","userFlow":["An included transaction reports execution failure","Show that execution failed and gas may have been charged","Use available simulation, trace, or decoded error data to explain the cause","If the cause is unavailable, say so","Refresh state and estimate before offering another submission"]},{"name":"Transaction History with Status","description":"Show success/failure status for all past transactions","userFlow":["User views transaction history","Each transaction shows status icon","Success = checkmark, Failed = X","At-a-glance understanding of outcomes"]}],"uiComponents":[{"name":"TransactionStatusBadge","description":"Visual indicator of transaction success/failure","states":["pending","success","failed"],"props":["status","showLabel","size"]},{"name":"ReceiptDisplay","description":"Show full transaction receipt details","states":["loading","success","failed"],"props":["receipt","showTechnical","onRetry"]},{"name":"FailureExplanation","description":"Human-readable failure reason","states":["generic","specific","actionable"],"props":["errorCode","errorMessage","suggestion"]}],"antiPatterns":[{"pattern":"Showing \"Confirmed\" for failed transactions","why":"Confirmation means included in block, not success. Users think it worked.","instead":"Display inclusion, top-level execution status, expected application outcome, and required finality as separate facts.","severity":"critical"},{"pattern":"Not explaining why transaction failed","why":"User knows it failed but not what to do about it","instead":"Decode a reason only when the RPC, trace, or simulation supplies one. Otherwise show an unknown-reason state with a useful next step.","severity":"high"},{"pattern":"Hiding gas charges on failed transactions","why":"Users don't understand why they lost money on a failed tx","instead":"Show the actual fee charged on this network from the receipt and fee accounting, even when execution failed.","severity":"high"},{"pattern":"Using same color for pending and success","why":"Users can't distinguish waiting from done","instead":"Use distinct labels and icons for pending, execution success, and failure. Color can reinforce these labels.","severity":"medium"}],"relatedStandards":[{"id":"EIP-2718","relationship":"Defines typed transaction and receipt envelopes; each transaction type defines its payload."},{"id":"ERC-6093","relationship":"Custom errors provide detailed failure reasons beyond just status=0"},{"id":"ERC-7751","relationship":"Wrapped errors give even more context about why transactions failed"}],"lastUpdated":"2026-09-18","lastReviewed":"2026-09-18","sources":[{"label":"EIP-658 official specification","url":"https://eips.ethereum.org/EIPS/eip-658","type":"official-spec"},{"label":"Ethereum JSON-RPC receipt fields","url":"https://ethereum.org/en/developers/docs/apis/json-rpc/#eth_gettransactionreceipt","type":"reference"}],"technicalNotes":"A status of 1 means the top-level execution succeeded; caught inner-call failures or unmet application expectations can still occur. A status of 0 does not contain a revert reason. JSON-RPC returns hexadecimal quantities; SDKs may return numbers, bigint, or named status values. A missing receipt is not a failed receipt, and a receipt does not by itself establish finality."},"sources":[{"label":"Official specification","url":"https://eips.ethereum.org/EIPS/eip-658","type":"official-spec"},{"label":"Discussion search","url":"https://ethereum-magicians.org/search?q=EIP-658","type":"discussion"},{"label":"Ethereum JSON-RPC receipt fields","url":"https://ethereum.org/en/developers/docs/apis/json-rpc/#eth_gettransactionreceipt","type":"reference"}],"urls":{"canonical":"https://www.eipsfordesigners.com/standards/EIP-658","markdown":"https://www.eipsfordesigners.com/standards/EIP-658/content.md","agent":"https://www.eipsfordesigners.com/standards/EIP-658/agent.md","api":"https://www.eipsfordesigners.com/api/standards/EIP-658","official":"https://eips.ethereum.org/EIPS/eip-658","discussion":"https://ethereum-magicians.org/search?q=EIP-658"},"freshness":{"lastReviewed":"2026-09-18","lastUpdated":"2026-09-18"}}