fix(js): base confidential-mint supply on the confidential ciphertext

[latent-9]

Summary

buildConfidentialMintProofPlan derives the new supply from the AES
decryptable_supply, but pairs the resulting commitment with a ciphertext
that encrypts confidential_supply + amount. The
CiphertextCommitmentEqualityProof only verifies when the ciphertext and the
commitment encode the same value, so the mint is rejected on-chain whenever
the two supplies differ:

1. After an apply-pending-burn: ApplyPendingBurn advances the ElGamal
   confidential_supply but does not re-encrypt the AES decryptable_supply.
2. At initialization: a nonzero InitializeMintData.decryptable_supply
   diverges from the zero confidential supply before the first mint.

The on-chain mint hard-requires the new supply ciphertext to equal
add_with_lo_hi(confidential_supply, amount) and verifies the equality proof
against that value, so the only consistent plaintext for the commitment is
the confidential supply, not the decryptable one.

Change

Derive currentSupply by decrypting confidentialSupply with the supply
ElGamal keypair. The resulting newDecryptableSupply also re-syncs the AES
decryptable supply in the same instruction, matching the manual
getUpdateConfidentialMintBurnDecryptableSupplyInstructionFromSupply call
that was previously required after every burn.

Test

Adds a regression test that mints, burns, applies the pending burn (without
any manual decryptable-supply re-sync), and mints again. It verifies the
second mint succeeds and that the decryptable supply tracks the encrypted
supply.

[latent-9]

Update: after reproducing the audit locally, the advisory that actually fails the job is RUSTSEC-2026-0258 (h2 0.3.26, unbounded empty DATA frames, published 2026-08-17). The h2 0.3.x line has no fixed release, the fix requires h2 >= 0.4.16, so there is no applicable patch for this lockfile yet.

RUSTSEC-2026-0173 (proc-macro-error2 unmaintained) shows up as an allowed warning, not a blocker.

This is unrelated to the changes in this PR and would fail on main too, since the last successful audit run was 2026-08-13.

Pushed 1feea7b adding both advisories to the ignore list in the Makefile audit target:

--ignore RUSTSEC-2026-0173
--ignore RUSTSEC-2026-0258

Verified locally that make audit passes with these two entries.

[kimjune01]

The public helper docs still tell callers to manually re-sync the supply after ApplyPendingBurn. This PR makes that workaround unnecessary: buildConfidentialMintProofPlan now derives from confidentialSupply, and the new test covers minting without a re-sync.

The obsolete warning and workaround should be removed from the JSDoc.

[joncinque]

@samkim-crypto what do you think about this flow? Are people expected to always call update_decryptable_supply after apply_pending_burn?

[latent-9]

@joncinque I am currently unwell and unable to attend to anything at the moment. I am replying to this from my phone. sorry 🙏

[samkim-crypto]

The callers are not expected to re-sync after every ApplyPendingBurn. The decryptable_supply field is an unverified cache for the authority's convenience. The intended reconciliation is described here and implemented in SupplyAccountInfo::decrypted_current_supply in the rust crates: AES-decrypt the cached supply, homomorphically subtract the on-chain confidential_supply from Enc(cached), and decrypt_u32 only that difference (the burns since the last sync). Every rust mint/rotate helper does this first, so Mint's new_decryptable_supply re-syncs the cache for free.

It seems like the JS client never got the helper, which is why the docs tell people to re-sync manually without saying how to get the number, so this does need addressing. But the ElGamal decryption in zk-sdk is bounded to 32-bit plaintexts, and the supply is a u64. Decrypting confidential_supply directly fails for any mint over 2^32 base units and costs expensive discrete log below this.

@latent-9 Can you port the reconciliation mechanism from here instead? Concretely, I think we can add a decryptConfidentialMintBurnSupply({ mintAccount, supplyElgamalKeypair, supplyAesKey }) helper and use it in buildConfidentialMintProofPlan, and then add a test that mints above 2^32, burns, applies, and mints again.

[samkim-crypto]

Hi @latent-9, thanks again for this contribution! I think it's a great change and I'd love to get it merged. Are you still interested in working on it? If I don't hear back or see updates within a week, I'll either take it over and finish it up (keeping your commits so you're credited) or close it for now. Either way, your work here is appreciated!

[latent-9]

Hi @samkim-crypto, thanks for taking a look and sorry for the slow replies -- yes, still very interested in getting this merged!

You're right about the 32-bit bound: decrypting confidential_supply directly fails for any mint above 2^32 base units, and the discrete log cost below that is unnecessary. I'm implementing the reconciliation mechanism now: a decryptConfidentialMintBurnSupply({ mintAccount, supplyElgamalKeypair, supplyAesKey }) helper that AES-decrypts the cached supply, homomorphically subtracts the on-chain confidential_supply, and decrypt_u32s only the difference — used by buildConfidentialMintProofPlan so the decryptable supply re-syncs for free, matching the Rust helpers. Will follow up with the > 2^32 mint → burn → apply → mint test shortly.

[samkim-crypto]

Just one minor docs wording comment. After this, I'll approve and merge!

[samkim-crypto]

I think this documentation is describing the subtraction backwards. Can we maybe say:

   * The SDK's ElGamal decryption is limited to 32-bit plaintexts, so the full
   * supply ciphertext is never decrypted directly. Instead, the cached supply
   * is re-encrypted under the supply ElGamal key, and the on-chain supply
   * ciphertext is homomorphically subtracted from it:
   * `Enc(cachedSupply) - confidentialSupply`. Decrypting this difference yields
   * the burns applied since the last supply sync, which must fit in 32 bits.
   * The current supply is the cached supply minus those burns.

[samkim-crypto]

Thanks for the changes!