zkProf

The Problem When the Wonderland DAO incident unfolded in early 2022, it exposed something far deeper than one pseudonymous contributor with a dark past.

It revealed a structural flaw at the heart of Web3: anonymous contributors have no safe, accountable way to reveal their identity to a specific party without exposing themselves to everyone.

In Wonderland’s case, the treasury manager “0xSifu” was later identified as Michael Patryn, a convicted felon and Co-Founder to QuadrigaCX a $200m fraud. This wasn’t just damaging because of who he was; it was damaging because there was no mechanism for the community to have verified his identity privately and safely before entrusting him with billions.

When the truth came out, trust evaporated, and with it, the value of the ecosystem.

The entire system had been built on an assumption: “anonymity is fine as long as the work gets done.” But anonymity without selective accountability is not decentralisation, it’s fragility.

Today, pseudonymous builders, founders, and contributors face a paradox.
If they choose to stay anonymous, teams have no real way to vet them.
If they choose to reveal themselves, they must expose their identity not just to a single hiring manager or DAO multisig, but to the host platform, the backend database, the company’s entire staff, and, in the worst case, a hacker who breaks in.

There is also no protection against the person requesting the identity. A founder or hiring manager can take an ID photo or passport scan and forward it to anyone. They can leak it, weaponize it, or expose it publicly. The anon has no legal protection, no cryptographic proof of misuse, and no ability to enforce consequences.

Web3 has privacy. Web2 has accountability.
There is no bridge between them. And until that bridge exists, another Wonderland-style collapse is always one leak, one breach, or one irresponsible request away.

The Solution zkProf, a new model: selective, encrypted, legally enforceable identity revelation that protects the anonymous user, protects the requesting entity, and removes platforms from the risk entirely.

With zkProf, an anonymous user can take a real, timestamped photo while signing with their wallet. That photo is encrypted instantly in the browser, meaning the platform itself cannot access it, store it, or leak it.

The identity can only be decrypted by the specific requester, and only after that requester has signed an NDA that binds them legally and cryptographically. This creates a controlled, accountable flow: the anon chooses who sees their identity, under what conditions, and with an audit trail that proves the reveal happened at a specific time under a specific agreement.


The requester, on the other hand, gains confidence that they’re dealing with a real person, not an AI-generated persona or a malicious actor. They know the identity is fresh, verified at the moment of signing, and tied to the wallet they are onboarding. But they cannot forward it or dump it into a group chat without violating a legally binding NDA, and if they do, there’s a tamper-proof on-chain record showing exactly when the reveal occurred and who received it.

Payment and auditability are handled through Solana using x402 payments.

Every identity request, every verification event, and every doxx approval is recorded on-chain in an immutable memo.

This creates a perfect compliance trail for both parties without ever risking the user’s personal information.

To solve the issue of over-exposure and prevent anyone from reconstructing or leaking a user’s full profile photo, the reveal system only discloses a small circular area of the image at a time, and only where the viewer’s mouse is currently hovering. The rest of the photo remains fully obscured.

Each revealed region automatically includes a watermark containing the viewer’s wallet address and name, embedded directly over the visible pixels. This ensures that even if someone attempts to take multiple screenshots and stitch them together into a full image, every piece would still contain their identifying watermark, making it traceable back to the person who viewed and leaked it. This approach provides controlled visibility for trust-building while maintaining strict protection against full-image reconstruction.

The result is a privacy-preserving trust layer that neither Web2 nor Web3 has ever had. Anon founders can work with investors, pseudonymous contributors can be hired by DAOs and companies, and high-profile identities like Punk6529 could privately prove they are who they claim, all without surrendering their anonymity to a platform or risking public exposure.

This isn’t about forcing people to doxx. It’s about creating a world where anonymity and accountability finally coexist.

zkProf turns pseudonymity from a liability into an asset,
and transforms Web3 identity from a point of fragility into a foundation for trust.

1. Outdated Circom Version Causing Compilation Failures One of the first blockers I hit was a set of cryptic Circom compilation errors that didn’t make sense based on the documentation I was following. After hours of debugging, I realised I was using an outdated version of Circom. Updating to the latest release instantly resolved the issue, and the circuits compiled as expected. Lesson: Always version-check before debugging the impossible.

2. Circuit Key Mismatches Due to Bit-Length Issues Another recurring problem was that my proving and verification keys wouldn’t match after compilation. This was caused by a mismatch in bit lengths inside the circuit constraints (a common issue with circuits involving hashes, signals, and field element limits). The compiler would generate artefacts, but they wouldn’t align. I solved this the long way: repeatedly recompiling, adjusting constraints, and regenerating all artefacts over several days until the bit-length configuration finally aligned and the keys matched perfectly. Lesson: Circom is extremely sensitive to small inconsistencies, sometimes the only way out is disciplined iteration.

3. Solana Mainnet Payments Routed to the Wrong RPC For the Solana payment and memo-logging layer, I kept running into an issue where transactions were being unintentionally routed through the default Solana RPC instead of the Helius RPC I had explicitly set. Because zkProf uses x402-style payments and the memo acts as an immutable audit trail, this had to be completely reliable. The root cause was that the frontend/wallet was defaulting to a standard Solana RPC endpoint if it couldn’t reach the backend where the Helius API resides. I resolved this by explicitly specifying the Helius RPC endpoint in both .env, and also by exposing it publicly but restricting it within the Helius dashboard so that only zkprof domain can use it. Lesson: RPC routing can fail silently, enforce your RPC at every layer, also clear error handling toasts to define the route of issues.