CipherOps Technical Follow-Up: What Happens After a Token Becomes Confidential?

Zama Developer Program
1

CipherOps Technical Follow-Up: What Happens After a Token Becomes Confidential?

This is a technical follow-up to my original CipherOps introduction.

The first post gave a general overview of the project, but it did not properly explain how the different parts work together or show much of the onchain testing behind them. This post goes a little deeper into the actual flows, including the parts that took the most time to get right.

One clarification before I start: the core CipherOps lifecycle and TokenOps integrations were implemented and deployed before the Season 3 submission deadline. This is not a new submission or a late feature update. I simply wanted to document the architecture, verified flows, and limitations more clearly than I did in the original announcement.

Original post:

community . zama . org / t / introducing-cipherops-composable-confidential-business-operations-built-with-the-zama-protocol / 4557

Live app:

cipherops-orcin . vercel . app

GitHub:

github . com / mrcryptooo / cipherops

Please remove the spaces from the addresses above to open them.

The question behind CipherOps

When I started working with confidential tokens, I found that individual operations were understandable on their own.

You could wrap an ERC-20 into an ERC-7984 token. You could decrypt your own balance. You could distribute confidential tokens using TokenOps.

The harder question was what happens when these actions need to become one usable workflow.

A business does not only “wrap a token.” It may need to discover the correct asset, acquire test tokens, approve a wrapper, create a confidential balance, distribute different encrypted amounts, let recipients claim them, and later manage vesting.

That is the problem I tried to explore with CipherOps.

The result is not a new token or another isolated FHE example. CipherOps is a frontend and workflow layer built around Zama’s official confidential-token infrastructure and the TokenOps SDK.

1. Reading the official Wrapper Registry

CipherOps begins with the official Zama Wrapper Registry.

The application reads wrapper pairs directly from the registry contracts on Sepolia and Ethereum Mainnet. It does not rely on a manually maintained token list or a cached index.

For each valid pair, the interface retrieves the underlying ERC-20, its ERC-7984 confidential wrapper, token metadata, balances, and allowance information.

Registry addresses used by CipherOps:

  • Sepolia: 0x2f0750Bbb0A246059d80e94c454586a7F27a128e

  • Ethereum Mainnet: 0xeb5015fF021DB115aCe010f23F55C2591059bBA0

Mainnet is currently read-only in CipherOps. Transactional actions are deliberately limited to Sepolia while the product is still being tested.

This registry-first approach matters because developers and users should not have to search for separate deployments or guess which wrapper belongs to which ERC-20. The official registry should be the shared starting point.

2. The complete confidential-token lifecycle

The main Registry interface guides the user through the following lifecycle:

Faucet → Approve → Wrap → Private Reveal → Unwrap → Finalize

Each step is connected to the same selected registry pair.

Faucet

On Sepolia, users can mint the official test ERC-20 asset associated with the selected pair.

Approve

Before wrapping, the user approves the ERC-7984 wrapper to spend the underlying ERC-20. CipherOps displays the current allowance and refreshes it after the transaction.

Wrap

The approved ERC-20 amount is wrapped into its confidential ERC-7984 representation. After confirmation, the application refreshes the relevant balances instead of leaving the user with a transaction hash and no visible next step.

Private Reveal

A confidential balance cannot be read like a normal ERC-20 balance.

CipherOps first retrieves the encrypted balance handle through confidentialBalanceOf(address). It then uses the Zama relayer SDK and the EIP-712 user-decryption flow so the connected user can decrypt their own balance.

The revealed value is shown only in the local user flow. CipherOps does not publish it onchain.

Unwrap and Finalize

Unwrapping was the part that required the most investigation because it is not a single transaction.

The flow is:

  1. Encrypt the requested amount and call unwrap.

  2. Wait for the Zama Gateway to process the public decryption.

  3. Retrieve the cleartext result and decryption proof.

  4. Call finalizeUnwrap.

  5. Receive the underlying ERC-20.

The interface keeps these stages visible to the user because the delay between requesting and finalizing an unwrap can otherwise look like a failed transaction.

The complete lifecycle was tested on Sepolia with the official cUSDCMock / USDCMock pair.

Technical QA and transaction evidence:

github . com / mrcryptooo / cipherops / blob / master / docs / QA_CHECKPOINT_PHASE3 . md

3. Confidential Disperse

Once a confidential asset exists, the next useful operation is distribution.

The Operations Studio uses the TokenOps SDK to send different FHE-encrypted amounts to multiple recipients in one campaign.

I added a CSV-style input because entering recipients individually became inconvenient very quickly during testing. A sender can paste rows in the following format:

address,amount,label

CipherOps validates the rows, shows a preview, calculates a campaign summary, and then prepares the confidential distribution.

The individual payout amounts are encrypted before the transaction. The interface also produces a post-transaction receipt so the sender can retain the campaign details and transaction hash.

This flow was verified with two separate Sepolia transactions, including the final CSV/campaign version.

Disperse QA checkpoint:

github . com / mrcryptooo / cipherops / blob / master / docs / QA_CHECKPOINT_TOKENOPS_DISPERSE . md

One privacy detail is worth stating clearly: CipherOps protects the transferred amounts through FHE. It should not be described as a general-purpose anonymity system for wallet addresses.

4. Confidential Airdrop

Disperse is useful when the sender wants to execute the distribution directly. Airdrops need a different flow because recipients should be able to claim their own allocation.

The CipherOps Airdrop module covers both sides of that process.

For the campaign creator:

  1. Select a confidential token.

  2. Create and fund a TokenOps airdrop contract.

  3. Encrypt each recipient’s allocation.

  4. Sign a claim authorization.

  5. Export the authorization as portable JSON.

For the recipient:

  1. Open the claim interface.

  2. Connect the intended wallet.

  3. Paste the claim JSON.

  4. Submit the claim transaction.

  5. Use Private Reveal to decrypt the received confidential balance.

I chose portable claim JSON because it makes the boundary between issuer and recipient explicit. The issuer can generate an authorization and deliver it through any existing communication channel without requiring the recipient to use the same browser session.

The complete create, fund, authorize, claim, and reveal path was tested on Sepolia.

Airdrop QA checkpoint:

github . com / mrcryptooo / cipherops / blob / master / docs / QA_CHECKPOINT_TOKENOPS_AIRDROP . md

5. Confidential Vesting

The Vesting module extends the same confidential asset into a longer-term business workflow.

A sender can deploy a TokenOps vesting manager, create a schedule with an FHE-encrypted allocation, and assign it to a recipient. The recipient interface discovers the connected wallet’s vesting entries and allows available amounts to be claimed.

After claiming, the recipient can return to the existing Private Reveal flow to decrypt their confidential balance.

This reuse was important to me. Airdrop, vesting, wrapping, and decryption should not feel like four unrelated applications. They are different operations involving the same confidential asset.

The tested flow includes:

  • Vesting manager deployment

  • Encrypted schedule creation

  • Recipient schedule discovery

  • Claim transaction

  • Private balance reveal

Vesting QA checkpoint:

github . com / mrcryptooo / cipherops / blob / master / docs / QA_CHECKPOINT_TOKENOPS_VESTING . md

6. Runway: learning through real transactions

FHE concepts can be difficult to understand from documentation alone. Even when the technical explanation is correct, a new user may still not know which action to perform first or why a particular signature is required.

Runway is my attempt to make that learning process more practical.

It is a small startup simulation built inside CipherOps. Instead of reading a static tutorial, users complete missions involving real Sepolia operations. The application checks transaction hashes and turns the product flow into a sequence of concrete tasks.

Runway does not use mocked balances or pretend transactions. Its purpose is to help a user understand CipherOps by using the same flows available elsewhere in the application.

This part is still experimental, but I think interactive onboarding can be useful for FHE applications. Confidential workflows introduce unfamiliar states—encrypted balances, user decryption, gateway processing—and normal Web3 onboarding patterns do not always explain them well.

What I learned while building it

The FHE operation itself is only part of the product challenge.

A large amount of the work went into handling everything around it:

  • Explaining why a confidential balance cannot be displayed automatically

  • Making EIP-712 decryption understandable without hiding the security step

  • Representing the asynchronous unwrap/finalize lifecycle

  • Refreshing balances and allowances after confirmed transactions

  • Separating Sepolia write actions from Mainnet discovery

  • Recovering from RPC and relayer errors

  • Showing enough technical detail for developers without overwhelming a first-time user

The most difficult flows were not always the ones with the largest amount of code. Private Reveal and Unwrap, for example, needed careful handling because the user moves between wallet signatures, encrypted handles, relayer responses, Gateway processing, and normal contract transactions.

Current limitations

CipherOps is still an experimental application and has not been audited.

Some current limitations are:

  • Transactional flows are enabled only on Sepolia.

  • Mainnet support is currently limited to registry discovery.

  • Private Reveal and Unwrap are designed for EOAs; smart-account signature formats are not yet supported.

  • Gateway processing time can vary.

  • Public RPC endpoints may become rate-limited.

  • Mobile wallet support depends on a correctly configured WalletConnect project ID.

  • The interface needs more testing across wallets and browsers.

  • Automated contract and frontend test coverage still needs improvement.

I prefer to document these limitations openly rather than make the project sound more production-ready than it is.

Where CipherOps could go next

The current version focuses on confidential assets and their immediate operational lifecycle.

The next useful step would be moving from individual tools toward organization-level workflows, including:

  • Multi-user workspaces

  • Confidential approval policies

  • Private invoicing and treasury operations

  • Recurring confidential payments

  • Better transaction recovery and activity history

  • Smart-account support

  • Reusable APIs for developers building on the official registry

  • More Runway episodes based on realistic business scenarios

Before expanding the feature set, I also want to strengthen automated testing and improve the reliability of the existing flows.

Try it and break it

Live application:

cipherops-orcin . vercel . app

Source code and technical documentation:

github . com / mrcryptooo / cipherops

Three-minute demo:

x . com / Mrcryptoo1 / status / 2074574972211658951

Please remove the spaces from the addresses to open them.

If you test it, I would especially appreciate feedback on the parts that feel confusing—not only the parts that work.

I am interested in questions such as:

  • Is the difference between Wrap, Private Reveal, and Unwrap clear?

  • Does the Gateway waiting state make sense?

  • Is the claim JSON flow practical for a real airdrop?

  • What information would a developer need before trusting a registry pair?

  • Which operation still feels like a technical demo rather than a usable product?

Thanks to everyone who gave feedback on the first post, and thanks to the Zama and TokenOps teams for making these building blocks available.

I hope this follow-up gives a more accurate picture of what I built, what has been verified, and what still needs work.