Concepts
After this page you can read any WireTap screen, alert, or API response and know exactly what each number means. Five ideas cover the whole product.
The failure taxonomy
Section titled “The failure taxonomy”Every unhappy transaction is one of three kinds. The distinction matters because each kind needs different evidence to diagnose — and most tooling only sees the first.
1. On-chain failures
Section titled “1. On-chain failures”The transaction landed and failed. The chain records it, but as an opaque code
(custom program error: 0x1771). WireTap decodes it against your IDL to the error you wrote
(SlippageExceeded, code 6001), including which instruction failed and at what CPI depth.
Observed from chain data alone — no SDK needed.
2. Dropped transactions
Section titled “2. Dropped transactions”The transaction was sent but never landed. Nothing on chain, nothing in the explorer. WireTap’s correlation job matches SDK send-envelopes against observed chain data and classifies every unmatched send:
| Drop reason | Meaning |
|---|---|
expired_blockhash |
Not included before lastValidBlockHeight passed |
cu_exhausted |
Priority fee / compute budget lost the inclusion race |
rpc_lag |
The RPC accepted it but was behind or shedding load |
never_sent_preflight |
Failed client-side simulation; never left the machine |
Requires the SDK — no observer can see a transaction that was never recorded anywhere.
3. Preflight failures
Section titled “3. Preflight failures”A subclass worth its own bucket: the transaction died in simulation before sending. The SDK captures the simulation logs and error so these stop being invisible.
Events
Section titled “Events”One observed transaction = one event. Every rate you see is built on this unit: a transaction observed on-chain is one event; an SDK envelope that never lands is one event. Billing, though, is not metered on events — plans are a flat per-program subscription, with no credits and no per-seat math.
Landing Score
Section titled “Landing Score”The bot-adjusted real-user landing rate: of the transactions real users attempted against your program, the fraction that landed, scored per day with Wilson 95% confidence intervals. Bot traffic (~92% of headline Solana “failures”) is segmented out by a documented heuristic. Full recipe: Landing Score v1.
Issues & fingerprints
Section titled “Issues & fingerprints”Failures are grouped into issues by a stable fingerprint:
fingerprint = v1:sha256(program, top-level instruction, error code, CPI depth)The fingerprint deliberately excludes anything release-specific, so an issue’s history survives deploys — which is what makes the next concept useful.
Releases
Section titled “Releases”WireTap detects deploys of tracked programs (BPF Upgradeable Loader upgrades) and records the deploy slot. Every issue rate can then be split before vs after a release; a regression push fires in Telegram when a post-deploy rate degrades. See Telegram bot for the alert format.
Next: put the taxonomy to work — Quickstart or SDK to start catching drops.