Revealsome — Selective disclosure of Solana history

// the disclosure desk

Load. Seal. Reveal a few. Let anyone check.

Four folders, left to right in time. The root from folder II is the thing you post publicly first; the bundle from folder III is what you hand over later; folder IV is what the person you hand it to runs.

Load a wallet's recent transactions

Paste a Solana wallet's public address. The page asks mainnet (through this site's read-only proxy) for its latest signatures, then fetches each transaction and reduces it to one line: signature, slot, block time, and the SOL balance change for that wallet. Requests are paced to stay inside public RPC limits, so 50 lines take about half a minute.

Or import a private ledger (.json) A file you saved earlier from folder II — lets you reveal more lines from the same root later.

Public addresses only. Revealsome never asks for a seed phrase or private key, and has no field that could take one.

Seal the ledger into one root

Every line gets its own fresh 32-byte random salt, is hashed into a leaf, and the leaves are folded into a SHA-256 Merkle tree. The root (bound to the line count) is the only thing you publish. Tick the lines you will later reveal — you can change your mind until you build the bundle.

No lines yet — load a wallet in folder I.

Build the disclosure bundle

For each ticked line the bundle carries the line, its salt, and its Merkle proof (the sibling hashes up to the root). Unticked lines contribute only opaque hashes inside the proofs — because every leaf was salted, those hashes cannot be brute-forced back into transactions.

Verifier desk

This is what the recipient runs. Paste a bundle and — ideally — the root the discloser posted publicly before sending it. The page recomputes every leaf and walks every proof to the root. Optionally it re-fetches each revealed signature from mainnet and rebuilds the line from chain data to confirm the transaction is real and the numbers match.

Re-fetch revealed signatures from mainnet

// how it works

A Merkle tree with salted leaves

Normalize. Each transaction becomes one canonical text line, e.g. revealsome/v1|wallet=…|sig=…|slot=…|time=…|sol_delta_lamports=…|status=ok. The SOL delta is postBalance − preBalance for the wallet's account index, so it already includes any fee the wallet paid.
Salt and hash. Each line gets 32 random bytes from crypto.getRandomValues. Leaf = SHA-256(0x00 ‖ salt ‖ line). Without the salt, someone could guess a hidden line (signatures are public) and test it against the leaf; with it, they can't.
Fold. Pairs of nodes are hashed as SHA-256(0x01 ‖ left ‖ right); an unpaired last node is carried up unchanged. The distinct 0x00 / 0x01 prefixes stop a leaf from being passed off as an inner node.
Bind the count. Published root = SHA-256(0x02 ‖ uint32(count) ‖ treeRoot). The verifier learns “k of N lines”, and the discloser can't later claim the ledger had a different size.
Prove. A proof for line i is the list of sibling hashes on its path. The verifier derives left/right positions from i and N itself (it does not trust direction flags), recomputes the root, and compares.
Re-check the chain. Optionally the verifier fetches each revealed signature with getTransaction and rebuilds the line with the same code. If the slot, time, delta or status differs by anything — even one lamport — it fails.

root = H(0x02 ‖ N ‖ fold(H(0x00 ‖ salt₁ ‖ line₁), …, H(0x00 ‖ saltₙ ‖ lineₙ)))

// privacy model

Who learns what

The verifier learns

The root and the total number of lines N
Each revealed line in full — including the wallet address it is about
The position of each revealed line in the ledger (newest first)
Opaque sibling hashes along each proof path
Whatever the chain itself says about the revealed signatures

The bundle does not give them

The contents of any unrevealed line (salted — not guessable from its hash)
The salts of unrevealed lines
Your private ledger file, unless you send it
Any key or signing ability — none exists in this app

Why post the root first? A root that arrives in the same message as the bundle proves only that the bundle is internally consistent — the discloser could have built the tree around exactly the lines they wanted to show. Posting the root somewhere public and timestamped before the disclosure (a post, a commit, a signed note) is what makes it a commitment: lines revealed later must match a ledger that was fixed earlier.

Known limitations — please read

Solana history is public. Anyone who knows the wallet address can read every transaction on an explorer. Revealsome limits what you hand over and prove; it does not hide anything on-chain, and once a revealed line names your wallet the verifier can look up the rest. It reduces information exposure in a specific exchange — it does not provide anonymity.
A commitment is only as good as its timing. If the root was not published before the disclosure, the bundle proves consistency, not that you didn't choose the ledger after the fact.
Completeness is limited to the snapshot. The root covers the last N signatures you loaded from one wallet. It cannot prove you have no other wallets, or nothing outside that window. Signatures returned by the RPC can also change as new transactions arrive — the snapshot is what was fetched at seal time.
One number per transaction. Lines record the SOL balance change only — not token transfers, swaps or instruction details. A line with a small SOL delta can still be a large token trade.
Lose the private ledger, lose the ability to reveal more. Salts live only in this tab. Download the private ledger if you want to reveal additional lines later; anyone holding that file can open every line.
Trusts the RPC for chain data. Both the ledger and the verifier's re-check read through this site's proxy to a public mainnet RPC. A verifier who wants independence can re-check the signatures on any explorer or their own node.
Experimental and unaudited. Built on the browser's SHA-256; no third party has reviewed it. No program, token or on-chain component exists.

Show the line. Black out the rest.