Porto AA Batch Limits with ERC-7984: Measuring UserOp Calldata Growth from FHE Input Proofs

cPay — Confidential Onchain Payroll (ERC-7984 + Porto AA + ISO 20022 pain.001/pain.002)

Hi Zama community, elegant here and i’m sharing cPay, a confidential payroll MVP built with FHEVM + ERC-7984

What cPay does

  • Onboards users with passkeys + Porto smart account UX
  • Accepts payroll input as ISO 20022 pain.001
  • Validates recipients/amounts/totals before execution
  • Encrypts payroll amounts before onchain submission
  • Executes payroll in a single confidential batch run
  • Produces local pain.002 status receipts for finance operations
  • Lets each account decrypt only its own confidential balance

Why we built it

Public-chain payroll leaks sensitive compensation data.
We wanted to show a practical path for enterprise payroll ops with confidentiality preserved.

Current MVP status

  • End-to-end flow is working on Sepolia.
  • Stable operational batch size observed: up to 15 payments/run in current Porto AA setup.
  • Onchain contract max remains 100; larger batches need chunking strategy.

Technical notes

  • ERC-7984 confidential token wrapper
  • PayrollExecutor with nonce/replay/expiry/input-proof checks
  • Porto merchant fee sponsorship
  • Observer decrypt mode for current stability

What we’d like feedback on

  1. Best-practice chunking for confidential batch scaling (>15).
  2. Preferred approach for Porto-compatible client-side decrypt signatures.
  3. Any recommended indexer/event patterns for payroll auditability.

Live demo : cpay-web.vercel.app/

Cool use case — confidential payroll is exactly where FHEVM shines

:one: Batch scaling (>15)
If you mean contract-level scaling: minimize the number of FHE operations per call. Chunk based on total FHE op count, not just recipient count. Reduce redundant checks and keep each transaction’s FHE “weight” predictable.

:two: Porto-compatible decrypt signatures
Smart account signing for user decryption isn’t supported yet. For now, you’ll need an EOA-based EIP-712 signature flow. Smart account support is planned.

:three: Indexer / audit pattern
Zaiffer team inside Zama building the portfolio dapp, has built a custom indexer instead of using The Graph, quoting our engineer:

In Zaiffer we didn’t rely on an external indexer (like The Graph or something similar).
We built a dedicated indexing process that continuously reads Ethereum blocks, parses transactions, and maintains a local database of only the events relevant to us (those “ERC-7984-related”).
The approach was:

  • Monitor every new block on the eth blockchain
  • Filter for relevant contract addresses and event signatures
  • Persist structured data locally for reconciliation and business logic

That gives a fine control over how events are interpreted and linked to off-chain processes.

In short:

  • Recommended indexer → unfortunately I don’t have a specific recommendation, as I didn’t experiment with third-party indexers in this context.
  • Event pattern → emit structured events, then monitor, filter and store them locally for internal reconciliation and audit purposes.
1 Like

Thank you so much poppy, this is super helpful. I’ll be benchmarking fhe userops bundle size and share my findings as well

1 Like