Whitepaper

Ownership you can prove without publishing.

Draft 0.1Design documentNot audited · not deployed

DraftThis describes an intended design. It is not a report on a running system: nothing here has been implemented on a network, reviewed or audited, and the boxed values below are choices that have not been made yet.

Summary

Gatestock is a privacy layer for onchain ownership. An asset is placed into a commitment set under a key that has never held anything else. Holding, receiving and transferring are changes to that set. When ownership has to be demonstrated, a single commitment is opened to a single counterparty, and that counterparty learns one thing: that the claim is true.

The design goal is narrow and worth stating plainly. It is not to hide that assets exist, nor to obscure the movement of the set. It is to break the link between an address and an inventory.

The problem

A public ledger makes ownership durable by making it legible. Every mint, every claim and every token-gated login points back at one address, and an address accumulates. What began as a convenience becomes a permanent, public inventory of everything its holder owns, readable by anyone, for as long as they hold it.

The usual answer is a second wallet, and it fails for a structural reason: the moment the second wallet has to prove anything to anyone, it becomes the first wallet. Compartmentalisation by hand degrades every time it is used, and it degrades silently.

Hidden and not hidden

A privacy claim is only meaningful with its boundary attached. This is the boundary.

Intended to be hidden

Which asset a given commitment corresponds to, absent an opening.
The link between a wallet used to interact and the contents of the set.
The rest of a holder's portfolio, when a single commitment is opened.

Not hidden, by construction

That the set exists, and that it changed. An observer sees a leaf enter or leave.
The timing and the gas payer of every operation, which are properties of the chain and not of this design.
Anything a counterparty is told during an opening, and anything they can correlate with it afterwards.

Construction

Commitment

A commitment binds an asset to a secret salt and to a fresh key, and is computed on the holder's device. Only the commitment is intended to reach the chain. The preimage — asset, salt, key — stays with the holder, and losing it means losing the ability to prove or to transfer.

The console at /app runs this step literally, with SHA-256 over the concatenated preimage and keys from the browser's CSPRNG, so the shape of the operation can be inspected. The production hash and commitment encoding are not fixed; the console is an illustration, not a specification.

The set

Commitments accumulate in an append-structured set held onchain, against which membership can be proven without identifying the member. The concrete structure, its depth and its update rule are not fixed.

One-time keys

Every leaf is authorised by a key generated for it and used for nothing else. A key that has only ever touched one asset carries no history to correlate, which is the property the whole design depends on. Reusing a key would collapse the anonymity set back to the size of that key's history.

Receiving

Delivery is taken into the set rather than into the wallet used to collect. An observer sees the set grow by one. They do not learn which recipient the growth belongs to.

Transfer

Handing ownership on retires the authorising key on the spot and installs a new commitment under a new key. An observer sees one leaf out and one leaf in, with nothing linking the two beyond their adjacency in time.

Proving

A holder opens one commitment to one verifier. The verifier checks the claim against live chain state and gets a single bit back. Nothing else moves and nothing else is named. The proof system — and therefore the trusted-setup question, the proving cost and the verification cost — is not selected.

Threat model

The adversary assumed here is a passive observer with a full view of chain state and history, unlimited time, and the ability to join the set themselves. They are assumed to be able to correlate onchain events with each other and with public offchain data.

They are not assumed to control the holder's device, to observe the holder's network at the packet level, or to compel a counterparty to reveal what an opening told them. Each of those defeats the design, and none of them is in scope.

Limitations

These are properties of the approach, not defects to be patched later. They are listed because a privacy tool that hides its failure modes is worse than none.

Timing correlation. A set with few participants, or one operation at a distinctive moment, narrows the anonymity set regardless of the cryptography.
Gas and funding. Whoever pays for an operation is visible. Funding an operation from a wallet that is already public reattaches the identity the design just removed.
RPC and endpoint metadata. The node a holder queries can see what they asked about. This is outside the protocol and is not solved by it.
The counterparty. An opening is disclosure. A verifier can record it, publish it, or correlate it with everything else they know.
Key loss. Secrets held only by the holder mean no recovery path. This is the cost of self-custody, stated rather than engineered around.

Open parameters

Everything below is undecided. It is listed rather than filled in because naming a plausible choice here would read as a commitment that has not been made.

Proof system and its setup assumptions — tbd
Hash function and commitment encoding — tbd
Set structure, depth and update rule — tbd
Network and contract addresses — not deployed
Independent review — not commissioned

Status

Nothing described here is live. There is no contract, no token and no fundraising associated with this document. The only working software published so far is the local console, which touches no network at all.

Gatestock is an independent, self-custody design. It is not affiliated with, endorsed by, or operated by Robinhood Markets, Inc.