# STRK-20

Markdown version of https://l2beat.com/privacy/projects/strk20

## Summary

**Warning:** Real-time monitoring for this project is not supported.

- Total Value Locked: $951.76 K (+10.4% compared to seven days ago)
- Assets tracked: 7
- Buckets tracked: 7
- Deposits 7D: 185 (+12.1% compared to the previous seven days)
- Deposits 30D: 760
- Deposits Total: 17.03 K
- Tracked on: Starknet
- Attributes: ZK, Transfers, DeFi, Any amount

### Risks

- Trusted setup: Transparent setup (sentiment: neutral). Transparent setup: No trusted setup and no additional setup-related trust assumptions.
- Exit window: None (sentiment: bad). The pool implementation is immediately upgradeable, so users have no delay to withdraw before a malicious upgrade can take effect. This protocol does not pass the walkaway test: users cannot fully use it if all centralized protocol participants disappear. Although the full software stack needed to generate proofs and exit is published and self-hostable, STRK-20 heavily relies on the permissioned Starknet sequencer: it alone verifies client proofs and must include pool transactions, so users cannot exit without its cooperation.
- Privacy: Link privacy. Public observer: Link at risk (sentiment: warning); Chain analyst: Link at risk (sentiment: warning); Network observer: Link at risk (sentiment: warning); Privileged insider: Link exposed (sentiment: bad); Future adversary: Link exposed (sentiment: bad).
- Reproducibility: Reproducible (sentiment: good). The pool contract, TypeScript SDK, discovery service, and proving stack are publicly available and can be run locally, so users can audit what is actually proven and generate the required ZK proofs without revealing private data to a third-party prover.

### About

A privacy pool on Starknet for arbitrary-amount private transfers and DeFi actions, using Cairo execution proofs and auditor-accessible compliance data.

### Links

- Website: https://strk20.starknet.io/
- Docs: https://docs.starknet.io/build/starknet-privacy/overview
- Explorer: https://voyager.online/contract/0x040337b1af3c663e86e333bab5a4b28da8d4652a15a69beee2b677776ffe812a
- Repository: https://github.com/starkware-libs/starknet-privacy, https://github.com/starkware-libs/sequencer/tree/main/crates/starknet_transaction_prover
- Other: https://eprint.iacr.org/2026/474

## Protocol description

STRK-20 is a privacy pool deployed as [a smart contract on starknet](https://voyager.online/contract/0x040337b1af3c663e86e333bab5a4b28da8d4652a15a69beee2b677776ffe812a). It uses a UTXO-style note model: users deposit ERC20 tokens into the pool, create encrypted notes, spend notes by publishing nullifiers, and withdraw to public Starknet addresses.

The pool contract source code was reviewed for this entry. Other parts of the protocol stack are open source in the [starknet-privacy repository](https://github.com/starkware-libs/starknet-privacy) — the Cairo pool contract, TypeScript SDK, discovery service, audit reports, and Lean formal verification — and StarkWare published [instructions to run a local transaction prover](https://github.com/starkware-libs/sequencer/tree/main/crates/starknet_transaction_prover). Users can therefore audit what is actually proven and generate ZK proofs themselves without revealing private data to the proving service run by Starkware, although proving is compute-intensive (a ~48 vCPU / 96 GB machine is recommended).

Note that the proven (L1-verified) Starknet OS only checks that submitted proof facts are well-formed, reference a real recent block, and claim an allowlisted virtual OS program hash — the client's STARK proof itself is verified by the permissioned Starknet sequencer before transaction inclusion and is not re-verified on L2 or L1. As a consequence, the protocol would accept forged withdrawals from the Sequencer as valid.

### Privacy considerations
The protocol supports private transfers, arbitrary amounts, partial withdrawals through private change notes, and DeFi actions through external helper contracts. DeFi integrations use open notes: the pool creates a note whose final amount is filled after an external helper, such as a swap or lending adapter, measures the onchain output.

### Fees
The pool currently charges a flat fee of 6 STRK plus gas for any action that uses the privacy pool, including deposits, swaps, and withdrawals.

### Compliance
The compliance model relies on an 'auditor' public key. Users register an encrypted private viewing key, but all 'private' actions must include auditor-encrypted metadata. Whoever controls the auditor private key can decrypt user metadata offchain from onchain-emitted cyphertexts; this does not grant spending authority, but it can centrally remove any user's privacy, even retroactively.

### Anonymity set
The anonymity set, in the best case, corresponds to the set of all users of the privacy pool. But metadata leaks and the centralized auditor reduce the anonymity set in practice.

## Privacy

**What the protocol promises:** Hides amounts, senders and the link between deposit and withdrawal inside the pool. The first payment to each new contact is public.

On public blockchains like Ethereum, all actions transparent by default. A privacy protocol can at best cut the link between addresses or offer privacy while deposited. The colour says whether a careful user can keep the link, amount or recipient private against that adversary: green yes, yellow only outside supported options or by accepting another leak, red no. Fields marked at risk stay private only under the condition in their note.

### Public observer

Link at risk (sentiment: warning)

**Who:** Everyone with a block explorer and some basic tools. Sees every public onchain event, but does no correlation beyond following links. Examples: A curious counterparty, an employer, a journalist.

Transfers inside are encrypted, but the public part of every transaction lists the recipient address when you open a channel to a new contact, the token and amount of the fee you pay, and the target and calldata of any DeFi action. Deposits and withdrawals show address, token and amount. Submitting from your own wallet names you; a paymaster hides the submitter but shows the fee token and amount.

**Advice:** Submit every pool action through a paymaster and pay its fee in the most common token. Treat the first payment to a new contact, and any DeFi action, as public.

**Inside**

- Sender: private
- Recipient: exposed. Opening a channel writes the recipient address in cleartext; later transfers do not.
- Amount: private
- Asset: at risk. The fee payment names the token; DeFi actions name the target contract.
- Link: private

**Sources**

- [PrivacyPool contract on Voyager](https://voyager.online/contract/0x040337b1af3c663e86e333bab5a4b28da8d4652a15a69beee2b677776ffe812a)
- [Channel opening carries the recipient address](https://github.com/starkware-libs/starknet-privacy/blob/cc0dc408dee41f5658cd528ae59ab0794be2e298/packages/privacy/src/actions.cairo#L329-L334)
- [DeFi actions carry target contract and calldata](https://github.com/starkware-libs/starknet-privacy/blob/cc0dc408dee41f5658cd528ae59ab0794be2e298/packages/privacy/src/actions.cairo#L360-L365)
- [Deposit and withdrawal events carry address, token and amount](https://github.com/starkware-libs/starknet-privacy/blob/cc0dc408dee41f5658cd528ae59ab0794be2e298/packages/privacy/src/events.cairo#L17-L41)
- [Paymaster fee fixes the visible fee token](https://github.com/starkware-libs/starknet-privacy/blob/cc0dc408dee41f5658cd528ae59ab0794be2e298/sdk/src/interfaces.ts#L160-L172)
- [Protocol fee is pulled in STRK from the submitter](https://github.com/starkware-libs/starknet-privacy/blob/cc0dc408dee41f5658cd528ae59ab0794be2e298/packages/privacy/src/privacy.cairo#L845-L856)
- [Without a paymaster the client submits from the user wallet](https://github.com/starkware-libs/starknet-privacy/blob/cc0dc408dee41f5658cd528ae59ab0794be2e298/demo/src/hooks/useTransactionBuilder.ts#L247-L256)

### Chain analyst

Link at risk (sentiment: warning)

**Who:** Scrapes all public data and correlates it: timing, amounts, gas and wallet fingerprints, address clusters. Examples: Chain analytics firms, ZachXBT, data brokers.

The set of registered users is small and split further by token and by fee token. A channel opened in the same transaction as a deposit ties the two together, and most withdrawal addresses have also deposited. Paying gas from your own wallet instead of a paymaster exposes that wallet's fingerprint, its account implementation and fee habits, even from a fresh address.

**Advice:** Open channels in a transaction without a deposit, pay fees in the most common token, and withdraw uneven amounts that match no deposit. Wait before exiting and pick a different time of day than the deposit. Exit to a fresh address every time and spend from it with a different wallet than the one that deposited.

**Inside, compared with a public observer**

- Sender: at risk. A channel opened in the same transaction as a deposit names the depositor.
- Recipient: exposed
- Asset: at risk
- Link: at risk. Most withdrawal addresses have also deposited, which pairs the two ends.

**Sources**

- [PrivacyPool contract on Voyager](https://voyager.online/contract/0x040337b1af3c663e86e333bab5a4b28da8d4652a15a69beee2b677776ffe812a)
- [Deposit and withdrawal events carry address, token and amount](https://github.com/starkware-libs/starknet-privacy/blob/cc0dc408dee41f5658cd528ae59ab0794be2e298/packages/privacy/src/events.cairo#L17-L41)
- [Fee is charged per action in a visible token](https://github.com/starkware-libs/starknet-privacy/blob/cc0dc408dee41f5658cd528ae59ab0794be2e298/packages/privacy/src/privacy.cairo#L845-L856)

### Network observer

Link at risk (sentiment: warning)

**Who:** Sits between the user and the chain and sees web2 traffic only: RPC providers, relayers and broadcasters, indexers, ISPs. Learns IP addresses, timing, browser fingerprints, ciphertext and what becomes public. Assumes Tor to send transactions and, where the client has an RPC setting, an own node to read the blockchain. Examples: Infura or Alchemy, a Tornado relayer, a wallet vendor selling telemetry, Google captcha or analytics in the dapp frontend.

The paymaster and the sequencer receive the client proof with every action. Stwo proofs are not zero-knowledge by default, and how much of the private execution they reveal is not established. Traffic to the proving and note-discovery services is encrypted, and both support an oblivious relay that hides your address, but it is off unless the client turns it on.

**Advice:** Turn on the oblivious relay for the proving and discovery services, or run both yourself.

**Inside, compared with a public observer**

- Sender: unverifiable
- Recipient: unverifiable
- Amount: unverifiable
- Asset: at risk
- Link: unverifiable

**Sources**

- [Oblivious relay support is opt-in](https://github.com/starkware-libs/starknet-privacy/blob/cc0dc408dee41f5658cd528ae59ab0794be2e298/sdk/src/internal/ohttp-client.ts#L24-L32)
- [Discovery service: per-request keys and oblivious relay](https://github.com/starkware-libs/starknet-privacy/blob/cc0dc408dee41f5658cd528ae59ab0794be2e298/crates/discovery-service/README.md#L14-L32)
- [Proof and proof facts travel in the submitted transaction](https://github.com/starkware-libs/starknet-privacy/blob/cc0dc408dee41f5658cd528ae59ab0794be2e298/demo/src/hooks/useTransactions.ts#L140-L160)
- [Stwo Cairo is not zero-knowledge by default](https://github.com/starkware-libs/stwo-cairo/blob/2b1fb4ded5496fb2db4e8261cd5ee5ef6b710839/README.md#security-model)

### Privileged insider

Link exposed (sentiment: bad)

**Who:** Holds a protocol operator role or receives keys or plaintext by design: upgrade admin, sequencer, decryption or view key holder, TEE vendor, association set provider, hosted prover, note registry. Examples: A compliance backdoor key, a DAO with an upgrade key, a KMS committee, an ASP operator.

Every user's viewing key is escrowed onchain, encrypted to one auditor key that a role holder can replace at any time with no delay; that key decrypts everything the protocol hides. The default proving service receives your address, viewing key and actions in the clear, the note-discovery service receives the viewing key on every sync, and deposits need a fresh attestation from a screening provider that sees and can block every depositor.

**Advice:** Run the prover and note discovery yourself, or read the pool directly from chain. Nothing you do removes the auditor key.

**Inside, compared with a public observer**

- Sender: exposed
- Recipient: exposed
- Amount: exposed
- Asset: exposed
- Link: exposed

**Sources**

- [Auditor and screener keys in pool storage](https://voyager.online/contract/0x040337b1af3c663e86e333bab5a4b28da8d4652a15a69beee2b677776ffe812a)
- [Viewing key escrowed to the auditor key onchain](https://github.com/starkware-libs/starknet-privacy/blob/cc0dc408dee41f5658cd528ae59ab0794be2e298/packages/privacy/src/events.cairo#L5-L13)
- [Auditor and screener keys are settable roles](https://github.com/starkware-libs/starknet-privacy/blob/cc0dc408dee41f5658cd528ae59ab0794be2e298/packages/privacy/src/events.cairo#L43-L52)
- [Withdrawals carry the auditor-decryptable withdrawer address](https://github.com/starkware-libs/starknet-privacy/blob/cc0dc408dee41f5658cd528ae59ab0794be2e298/packages/privacy/src/events.cairo#L17-L29)
- [Proving request carries the user address and viewing key](https://github.com/starkware-libs/starknet-privacy/blob/cc0dc408dee41f5658cd528ae59ab0794be2e298/sdk/src/internal/proof-invocation-factory.ts#L128-L136)
- [Discovery request carries the viewing key](https://github.com/starkware-libs/starknet-privacy/blob/cc0dc408dee41f5658cd528ae59ab0794be2e298/sdk/src/internal/indexer-discovery.ts#L158-L165)
- [Deposits require a signed screening attestation](https://github.com/starkware-libs/starknet-privacy/blob/cc0dc408dee41f5658cd528ae59ab0794be2e298/packages/privacy/src/privacy.cairo#L784-L800)
- [Screening sidecar forwards the depositor to an external provider](https://github.com/starkware-libs/starknet-privacy/blob/cc0dc408dee41f5658cd528ae59ab0794be2e298/proof-interceptor/README.md#L37)
- [Upgrades & Governance](https://l2beat.com/privacy/projects/strk20#upgrades-and-governance)

### Future adversary

Link exposed (sentiment: bad)

**Who:** Harvest now, decrypt later. Holds every byte ever written onchain plus any retained logs, and future cryptanalysis such as a large quantum computer that breaks elliptic-curve key exchange and pairings, but not hashes, symmetric ciphers or lattices. Examples: First well-funded insiders, then everyone in a potential post-quantum future.

The proofs are post-quantum, the encryption is not. Channel keys, note contents and the auditor escrow use elliptic-curve key exchange, and the auditor public key sits onchain. A quantum computer recovers that one key and with it every escrowed viewing key, and so the whole history.

**Inside, compared with a public observer**

- Sender: exposed
- Recipient: exposed
- Amount: exposed
- Asset: exposed
- Link: exposed

**Sources**

- [Stark-curve ECDH encryption of channel and note data](https://github.com/starkware-libs/starknet-privacy/blob/cc0dc408dee41f5658cd528ae59ab0794be2e298/sdk/src/utils/encryptions.ts#L120-L136)
- [Viewing key escrowed under the onchain auditor public key](https://github.com/starkware-libs/starknet-privacy/blob/cc0dc408dee41f5658cd528ae59ab0794be2e298/packages/privacy/src/events.cairo#L5-L13)
- [Auditor public key in pool storage](https://voyager.online/contract/0x040337b1af3c663e86e333bab5a4b28da8d4652a15a69beee2b677776ffe812a)

## Value Locked

The interactive value chart is shown on [the HTML page](https://l2beat.com/privacy/projects/strk20#privacy-tvl).

## Flows

The interactive flows chart is shown on [the HTML page](https://l2beat.com/privacy/projects/strk20#privacy-flows).

## Assets Breakdown

| Asset | Deposits 7D | Deposits 30D | Deposits Total | Value Locked |
| --- | --- | --- | --- | --- |
| XSTRK | 0 ($0.00) | 3 ($50.33 K) | 14 ($66.61 K) | $468.67 K |
| USDC | 66 ($15.72 K) | 194 ($65.48 K) | 6.25 K ($838.18 K) | $208.11 K |
| STRK | 60 ($62.99 K) | 414 ($131.35 K) | 9.11 K ($1.28 M) | $159.68 K |
| ETH | 7 ($234.14) | 34 ($13.08 K) | 201 ($195.23 K) | $52.78 K |
| WBTC | 2 ($10.75) | 7 ($8.72 K) | 75 ($77.07 K) | $30.39 K |
| strkBTC | 50 ($229.32) | 108 ($35.14 K) | 1.36 K ($456.89 K) | $21.79 K |
| USDT | 0 ($0.00) | 0 ($0.00) | 10 ($15.14 K) | $10.31 K |
| Total | 185 ($79.19 K) | 760 ($304.14 K) | 17.03 K ($2.93 M) | $951.76 K |

## Risk summary

### Funds can be stolen if
1. the proof system or virtual Starknet execution model is broken or backdoored, allowing invalid server actions to be applied.
2. the Starknet sequencer includes a transaction with fabricated proof facts.
3. the escrow smart contract is maliciously upgraded (no delay).
4. an external DeFi helper or target protocol invoked by the user mishandles assets.

### Funds can be lost if
1. a user loses the Starknet account key or private viewing key required to spend their notes.
2. the pool is paused or upgraded in a way that prevents users from applying valid actions.

### Privacy can be lost if
1. the auditor private key holder decrypts registered users' viewing keys or withdrawal and metadata.
2. a third-party-hosted prover or note discovery service leaks user secrets or metadata (both can be self-hosted).
3. deposits, withdrawals, open-note fills, timing, unique amounts, or DeFi helper calldata make a user's activity linkable.

## Upgrades & Governance

The pool uses StarkWare-style role components and an instantly upgradeable smart contract implementation.

- `APP_GOVERNOR` can set the fee amount, fee collector, and proof validity window.
- `GOVERNANCE_ADMIN` can grant governance and upgrade-governor roles.
- `SECURITY_ADMIN` can grant pause, unpause, and auditor-key administration roles.
- `SECURITY_AGENT` can pause the pool, if granted.
- `SECURITY_GOVERNOR` can unpause the pool and change the auditor public key, if granted.
- `UPGRADE_GOVERNOR` can approve and execute upgrades, if granted.
- `UPGRADE_AGENT` can execute approved upgrades, if granted.

The live role holders observed were:

- `APP_GOVERNOR`: `0x2796da10aba2e1f445c38eba07e5a4393d6dab30d203d3432deb824e891619a` (2/4 Multisig)
- `GOVERNANCE_ADMIN`: `0x3103066e6c7037ba947ea9a7b5b8d110ae7f3d631fa5849435d0dc1fc5ef785` (EOA)
- `GOVERNANCE_ADMIN` and `SECURITY_ADMIN`: `0x663cc699d9c51b7d4d434e06f5982692167546ce525d9155edb476ac9a117d6` (7/12 Multisig)

## Trusted setup

Risk levels follow the [Trusted Setups Risk Framework](https://forum.l2beat.com/t/the-trusted-setups-framework-for-zk-catalog/381). Yellow (medium risk): all contributions are published and the final output can be verified, the ceremony client is open source, there were at least 30 contributions, participation was open to the public and announced, and participants are publicly identified. Green (lowest risk): everything required for yellow, with at least 150 contributions. Red (highest risk): at least one requirement for yellow is not met. N/A: the proof system needs no trusted setup.

### Transparent setup

- Risk: N/A (no trusted setup)
- Proof systems: Stwo (STARK)

Transparent proving systems require no trusted setups and have no additional setup-related trust assumptions.