Builder Privacy Overview

STRK20 is a privacy pool plus a small set of integration surfaces. Start with the narrowest surface that keeps user keys in the right place and only move to a lower-level route when your product needs more control.

Quick decision guide

Core surfaces

STRK20 pool

The pool is the base contract layer. Deposits move public ERC-20 tokens into the pool, private transfers spend encrypted notes inside the pool, and withdrawals move tokens back to a public address. Movement inside the pool hides sender, receiver, token, amount, and spent notes from public observers.

Starknet Wallet API

This is the recommended route for most private dapps. Your dapp asks the user's privacy-enabled wallet to perform an action; the wallet handles private state, proofs, and submission. A normal dapp should not receive the user's viewing key or manage note discovery directly. See the Starknet Wallet API overview.

Anonymizer contracts

Anonymizer contracts, also called helper contracts, are app-specific Cairo adapters for private DeFi. The pool withdraws tokens to the helper, calls its privacy_invoke entry point, and the helper returns OpenNoteDeposit instructions for whatever should be credited back into private notes. This is the focus for core builders shipping private dapps. See Anonymizer Contract Anatomy.

Privacy Bridge (EVM to pool)

Most users hold their USDC on an EVM chain, not on Starknet. The Privacy Bridge is a value-movement engine for exactly that gap: it takes USDC from an EVM wallet and deposits it into the pool as a private note, and moves value back out to an EVM chain, using Circle's CCTP for the cross-chain leg. Both directions run through its own Cairo anonymizer contracts - OutboundAnonymizer on the way out, InboundAnonymizer on the way back in - so the deposit side and the withdrawal side cannot be linked onchain. All client-side key material is derived from a single wallet signature; only the read-only viewing key may be persisted.

The repository is open source (Apache 2.0) and ships three parts: the bridge-anonymizers Cairo contracts, the framework-agnostic @starkware-libs/starknet-privacy-bridge TypeScript engine with optional React hooks, and a demo web app. It is early and moving fast - read its README before planning around it.

Build Privacy Wallets

The Build Privacy Wallets section is the lower-level SDK route for teams building privacy wallets on Starknet, account-controlled backends, and advanced integrators. Use it when you need to manage registration, channels, note discovery, transaction construction, and proving providers yourself. See Build Privacy Wallets.

Shadow accounts

Shadow accounts are persistent, pseudonymous identities for account-based app activity. Each (user, dapp, nonce) tuple maps to a deterministic address with no public onchain link to the user's main wallet.

Both integration routes are available. Dapps can send shadow_account_invoke through Wallet API 0.10.4 with starknet.js 10.8.0; wallets and advanced backends can use Privacy SDK 0.14.3-rc.8 through transfers.build().shadowAccounts(dappName). See Shadow Accounts through the Wallet API or Shadow Accounts with the Privacy SDK.

The shadow address, balances, calls, and positions are public. What stays private is the link back to the user's main wallet. A shadow account has no keys; only the ShadowAccountAnonymizer can execute through it.

Prover backend

Most dapps do not need to operate proving infrastructure. Wallets, infrastructure teams, and advanced integrators may run their own prover when they need operational control over proof generation. Running a prover locally does not itself require screening credentials. A transaction that needs a screening attestation - most notably a deposit - still has the depositing address evaluated by Elliptic. An FPI-managed signer attests an allowed result, and the pool verifies that signature onchain, so self-hosting does not bypass the deployed screening policy.

Builder rules of thumb

• Use the Starknet Wallet API first for user-facing private dapps.
• Use Build Privacy Wallets when you are building the wallet itself or need low-level SDK control.
• Do not ask a normal dapp user for their viewing key.
• Make per-account viewing-key export and recovery guidance easy to find before users shield meaningful funds. See Viewing Keys & Backups.
• For private DeFi integrations, expect both a Starknet Wallet API flow and an app-specific anonymizer contract.
• Deposits are screened on every route - self-hosted proving does not bypass onchain screening.
• Be explicit about what remains public: deposits, withdrawals, timing, and some app-side activity may still be visible.
• Verify wallet support, API versions, contract addresses, and compliance assumptions before launch.

Read next

• What is STRK20?
• Starknet Wallet API
• Anonymizer Contract Anatomy
• Build Privacy Wallets