Issue from Claude (filed by @stacks-alex):
Problem
Failed contract-call pages show one of two boilerplate sentences chosen by tx_status, plus the raw vm_error. In a 1,500-tx mainnet sample:
- 56% of failures are explicit
(err uN) returns, where vm_error is null — the page shows nothing beyond boilerplate.
- Every
abort_by_post_condition in the sample had an (err …) result (the call itself failed and the post-condition then evaluated N SentGe 0). The page says it "would have succeeded" — it would not.
- 40% are runtime panics shown as a bare
ArithmeticUnderflow.
The API and contract source contain enough to explain ~95% of failures in plain language with a concrete next step (94% of error codes resolve to a named define-constant in the called contract).
Proposal
- Deterministic diagnosis engine (pure TS, no model): classify → parse
vm_error → resolve error constants from source (called contract, then callees) → plain-language templates → cheap correlations (later successful retry, historical balance via until_block). Rendered as a tiered "Why it failed" card: headline + what to do above the fold, details behind a click.
- Agent context pack:
GET /txid/{id}/context.md (and .json) with the diagnosis, facts, relevant source excerpts and an embedded playbook, plus a "Copy prompt" CTA — so any agent can dig deeper with no inference cost to the explorer.
Scope: confirmed contract_call transactions only; mempool/dropped and deploy failures keep today's alerts. One PR for both parts.
Acceptance
On the fixture corpus (489 mainnet failures): 100% correct masked-vs-genuine post-condition classification; ≥90% of explicit error codes resolve to a named constant; no (err …) result ever yields a "would have succeeded" headline; Tier 0 renders server-side with zero extra requests.
Example: https://explorer.hiro.so/txid/0x22b61b960238b6e2a5c9749f61ed3f87084fac2002e8d4cd7b02339b3400d0f1?chain=mainnet
Issue from Claude (filed by @stacks-alex):
Problem
Failed contract-call pages show one of two boilerplate sentences chosen by
tx_status, plus the rawvm_error. In a 1,500-tx mainnet sample:(err uN)returns, wherevm_erroris null — the page shows nothing beyond boilerplate.abort_by_post_conditionin the sample had an(err …)result (the call itself failed and the post-condition then evaluatedN SentGe 0). The page says it "would have succeeded" — it would not.ArithmeticUnderflow.The API and contract source contain enough to explain ~95% of failures in plain language with a concrete next step (94% of error codes resolve to a named
define-constantin the called contract).Proposal
vm_error→ resolve error constants from source (called contract, then callees) → plain-language templates → cheap correlations (later successful retry, historical balance viauntil_block). Rendered as a tiered "Why it failed" card: headline + what to do above the fold, details behind a click.GET /txid/{id}/context.md(and.json) with the diagnosis, facts, relevant source excerpts and an embedded playbook, plus a "Copy prompt" CTA — so any agent can dig deeper with no inference cost to the explorer.Scope: confirmed
contract_calltransactions only; mempool/dropped and deploy failures keep today's alerts. One PR for both parts.Acceptance
On the fixture corpus (489 mainnet failures): 100% correct masked-vs-genuine post-condition classification; ≥90% of explicit error codes resolve to a named constant; no
(err …)result ever yields a "would have succeeded" headline; Tier 0 renders server-side with zero extra requests.Example: https://explorer.hiro.so/txid/0x22b61b960238b6e2a5c9749f61ed3f87084fac2002e8d4cd7b02339b3400d0f1?chain=mainnet