Hinkal

Hinkal is back Our EVM (Polygon, Ethereum, Base, and Arbitrum) contracts have been redeployed, independently audited, and are now live. You can resume using Hinkal Pay & Prime as normal, starting today. Solana, Tron, APIs and Hinkal Wallet will follow over the next few days. What we did We worked with @zksecurityXYZ, one of the best ZK security teams in the space, following the incident. The process combined zkao, zkSecurity’s automated vulnerability scanner, with a manual review of the circuit-level fix for the identified double-spend condition. The review focused on the identified double-spend condition and on verifying that the proposed circuit-level change prevented a single deposit from being spent more than once (a double-spend), and that there isn't an invalid proof that could be accepted as valid (a proof forgery). The issue is now fixed. Issue nullifyingPrivateKey was range-checked to be a canonical field element (< p, the BN254 scalar field prime), never reduced to or bounded by the BabyJubjub prime-subgroup order l. This is the precondition for a double-spend: a note bound only to the derived point k·G could be nullified by any scalar in the same residue class mod l. Fix We resolved the double-spend risk by binding the raw nullifyingPrivateKey scalar directly into the UTXO's stealth-address hash, rather than deriving the note's public key solely from the curve point k·H0. Because the scalar itself is now part of the commitment preimage, two congruent scalars k and k+l (which map to the same BabyJubjub point) now produce different public keys, and therefore different commitments: distinct tree leaves instead of one shared UTXO. Each committed note is reconstructable by exactly one scalar, its nullifier is unique, and the ~8 same-subgroup representatives can no longer open the same UTXO, closing the malleability path that would otherwise have allowed multiple valid nullifiers for a single note.