Manav.id
Brand4 min read

Why we won't sell user identity data

Won't sell identity data

A promise is a contract you write yourself. We make this promise — we will not sell user identity data — knowing that promises from companies are easy to break and harder to enforce. That is why we built the protocol so that even a future, worse Manav could not break it.

The four primitives that make selling impossible

Custody. The user's private key is on the user's device. We do not hold it. Our hosted services see signed presentations, never the underlying credentials. There is no central store of identity data to sell because we do not maintain one. Selective disclosure by default. Every credential is presented as a proof, not a payload. A relying party learns the predicate (age above 18, jurisdiction is EU, Trust Score above 700), not the raw value. Even if we wanted to sell aggregated data, the data we touch is structurally minimal. Audit anchoring. Every verification we perform writes a hash to a public ledger. If we deviate from the protocol's data-handling rules, the deviation is detectable by third-party audit. Open-source verifier. Anyone can re-verify a presentation without us. There is no monopoly on verification we could sell access to.

The four scenarios people worry about

The acquisition. A bigger company buys Manav. They cannot retroactively sell user data because we do not hold it; they cannot retroactively force users to give it because we do not have a custody relationship to convert. The desperate quarter. Revenue tanks; the board pressures the CEO. The CEO cannot decide to sell what we do not have. The protocol's structural minimality survives leadership decisions. The court order. A government compels disclosure. We comply with what we hold; what we hold is operational metadata about verifications, not identities. The credentials remain with the user; the court must request them from the user, not from us. The bad insider. An engineer with admin access tries to exfiltrate. They find audit hashes and operational logs; they do not find a user database to leak.

What we will sell

The hosted verification service. Audit dashboards. Compliance integrations. Professional services. None of these involve selling user identity data. They involve charging relying parties to use software we maintain.

What this is and isn't

It is a protocol-enforced posture. It is not magic. If a user voluntarily exports their data and sells it themselves, that is the user's choice and we cannot stop it. If a relying party logs the predicate it received and shares the log, that is the relying party's posture, not ours. The protocol removes us from the data-broker chain; it does not remove every party from the chain.

Why we wrote this down

Because every identity company that has done this has eventually faced the temptation to monetize the data. The ones whose business models do not require the temptation have stayed honest; the ones whose business models did require it usually failed. We designed our business to not require it. We are putting that design choice in writing so that the next generation of Manav leadership inherits a clear standard.

Common objections

Two objections worth answering. Stated values do not survive growth pressure — true historically, which is why we put structural mechanisms (open-source, governance, protocol-enforced custody) behind the words rather than just the words. This sounds like marketing — the test will be the audit hashes, the protocol design, and the operating agreements, not the prose.

Frequently asked questions

What does this commitment cost us if we honor it? Real money in the years where the temptation would have been highest. We are pricing it in upfront because the commitment is structural, not aspirational.

Where do we publish this commitment? Here, on the protocol governance page, and in the operating agreements with our investors. Anyone can audit whether the commitment is being kept by reading the audit hashes we publish quarterly.

What if leadership changes? The commitment is structural enough that a new leadership cannot quietly reverse it. The protocol mechanics make the breach detectable; the legal commitments add a second layer; the cultural commitments add a third.

Where to start

For the wider posture, read why open source and zk selective disclosure. The values, the protocol, and the operating model only fit together when read in that order.

The mistake other identity companies made

Three identity companies in the past decade built the trust, then sold the data. They did not announce the sale; they buried it in the privacy policy and called it "analytics partners." The users found out from a journalist with a FOIA request, or from a leaked CSV on a forum. In every case, the company recovered financially and never recovered reputationally. We watched those companies write the case law of what users will not forgive. The contract we are signing with our users is structural, not promissory. Selling the data is not a thing we have decided not to do; it is a thing the protocol is engineered to prevent us from doing, even if a future founder, board, or acquirer decided to. The bright line is not in the privacy policy; it is in the architecture. That is the difference between trust we ask for and trust we earn.

The promise we make today is the protocol you can audit tomorrow. Trust is structural; integrity is plumbing.