zkVerify blog

From GitHub Stars to Secure Identity: A Guide to zkTLS

a man sitting in front of a laptop with the words from github stars to secure identity a guide to zktls
a man in a suit and white shirt is smiling for the camera .
John Camardo

At zkVerify, we're constantly exploring new ways to bridge the gap between the vast data of the existing internet and the world of Web3. This journey recently led me to an exciting application for Zero-Knowledge Transport Layer Security (zkTLS). I set out to solve a simple problem for our incentivized testnet: how can we reward users for a social task, like starring our GitHub repo, without forcing them to reveal their personal information?

The Privacy Problem with Proving Online Actions

My (loose) goal was to incorporate a simple social quest into our programs to bring more attention to our GitHub repo. An incentivized testnet is currently running at points.zkverify.io. A straightforward approach would be to ask users to submit their GitHub usernames so we could manually verify they had starred the repository. However, this method has a significant privacy flaw: it would expose users' GitHub identities and link them to their EVM addresses.

This creates a dilemma. We need to confirm that the user who starred the repo is the same user who owns the EVM address receiving the rewards. Without a robust verification method, any user could claim points for a repo starred by a different, unrelated GitHub account. This is where Zero-Knowledge proofs, and specifically zkTLS, provide a powerful solution.

The Solution: Building a Private Proof with zkTLS

zkTLS is the perfect technology for this challenge. The fundamental idea is to allow a user to prove that they logged into their GitHub account and, while logged in, confirmed that a specific repo was starred. All of this can be done without revealing their username, IP address, or any other private session data.

To demonstrate this, I built a conceptual demo. The ideal user flow is simple:

  1. Connect your wallet to a user interface.
  2. Click a button to start the proving process, which would prompt a GitHub login.
  3. The system then constructs a proof, keeping all user information private except for the fact that the repo has been starred and the user's designated EVM address.

For my demo, I used a simplified Circom circuit and mocked the live GitHub login. The proof was constructed by scanning local HTML code for the text "Unstar this repo," which only appears if a user has already starred the repo in question.

How the Proof and Verification Work

This demo, while not interactive, effectively showcases the core mechanics of zkTLS:

What the Proof Is Proving (The "Secret")

The Zero-Knowledge Proof generated in the user's browser cryptographically proves several facts to a verifier without revealing the underlying data.

  • Knowledge of HTML Content: The user proves they possess knowledge of a specific 64-byte section of an HTML document. In a real-world scenario, this would implicitly prove the HTML was genuinely received from github.com over a secure TLS connection. For our demo, this was simulated using a mock HTML file.
  • Presence of a Specific String: The proof confirms that this HTML chunk contains the exact string "unstar button". This string is only present on GitHub's user interface if the user has already starred that repository.
  • Binding to Public Identity: The proof is generated using the user's Ethereum wallet address as a public input. This makes it impossible for another person to use the proof to claim credit.

Essentially, the proof states: "I can confirm I saw the 'unstar button' on a specific GitHub repo, and I am binding this fact to my public wallet address, all without revealing my GitHub identity or other session data."

What zkVerify Is Verifying (The "Public Check")

The verification process, which can be done off-chain, with a service like zkVerify or on-chain with a smart contract, checks the proof's integrity against public information.

  • Proof Validity: It mathematically confirms the proof was generated correctly according to the circuit's rules, ensuring it could not have been faked.
  • Public Input Consistency: It verifies that the public inputs, like the user's wallet address and the specific GitHub repo, match what the verifier expects.
  • Circuit Satisfaction: It confirms the circuit's underlying conditions were met—namely, that the HTML chunk containing the "unstar button" was present.

In short, the verification confirms: "Yes, this proof is cryptographically sound, it is for the correct repository, and it is linked to this user's public address, confirming they met the criteria without revealing private Browse data."

Beyond the Demo: Real-World Applications of zkTLS

This simple demonstration lays the foundation for powerful, privacy-preserving applications that can bridge Web2 data with Web3 systems.

  • Sybil Resistance & Airdrops: dApps could verify unique human users by having them prove they have a certain number of Twitter followers or have spent time on LinkedIn. This allows for fair airdrops and whitelist access without requiring users to link their social accounts directly.
  • Private Identity & KYC/AML: DeFi protocols could achieve regulatory compliance by allowing users to prove they are over 18 or reside in a specific country without submitting sensitive documents. A user could prove their credit score is above a certain threshold without revealing the exact score.
  • Reputation & Loyalty Programs: Users could port their reputation from Web2 platforms to Web3. For example, a new decentralized marketplace could offer benefits to users who can prove they have a high rating on platforms like Uber, Airbnb, or eBay, fostering trust in new ecosystems.
  • Gaming & Achievements: Players could receive soul-bound NFTs or unlock exclusive content in Web3 games by proving they earned specific achievements or own rare items in Web2 games.
  • Data Monetization & AI: Users could contribute verifiable data points to AI models—for instance, proving "my average weekly grocery spending is over $100"—without revealing their actual transaction history. This allows users to monetize insights from their private data without compromising their privacy.

The core principle in all these cases is the ability to prove a specific fact about data from a secure web session without revealing the sensitive data itself. We believe this capability is a critical bridge between the privacy of Web3 and the vast data of Web2.

If you have questions or have the patience to build a similar demo, we encourage you to share it with us. We are excited to see what you build.


If you're into ZK, AI, and building real things—not just reading papers—follow me on X: @john_camardo.