amount-correlation linker

Same sum.
Same hands?

Mainnet live · checking… Status: Ticker (placeholder, no token exists):
the working app

Do these two wallets share a sum?

Paste two public addresses. Sumtrace reads both histories from mainnet, lists what left A and what arrived at B, and pairs transfers whose amounts agree within your tolerance and time window.

Compare

Both histories are capped so the public RPC stays usable.

Waiting for two addresses.

Amount meter

How identifying is an amount? Type one — computed locally, nothing is sent.

Significant digits are what make an amount a fingerprint.

Matches

—out of sender
—into receiver
—amount pairs
—direct transfers
Heuristics from public mainnet data, not proof.
No comparison yet.
how it works

The matching, step by step

  1. Read both sides. For each wallet: getSignaturesForAddress (up to 100), then getTransaction (jsonParsed) for up to 40 of the newest successful ones, two at a time with back-off on rate limits. A transaction both wallets share is read once.
  2. Parse transfers. System Program SOL transfers and SPL Token / Token-2022 transfer, transferChecked, transferCheckedWithFee, including inner instructions; token accounts are resolved to their owners from the transaction's token-balance metadata.
  3. Pair. Every transfer out of the sender is compared with every transfer into the receiver of the same asset: the receive must come after the send and inside the window, and the amounts must agree within the tolerance (plus a fee allowance for SOL). Exact BigInt arithmetic — no floating-point rounding.
  4. Rate the evidence. An exact, specific amount (many significant digits) is strong; a round amount like 1 SOL is weak because thousands of people send it. If one send matches several receives, each is marked ambiguous. Direct A↔B transfers are listed separately — they need no matching at all.
Don't forward exact sums.Moving 3.71842 SOL in and 3.71842 SOL out is the clearest fingerprint there is.
Split and vary.Different, non-round pieces over different times break the one-to-one pairing — but each piece is still a public transfer.
Let time pass.Tight timing makes even round amounts suspicious. A long, irregular gap widens the crowd you blend into.
privacy model

What this shows — and what it can't hide

Kept private

  • Which wallets you compared: the server only relays allowlisted read calls and keeps no log of them; no account, no analytics
  • The matches: computed in this page, never uploaded or stored
  • The amount meter: runs entirely in your browser

Still visible

  • Every amount and timestamp on-chain is public — anyone can run this exact comparison on your wallets
  • The RPC operator (this proxy and the upstream mainnet RPC) sees your IP, the time, and that both addresses were requested together
  • Explorer links open a third-party site that sees what you click
  • Sumtrace can't unlink anything; it only shows what's already linkable

Sumtrace helps you reduce linkability by making it visible. It does not provide anonymity.

Known limitations — please read

  • A match is not proof. Equal amounts can be coincidence — especially round ones on busy wallets. Treat every pair as "an observer would suspect this", never as fact.
  • No match is not privacy. Only the newest transactions (≤40 per wallet) are read. Older history, multi-hop paths, splits, swaps between assets, exchanges and bridges are not followed.
  • Windows must overlap. If the two wallets' analysed periods don't overlap, pairing can't work — the page warns you when that happens.
  • Token coverage. Incoming token transfers usually touch only the receiver's token account. The token-account option reads up to three of them, for tokens the sender actually sent.
  • Public RPC limits. Reads are throttled and retried, may be slow, and some may fail; failures are counted, not hidden. Experimental and unaudited.