Sepolia user decrypt fails in KMS share reconstruction (9/13 Gao decoding failure)

[EvanYan]

Hi Zama team,

This may be related to the recent Sepolia incident reported here:

Sepolia: handles created after ~2026-08-31 will not decrypt, while older handles on the same contract still do

Edit: Back up now ~6:15pm est. My test suite passes now and the new handles properly decrypt, no code changes on my end. The old failing ones are working properly now. Old post: Since some point after 2026-08-30 I cannot decrypt any newly created handle on Sepolia, while older handles on the same contract, same account and same code decrypt normally. I have a clean control on both sides and I have not been able to make it my own bug, so I think it may be infrastructure, but I would rather be t…

That thread reported newly created handles failing and then recovering without client changes. On 2026-09-03 we observed a different, deeper failure signature during user decryption on Sepolia, after the recovery noted in that thread.

Environment

• Chain: Sepolia (11155111)
• Operation: user decrypt, one handle in the request
• @zama-fhe/sdk: 3.4.0
• @zama-fhe/react-sdk: 3.4.0
• Transitive @fhevm/sdk: 0.13.2
• Application: CachePot

Observation

Timestamp: 2026-09-03T02:28:43.874Z
Duration before failure: 5707 ms

Handle:

0x2b585485a039fdf029e8ed750f00302ae6537c3a32ff0000000000aa36a70500

Technical error:

Error in core/service/src/client/user_decryption_wasm.rs:378:44:
Error reconstructing all blocks:
Error in core/threshold-algebra/src/poly.rs:711:20:
Gao decoding failure: Allowed at most 0 errors but xgcd factor degree indicates 1.
n=13, deg=4, #shares=9, block_shares=9, recovery_errors=0

Checks already performed

• The ciphertext handle is read onchain immediately before the SDK request.
• Onchain persistent ACL permission is present for both the wallet and the holding contract.
• The public relayer key endpoint responds successfully.
• The request contains exactly one ciphertext handle.
• No signature, permit or transport-key material is included in this report.

Some other balances in the same application remain readable, but they may be served from the SDK’s persistent plaintext cache, so I am not treating them as a clean old-vs-new control.

Interpretation / questions

This appears to reach browser-side threshold-share reconstruction, rather than failing during ACL authorization or relayer transaction simulation. With 9 shares received out of 13 and recovery_errors=0, the Gao decoder reports one inconsistent share but has no remaining error-correction budget.

1. Is this a known Sepolia KMS quorum/share-consistency incident or a continuation of the earlier new-handle incident?
2. Is the interpretation of these fields correct: four missing shares consume the tolerated fault budget, leaving the decoder unable to correct one inconsistent accepted share?
3. Is there a recommended retry/backoff policy and a realistic upper bound before an application should surface a persistent service incident?
4. Would a transaction hash, handle creation block, contract address, or repeated-request traces help identify the affected party/epoch? I can provide them.

Thanks.