Mainnet KMS context not activated: getCurrentKmsContextAndEpoch() reverts, so relayer /v2/keyurl cannot initialize

Zama Protocol
1

We are integrating confidential payments on Ethereum mainnet (ERC-7984 token on the FHEVM host stack) and are blocked on what looks like the final activation step of the mainnet KMS context. Posting the full evidence in case it helps, and to ask about the timeline.

Environment

  • Host chain: Ethereum mainnet (chain id 1)
  • Self-hosted relayer built from zama-ai/fhevm @ 5c46d5d4aae539912a7f905fdbfcba15f07c1558 (main, 2026-08-18); /version reports relayer-service 0.14.0
  • Contracts from the SDK MainnetConfig: ACL 0xcA2E8f1F656CD25C01F05d0b243Ab1ecd4a8ffb6, ProtocolConfig 0xD8236B57394f90726b26aB25D38CeAC776E1a7C4, KMSGeneration 0xF102CC9a9D2174630C394f5B7B7D63104E348dAa, Gateway chain 261131

What works

  • The relayer boots and reports healthy: gateway listeners, gateway HTTP, and database all ok
  • On-chain symbolic FHE operations work (our token mints and transfers confirm on mainnet)
  • KMSGeneration.getActiveKeyId() returns 0x0400...0001 and getActiveCrsId() also answers, so key material appears to be registered

What is blocked

  • ProtocolConfig.getCurrentKmsContextAndEpoch() reverts with empty data:

    curl -s -X POST -H ‘content-type: application/json’
    –data ‘{“jsonrpc”:“2.0”,“id”:1,“method”:“eth_call”,“params”:[{“to”:“0xD8236B57394f90726b26aB25D38CeAC776E1a7C4”,“data”:“0x65b394af”},“latest”]}’
    https:// ethereum-rpc . publicnode . com
    → {“error”:{“code”:3,“message”:“execution reverted”,“data”:“0x”}}

  • The relayer’s keyurl poller gates on that read (RFC 005 context-aware /v2/keyurl, PR #2810), so /v2/keyurl cannot initialize and no FHE keys are served. An unpatched build exits at startup on “Failed to initialize /v2/keyurl from host chain”; we patched ours to boot and serve a failed placeholder until the poller succeeds, and it currently returns:

    {“status”:“failed”,“response”:{“fheKeyInfo”:,“crs”:{}}}

  • Net effect: input proofs, user decryption, and public decryption are all unavailable on mainnet through a self-hosted relayer, while everything else in the stack is up.

On-chain history we observed (full event scan of the ProtocolConfig proxy since deployment)

  • Deployed and initialized around 2026-08-05
  • Both proxies upgraded and reinitialized on 2026-08-10 11:50:47 UTC (tx 0x3a73cbfe82d45d522aafa83acbc4a44dd89a2b409530e3a52d0076009a036c78)
  • No further transactions or events since; consistent with the KMS context activation not having been executed yet as of block 25,803,269 (2026-08-21)

We also note the protocol changelog lists Mainnet at FHEVM v0.11 while the KMS context and epoch lifecycle shipped in the v0.13-era work, so we understand mainnet may simply not have reached this step of the rollout.

Questions

  1. Is the KMS context activation on Ethereum mainnet scheduled or in progress, and is there a rough timeline?
  2. Does the Zama-hosted mainnet relayer (relayer. mainnet. zama. org, API-key gated) currently serve real keys, or is it gated on the same on-chain activation?
  3. For self-hosters targeting mainnet today, is there a recommended commit or tag that matches the currently activated mainnet protocol state, rather than main?
  4. Anything else integrators should configure differently for mainnet in the meantime?

Happy to share relayer logs or run further probes if useful (privately).

Company/Project: Aro Media Inc. / AroPay
Contact: dnzagha[at]aro[dot]media

2

Hi there, to help with this can you please clarify what SDK and what version are you using, because there’s a couple of different libraries that people use.

Zama SDK is our recommended option, but I know some people use the legacy Relayer SDK or FHEVM SDK. The reason I ask is this problem might be occurring because you’re on an old version potentially.

3

Thanks @ankurb. Exact versions:

  • Client: @zama-fhe/relayer-sdk@0.4.3 (npm), used in Node API routes and in the browser via the UMD bundle. Happy to migrate to @zama-fhe/sdk v3 if that changes anything here.
  • Self-hosted relayer: relayer-service 0.14.0, built from zama-ai/fhevm main @ 5c46d5d (2026-08-18), configured per relayer/docs/SELF_HOSTING.md with the mainnet ProtocolConfig (0xD8236B57…) and KMSGeneration (0xF102CC9a…) proxies.

The reason we don’t think this is a client-SDK issue: the blocking issue is on-chain and relayer-side. ProtocolConfig.getCurrentKmsContextAndEpoch() reverts on Ethereum mainnet via plain eth_call, and the v0.13+/v0.14 relayer’s /v2/keyurl poller gates on that read, so the relayer serves no keys and any client SDK version then fails at key fetch. Since the changelog lists Mainnet at FHEVM v0.11 and the KMS context/epoch lifecycle is v0.13-era work, our relayer built from main appears to be ahead of what is currently activated on mainnet.

So the actionable questions for us are:

  1. For self-hosting against mainnet today, which fhevm tag/release should we run? Is there a v0.11-line relayer that serves keys without the KMS-context gate, or is self-hosting on mainnet effectively unsupported until the context is activated?
  2. Is the mainnet KMS-context activation scheduled? And does the hosted relayer (relayer.mainnet.zama. org) with @zama-fhe/sdk v3 already work end-to-end on mainnet today? If so, we’ll take that path with an API key in the meantime.
4

Hi! This isn’t an activation issue, and it isn’t SDK-related (no need to switch off @zama-fhe/relayer-sdk for this).

Root cause: There is an active KMS context on mainnet (getCurrentKmsContextId() returns a real non-zero id). The revert is because getCurrentKmsContextAndEpoch(), the getter your relayer’s /v2/keyurl startup check depends on, doesn’t exist in mainnet’s currently deployed ProtocolConfig implementation. Your relayer, built from main, expects a newer ProtocolConfig interface than what’s live on mainnet.

Fix: Build your self-hosted relayer from tag v0.13.3 instead of main. That’s the latest release before the combined getter was introduced, and its ProtocolConfig ABI matches what’s actually deployed on mainnet. One thing to note: at that version /v2/keyurl is still the static, config-driven implementation (key material comes from your relayer config, not fetched on-chain) rather than the newer host-chain poller, so double check your relayer config carries the fhe_public_key/crs settings instead of relying on-chain auto-discovery.

Thanks so much for raising this, it helps us to make the SDK’s better! Let us know if you run in any more issues!