ZKolosseum

• Link to Slides (short pitch)
• Link to Slides (long pitch)

Gaming in web 3.0 is a "too small blanket"-problem. Indeed, relying on the chain costs too much, not relying enough introduces unfairness and, most importantly, these hard-to-balance issues negate capability to scale and build a transparent tournaments where multiple players compete to win a prize. Transparency is key: players want to be sure the prize exists, teams and spectators want matches to not be rigged and organizers would like spectators to participate and get a gain for the logistic!

We are a team of mathematicians so we went all-in to solve the following question:

Can a transparent game be built on XRPL? How would such a solution look like?

ZKolusseum is our hackathon solution that combines technological API masterpiece from XRPL ledger/smart-contracts, Boundless ZK framework, good-old theoretical research to allow our transparent scaling of gaming 3.0. For the occasion, we invented a never-seen-before game, designed only for Hack the Block 2026 and that metaphorically encapsulates the complex interaction for getting the solution!

To begin with, one needs a small premise on ZK proof and their capabilities. Out of all the properties of zero-knowledge, we cherry-picked three that have an impact on our solution:

1. ZK proofs, especially via SNARK/STARK, are succinct meaning that long transcripts can be compressed into short proofs. What are the implications? Well, less stuff must be sent to XRPL implies smaller fees and costs (even smaller that the already small XRPL's fees)!
2. ZK proofs (may) allow to hide information, meaning that if the game has secrets, the proof will not reveal anything. Implications? The game strategy is hidden thus removing any chance of "studying" your adversaries and increasing the challenge value for the spectators!
3. The most important property, ZK proofs are efficiently verifiable, way more computationally cheaper to evaluate! Implications? Complex games with complicate mechanisms to be proved can outsource all the computational costs into the ZK proving phase which is off-chain. This means that on-chain there is only cheap and quick-to-compute verifications!

The key observation is that games can generate a transcript, basically a list of inputs that when precisely played will always result in the same game finishing state.

*What about randomness?* - Asked someone from the public.

Well, much randomness is pseudo-random, meaning that it's deterministically computed to look random but it effectively is not.

So... how to combine all of this? Let us go by steps and see how ZKolosseum creates a tournament:

1. XRPL hosts a smart-contract that mainly describes the tournaments structure: it creates a prize poll, defines the matches and players and provides a hook for spectators to interact and to show the organizers costs (and gains) transparently. All these actions do not require complex code, they are all conditional checks, where providing the correct signatures or correct ZK proofs would allow to advance the correct team to the next phase, until the prize is won!

2. When a match starts, XRPL can provide a pseudo-random seed employed by the game to initialize its internal randomness. This guarantees fairness that the seed is properly generated!

3. During the game execution, the game-transcript is recorded. Additionally, the game can provide spectators with interactive gigs such as allowing chat to decide how to mess up with the game rules, creating more fun and a more interactive experience! These interactions can be properly handled via XRPL in form of micro-transactions that are added to the prize-poll.

4. When a player wins, the transcript is used as input for an ad-hoc WASM circuit designed for Boundless, describing how the game works. The goal of this proof is to verify that the game transcript is valid and that a winner has been correctly selected.

5. The ZK proof is then pushed to XRPL allowing to move the tournament to the next phase. At the end, the prize poll is fairly distributed to the winner(s) and a logistic-fee is transparently kept by the organizers.

As Rome was not built in a day during an ancient hackathon, our ZKolosseum is, sadly, not yet complete. However, we have seen that every step of our solution is feasible and can therefore be brought to life!