Deep dive: the Hyli wallet abstracts your identity

On the Hyli testnet, you have one wallet to rule them all and climb the leaderboard. This wallet operates with every single testnet app without needing bridges or complex UX: it’s just a unified account that you can use with all the apps that settle on Hyli.

Here’s a deep dive into the technical choices we made for this application.

At one glance

Create a wallet

Creating a Hyli wallet is done, just like everything else on Hyli, by sending a transaction. The transaction includes two blobs:

1. A CheckSecret blob takes Max’s password as private input and asserts that the hash is correct;
2. A registerAccount blob verifies and stores Max’s Hyli identity, max@wallet, in its state.

Other systems could be used for alternative identification methods, but for our testnet, we opted to keep users in their comfort zone and use a simple login and password method.

The CheckSecret contract is written in Noir; see the source code on GitHub.

Create a session key

The user can create a session key on any app. A session key includes a public key and a private key.

In our example flow, Max wants to use a USDC contract, so his session key comes from that contract.

Register the session key

Max registers his session key in a new transaction, which, again, includes two blobs:

1. A CheckSecret blob makes sure that the password is correct, meaning that Max is correctly authenticated;
2. A registerSessionKey blob registers the public key as a session key associated with Max’s account and adds the USDC contract to the allowlist.

Now, the session key is linked to Max’s wallet. This means that Max can use his wallet to interact with the USDC contract.

Use the session key for a future action

Max wants to transfer money using the USDC contract. His new transaction will include three blobs:

1. A blob to verify his signature using his private key. The blob signs a timestamp and is used to update the session key’s nonce.
2. A blob to verify the session key, asserting that the key used for the signature in the first blob is associated with Max’s account.
3. A blob for the transfer itself.

Why Hyli relies on session keys

With this architecture, the transfer does not require any private input in the zkVM. The signature is verified natively without requiring the generation of a zero-knowledge proof for this blob.

The two other blobs don’t require authentication, as the authentication blob works for the entire transaction. Thanks to Hyli’s native proof composition, if the signature blob fails to verify, the other blobs fail, and the transaction doesn’t happen.

This has the added benefit of avoiding timeouts. Since there are no private inputs, anyone can verify every blob in the transaction without worrying too much about privacy, and there is no bottleneck in verification times, as would be the case if there were invalid data in a private input. The USDC app can offload the work to a specialized prover without worrying about security.

Build with the Hyli wallet

You can use any contract as a source of identity on the Hyli wallet: experiment and devise fun, innovative, or straightforward ways to connect!

When building your app, remember to leverage the Hyli wallet to offer your users a better experience. Focus on what matters and let us take care of the rest!

The Hyli testnet is currently live! You can see the wallet in action at hyli.fun if you have an invite code or start building your own apps.