Verifiable Blackjack: A Product Manager's Journey into zkProofs Part 2

After my last project, I had a nagging feeling. I’d created a front-end for a pretty standard academic AI project, but I hadn't truly gotten my hands dirty. Now, I wanted to build something real, something with tangible utility.

Given I was now fixated on vibe coding and pumping out new things, I set my sights on a new domain. That's how I landed on zkBlackjack.

Why Blackjack? The Perfect Hand for Zero-Knowledge Proofs

Blackjack is more than just a game of chance. Its integrity hinges on the entity hosting the game—whether a company, person or a program—properly:

• Providing a fair deck or decks of cards
• And then shuffling those cards

But, how can a player be sure the game is fair?

This is a perfect use case for zero-knowledge (zk) proofs. A player needs to verify that the virtual deck started in a perfectly ordered state and was then properly randomized, all without revealing the final order of the cards. Given I was still just starting out, I chose to use Circom, a language for creating zk circuits.

Building with an AI Partner

The development process was a whirlwind of collaboration, mostly with my go-to AI assistant, Gemini. I had a lot of back-and-forth, even hitting my rate limits a few times! My process was simple: feed the AI the error codes directly and work through the solutions it provided. I’ll note here that I am not vibe coding in the way a lot of folks do, prompting AI assistants directly in their IDE of choice. I prefer the back and forth nature that I employed, as I felt it gave me a bit more control over what was being done, and allowed me to learn a bit more about what the AI was providing throughout the process.

Eventually, we got a working solution. The system generated a proof of a correctly shuffled deck, which I then sent for a quick check on a verification network. For this, I used zkVerify and its zkVerifyjs library. Just like that, I had a "finished" proof-of-concept!

Check out the demo below:

The Product Manager's Reality Check: A UX Problem

As you can see in the video, the user experience is... less than ideal. The core issue lies with the proof verification step.

This verification is essential. It’s how the user knows the game is fair before being able to proceed with the gambling part of the game. However, because zkVerify is a blockchain, the feedback isn't instant. The proof has to be verified by several nodes before it's finalized, and this process currently takes about 30 seconds.

For a fast-paced game like blackjack, a 30-second wait to start a new hand is an eternity. It completely breaks the flow of the game. While I was proud of building a successful second demo, my product management instincts were screaming. The technology worked, but the user experience was a non-starter.

This project was a fantastic learning experience. It proved that we can use zk-proofs to create verifiably fair games. But it also highlighted a critical challenge: for decentralized technologies to achieve mainstream adoption, they need to be seamless. The next step? Figure out how to deliver that trust without the wait. The product manager in me knows we can do better.