TXINT

Purpose

To follow money on a chain, an analyst opens one explorer, then a second, then a third, and holds the overall picture in their head. Working this way, the analyst loses the links between operations.

• The hidden shape of the movementA four-hop chain of intermediary addresses, a split that reconsolidates later, a ring of transfers: every single hop looks ordinary on its own.
• The volume of an exchange walletHundreds of thousands of transactions arrive with an exchange address, and the transactions the address was opened for are lost among them.
• A partial answer passing for a complete oneA provider that timed out, a walk that hit its cap: unless the product says so, an incomplete graph reads as “nothing else happened”.

TXINT is built for these three problems: it shows the shape of the movement, keeps large addresses closed and states where an answer is incomplete.

From an address to a finding

Five stages, and each one can stop early. The product records in the warnings where it stopped.

1. Input
2. Chain detection
3. History
4. Graph
5. Detectors

A branch to a second chain is drawn only when the deposit transaction itself declared the destination and the recipient, and the arrival was then found there.

Capabilities

• Thirteen networks, detected and read

  Six EVM chains (Ethereum, BNB Chain, Polygon, Base, Arbitrum and Optimism), plus Bitcoin, Litecoin, Dogecoin, Bitcoin Cash, TRON, Solana and TON, and ENS names.

  The same address string is valid on several chains at once, so the answer is a list of candidates ranked by evidence rather than one guess. A chain whose adapter has not been written yet is reported as unavailable, never as an address with no activity.

  Inside an EVM transaction the product reads asset flows, net balances, decoded logs, and the call tree when the node will serve one.

• The shape of the movement

  Fifteen detectors read the graph. Four of them as examples: a peel chain, a ring, a fan-out that later reconsolidates, value passed along through intermediary addresses.

  Every finding carries a confidence, an explanation of what it was read from and the thresholds it was found with. Detectors work over the stored graph and ask the network for nothing, so the same graph with the same thresholds gives the same findings.

• Completeness of the answer

  Every cap records a named reason, and the answer says which cap was hit and where. A finding whose region touches a hub or a truncated expansion carries a reduced confidence and says so.

  Read those warnings before the graph: the same picture means different things depending on what they say. A graph can end because a cap was reached, because a provider did not answer, or because a bridge never declared where it went — and on screen all three look alike, as an edge that is simply not there.

• Hub addresses

  A hub check runs before any history is fetched, and an address above the threshold is sampled, flagged and never expanded on its own. The labelled addresses of exchanges, mixers and bridges are left closed for the same reason: behind each of them stand millions of other people's transfers.

  The check reads the history endpoint rather than the account's transaction counter, because that counter is zero for an address that only ever received, and counts something else entirely for a contract. It would miss exactly the addresses the check exists to catch.

• Crossings between networks: five states

  Confirmed, unconfirmed, unsupported destination, undeclared and not checked. The last is an answer like the others: confirming an arrival needs history on the destination chain. Without a key for it the deposit is still decoded, and its declared destination is shown marked as not checked.

  Every deposit is listed either way, and the export carries the ones that led nowhere too. Without them a reader cannot tell whether the bridges were examined at all.

• Export of the result

  Export as JSON, CSV, Excel, Markdown or PDF, the graph over an API, the build reported as events while it runs. The interface is in English and Russian, findings included.

How it is used

The product comes up with one command and runs without a single key. Keys are added as the work needs them.

1. 01One commanddocker compose up --build. The interface is on port 3000, the API on 8000, with the generated API documentation beside it.
2. 02Work with no key at allDetection, ENS resolution, Bitcoin, Litecoin and TON need none, and the whole test suite runs offline.
3. 03Add keys as you need themOne Etherscan V2 key opens all six EVM chains and is the one worth getting first. Every key is personal, billed against one account, and never reaches a log line.
4. 04Ask what is availableThe health endpoint states which keys are configured, which chains have an adapter, and whether the node will serve a transaction call tree.
5. 05Start narrow and widen a step at a timeDepth and window decide more than anything else: on one Bitcoin address a thirty-day window gave 717 nodes and 27 findings, ten years gave 2178 and 104. On a UTXO chain every output of a transaction becomes a node, so a few hundred transactions turn into thousands of nodes. Six hundred findings are no more use than thirty: the ones that matter are lost among the rest.

In detail

1. The methodWhat the detectors look for, how the confidence of a finding is computed, and how the risk level is set.→
2. The formatWhat an export holds and how its recipient checks it against the journal it carries.→