Launching CacheCash: a private, high-TPS payment minigame
High-TPS privacy was still a challenge… until Hyli. Discover our faucet mini-game with fully private transactions: CacheCash.
Privacy shouldn’t rhyme with latency. CacheCash lets you slice, earn, and move tokens instantly without revealing a single transaction.
Today, we unveil our demo mini-game, CacheCash: a fun, high-throughput faucet mini-game where every transaction is fully private.
| App type | Faucet mini-game (Upcoming) P2P exchange |
| Key Hyli feature | High-TPS privacy |
| Proof systems | SP1 (commitments) Noir (transactions) |
| Source code | https://github.com/hyli-org/cachecash |
Introducing CacheCash
The faucet behind CacheCash is permissionless, limitless, and anonymous. You slice something, and you get Pumpkins on your demo Hyli wallet. That’s it!
To read more about the faucet, you can read about Faucet Ninja, which was the non-private version of this game when we ran our Martian testnet last summer:
Alex Sirac
What’s really interesting is what happens behind the scenes to keep your transaction private.
CacheCash uses a stateless Noir contract for UTXO validity and ownership, paired with SP1 for commitments.
What makes CacheCash special
Local-first
The faucet issues a private UTXO, which your browser stores locally; only SP1 commitments land onchain, and they don’t include transaction details.
Native proof composition for fast privacy
When you play, the faucet server generates a Noir proof that the transfer is valid, and an SP1 proof checks that committed notes have evolved consistently.
This separation keeps Noir fast and stateless while SP1 enforces ordering and avoids data leakage from Merkle paths.
The result is the lightest private token pattern to date: balances reconcile onchain from commitments, while UTXO data and metadata never leave your device!
User-to-user transfer
Soon, you will be able to complete user‑to‑user transfers in CacheCash!
With this P2P private payment system, you trade UTXOs directly with someone. The person then claims their UTXOs by generating another proof, preserving unlikability.
For performance reasons, you can’t just send tokens to an address; the recipient must know your transfer is coming and claim it. Private payments are also a strong tool for the future of a more human and interconnected Internet, where every transaction is a chance for a conversation!
We’re excited to see you all play CacheCash on Telegram and on social media!
The future of high-TPS private payments
With Hyli, private payments are instant, auditable, and composable: fast enough for real apps, private enough for real life.
High‑TPS private payments, as enabled by Hyli’s architecture, make privacy feel smooth again.
You get the discretion people praise in Zcash and the everyday smoothness of any payment solution, but at interactive speed: tap, confirm, move on.
Receipts exist without exposing your whole graph; your balance is auditable, but your payments remain protected from nosy explorers.
Apps can compose private flows for anything: it starts with P2P payments and private KYC, but high-speed privacy opens the door to many more mainstream private apps. When privacy doesn’t come at a cost, we can bake privacy into every step of our lives.
The result is simple: private by default, fast enough for real life, and finally practical for mainstream uses.
(This is a testnet game. Tokens do not and will not have any monetary value. This game is not financially incentivized.)
How it works behind the scenes
The mini-game includes several key players:
The data availability server includes two Merkle trees:
- Notes: Each UTXO is a leaf of the note tree.
- Nullifiers, not linked to notes in the database. The nullifiers and notes are only linked locally by the owner of the note in question.
The full user flow is as follows.
Step 1: The user slices a pumpkin.
This signals to the faucet that they want 1 Pumpkin and starts the transaction.
Step 2: The faucet requests to read the current state of the note tree.
This may signal to the storage server that the user faucet is intending to make a transaction; however, as the full state is being requested, there is no information on what notes the transaction will affect.
In production use cases, we’d recommend setting up frequent auto-checks, so that requesting information wouldn't necessarily be linked to a transaction.
Step 3: The faucet burns a note and creates two new notes.
The faucet burns a note and creates a new one to be given to the user; in most cases, it also creates a « change » note if the value of the previous note is not exactly one pumpkin.
To do this, the faucet generates a blob transaction for each note, each including two Noir proofs:
- Proof that the original note is indeed in the Notes tree
- Proof that the original note’s nullifier is at a given address in the Nullifier tree
The faucet sends these proofs to Hyli, which verifies and settles them onchain. This does not change the trees themselves; it just says that a Noir proof was submitted and was valid.
The only information available onchain is that a note has been linked to a nullifier, and that two notes have been created.
Step 4: The faucet sends the newly-created note to the player.
The faucet sends the newly created 1 Pumpkin to the player. In our case, the faucet server sends the note into the player’s browser, meaning that the player now has the note information stored locally. This information never goes onchain and is never stored anywhere other than locally, either on the faucet server (faucet-side) or in the player's browser.
When we launch user-to-user transfers in a couple of weeks, we’ll do a deep dive into exactly what this step entails. Make sure to sign up for our newsletter if you want to know all about private transfers on Hyli!
Step 5: The storage server reads the chain and proves the new Merkle trees.
Our storage server reads the Hyli chain at regular intervals for tree bookkeeping. It updates the trees when it successfully checks that the new created notes are not nullified, ie, that the previous transaction (made with Noir proofs) is still valid in the current tree state.
As a reminder: the only information available to this server is that a note has been linked to a nullifier, and that two nullifiers have been created. The storage server never knows who initiated the request or what notes (and therefore amounts) have been created.
The storage server generates a proof of the new tree states using SP1 and sends it to Hyli.
Step 6: Hyli verifies and settles the new chain state.
Hyli receives the SP1 proof of the new tree states. It verifies it natively and settles it onchain, finalizing the transaction.
Interested in learning more about the architecture? We strongly recommend reading Payy’s whitepaper, which inspired this whole app: shoutouts to them for being at the forefront of private payments!