How a scan works

A scan reads public data only, and it runs in your browser. It needs an address, nothing else: no account, no wallet connection, no signature. If a public explorer refuses your browser (too many requests, or a bot check), that request goes through the Nymra relay, which keeps no log. The relay also reads the few chains whose free API needs a key.

The steps

An address goes in. Any EVM address, or an ENS name that the Terminal turns into one.
A quick check per chain. For each chain the scan covers (the 17 that are on by default, see Supported chains), one call to a public node asks how many transactions the address sent there and whether it holds the native coin. If neither, the chain is marked “no activity” and not read further.
The history is read. From the chain’s free public explorer: the newest 500 transactions, the newest 250 token transfers and, where the chain has traces, the newest 50 internal transfers. These are fixed counts, not a time limit, so two scans of the same wallet read the same data. When a list is cut off, the oldest 50 transactions are read as well, so the coins that paid for the first transaction stay visible, and the result marks the chain as cut off. An explorer gets up to 90 seconds for the internal transfers.
The public identity is read. On Ethereum: the primary ENS name, its text records, the other names the address owns, explorer labels, and whether the address is a contract.
Seven detectors look for leaks. Each finding has a rule id, a severity, a confidence and the evidence behind it. Some detectors read a few other wallets as well, such as a funder or a deposit address, within a small budget that keeps the scan inside the explorers’ free limits. One call per chain reads how many transactions each wallet it dealt with has sent, to tell services from people.
The findings become a score. Each finding takes points off 100, by an open formula.

Results stream in: after each chain the page shows an updated result, and the result keeps filling in until every chain is done.

What counts and what is ignored

Only real transfers. A token contract can write any transfer into any history. A token transfer the wallet did not sign counts only when the token is real: priced on the explorer, held by 10,000 or more addresses, or a major token the engine lists by contract address. An incoming token also counts when the wallet sent that same token itself, and never when the explorer flags it as a scam. Airdropped spam and forged transfers do not create links.
Services and contracts. Exchanges, contracts, known service wallets and any wallet that sent 2,000 or more transactions on that chain are left out of links and counterparties: a service is never a link.
A contract or a service as the scanned address. Its traffic says nothing about a person, so only the public identity and cross-chain rules run, and it makes no links. An address is a service when the bundled lists name it (an exchange wallet or deposit address, a bridge, bot or other service wallet), when the explorer tags it as an exchange, a deposit address or an MEV bot, or when it sent 50,000 or more transactions on one chain: no person signs that many, so it counts as a bot. The result says which kind of service it is instead of showing a band.
An unused address. An address that never sent a transaction and holds nothing on any chain read, and that nothing names, has nothing to score. The result says it is unused instead of showing a band.
Activity. A chain counts as used only where the address sent a transaction. What others sent to it there is listed as received only.
Failed transactions and zero-value calls do not count as transfers.

Warnings

Scammers create addresses that start and end like yours, or like a wallet you often pay, and send you dust or fake token transfers from them, hoping you later copy one from your history. This is called address poisoning. An address is a look-alike when it shares at least the first 3 and last 4, or the first 4 and last 3, hex characters with your address or with one of your counterparties; two random addresses match like that about once in 130 million pairs. Of two look-alike counterparties, the original is the one you sent more to, or on a tie the one that appeared first, because a poisoner reacts to a real transfer. Precompiles and system contracts (an address with 30 or more leading zeros, such as 0x...01) all look alike by design and are never a look-alike.

A look-alike is never a linked wallet and costs no points. The result lists it under warnings (address_poisoning), with the address it imitates, always in full: shortened, a look-alike reads exactly like the real address. Never copy an address from a transaction history; check every character against a source you trust.

Confidence

Onchain data almost never proves who is behind an address. It shows patterns, and patterns can be strong or weak. So every finding, and every link between two wallets, carries a confidence from 0 to 1, set by the rule that produced it. Each rule’s confidence is published on its finding page.

Every link between wallets is printed with a word and its confidence as a percentage, for example “Likely 82%”. The edges come from the engine itself, so the Terminal, the docs and the result always use the same ones:

Confidence	Word	How to read it
70% to 100%	Likely	A strong signal, or several independent ones that agree.
45% to 69%	Possible	Worth knowing; other explanations are plausible.
below 45%	Weak	Shown for completeness. It barely moves the score.

Evidence you can check

Every finding lists its evidence: transactions, addresses, labels or statistics, each with a link to a public block explorer where one exists. If you disagree with a finding, open the evidence and judge it yourself.

Coverage

Next to the score, the result shows for each chain what was read and what was not:

Status	Meaning
scanned	The history was read
partial	Some lists could not be read, for example the token transfers, or the explorer’s index misses transactions the chain says the address sent
no activity	Nothing found, or the quick check showed no transaction sent and no native coin held
error	The explorer refused or did not answer, also through the relay. The chain counts as unread, never as clean
skipped	The chain is read through the relay with a free API key, and that key is not set up. The result gives the reason

A result also says when a history was cut off at the read limit, and lists the limits of each chain, such as the missing traces on Robinhood Chain.

When something could not be read (a rate limit, a timeout or a bot check), the result is marked partial and lists what is missing. A partial score is computed from what was read only, so a wallet that looks clean on a partial scan is not proven clean.

An explorer’s index can have gaps. When the chain’s own count says the address sent transactions there, but the explorer’s complete list shows none of them, or far fewer (at least 3 and more than 10% missing), the chain is partial, never “no activity”, and the result says how many are missing.

What a scan does not do

It does not use private data, leaked databases or off-chain tracking.
It does not say who owns a wallet. It reports patterns that already exist on the public chain.
It cannot move or touch funds. It only reads.