Enhancing Privacy: Implementing ZK-Commitments for Lido Payroll & Grants

The Problem: Lido’s treasury is transparent, but direct payouts doxx contributor wallets. Every grant or salary payment links a contributor’s identity to their total net worth and transaction history.

The Solution: Implement a Commitment Layer (Proof Crater) to decouple treasury transparency from individual privacy:

  1. Commit: The DAO anchors a Merkle root of payment obligations and locks funds in a ZK-Vault.

  2. Verify: Contributors generate a ZK-proof locally (browser-side) to prove they are a valid recipient.

  3. Claim: Funds are withdrawn to a clean address. The link between the Lido Treasury and the recipient is severed, but the total distribution remains verifiable on-chain.

Is the LEGO team or Treasury Ops interested in a pilot for private grant distributions?

1 Like

While contributor privacy is a strong incentive for talent retention, how do we ensure the DAO doesn’t lose its “Accountability Signal”? If LEGO (Lido Ecosystem Grants Organization) can’t link specific milestones to disbursements via public audit trails, we risk creating an accountability gap.

Does the Proof Crater design allow for “selective disclosure”? It would be prudent to have a mechanism where the LEGO committee or designated auditors hold viewing keys to verify that funds reached the intended recipient, even if that link remains hidden from the general public.

Thanks — that’s a very fair concern.
A few clarifications on how the current ZK Vault works:

Each withdrawal emits a nullifier, computed as: Poseidon([secret, nullifier_seed])
The contract stores used nullifiers to prevent double claims.
Whoever generated the original secrets (e.g., LEGO / the grant allocator) can recompute the nullifier for every allocation. When a withdrawal happens, they can match the emitted nullifier to a specific allocation and determine which milestone payout was claimed.

The public cannot link the payout to a recipient address.
The allocator (or any party holding the secret registry) can distinguish which allocation was withdrawn.

Is this what you mean by “selective disclosure”?
If the requirement is that LEGO or designated auditors must be able to internally verify that a specific milestone allocation was claimed — without exposing that link publicly — the current design already supports that.

If you’re envisioning something stronger (e.g., identity-bound verification, third-party auditor keys, regulatory reporting hooks), could you describe the technical and compliance requirements in more detail? “Selective disclosure” can mean different things cryptographically.

Also — I’d encourage you to try the live demo on Sepolia. You can use one of the secret pairs provided on demo page of the website and withdraw the allocated mock tokens to any address.