What a public chain already tells the room

Fields inside a Solana transaction

A transaction is a signed message plus execution metadata. Validators, explorers, and indexers all see the same structure. Solana documents transactions, accounts, and the RPC methods getSignaturesForAddress and getTransaction.

• Signatures and time

  A permanent activity log. getSignaturesForAddress returns signature, slot, error, memo, and blockTime for anyone who asks.

• Account keys

  Every writable and read-only account the transaction touched, including token accounts and address-lookup-table loads.

• Fee payer

  Account zero paid the fee. That is usually the wallet that signed and submitted the transaction — stronger than a receive.

• Program ids

  Which applications ran. Swaps, markets, and bridges become a behavioral fingerprint when one address is reused.

• Inner instructions

  CPI calls are in the metadata. A Jupiter route still reveals the underlying AMM, token accounts, and amounts.

• Balance changes

  preBalances / postBalances for SOL, plus preTokenBalances / postTokenBalances for SPL amounts and owners.

• Memos

  UTF-8 notes stored on-chain by the Memo programs. Invoices, names, and ids leak here more than anywhere else.

• Program logs

  msg!() output replicated by RPC nodes with the transaction. Application payloads do not belong here.

• Loaded addresses

  Versioned transactions can pull extra accounts from lookup tables. Those pubkeys are still listed in meta.loadedAddresses and join the same public graph.

• Compute budget

  Priority fees and unit limits are public infra, not identity. They can still reveal a bot’s fee strategy when the same wallet is reused.

• Token owners

  preTokenBalances / postTokenBalances include mint, amount, and owner. Associated token accounts derive from a wallet — they are a join key, not a disguise.

Methodology

VEIL Scan is a translator, not an intelligence product. It does not crawl social graphs, exchange KYC, or IP logs. The pipeline is the same one described on How it works: public RPC in, cited findings out. Solana’s own references for the surrounding model are transactions, cross-program invocation, and Token-2022 confidential transfers.

1. 01

   Window

   getSignaturesForAddress, limit 100, confirmed, newest first. Failed signatures stay in the list.

2. 02

   Bodies

   getTransaction with jsonParsed for each signature. Missing bodies are counted, not invented.

3. 03

   Flatten

   Top-level instructions plus inner CPI calls. Memo programs, system transfers, and token balance owners are collected.

4. 04

   Cite

   Findings, transfer edges, apps, and debug leaks each carry signatures. No off-chain graph is merged in.

Exposure score

The 0–100 number is a reading aid. Labels: no recorded trail, limited (1–24), moderate (25–49), high (50–74), severe (75+). It is not a legal risk rating and not a claim about the person who might control the key. Always read the findings. Weights, in plain language:

• Any history

  +12 if the window is not empty; more as volume crosses 20 and 80 signatures.

• Counterparties

  Up to +18 from unique other addresses in transfers or token owners.

• Memos

  +18 if any plaintext memo appears. This is the sharpest accidental leak.

• Apps and tokens

  Recognized non-system programs and distinct mints add a capped amount.

• Logs and control

  Application-shaped logs, failed txs, heavy fee-payer share, and UTC clustering add smaller bonuses.

What is public by default

On Solana, a transfer publishes sender, recipient, and amount unless an application uses a confidentiality extension or keeps the payload off-chain. Failed transactions still exist: the program, the accounts, and often the attempted amount remain in the signature list. Reusing one hot wallet across mint, swap, lend, and bridge is a join key — those behaviors become one public story.

Token-2022 has optional confidential transfer hooks. They are not the default, they are not Zcash, and most wallets still move value in cleartext. VEIL Scan reports what the RPC actually returned, not what a future program might hide.

What this report will not claim

• A transfer is not proof that two addresses share an owner.
• A time-of-day cluster is not a passport or a home address.
• A recognized program is a behavior, not a legal identity.
• VEIL Scan does not merge CEX KYC, social graphs, or IP logs.
• A 100-signature window is not a lifetime dossier. Older history remains public elsewhere.

What a zero-knowledge proof changes

A zero-knowledge proof lets a prover show that a statement is true without revealing the underlying witnesses. In a shielded payment, the statement is roughly: “these notes are valid, the values balance, and I had the right to spend them.” The network can verify that without learning who paid whom, or how much.

Zcash designed shielded transfers around that idea. Transparent ZEC (t-addresses) still look like a public ledger: sender, recipient, and amount are visible. Shielded transfers use zk-SNARKs so those three fields stay in the proof, not in the clear. Viewing keys exist so an owner can disclose a payment later — that is selective disclosure, not a backdoor for the whole chain.

Transparent chains can still host applications that avoid putting extra data in memos and logs, but they do not get those privacy properties for free. Splitting wallets, hashing references, and keeping user ids off-chain are hygiene. They are not the same as a shielded value transfer.

Zcash maintains its own explainers for the cryptography and the culture around using it: z.cash/learn, technology overview, and the protocol specification. ZK VEIL is not a Zcash wallet and does not submit shielded transactions.

Hygiene on a transparent chain — splitting fee payer from treasury, hashing invoice references, keeping user ids out of memos and logs — reduces accidental extra disclosure. It does not hide sender, recipient, or amount. Token-2022 confidential transfers are an optional extension, not the default, and they are not a Zcash shielded pool. If you want the cryptography from the people who shipped it, stay on z.cash/learn and the technology overview. If you want the scanner’s own limits in Q&A form, see the FAQ.

A side-by-side, not a product bridge

On this site

The scanner has its own contract, vocabulary, and product limits. Those live next to this contrast, not inside a Zcash document.

• How it works

  The RPC pipeline: last 100 signatures, parsed bodies, cited findings.

• Methodology

  Score weights, transfer-map caps, and claims we refuse to make.

• Glossary

  Fee payer, memo, jsonParsed, shielded transfer, viewing key.

• FAQ

  Wallet connect, tokens, scan privacy, Zcash affiliation.