In short
Your address is not in the proof. Your address is not stored.
Attested by our notary, not zero-knowledge. The notary server sees your address for the moment it checks your balance, and that is the trust you give it.
What the notary sees, stores, and never stores
| Sees (while it works) | Stores | Never stores |
|---|---|---|
| Your wallet address, recovered from your signature, while it checks the balance. | The proof: id, token, symbol, decimals, threshold, block number and hash, issue and expiry time, label, tier, notary signature. | Your wallet address. |
| Your signature on the challenge message. | The challenge text and nonce, until it is used or expires (5 minutes). | Your signature. |
| Your IP address, to apply per-IP rate limits in process memory. | A wallet × token tag (HMAC) with the hour, deleted after 24 hours. | Your IP address. |
| Your token balance at one block. | Counts: proofs issued, tokens seen, API verifications. | Your balance. |
The notary server sees your address while it checks the balance. It does not write it to disk.
Our RPC provider sees a balance query for your address coming from our server.
The database schema is public: see the schema file in the repository.
The quota tag
One wallet can get 3 proofs per token per day. To count that without keeping addresses, the server stores HMAC-SHA256(secret, address ‖ token) and the hour, nothing else.
The tag lets us count proofs per wallet per token. We cannot list addresses from it, but whoever holds our secret could test a guessed address against it. Tags are deleted after 24 hours.
The quota table has no column that links a tag to a proof.
Logs
| Logged | Never logged | |
|---|---|---|
| App | Start and stop, version, commit, error counts per code per hour, RPC errors without parameters. | Addresses, signatures, nonces, request bodies, IPs, proof ids, which token a request was for. |
| Web server | Critical errors only. | Access logs are off for the whole site, including proof pages, so an IP is never tied to a proof id. Request bodies are never logged. |
| Database | The tables listed above. | Addresses, user signatures, IPs. |
Proof links are served with Referrer-Policy: no-referrer, so a link you click on a proof page does not tell the next site which proof you came from.
No analytics. No third-party fonts or scripts. The only outside service the browser talks to is the Robinhood Chain RPC, to check a block.
How long things are kept
- Challenges: deleted once used or after 5 minutes.
- Quota tags: deleted after 24 hours.
- Proofs: valid 24 hours, kept 30 days after expiry, then deleted.
What goes on chain
Every hour, the notary writes one Merkle root of all proofs issued that hour to Robinhood Chain.
A leaf is the hash of a signed proof. The transaction is sent by the notary key, not by you.
The contract holds no funds and stores no wallet addresses.
Limits of v1
- The notary server sees your address while it checks the balance. It does not write it to disk.
- Our RPC provider sees a balance query for your address coming from our server.
- A proof is a bearer link: it shows that a wallet qualified, not who is showing it to you.
- If very few wallets hold that much, the threshold itself narrows down who you are. Pick a threshold many wallets clear.
- EOA wallets only. Smart-contract wallets (ERC-1271) are not supported in v1.
Attested by our notary, not zero-knowledge
In v1, our notary sees your address, checks the balance, forgets the address, and signs the result. What you have to trust:
- The notary key. Only proofs signed by the published notary address are valid. Anyone can check that signature in the browser or with curl.
- The code that runs it. That the server does what this page says: no address on disk, no access logs.
What you do not have to trust us for: whether a proof was really signed by the notary, and whether its block exists on Robinhood Chain. You can check both yourself.