Deep dive: the proof-of-work Hyli Chat
The Hyli testnet features a fully onchain and ZK-powered chat. It leverages client-side proving and bypasses pipelined proving as a built-in spam minimization system.

The Hyli testnet features a fully onchain and ZK-powered chat. It leverages client-side proving and bypasses pipelined proving as a built-in spam minimization system. Here are the technical choices we made for this application.
At a glance
Purpose | Sending zk-proven messages to other testnet participants. | |
---|---|---|
Proof systems | Noir | |
Key Hyli feature | Client-side proving Data availability |
|
Source code | https://github.com/hyli-org/testnet-chat |
How the Hyli chat works
Sometimes, things are just simple.

On the Hyli chat (integrated into Orange Trail), you send a commitment to send a specific message. You generate a client-side Noir proof, which includes that message. Your proof includes both your message in plain text and a link to the commitment, demonstrating that the commitment aligns with the final message.
Why do we require users to generate a proof and not just send messages? The Noir proof forces users to spend computing power, deterring spam and chat flooding. A bit like a lightweight proof-of-work!
The Hyli chat is, to put it simply, a tiny explorer. It displays the transaction, the sender, and the message content.
Of course, we also included a limited moderation mechanism: people with mod rights can create a transaction to hide another transaction from the chat.
Bypassing pipelined proving
The most interesting aspect of the Hyli testnet chat might be that, for once, pipelined proving is counterproductive. Usually, we love to tell you how great and scalable pipelined proving is! In the case of our chat app, we chose to bypass pipelined proving.
Normally, with pipelined proving, you’d send a blob transaction with the message included and then prove the message asynchronously, which is ideal for latency-sensitive UX. But here, we want latency. Requiring the user to prove their message before it's published acts as a built-in rate limiter, given that generating proofs in-browser isn’t instant, therefore minimizing spam.
What Hyli brings: native proof verification and fast data availability
The Hyli chat has the additional advantage of involving a stateless contract. These are really easy to register and use, as you can see from our « how this works » section. With pipelined proving, you generally wait until your blob has been sequenced before generating the proof because the sequencing tells you what base state your transaction can start from. This avoids state transition conflicts and enables parallelization. Here, the state really doesn’t matter: since you don’t care about the base state, you can start generating your proof right away without waiting for the blob transaction to be sequenced on the Hyli chain.
There are several ways to build such an app on a legacy blockchain. However, they require expensive onchain execution, depend on wallet signatures, and ultimately provide a less-than-ideal user experience. With Hyli, you’re essentially leveraging our data availability for an app like this: it’s cost-effective, fast, and efficient. And the final advantage is that it’s really easy to register a Noir contract on Hyli!
The Hyli testnet is currently live! You can start chatting at hyli.fun or start building your own apps right now.