World War IIInu: A ZK Gaming Experiment

I will be the first to admit that I am not really a math geek, and I certainly don't fully understand the mechanisms underlying zero-knowledge proofs. But with the rise of AI coding assistants and my insatiable hunger for experimentation, that didn't stop me from creating a novel blockchain and ZK-enabled game called World War IIInu (pronounced "Three-new").

EncryptedERC and the Spark

It all started when AvaCloud released a novel encrypted token standard called EncryptedERC. This standard provided a framework for deploying natively encrypted tokens as well as token wrappers that could turn any ERC20 into a new encrypted version. The benefit of these encrypted tokens is that they hide a user's token balance and create a layer of anonymity around user funds.

When I saw this release, I immediately began thinking about potential use cases for a blockchain-based game. The idea of being able to mint invisible tokens seemed perfect for a strategy game, and Encrypted War Games (later dubbed WWIIInu) was born.

How the Game Works

The concept is fairly simple. There are 5 interconnected bunkers where users can stake tokens to enter the game. Once inside a bunker, there are 8-hour rounds in which users can either move to a new bunker, attack a connected bunker, or defend their bunker. The way attack and defense actions are taken is by minting encrypted ATTACK or DEFEND tokens to bunkers. At the end of each round, bunkers lose tokens based on the difference between attacks received and defense accumulated.

The tricky part was keeping things concealed. While EncryptedERC does hide token balances, you can still see the address tokens were minted to. This is where some clever logic was needed. To correctly obfuscate a user's action, it was required to mint both attack and defense tokens each turn. So if you wanted to attack bunker 3 from bunker 1, you would mint mostly attack tokens to bunker 3 and a single defense token to your own bunker. This way nobody could tell the balance of your attack versus defend action.

This mechanism worked well, and we ran test games on a testnet before finding other areas of gameplay that needed modification.

Why It Stayed on Testnet

While the game was moderately fun and provided something to engage with on testnet, I ultimately decided not to proceed with a mainnet launch. The core issue was that the game was very PvP, and people lost a lot of tokens. On mainnet, users would have had to put real money at risk and potentially lose it all to other players.

It was a fun concept, but I don't like when my community loses money. This is a tension that exists in a lot of blockchain gaming. The mechanics that make games interesting often involve winners and losers, and when real value is on the line the losing side tends to stop playing.

AI-Assisted Development

World War IIInu lives on as a testament to the growing power of AI-assisted coding. I completed this project around Summer 2025, when AI coding tools were still relatively new, and yet I was able to create an entire project implementing custom ZK circuits and blockchain-enabled technology with AI assistance. There were backend services that needed to decrypt ZK balances and execute on-chain transactions, as well as a full suite of indexers and contracts required by the UI.

You can see the mess of a repo here, but please note that I really didn't clean it up very much. Looking at the repo you will be able to see many requirements documents where I was trying to communicate with AI on my intentions and learning the ins and outs of AI-assisted development.

When I look back on this work I am amazed at how far we have come in this area. Where I once had to check every commit line-by-line with a fine-toothed comb, I now find myself hardly having to intervene, as long as I spend a good amount of time on creating comprehensive PRDs.

If you're interested in ZK applications or blockchain gaming, get in touch.