A Question to help us Scale

Zama Developer Program
1

Hello Jan it’s the team behind Mediflow, we are hoping to solve a tiny bottleneck as with regards to “GAS ABSTRACTION”

Hospitals might find it difficult to adopt Mediflow if every patient record check requires them to pay gas or sign a blockchain transaction, we dug around a bit and figured OpenZeppelin Relayer Added Support for Zama FHEVM sometime around May so we can abstract the UI and cost from the users

But we wanted to know how best to scale down on the cost if there are any?? since we are in the starting phases and would need to cover some of these till we are able to bootstrap enough customers..

2

We’ve received your Season 3 submission and the review process is ongoing, so stay tuned on that.

On the gas abstraction question: could you share a bit more about your setup and needs?

Best regards,
Jan

1 Like
3

Hi Jan,
Thanks — happy to share the setup and what we’re actually blocked on. because now more than ever the MVP we built absolutely needs to be scaled

What we built

MediFlow: but just recently there’s been report that the Officials at the National Identity Management Commission in Nigeria have been caught selling IDs of Nigerians for as low as #250, it contains practically every single critical detail of a citizen in the country, which is exactly the type of problem Mediflow was built to prevent against a primitive that stores citizen attributes as FHE ciphertexts and lets a registry, query engine, or hospital contract compute on them (eligibility, counts, updates) without plaintext. A citizen retrieves their own record via user decryption / re-encryption, not by giving the agency a master key.Current setup

  • fhEVM / Zama FHE stack on a public test host (Sepolia-style)
  • Encrypted inputs client-side, handles on-chain, ACL for who can user-decrypt
  • Works as an MVP. Breaks as a national system on cost and sovereignty.

The two needs

  1. Gas / compute cost at government scale
    Encrypting and updating large identity or health datasets on a public EVM host is not economically viable for us. We need a path that keeps FHE guarantees but does not charge public-L1 gas for every ciphertext write, ACL grant, or query.
    Specifically: is the intended production path symbolic execution + coprocessors so the host only stores handles/events? Are there batching, ciphertext-off-chain DA, L2/app-chain, or gas-abstraction options you recommend for this class of workload? What would a realistic cost model look like for millions of records, not demo balances?
  2. Sovereign / government deployment
    No serious state will put raw national identity on public Ethereum, even if values are encrypted. The political requirement is: data residency, operator set, and key custody the country can accept.
    Does Zama support (or plan) a government / permissioned deployment where:
    • the host chain is a national or regional chain, not public Ethereum mainnet;
    • coprocessors can be run in-country or by appointed operators;
    • KMS/threshold parties can include national institutions so the FHE secret is not solely held by a global public operator set;
    • ciphertext storage/DA stays under a residency policy;
    • public verifiability is optional or scoped, rather than “anyone on Ethereum can index the handles”?

We are not asking to weaken encryption. We are asking whether the protocol can be instantiated as sovereign confidential infrastructure (same FHE + ACL + user decryption) instead of “NIMC on public Ethereum.”If that product exists, or if Season 3 / enterprise conversations are the right door, we want to be pointed there. Happy to share architecture, contract surface, and the cost numbers that stopped us.
Best,
0ncharted