How to report something real.
Confidential token operations on FHEVM is new ground. If you've found a privilege escalation, money-loss path, ACL bypass, or EIP-712 signature forgery, please reach the maintainers BEFORE filing a public issue.
security@tokenops.xyz
Mail security@tokenops.xyz with a description of the issue, reproduction steps, and (if you have one) a PoC. We respond within 48 hours; serious reports receive a same-day acknowledgement.
What counts as in-scope: anything that lets a non-authorised party (a) move funds, (b) decrypt a ciphertext without holding the right ACL grant, (c) forge an EIP-712 claim against a domain they don't own, or (d) escalate to DEFAULT_ADMIN_ROLE on a factory / clone / singleton.
What's out of scope: gas-grief vectors that don't change ownership of value; UI bugs in the docs site; opinions about the FHE model itself (raise those with Zama).
What the SDK trusts
DEPLOYED_ADDRESSES
The factory + singleton addresses baked into the SDK are the audit boundary. The SDK never deploys factories, it only calls into pre-deployed ones.
Zama relayer + KMS
Encrypt + user-decrypt round-trips hit Zama's infrastructure. The SDK doesn't hold keys, but it does depend on Zama's threshold posture for liveness + correctness.
Caller's wallet
Operators are responsible for keeping their admin keys safe. The SDK encourages splitting CLAIM_AUTHORIZER off the main operator key (cold signer) so a warm-wallet compromise doesn't leak authorization.
Encrypted handle bytes
A handle is opaque. Possessing it tells you nothing about the plaintext. The SDK logs handles freely (debug, telemetry), this is by design and doesn't leak.
Where each product stands
Live audit-status table. fhe-disperse mainnet is audited; the report is pending publication. fhe-vesting + fhe-airdrop are in audit ahead of their mainnet flip.