Umia Extension and zkTLS
Privacy-preserving audience curation for Tailored Auctions
Most launches face an ugly trade-off: either do an open token sale full of bots and buyers without conviction, or a private sale that limits the participation of your community. The Umia Extension removes the trade-off. It lets your auction be tailored to exactly the kind of participants you want, while those participants prove they qualify without revealing their identity, their accounts, or their data.
A launch that starts with people who understand and believe in the project builds a healthier holder base from day one, and early access is itself the incentive that brings those people in.
What zkTLS Is
zkTLS is a way to prove a fact from any website that sits behind a login: a balance, a score, an account age, a credential, using a zero-knowledge proof. The proof confirms the criterion is met without revealing the underlying data, and without linking that data to the participant's wallet.
The Umia Extension is built on the Reclaim Protocol. If a website has information behind a login, a proof can be generated about it: the participant logs into the site as themselves, and the protocol produces a cryptographic attestation about the specific fact being checked, nothing more.
How the Extension Works
The Umia Extension is a standard Chrome extension: the client tool participants use to generate proofs during an auction. It sits between the participant's data source and the auction's eligibility check.
From the participant's side the flow is short: install the extension, open the auction's gated round, log into the site the criterion refers to, and wait a few seconds while the proof is generated in the browser. The auction contract sees a valid proof of eligibility; it never sees the account, the login, or the data behind it.
For the implementation walkthrough (architecture, privacy model, sybil resistance), see Reclaim zkTLS Integration.
What Can Be Verified
Any claim that can be proven in the browser over a TLS connection. In practice that means almost anything behind a login. Some examples of the shape of criteria founders can set:
- Product usage: has this person actually used a product like yours? For example, how many API credits they've spent on an AI platform.
- Platform activity: are they active on prediction markets, or on the platforms your project builds for?
- Trading history: can they prove their exchange account cleared a certain lifetime trading volume, without revealing the account?
- Account age and KYC reuse: reuse the fact that another platform already verified this person, as an anti-sybil measure, without collecting anyone's documents yourself.
If there's something specific you want to verify (your product's usage or anything else), you can contact the Umia team to get it added to the Extension.
Why This Matters for Your Launch
- You reach the right community, not the fastest bots. Eligibility is about who the person is as a user, not who got in the queue first.
- No public allowlist. You never hold a list of names or accounts, and participants never expose themselves to have their eligibility checked. With this you get to verify things that users might not want to associate with their wallet, such as accounts or scores.
- Early access becomes a reward for the people you care about. A gated early round gives your actual users a reason to become holders before the general public.
- Sybil resistance without friction. Criteria tied to real, hard-to-fake account history filter out multi-wallet farming better than captchas or forms.
How It Plugs into Your Auction
Eligibility criteria are defined when your Tailored Auction is configured, and they gate specific parts of it: typically an early-bid round or specific supply buckets, each with its own caps. The rules plug directly into the auction's configuration alongside phases, caps, and refund logic. See Tailored Auctions for how the rounds themselves work.
Criteria are set per launch and published before the gated round opens, so participants know what qualifies and can generate their proof in advance.
Security and Trust Assumptions
Proof generation happens client-side; sensitive data does not leave the participant's browser and never touches the chain. What the proof guarantees, and the trust assumptions behind the underlying protocol, are covered in Security and Audits.