Aletheia: reputation based anonymous login system


Aletheia is a login system built for a web3 first world. It has three main features. First, it allows websites to only allow users to login if they fulfil certain on-chain criteria (aka reputation). Second, users don’t need to give up their privacy, e.g. their transaction history, when logging in to a website since the website never gets access to the wallet address of a user. Third, users can use the same password for all websites without giving websites access to the password.

Application Type


Proposal Overview

Within the scope of this proposal, the MVP is to implement the following components:

  1. Frontend for website owners to register their own NFT collection as reputation criteria
  2. Relayer backend that allows users to create a global password without revealing their wallet address
  3. Maintenance service backend that keeps a merkle tree on chain up to date about which user fulfils a reputation criteria
  4. Demo frontend that shows websites owners how to integrate the ZKP generating code in the frontend
  5. Demo backend that shows website owners how to verify ZKPs in the backend

Use Cases

Aletheia is an anonymous & on-chain reputation based login system for websites. Image you are a website and only want to make it available to users that own at least 1 CryptoPunk. Aletheia allows a website owner to set such a filter when designing the login system. Users who use Aletheia to login to a website don’t reveal their wallet address. Especially users with a lot of activity and stored value on chain care about their privacy. Aletheia allows them to keep it.The MVP will focus on the most thought after form of reputation: NFT ownership. It can be extended to arbitrary reputation in a later stage.

Competitive Landscape

There is no similar product in the market as far as we know.

Proposal Ask

Aletheia will become community-driven and self-funded by its own DAO and subscription fees by website owners for maintaining their reputation data of users (merkle trees on chain). In order to get this up and running, we will be requesting the $15k/year stable basic income to take care of initial development, welfare, and operations costs.

This ask will be in line with the laid down milestones as detailed below

  1. launching a feature-complete product on our testnet
  2. forming a DAO with 5-out-of-9 multisig
  3. launching on mainnet with audit
  4. attracting ?k daily active users
  5. attracting ?k daily active users

Road Map

So far a simplified version with two hard coded NFT collections is published on Mainnet. In the next step the current version will be generalised to custom NFT collections.

Objective Date Status
Testnet launch May 6th Done
Beta Testing and Fixes May 19st Pending
Smart Contract Audit June 10th Pending
Mainnet Launch June 10st Pending

External links

Dummy reputation + global password:
Demo login:
Source code: Aletheia-ZK · GitHub

=> Here you can test Aletheia with two NFT test collections.

Mainnet ETA

It mainly depends on how quickly I can secure a smart contract audit.

1 Like

Hi Jan, please include the link to your source code as well. Thanks.

Just made an edit to the proposal.

1 Like

After having talked to another student in my ZKU cohort, I think I will change the project slightly.

My main goal is to show other websites and users how they can use on-chain reputation to filter users and allow their users to login without revealing their wallet address. This tech is available now on main net and not only proposed in some random white paper. The first step is that users and websites understand the new authentication system and its benefits.

Since the tech sign in with wallet instead of email + ZKP + reputation is all pretty new, users and websites are confused how the different components work together. I think it’s more beneficial for the adoption to first build a version of the project which focuses on showcasing the new tech and building out the story why this is important vs generalising it directly.

What does it mean concretely? What would I like to change?
Instead of allowing websites to use their own NFT contract as a reputation, I’d like to stick to 1 or 2 pre-deployed NFT contracts as reputation which makes it easier to create a story and explain the benefits of such a system. It’s unlikely that website owners will directly use it.

What do you think?

Is the change you mentioned only for demo purposes? Or do you expect the website owners to deploy their own copy of Aletheia for their own NFTs? I think the issue with the latter is that it will not be qualified as a product, more like a protocol, and making reaching milestones 4 and 5 very difficult.

On the other hand, I tried out but cannot get through the part that it waits for the merkle tree update. Please advise.

The number will have to follow About the zkDAO category , which is in DAU - I think for your particular app, it can be website owners and users combined.

Thank you everybody for the input here in the forum or via DM.

Here are the updated milestones and road map.


  1. launching a feature-complete product on our testnet
  2. forming a DAO with 5-out-of-9 multisig
  3. launching on mainnet with audit
  4. attracting 1k daily active users
  5. attracting 10k daily active users

Road Map

So far a simplified version with two hard coded NFT collections is published on Harmony main net and test net. The main net version can be accessed here: and You have two wait ~10 minutes before you can login at since the reputation indexer and the covalent api need time to reflect the correct state.
In the next step the current version will be generalised to custom NFT collections.

Objective Date Status
Testnet launch May 6th Done
Beta Testing and Fixes June 4th Pending
Smart Contract Audit June 10th Pending
Mainnet Launch June 15st Pending

Nice!, The product has some interesting use cases.
Please include a demo video of the product, the interface isn’t very obvious to use.
Also, I noticed you’re using a backend and redis. Can you elaborate on why you’re using one and what’s being stored on the database?

Demo link: Loom | Free Screen & Video Recording Software

Aletheia uses two backend services: relayer service and maintenance service. They communicate with each other using a reddis DB.

Relayer service
The relayer service allows the user to set a global password and store an identity commitment without revealing his public wallet address. In addition, the relayer service functions as an API. All data can be read from the blockchain directly, but the relayer service exposes an API to construct Merkle Proofs more easily.

Maintenance service
The maintenance service updates the reputation merkle trees on chain every 10 minutes. When a new user acquires a reputation, i.e. mints an NFT, the user’s public address gets added to the reputation merkle tree by the maintenance service after ~10 minutes. The updated merkle tree is also stored in reddis to provide the data to generate a merkle tree proof more quickly.

My initial idea was to build out a demo without allowing website admins to use their own NFT contracts as reputation and go around with my PoC and find potentially interested websites/communities and co-develop the app with them. With this approach, I don’t quality for the launch grant that’s why I am now in the process of extending the PoC so that it can be used with arbitrary NFT contracts (turn it into a full product) while still having a demo built in with predeployed NFT contracts.

Thank you for the explanation. I finally got through the entire process of your app (waiting for the server update did take a while) and can confirm it’s functional.

I do hope that you can explore a better way to maintain the database rather than updating every 10 minutes in the future.

As a zkDAO governor, I approve this proposal and can confirm the first milestone has been reached.

Hi Jan, I think that this could be a really nice project, which could attract many users. I would suggest you to create a repo with the good documentation on how the whole process works. Create the diagram representation of the system architecture.
Also what is the reason for 10 min update period?

thanks @AleksandarHadzibabic that’s the plan!

I only update the reputation merkle trees on chain every 10 minutes for two reasons:

  • easier to badge updates across different reputations
  • covalent (indexing service) only gives reliable results after 10 minutes

What does reliable results mean?
If you mint an NFT and then use the covalent API to check the number of NFTs minted from a contract it takes 10 minutes until the response from covalent is stable.

Let’s assume so far three NFTs have been minted and you just minted a new NFT. This is how the API response might look like within the first 10 minutes:
After 1 min: 3
After 2 min: 3
After 3 min: 4
After 4 min: 3
After 5 min: 4
After 6 min: 3
After 7 min: 3
After 8 min: 3
After 9 min: 4
After 10 min: 4

Through trial and error I found out that the result is stable after 10 minutes. To speed up the process I would have to find a better indexing solution.

The 10 minute window might be a bit annoying for a demo but I think later for real world use cases it shouldn’t matter much since in most cases users acquire their reputation way before they will attempt to login to a website.

thanks @socathie for the approval!

1 Like

As a governor of zkDAO, I also approve this project and confirm that the 1st milestone is reached.

Understood, thanks.
Approved and milestone 1 confirmed

A good and necessary software solution, we in Harmony Ukrainian DAO need such a tool in our community

1 Like

Great project. I vote yes as a zkDao governor and confirm milestone 1 has been reached.

Thanks for the support!

Little update:

  • One final zkDAO governor confirmation is still missing before I will form the multisig DAO.
  • I am currently writing tests for an updated version of the solidity contract as well as redesigning the frontend.
  • With the updated version websites can use their own NFT contracts as reputation and don’t have to rely on the two I provided as a proof of concept
1 Like

This is approved and milestone 1 is confirmed.

1 Like

I have just created the multi sig contract for the DAO for Aletheia.

Multi sig address: 0xB6812AAC424d074f28806d8C8415977E86D1CF7E

The signers are a mix of mentors/teachers at ZKU and fellow students who I have met in person during ETHAmsterdam.


Kosik: 0x683672825A7dC4d706c62eD134E2C208086d9158

Margulus: 0x3c1e75b9039945C4f6e252b2Af35C0e024E4a93b

lovelace: 0x16616267e8aF3b1a8872CCa0261515deF2C8F205

ThanksSkeleton: 0xd0cb2309Fe6a3Ec912604bBED4C978358ae195D9

Casie: 0x62763A0D45Eb16EFe2B9f2f30743BE0e6ec3A207

tomo: 0x98cEbab8451FDb86B9Cd1200D5aa1ED2b97aFc01

shada: 0xF8B30daFCbb48C3EBa1ff6ABe8A50Ca24233aF00

hadzija: 0xbb59c2ad6083A2DA55972Fc1Bde73509Dcb062F1

Thank you everybody for participating!

Mini update:

With the market downturn I feel less pressure to publish the project quickly so I have decided to learn Go before and rewrite my backend in it. I think it will pay off in the long term. Go is the dominant language for crypto backends since most clients use it.

Here are the resources I used to learn Go:

Both resources supplement each other pretty well and focus on deep understanding as opposed to just hacking code together. You will learn how code is executed on the machine. There are scholarships for students for the course provided by Ardan Labs and the book “Learn Go with tests” is free.

Would be happy to chat with others who use Go as their backend language for crypto projects to chat about best practices!

1 Like