Here is what I built, how I built it, and what the FHEVM primitives actually feel like at the application layer.
Phase — Special Bounty × TokenOps SDK
Track: Special Bounty (Launchpad for Private Token Distribution)
Phase is a private token distribution launchpad. Admins launch confidential claim drops, recipients reveal only their own allocation via wallet-authorized user-decrypt, and observers verify campaign activity without seeing amounts or recipient identities.
The core privacy guarantee is enforced at the FHE layer
Each allocation is encrypted as a euint64 ciphertext and bound to the recipient’s wallet address with input proofs via an EIP-712 signed handle using the TokenOps SDK:
export async function buildClaimAuthorization({
recipient,
encryptedInput,
}: {
recipient: `0x${string}`;
encryptedInput: { handle: `0x${string}`; inputProof: `0x${string}` };
}) {
const signature = await signClaimAuthorization({
walletClient,
airdropAddress,
recipient,
encryptedAmountHandle: encryptedInput.handle,
});
return { recipient, encryptedInput, signature };
}
When a recipient requests their allocation, they sign a user-decrypt authorization. The FHEVM decrypts the ciphertext exclusively for that address. Other recipients’ ciphertexts are unaffected.
An admin cannot read a recipient’s allocation after sealing. A block explorer shows only handle
What the TokenOps SDK unlocked:
The SDK compressed what would have been 3-4 weeks of raw FHEVM contract work into a focused frontend integration problem. The confidential airdrop lifecycle — deploy, fund, encrypt allocations, sign claim authorizations, execute claims: is handled by the SDK. My job was building the product layer on top: the admin workspace, the recipient reveal flow, and the observer page.
The design decision I’d highlight:
The observer page is the most important page in Phase. It makes the privacy model visible: campaign activity is public, but amounts and recipient identities are sealed. Most privacy-preserving products hide their privacy guarantees in documentation.
Phase surfaces it as a UI element this way: “Allocation: sealed” as a live badge on the distribution card. I made sure the privacy boundary becomes part of the product surface instead of a footnote.
Lattice Pay — Builder Track
Track: Builder Track (Confidential Payroll Infrastructure)
Lattice Pay is a confidential payroll execution system built on ERC-7984 and FHEVM. It handles the full enterprise payroll workflow — ISO 20022 pain.001 import, encrypted batch execution, per-payment status tracking, pain.002 receipt export, and a recipient portal for wallet-authorized balance reveal.
The ISO 20022 integration is the detail worth unpacking. pain.001 is the international payment initiation standard used by banks, treasuries, and payment processors globally. Most DeFi payroll tools ignore this entirely and build bespoke CSV schemas. Lattice Pay imports real pain.001 XML, validates recipients and totals against the uploaded file, and exports a pain.002 receipt on completion, I.E. the standard acknowledgement format.
This matters because the actual path to enterprise adoption for confidential payroll is meeting treasuries at the tooling they already use rather than convincing them to learn new tooling.
The FHE primitive doing the work:
The PayrollExecutor contract submits confidential transfers recipients, encrypted amounts, and per-payment proofs move as arrays in a single call.
nonce and validUntil block replay. executedRunId blocks double-execution of the same run.
One failed payment doesn’t sink the batch, only a fully-empty run reverts.
Every encryptedAmounts[i] is ciphertext with its own proof. Plaintext salary amounts are never published onchain – not in storage, not in events, not in calldata.
The ERC-20 → ERC-7984 bridge:
Most treasury stablecoin flows today start as ERC-20. Lattice Pay handles this directly: mint mock ERC-20, approve the ERC7984ERC20Wrapper wrap into the confidential payroll token. This is the bridge from today’s treasury model into confidential payroll infrastructure — and it’s intentional. The path to adoption runs through existing systems, then we go full adoption.
The recipient portal:
A recipient connects their wallet, signs a user-decrypt request, and sees only their own confidential payroll balance. Other recipients’ balances remain private. This is the moment where the FHE value becomes concrete in the product experience. A payroll system where the employee can verify their own salary onchain, without the entire company’s compensation structure becoming public data.
What building both taught me about FHEVM at the application layer
Three things I did not fully appreciate before this season:
1. The ACL is the product.
Access control in FHEVM is not a security feature bolted onto the application. I learnt it is the application. Every design decision in both Phase and Lattice Pay traces back to a single question: who is allowed to decrypt what, and when? FHE.allow(), FHE.allowTransient(), FHE.makePubliclyDecryptable(). They are the product specification expressed in code.
2. User-decrypt is the UX unlock.
The moment a recipient signs a user-decrypt request and their own allocation or salary appears — that is the product’s hero interaction. Everything else in both apps is plumbing for that moment. If you are building on FHEVM, design backward from that moment. It is where the cryptographic primitive becomes a ux.
3. The observer view is underbuilt in most FHEVM dApps.
Both Phase and Lattice Pay invest heavily in the observer/public view — what someone without decryption access can verify. This is where trust is built with the broader ecosystem. A private distribution that nobody can verify happened is not a product. A private distribution with a proof-safe public audit trail is infrastructure.
Links
- Phase: usephase.vercel.app
- Lattice Pay: latticepay-app.vercel.app
- GitHub: 0xNana (elegant.eth) · GitHub
- X: @0xelegant