Starknet Opens Its ZK Privacy Stack to Builders—With Version Discipline Required

Starknet’s latest privacy milestone is less about introducing another proof system than about making an existing one usable by application developers. On July 15, Starknet announced that its Privacy SDK and Privacy Wallet API were open to builders, extending STRK20 from a mainnet capability into an integration layer.

That distinction matters. A privacy protocol can be cryptographically sound and still fail as developer infrastructure if every wallet and application must independently implement viewing keys, encrypted notes, proving, and transaction submission. Starknet’s new stack is designed to divide that work between two integration paths.

The direct path is a TypeScript SDK for wallets and advanced integrators. It handles viewing-key registration, per-token channels, note management, proof generation through a configurable backend, and onchain submission. The higher-level path is the Privacy Wallet API, exposed through starknet.js. A normal decentralized application can ask a privacy-enabled wallet to shield, transfer, unshield, or swap without directly handling a user’s viewing key, notes, or proofs.

The architecture is a useful reminder that “private” does not mean “invisible.” STRK20 stores shielded balances as encrypted notes. Private transfers consume existing notes and create new ones, with a zero-knowledge STARK proof showing that the notes are valid, unspent, and value-conserving without revealing the sender, receiver, or amount. Deposits, withdrawals, and the fact that a user is interacting with the pool remain visible.

For DeFi builders, the more interesting feature is composability. An anonymizer contract can let the privacy pool call an application atomically: funds can be withdrawn, used for a swap or another action, and credited back as private notes in one transaction. If the application step reverts, the overall operation rolls back. This gives developers a way to experiment with private swaps, lending, or staking without forcing users through a public unshield-and-reshield workflow.

The proof path is built into Starknet’s protocol rather than delegated to a conventional application contract. Starknet’s v0.14.2 release added proof and proof_facts fields to Invoke V3 transactions, allowing transactions to reference off-chain execution proofs while consensus performs the verification. That design avoids the transaction-size problem that makes direct verification of large STARK proofs impractical inside ordinary smart-contract calls.

There is, however, an operational boundary developers should treat seriously. The open-source repository describes a pipeline involving an SDK, a discovery service for encrypted onchain storage, a proving service, a privacy-pool contract, and optional anonymizers. It also publishes a compatibility matrix and says components are tested together at matching revisions. The current repository lists release-candidate tags for several components, so the builder experience is not yet equivalent to a frozen, universal production API. This is a version-sensitive stack, and that caveat applies equally to the English and Persian versions of this article.

The practical takeaway is straightforward: ordinary dapps should begin with the Wallet API, while wallets and teams that need control over proving and note management can work directly with the SDK. The cryptographic headline is still zero-knowledge validity, but the developer story is now about interfaces, key custody, discovery, proving infrastructure, and failure recovery. That is the point at which privacy technology starts becoming application infrastructure rather than a standalone demo.