TXLens
Check
Public data, explainable rules

TXLens methodology

A TXLens diagnosis is a comparison: what the public ledger says happened against what the destination publicly says it accepts. This page explains the inputs, source hierarchy, automated checks, human limits and freshness policy behind that comparison.

Published and reviewed 18 August 2026

1. Inputs and public-data sources

The required input is a transaction ID. A destination platform is optional, but it is needed for a platform-specific comparison. A transaction ID, addresses, value and status are already public on the relevant blockchain.

TXLens queries public JSON-RPC or API endpoints for Bitcoin, Ethereum and supported EVM networks, TRON, Solana and the XRP Ledger. Depending on the network, it reads inclusion status, timestamp, sender and recipient, native value, token transfer events or balance changes, and confirmation or finality status. Third-party endpoints transport this public data; they are not treated as authorities on exchange policy.

2. Source hierarchy for policy claims

  1. Protocol and ledger evidence first. Network documentation defines mechanics such as destination tags. For example, the XRP Ledger destination-tag documentation explains how a shared address payment maps to an off-ledger customer.
  2. The receiving platform for its own rules. Official support material and deposit screens outrank blogs, forums and aggregator tables. Kraken's confirmation guidance is an example of a primary source for crediting thresholds.
  3. Official recovery policy for recovery claims. Eligibility is never inferred from address format alone. The Coinbase asset-recovery documentation shows how platform, asset and network eligibility can narrow a route.
  4. Government warnings for scam patterns. Claims about recovery fraud are grounded in sources such as the US Federal Trade Commission recovery-scam guidance.

Community posts can reveal that a rule may have changed, but they are not cited as proof of a platform policy. A primary source is required before TXLens changes that policy.

3. How the comparison works

  1. 1. Candidate networks are identified from the transaction-ID format and queried.
  2. 2. The matching ledger record is normalised into network, asset, amount, addresses, status, timestamp, confirmations and any memo or destination tag.
  3. 3. If a destination is supplied, those facts are compared with the stored network support, confirmation threshold, approximate minimum and memo rules for that platform.
  4. 4. Deterministic failures are separated from uncertain platform-side states. A failed transaction can be stated as failed; an exchange's internal review queue cannot be observed and must remain a likely explanation.
  5. 5. The output points to the destination's official recovery or support route. It never claims that TXLens can carry out recovery itself.

4. Automated checks and editorial review

Automated checks validate catalogue structure, source presence, internal links, structured-data shape and data-table consistency. They can detect contradictions in the stored dataset; they cannot decide whether an exchange's prose is current or interpret an ambiguous policy change.

Source review is performed under the organisational identity TXLens Editorial. It combines those automated data checks with an editorial comparison against primary sources. TXLens currently has no named credentialed human reviewer, and does not manufacture a person or qualification. Structured data supports a named human reviewer later, but one is emitted only when a real reviewer is explicitly recorded.

5. Review cadence and freshness

  • The target cadence for platform-rule and high-risk guide review is at least monthly, with an earlier check when an official policy change is found.
  • A guide's full reviewed date means its claims and primary citations were checked. Older generated pages may carry only the month available in the platform dataset.
  • Sitemap and structured-data dates come from those stored review fields. Deploying or rebuilding unchanged content does not create a new freshness date.
  • If a page is past its target cadence, the old date stays visible. TXLens does not move it forward merely to make the content look fresh.

6. Uncertainty and limitations

  • Public chain data does not expose an exchange's account mapping, maintenance queue, compliance hold or internal crediting decision.
  • Confirmation thresholds, supported networks, minimum deposits and recovery fees can change without notice. Stored values are comparisons, not promises by the platform.
  • The same address format across EVM networks can make recovery technically possible without making it available under the receiving platform's policy.
  • A successful on-chain transfer proves delivery to an address, not ownership of that address or entitlement to an exchange account credit.
  • Provider outages or incomplete responses can delay a result. TXLens should report that gap rather than replace it with a guess.

7. Corrections, the paid line and scam safety

The correction standard and current contact limitation are published at About TXLens: corrections and contact. A correction changes a review date only after the cited rule is re-checked.

Transaction facts remain free. The paid boundary is the interpretation and transaction-specific action plan, not access to the public evidence. Paying does not buy recovery, exchange influence or certainty.

Anyone who contacts you first, asks for a seed phrase or private key, claims to reverse a confirmed transfer, or demands an extra payment to “release” recovered funds is not providing a TXLens diagnosis. Stop and use the recovery scam guide.