The product is the signer gate
Input is a serialized Solana transaction plus multisig context. Output is a report with decoded execution context, state changes, findings, a calibrated verdict, and signer-facing verification guidance.
The core mechanism is simple: parse the transaction, simulate it against live chain state, enrich what the raw bytes mean, and reduce the evidence into a verdict before the signature is granted. TxScope is designed for the moment where a protocol can still stop a bad transaction, not only explain it after it lands.
The moat is not a secret prompt. It is transaction-level evidence, protocol knowledge, incident regression, and a conservative decision layer that refuses to label ambiguity as safety.
Resolve the transaction structure, signer set, writable accounts, and governance context.
Execute against current on-chain state and extract account, token, and CPI evidence.
Apply protocol-aware registries, IDLs, and semantic enrichment where coverage exists.
Reduce the evidence into a signer-facing verdict while keeping immature signals from overfiring.
Emit the report, evidence checklist, and trigger list a signer can inspect.
What actually feeds a verdict
TxScope is not source-code verification and it is not a brand reputation oracle. It reasons over the transaction, the simulated execution result, curated protocol knowledge, and explicit analysis gaps.
The transaction is read as submitted, then simulated against live state so TxScope can reason over what the chain would do right now, not what a UI claims it does.
Native balance changes, token movements, account-state mutations, and CPI context are surfaced as first-class evidence instead of opaque blobs.
Known programs, governance adapters, bundled IDLs, and registry context turn more of the transaction into reviewable semantics.
Unknown programs, unresolved instructions, stale dependencies, and incomplete analysis remain explicit. Clean-looking ambiguity is more dangerous than visible ambiguity.
Protocol-aware decoding without pretending omniscience
Raw Solana transactions are too opaque to review reliably if you stop at program IDs and account indices. TxScope ships a protocol-knowledge layer so common governance, lending, AMM, bridge, and treasury workflows resolve into recognizable actions.
But we deliberately preserve uncertainty. If a program is unresolved, newly deployed, registry-only, or only partially decoded, that ambiguity remains visible in the report and can elevate the signer friction. We do not paper over unknowns with a confident story.
Protocol families tracked through a maintained catalog instead of a flat allowlist.
Programs with shipped IDL-backed enrichment for stronger semantic decoding.
Registry-only programs that remain high-friction when the engine cannot decode enough structure safely.
How we keep pre-sign signal usable
A pre-sign engine fails in two opposite ways: it misses known exploit shapes, or it labels everything suspicious and trains signers to ignore it. TxScope is tuned against both failure modes.
Public case studies and internal regression checks guard against losing coverage on exploit classes Solana protocols already know matter.
The engine is checked against ordinary governance and treasury activity so normal maintenance does not become a stream of meaningless red alerts.
New signals can be observed and measured before they are allowed to dominate signer-facing verdicts. Mature categories carry more weight than speculative heuristics.
The verdict is calibrated, not theatrical
TxScope reduces the evidence surface to three outputs: BLOCK, CAUTION, and Clear for review. Those labels are only useful if they remain scarce enough to mean something.
We do not publish a complete public trigger map, because that would be a gift to anyone trying to design around the edges. What we do expose is the structure of the decision: control-plane changes, unresolved execution context, material value movement, exploit-shape correlation, and signer-relevant evidence gaps all feed the verdict, and the report shows which triggers fired.
The production scanner is intentionally strict at approval time. Internal calibration workflows help tune noise, but the customer-facing decision is judged on whether it stops dangerous approvals before they are signed.
Reserved for signer-facing conditions that are materially unsafe or too unresolved to trust at the moment of approval. These labels must stay meaningful.
Used when the transaction may be legitimate but contains enough risk, ambiguity, or unusual structure that manual verification is required before signing.
Means the engine did not find a known threat pattern or enough unresolved risk to escalate. It does not mean “safe,” and TxScope never uses that word.
What a signer or reviewer actually gets
The output is not just a color badge. A TxScope report includes a decoded instruction trace, structured state diff, matched shapes, plain-English mechanism summary, explicit verification checklist, and verdict triggers that explain why the label moved.
This matters because the report should remain useful even if the reader disagrees with the final verdict. The evidence has to stand on its own.
A signer-readable explanation of the mechanism and the main danger, grounded in the structured report rather than treated as the source of truth.
The exact places to cross-check addresses, token amounts, admin changes, and invoked programs against explorer data.
Evidence the signer must verify externally before approving, phrased as concrete checks rather than intent-confirmation traps.
A compact account of why the label moved. Enough to audit the decision, without publishing a full evasion guide.
What the engine does not prove
TxScope does not prove that a program is bug-free. It reasons over transactions and execution context, not over Rust source or formal program correctness.
The report reflects chain state at analysis time. Oracle values, balances, authorities, and surrounding context can drift before execution.
No pre-sign engine catches every novel attack. The right question is whether the product catches known dangerous classes and still preserves usable signer signal on routine traffic.
When decoding or external dependencies are incomplete, the report says so. We do not convert missing evidence into a reassuring story.
The strongest positive signal is that no known threat was detected in simulation. The signer still owns the approval decision.
How protocols can cross-check us
- Open a known incident from /case-studies and compare the current engine report against explorer data, not against our marketing.
- On the Cashio report, verify the 2,000,000,000-unit token movement and the authority-related state changes against the chain data shown for that transaction.
- On the Drift reports, verify the durable-nonce status, the authority handoff, and the post-change control surface from the structured fields, not just the headline label.
- Cross-check the exact addresses, amounts, and programs named in the report against the state diff, instruction trace, and external explorer.
- Read the verdict triggers. If you disagree with the conclusion, you should still be able to see the evidence that moved it.
- Test normal protocol-maintenance transactions too. The scanner should preserve friction for risky approvals without teaching your team to ignore every warning.
Public proof surface
The public proof surface is intentionally narrow. It shows coverage breadth, protocol depth, and current-engine case-study behavior without publishing exact detector thresholds or internal calibration data.
Paste a Squads URL, vault address, or raw transaction. Then compare the report against the chain data yourself.