# What is STRK20?

> An introduction to Starknet Privacy - confidential token transfers on a public chain

The foundation for all privacy on Starknet: the layer everything above reads from
and writes to. STRK20 brings shielded balances, private transfers, and private
DeFi to any ERC-20 on Starknet, built on the wallets and liquidity that already
exist rather than a separate ecosystem.

### How it works at a high level

- **Note-based pool: not a mixer.** Shielding deposits an ERC-20 into the pool,
  where the balance is held as an encrypted note (a UTXO). Private transfers
  spend existing notes and generate new ones.
- **Registration first:** An account must register in the pool (set a viewing key)
  before it can hold or receive private balances; both sender and recipient must
  be registered before private transfers between them. Wallets handle registration
  on first use, and channel setup between counterparties is automatic after that.
- **Onchain proof verification:** Every private transaction carries a
  zero-knowledge (STARK) proof confirming the spent notes exist, belong to the
  spender, haven't been double-spent, and that value is conserved. Starknet
  verifies the proof in-protocol before updating the pool's state.
- **Hidden vs. visible:** Inside the pool, the sender, receiver, amounts, token
  type, and which notes were spent are all private. What stays visible: deposit
  and withdrawal amounts (the public ERC-20 legs), that someone is interacting
  with the pool, and timing. A Paymaster can decouple the submitter's address
  from the transaction.
- **Shielding:** Users shield assets when they want privacy and unshield them when
  transparency is required, moving value between public and confidential states on
  the same underlying token.

> **Before holding shielded funds:** export and securely store the account's
> viewing key. Ready and Xverse provide an account-specific export; repeat it for
> every account in the wallet. Losing the key can make the shielded funds
> inaccessible, while leaking it exposes private activity but does not let an
> attacker move funds. See [Viewing Keys & Backups](/viewing-keys).

## The lifecycle: public → private → public

1. **Deposit** - move public ERC-20 tokens into the pool. The deposit itself is
   visible on-chain (depositor and amount), but the resulting note is encrypted.
2. **Private transfers** - transfer value inside the pool by spending notes and
   creating new ones. Nobody watching the chain can tell who paid whom, or how much.
3. **DeFi** - if your flow calls for it, notes can fund DeFi actions through an
   anonymizer contract, with results credited back as private notes. This leg
   is confidential rather than fully private: the link to the user is hidden,
   but the app-side action and amounts can still be public.
4. **Withdraw** - move tokens back out of the pool to a public address.

**Shadow accounts** widen the DeFi leg: account-based flows such as borrowing
and staking run through persistent, deterministic addresses with no public
onchain link back to the user's main wallet. Each dapp and nonce can use a
different identity. The shadow account's balances, calls, and positions remain
public; its privacy comes from unlinkability. Shadow accounts are available
through both the [Starknet Wallet API](/starknet-wallet-api/shadow-accounts) and
the [Privacy SDK](/sdk/shadow-accounts).

## What makes it different

- **Native to Starknet** - no separate chain or bridge. It runs as a contract on
  Starknet and composes with existing accounts and DeFi.
- **Variable amounts, reusable notes** - unlike fixed-denomination mixers, notes
  carry arbitrary amounts and change is handled automatically.
- **Scalable discovery** - recipients find their incoming funds by scanning only
  their own channels, so cost scales with your activity, not total pool volume.
- **Selective disclosure** - at registration every user encrypts their private
  viewing key to an auditor's public key, so the system can disclose the
  information needed to respond to a legitimate regulatory request without
  exposing unrelated users.

## The building blocks

| Concept             | What it is                                                                                            |
| ------------------- | ----------------------------------------------------------------------------------------------------- |
| Note                | Immutable record of ownership of an amount of a token                                                 |
| Nullifier           | One-time value revealed when spending a note (prevents double-spend)                                  |
| Viewing key         | Keypair used to encrypt/decrypt note data and derive nullifiers                                       |
| Channel             | Unidirectional sender → recipient lane where notes are stored                                         |
| Anonymizer contract | Small adapter that lets pool funds interact with external DeFi                                        |
| Shadow account      | Persistent per-dapp address that is not publicly linked to the user's main wallet                     |
| Deposit screening   | Elliptic screens each deposit; an FPI-managed signer attests allowed results for onchain verification |

Each of these has its own page in the Concepts section - read them in order and
you will have the full mental model.

## Who this site is for

- **Private dapp developers** integrating with existing wallets - see the
  Starknet Wallet API section.
- **Core dapp builders** writing private DeFi integrations - see the
  Anonymizer Contracts section.
- **Wallet builders** implementing privacy flows directly - see Build Privacy
  Wallets.
- **Anyone** who wants to understand how private payments work on Starknet - start
  with the Concepts pages.

Have a coding agent? It can run this integration for you - see
[Agent Skill](/agent-skill).