I’d like to ask about the pricing mechanism of FHEVM.
If I build a privacy-preserving dApp using Zama’s FHEVM system contracts and off-chain coprocessor, how does Zama charge for usage?
From the gateway contract, I can see fees for:
public decryption
user decryption
Does this mean the main revenue model is based on decryption services?
Or are there other types of usage fees (e.g., computation, coprocessor services, network access, etc.)?
Is there any official documentation or roadmap that explains the pricing model for FHEVM? If so, could you please share a link?
Yes, Zama charges primarily for Gateway services, not computation itself.
If you’re building a dapp using the protocol, here’s how usage is priced:
Encrypted Input Verification
When users submit encrypted values (e.g. private bids, amounts), the Gateway verifies them. This step costs a small fee in $ZAMA tokens.
Public Decryption
If your smart contract needs to reveal an encrypted value on-chain (like auction results), you pay a fee for the KMS to decrypt it.
User Decryption
If you want to show a user’s encrypted balance or result in the frontend, the frontend app sends a signed request to decrypt. This is also paid.
All protocol fees are paid in $ZAMA, and operators (coprocessors, KMS) earn rewards by staking and serving the network.
Hi Clement, I have a couple of questions about the fee model following up on this:
If the fee model doesn’t modulate cost with FHE operation complexity, how are Operators incentivized to run complex FHE operations? At what point does the user pay more for a tx that runs tons of GHE operations vs one?
If we have to pay a fee every time we decrypt data, isn’t that a UX issue? Like how do I get instant balance update on a confidential ERC20 without spamming decrypt and spending a lot of tokens?
To give a bit more context about the second question, I am currently building a DApp using Zama and I want to provide the best UX possible. That means not having to click refresh manually on every variable every time we execute a transaction, and not having to sign with MM every time. One idea I had was to build a service to which one could delegate the right to decrypt data and the service would just poll decryption for the frontend. But if every decryption has to be paid for this is not going to work…
We run the infrastructure that executes FHE operations, so regardless of who submits the transaction, it will be executed once included. While users may compete for block inclusion at some point, execution itself is transparent. The cost of executing FHE operations is covered by the revenue generated from decryption and input verification.
Regarding payments, the goal is not for end users to pay directly. The dApp pays, and it’s up to each dApp to decide whether and how to pass that cost on to users as part of its own business or UX logic.
Hi Clement, I have a question about the fee model：
There should be only one Gateway contract in the entire FHEVM system, while multiple coprocessors can exist. In this design, all fees collected by the Gateway go solely to the contract deployer, leaving other coprocessors unable to charge fees. Isn’t this design potentially unreasonable?
Coprocessors provide FHE computing power but cannot charge fees — how, then, are they supposed to cover and amortize the costs of providing these FHE resources?
But as FHE operations will be decentralized, then you will need to charge per computation, right?
Regarding " the goal is not for end users to pay directly", what did you have in mind? The user would delegate decryption to the DApp backend? What about encrypted inputs? Is there some kind of AA for this?
Encrypted Input Verification
When users submit encrypted values (e.g. private bids, amounts), the Gateway verifies them. This step costs a small fee in $ZAMA tokens.
Public Decryption
If your smart contract needs to reveal an encrypted value on-chain (like auction results), you pay a fee for the KMS to decrypt it.
User Decryption
If you want to show a user’s encrypted balance or result in the frontend, the frontend app sends a signed request to decrypt. This is also paid.
And then, @clement mentioned that the dApp pays, and that it’s up to the dApp to get some money from its own users, eg with some kind of subscription which is managed on its side, independantly of Zama Protocol. Like, some SaaS company paying its bill to AWS, and then make its own customer pay a subscription to cover the expense and make some profit.
Maybe, if you want to go further, you would request a meeting with some of our Business Development team, it would be easier. You can reach out to them by this form: Contact - Zama
Encryption is done client side. Once encrypted, no need to trust server or relayer since response are signed by the set of coprocessors so no one in the middle can change things.
Right so what I’m wondering is how I (as a DApp Developer) can sponsor fees for my users. Although the litepaper stipulates that DApps can pay ZAMA fees for their users, there is nothing in the relayer doc about how to do that.
I am currently building a POC for confidential RWAs and I want the UX to be as smooth as possible in order to onboard TradFi users.
I am trying to figure out the missing pieces to abstract away encryption and decryption and avoir having a user sign messages all the time. Ideally something like AA. I am willing to build these tools if necessary but I need to know how it would work.
It might be a good idea to setup a meeting with Biz Devs indeed but I do realize you are all very busy with the sale so maybe I’ll come back in a week.
