The passport in the drawer
Somewhere there is a drawer, and in it is a scan of your passport. You do not know which drawer. You made the scan on a Tuesday evening in 2021 because a screen asked you to, and the screen belonged to a company that has since been acquired, rebranded, and possibly breached. The scan is still there. It will be there after you have forgotten the company's name.
This is the normal condition of a person who has ever done anything financial online. Each service that needed to know one thing about you took everything, because taking everything was the only way anyone knew how to check one thing. You wanted to buy a share. They wanted to know you were allowed to. The transaction between those two facts was your whole identity, copied.
vry:st begins with a simple refusal: the copy was never necessary. It was a limitation of the tools, not a requirement of the question.
What a question costs
Every gate in a regulated market is a question. Are you over eighteen? Are you resident somewhere we may serve? Are you on a list we may not serve? Do you hold what you claim to hold? These are yes-or-no questions. The correct answer to each is one bit.
Look at what is paid to obtain that bit today. A document with your face on it. A utility bill with your address. A selfie holding the document. A liveness video. The provider's storage of all of the above, indefinitely, across jurisdictions, under a privacy policy you did not read. Then the same again for the next venue, and the next.
The price of a bit has been, roughly, a life. We think the price of a bit should be a bit.
The database somebody else keeps
There is a quiet assumption underneath every identity system built in the last twenty years: that the record must live with the party who checks it. The verifier keeps the file because the verifier does the verifying. It feels natural. It is also the root of nearly every harm the system produces.
A database somebody else keeps is a database you cannot delete, cannot audit, and cannot know the future of. It changes hands in acquisitions. It is subpoenaed for things unrelated to why it was built. It leaks. When it leaks, the fact that you once bought a share becomes the fact that a stranger has your passport.
The alternative is not "no database." It is a database you keep, with a way to answer questions from it that does not require handing it over. That is the whole idea. Everything else is engineering.
Compliance is a boolean
We say this often enough that it has become a slogan, so it is worth being precise. A rule says: this asset may only be held by persons meeting condition C. The rule does not say the venue must possess the evidence for C. It says the venue must not serve people for whom C is false.
Those are different obligations. The first is satisfied by knowing C is true. The second is satisfied by an audit trail showing you only served people for whom C was demonstrated. Neither requires the venue to hold the underlying facts, as long as someone accountable once checked them and the check can be shown to have happened.
Compliance, then, is a boolean plus a provenance. Not a biography. The moment you accept that framing, the passport in the drawer becomes obviously excessive.
The bar
Our visual language is a black bar over text. It is the oldest privacy technology there is: the redaction. A redacted document is still a document. It still has a date, a signature, a structure, a meaning. It simply withholds the parts that are not the reader's business.
We chose the bar because it is honest about what it does. It does not pretend the information does not exist. It says: this is here, and you are not entitled to it. A verifier looking at a vry:st receipt sees exactly that. The claim, the result, the timestamp, in the clear. The subject, the jurisdiction, the balance, the history, under the bar.
The bar is also a promise about our own product. Anything we could have put under it and did not, we owe you an explanation for.
Why now, why here
Zero-knowledge proofs have been mathematically possible for decades and practically usable for a handful of years. What changed is not the math but the cost. A proof that once took a server minutes now takes a phone a second. That is the threshold at which a proof can sit inside a checkout flow instead of beside it.
The other thing that changed is that regulated assets are moving on-chain in earnest. Tokenized equities, funds, and credit are no longer experiments. They are products with terms of service. And every one of them needs a gate.
Robinhood Chain is where those two curves cross. A chain built to carry regulated financial assets is a chain that will ask more questions per transaction than any before it. Someone has to decide whether each question costs a bit or a life. We decided.
Tokenized markets and the second upload
Here is the specific failure we are here to prevent. A person verifies with a broker. Tokenized shares of a company become available on-chain. The venue listing them is a different legal entity, so it asks the person to verify again. A lending protocol accepts those shares as collateral, so it asks a third time. A secondary market, a fourth.
Each upload is a new drawer. Each drawer is a new breach surface. And the person, who was verified once and has not changed, is treated as unverified everywhere the first record does not reach.
The second upload is the symptom. The disease is that verification produced a file rather than a fact. vry:st makes it produce a fact — a credential, held by the person — that can be asked about anywhere without being copied anywhere.
The three parties
Every vry:st interaction has three roles and we are careful to keep them separate. The issuer knows you. It checked your documents once and signed a statement. The holder is you, or more precisely your wallet, which keeps that statement and can compute proofs from it. The verifier needs one thing to be true and does not care about the rest.
The design principle is that no party gets to play two roles at once. The issuer does not learn where you prove. The verifier does not learn who issued. The holder does not have to trust either of them with anything they did not already have.
vry:st itself is not a fourth party. There is no vry:st server in the path a proof takes. That is deliberate and we will keep coming back to it.
Attest once
The first primitive is attest. An issuer that has verified you signs a commitment to what it found, bound to your wallet, and hands it back. That is the end of the issuer's involvement in your daily life. It does not get a call every time you use the credential. It cannot see a log of where you went.
This inverts the usual power relationship. Today the verifier of record is a gatekeeper you return to. Under vry:st the issuer is more like a notary: important at the moment of signing, absent afterward.
It also means the issuer's business changes. It is paid for the quality of its attestation, not for the size of the database it accumulates. We think that is the right thing to be paid for.
The question the verifier is allowed to ask
The second primitive is verify, and it starts with the verifier, not the holder. A verifier publishes a requirement: exactly which claim it needs, which issuers it will accept, how long a receipt may live, and whether it will share receipts with anyone. This is public. Anyone can read it. A holder's wallet reads it before the holder even reaches the button.
Publishing the question has a disciplining effect. A venue that asks for age ≥ 18 and jurisdiction in permitted set is asking for what the law requires. A venue that asks for full name and date of birth is asking for more, in public, and has to explain why.
The claim language is small on purpose. Comparisons, set membership, freshness, conjunction. If you cannot say it in those terms, you are probably asking the wrong question.
Proofs are not promises
People sometimes describe zero-knowledge proofs as "trust me, but cryptographically." That undersells them. A promise can be broken by the person who made it. A proof cannot be broken by anyone, because it is not a statement about intent; it is a demonstration that a computation happened and its output was what is claimed.
When a wallet proves jurisdiction in permitted set, the verifier does not trust the wallet. It trusts a verification equation that either holds or does not. The wallet could be lying about everything else in its life and the equation would still not hold unless there is a real credential, from a real accepted issuer, that satisfies the claim.
This is why we can afford to be so strict about what leaves the device. The proof carries all the assurance. The data would carry only liability.
The receipt
The third primitive is settle, and its output is the receipt. A receipt is small: a claim id, a result, a scope, an expiry, and a nullifier. It lives on Robinhood Chain. It has no owner field.
That last detail matters. A receipt is not a token you hold. It is a record that a proof was verified, findable by the verifier it was made for, and connected to you only through a value that you and that verifier can compute and no one else can.
We chose to settle receipts on-chain rather than pass proofs point-to-point because a receipt is reusable and a proof is not. Once your jurisdiction receipt exists, any venue asking the same question in the same scope can accept it. You proved once. You are done.
Nothing without an expiry
Every receipt has a time to live, and the holder sets it, within a maximum the verifier declares. When it passes, the receipt is inert. There is no renewal transaction. If you want to keep trading, you prove again, which takes under a second and costs nothing.
We insist on expiry because permanence is where privacy goes to die. A fact that was true and harmless in 2026 is a fact that can be joined with something else in 2031. The only reliable defense is to make facts stop existing. Anything that can expire, should.
Expiry is also our answer to revocation, as the next chapters explain. A short TTL is a faster reaction than any revocation list, and it does not leak.
Scope, or the right not to be joined
The most underrated privacy harm is not disclosure. It is joining: the ability to take two records that are each harmless and combine them into one that is not. The venue that knows you are over eighteen and the venue that knows you hold a particular asset are, separately, fine. A party that can see both and link them has built a profile.
vry:st receipts are scoped. A receipt made for one verifier carries a nullifier that only that verifier can match to you. The same claim proved to a second verifier produces a different nullifier. Their records cannot be joined, not because they promise not to, but because the values do not correspond.
You may choose a broad scope for convenience. The wallet will tell you what that costs. We would rather you did not, and we say so in the docs.
The issuer you cannot name
A verifier accepts a set of issuers. Three, five, ten. When you prove, the proof shows that your credential was signed by one of them. It does not show which.
This seems like a small thing until you consider what an issuer's identity reveals. A regional KYC provider tells you where someone lives. A specialist accreditation firm tells you their wealth bracket. The choice of issuer is itself a fact about a person, and we put it under the bar.
It also protects issuers from being singled out and pressured. If a verifier cannot tell which provider a holder used, it cannot discriminate between them after the fact. It must decide, up front and in public, which issuers it trusts, and then live with that decision.
On revocation and the ethics of forward-only
Credentials can be revoked. An issuer discovers it was deceived, or a person's status changes, and the issuer updates a revocation structure that every future proof must be checked against. That much is standard.
What is not standard is our refusal to make revocation reach backward. An existing receipt stays valid until it expires. We are sometimes asked why. The answer is that a retroactively cancelled receipt is a signal: it tells the verifier, and any chain observer, that this specific nullifier belongs to someone who was just revoked. That is a disclosure, and a damaging one.
Verifiers who need faster reaction have a tool: set a shorter maximum TTL. It costs the holder nothing and leaks nothing. We would rather give verifiers that lever than build a mechanism that turns revocation into an announcement.
The device is the boundary
All proving happens on the holder's device. Not on a vry:st server, not on the verifier's server, not on a "trusted enclave" somewhere. The credential is decrypted in memory, the circuit runs, the proof is produced, and the credential is re-sealed. Nothing crosses the boundary except the proof.
We are aware this is a harder engineering path. Client-side proving means shipping WebAssembly provers, caching keys, handling low-end phones. A server would have been easier to build and easier to scale.
It would also have been a drawer. A very well-designed drawer with excellent access controls, but a drawer, with a passport scan in it, that someone other than you keeps. We have already explained why we will not build that.
What the chain sees
Let us be exact about the public record. For every settled receipt, Robinhood Chain contains: a claim id (a hash of a question that thousands of people answer), a boolean, a scope, an expiry, a settlement time, and a nullifier (a value that looks random to everyone except one verifier).
From this an observer can learn that, at a certain block, someone somewhere satisfied a common requirement for a certain venue. They cannot learn who. They cannot learn which issuer. They cannot connect it to the same person's receipt at another venue. They cannot connect it to the address that paid the gas, if a relayer was used.
That is the entire footprint. We publish it because we would rather you check it than trust it.
Regulated and private are not opposites
There is a lazy story in which privacy is what you have before regulation arrives, and regulation is what removes it. Under that story, a compliant market is by definition a surveilled one, and anyone building privacy tools for regulated assets is confused about which side they are on.
We think the story is wrong and the confusion is elsewhere. Regulation specifies outcomes: no minors, no sanctioned parties, no unaccredited holders of restricted instruments. It does not specify that the venue must become a repository of everyone's documents. That was an implementation detail chosen by people without better tools.
A venue running on vry:st is more compliant, not less. Every gate is enforced by a proof that cannot be faked, against a requirement that is public and auditable. What it lacks is the honeypot. We do not think regulators will miss the honeypot.
The honest regulator's interest
Consider what a regulator actually wants from a market. That the rules were applied. That there is a record showing they were applied. That the record can be examined if something goes wrong. That the people applying the rules were competent and accountable.
vry:st gives all four. Rules are applied by proofs. Records are receipts, on a public chain, timestamped. Examination is possible: a regulator can see that a venue's requirement matches the law, that every order was gated, and can, through the accountable issuer, resolve a specific case if a court requires it. Accountability sits with named issuers who registered their keys in public.
What vry:st withholds is the bulk view: the ability to read every holder's profile at once, without cause. We think a regulator acting in good faith does not need that, and a regulator who wants it should have to say so.
Against the honeypot
A honeypot is any place where the value of what is stored exceeds the cost of stealing it. Identity databases are the purest honeypots that exist. A single breach yields millions of complete, verified, government-grade identities, each of which is worth more than the account it was collected to protect.
The security industry's answer has been to guard the honeypot better. Encryption at rest, access logs, bug bounties. This is like guarding a warehouse of gold by hiring more guards. It works until it does not, and the failure mode is total.
Our answer is to not have the warehouse. Distribute the gold to its owners, in their own pockets, and build a way to check they have it without collecting it. A breach of vry:st's contracts would yield a list of hashes. A breach of a holder's device would yield one person's credentials, bound to their key, useless to anyone else. There is no place where everything is.
Reuse as a right
Once you have been verified, that fact belongs to you. Not to the company that verified you, not to the first venue you used it at. You should be able to carry it to the next venue, and the next, without asking anyone's permission and without re-uploading anything.
This is not just convenience. Each re-verification is a chance for a new drawer, a new breach, a new copy. Reuse is how you cap the number of copies at one, and keep that one with you.
Receipts are the mechanism. A receipt in a shared scope can be shown to any venue asking the same question. A credential can produce a fresh receipt for any narrow scope in under a second. Either way, the verification you paid for with your documents keeps paying, and nobody gets a second copy.
The reveal field, and why it is ugly
The SDK has a parameter called reveal. It lets a proof disclose a specific field in plaintext alongside the boolean. We built it because some regulations genuinely name a field that must be recorded, a tax residency code, for instance, and a protocol that cannot comply with such a rule will simply not be used.
We want to be candid that we find it ugly. Every use of reveal is a small drawer. The wallet shows the user exactly what will be disclosed and asks for explicit consent. The docs tell verifiers not to use it unless a rule names the field. We will publish which verifiers use it and how often.
A protocol that pretends the ugly case does not exist will be routed around. We would rather include it, name it, and make it visible.
If we can read it, we built it wrong
This is the sentence we hold ourselves to. At any point in the system, if vry:st, the company or the contracts or the relayers, can read a holder's credential, a holder's identity, or the link between a holder and a receipt, we have made an error and we will treat it as such.
It is a strong claim and we mean it literally. It is why there is no proving server. It is why relayers receive proofs and not credentials. It is why the registries store hashes and roots and never fields. It is why the wallet module derives its secret from the user's key and never exports it.
We invite anyone to find the place where the sentence is false. If they do, the fix is a change to the protocol, not a change to a privacy policy.
On not curating trust
vry:st does not maintain an official list of trusted issuers. Anyone can register. Each verifier chooses its own accepted set. We are sometimes told this is irresponsible; surely the protocol should vouch for the issuers.
We think a protocol that vouches is a protocol that decides who gets to participate in finance, and that is not a power we want. It is also a power that would make us the party every regulator, every government, and every large customer comes to with a request. The only way to be unable to grant those requests is to never have held the power.
Verifiers are the right place for this decision. They are regulated entities with lawyers. They already decide which providers to trust today. vry:st just makes that decision public, per venue, and lets holders see it.
Metadata, relayers, and the gas payer
A proof can be perfect and the transaction that carries it can still leak. If you submit your own settlement, the address that paid gas is your address, and now the receipt is linked to an on-chain identity that may be linked to everything else you have done.
So we built relayers. A relayer receives a proof and submits the settlement itself, paid from the protocol fee. The receipt's gas payer is the relayer. Your address never touches the registry.
Relayers are optional and replaceable; anyone can run one. They see a proof, which reveals nothing, and an IP address, which we tell them not to log with the nullifier. This is the one place where the protocol asks for operational discipline rather than providing a cryptographic guarantee, and we say so.
What we refuse to build
Some things will be requested, and we want to answer in advance. We will not build a master key that lets any party decrypt credentials. We will not build a global lookup from nullifier to holder. We will not build an issuer allow-list that we control. We will not build a proving service that runs on our servers. We will not build a "compliance dashboard" that shows a venue the profiles of its users.
Each of these has an obvious customer. Each would make the product easier to sell. Each would also convert vry:st from a protocol that cannot betray you into a company that has promised not to. We are not interested in the second thing.
If the market requires those features, the market will be served by someone else, and we will have been right about what the market was.
The holder's UI is the protocol
Cryptographers sometimes treat the interface as a detail. We treat it as part of the security model. A proof that reveals nothing is worthless if the wallet tricked the user into a reveal they did not understand, or into a broad scope they did not intend.
So the wallet module is opinionated. Before any proof, it shows in plain language what the verifier will learn and what it will not. It marks broad scopes as such. It shows the TTL in days, not seconds. It refuses to proceed without a deliberate action. It uses the bar: the fields that stay hidden are shown as bars, so the user can see the shape of what is withheld.
The bar in the interface and the bar in the receipt are the same bar. That is the point.
A market that forgets
Imagine a tokenized-equity venue on Robinhood Chain a few years from now. It has served a million holders. It has enforced every rule. It has an audit trail a regulator can read end to end. And it holds, about those million people, nothing. No names. No documents. No addresses. A registry of receipts that have mostly expired.
If that venue is breached, the attacker gets a list of hashes. If it is acquired, the buyer gets a business, not a dataset. If it is subpoenaed, it can produce exactly what was gated and when, and nothing more, because nothing more exists.
A market that forgets is not a market that is careless. It is a market that was built so that remembering was never necessary. That is the venue we want to exist, and vry:st is what it runs on.
Prove it. Reveal nothing.
Four words. Two verbs. They are the whole product and they are also the whole argument.
Prove it is the concession to the world as it is. Markets have rules. Rules need to be enforced. We are not asking anyone to trust holders on their word, and we are not pretending that regulated assets can be traded by anyone at all. The proof is real, and it is strict, and it is stronger than any document check.
Reveal nothing is the refusal. Not "reveal as little as possible," not "reveal only to trusted parties." Nothing. The answer to the question, and the question, and nothing else, ever, to anyone. If a system needs more than that, the system is asking the wrong question, and we will keep saying so until the questions change.
A verifier is owed an answer, not a file. Everything under the bar stays under the bar.